信息系统，用户主导的时代来临了！

[信息系统上“路”三部曲]之一

信息系统，用户主导的时代来临了！

没有“银弹”

没有任何一种单纯的技术或管理上的进步，能够独立地承诺在十年内大幅度地提高软件的生产率、可靠性和简洁性。
——弗雷德里克.布鲁克斯
这是布鲁克斯在1986年发表的经典文章《没有银弹》中的断言。该文一发表，在业界引起轩然大波，遭到许多软件专家的讨论与质疑。
在反对布鲁克斯观点的专家中，库克斯和布鲁克斯的论战最引人瞩目，库克斯认为“重用和交互的构件开发是解决软件根本困难的一种方法”，但布鲁克斯认为库克斯在两点上误解了他的本意。
首先，库克斯断定软件困难来自“编程人员缺乏构建当今软件的技术”。而布鲁克斯则认为根本困难是固有的概念复杂性，作为本质上的困难，构思软件概念性的结构本身就有复杂性、一致性、可变性及不可见性的特点。无论是任何时间，使用任何方法设计和实现软件的功能，它都存在。
二十年以来，尽管软件专家们努力研究新方法来解决软件的困难，但是布鲁克斯认为这些方法，包括高阶语言、OOP 、AI等皆舍本逐末，只解决了一些概念的表达技巧而已，无法解决根本性的概念结构问题。 由于没办法解决这种根本性的困难，使得原本单纯可爱的软件，逐渐演变为进度落后、成本暴涨、错误丛生问题的集合体，像恶梦中的狼群般蜂踊而至，于是哀号而希望有种“银弹”能即刻平息它们。然而布鲁克斯认为:“不仅眼前找不到‘银弹’，由于软件的本质使然，未来也不太可能找得到。”
二十年来是否存在“银弹”的争论一直没有结束过，各种观点相继出现，直到今天也没有得出一个最终的结论。

面向构件开发是“银弹”吗?

面向构件开发是九十年代提出的一种软件开发新范型，它是在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。由于以分布式对象为基础的构件实现技术日趋成熟，它已经成为现今软件复用实践的研究热点，被认为是最具潜力的软件工程发展方向之一，是解决软件问题的“银弹”。
面向构件开发概念的提出虽然有一段时间了，却很难实现产业化。如果仔细思考一下，事情恐怕没有想象的那么乐观。
首先，面向构件开发并不能解决软件开发的根本困难：
1． 软件系统的主要难度就在于概念和整体结构的合理性，先要有整体结构的设计，才有构件，构件是由整体结构决定的，而不是反过来。构件丝毫没有减少概念和整体设计的难度，反而可能会增加难度。
2． 由于企业的需求不断变化，软件的结构也需要跟着改变，由于变化的粒度有大有小，构件本身也很可能需要改变，一个构件的改变很可能导致其它与之相关的构件的改变，而构件的开发、组装和调试都是需要时间的，所以很难跟上快速的变化。
3． 开发一个软件系统时，在用户需求与软件实现（构件）之间存在着一个很大的鸿沟。用户需求的准确表达和组织，以及如何正确地转化成软件的功能实现，都存在很大的困难。构件开发并不能解决这个问题。
4． 用户希望复用的是业务，而不是构件，这一点构件化的方法做不到。
其次，关于构件的产业化，我们认为，作为信息时代的软件生产，自有其自身的特点，把它与工业时代的大规模生产方式简单类比，认为软件产业也会复制工业时代的生产方式是不切实际的，理由是：
1． 标准化问题，现在软件产业的标准基本都是底层技术级别的标准，如通信、组件、数据库访问等，高级应用层的构件标准能否制定出来，由谁来制定，是个很大的问题。目前关于软件构件的标准远未出台，如果各构件平台厂商推出的构件互不兼容，不能够实现复用，将又造成资源浪费。
2． 可靠性问题，机器（如汽车）的性能是由少数几个主要零部件（如发动机）决定的，而软件系统则要复杂得多，将很多符合“标准”的构件组装起来，是否就能组成整体上满足要求的软件系统，实在是个问题。
3． 经济问题，构件组装的可靠性问题即使能找到解决办法，其耗费的时间和成本必定是惊人的，很可能得不偿失，完全有违当初构件产业化的初衷。
4． 应对变化的问题，一个构件的改变很可能导致其它与之相关的构件的改变，如果由于需求的变化而需要新的构件，是向构件的供应商求助，还是自己解决？时间来得及吗？
5． 商业模式问题，对于构件的生产者来说，构件的开发成本基本是由第一个合格的版本决定的，后面的复制基本不需要成本，所以，最大的风险在于，花费巨大成本开发的构件能卖多少份拷贝？如果只能卖少数几份拷贝，则肯定亏本，而这是事前很难预计的。对于构件的购买者来说，也面对类似的问题，即购买多少份同样的构件？如果购买大量的拷贝，这比自己开发更合算吗？所以，无论是构件的生产者，还是构件的消费者，都面临很多不确定的问题，很难下决心走上这一条路。
在可以想象的将来，这些问题尚看不到解决的希望，构件的产业化不太可能成为现实。
这种基于“标准化构件”开发软件的思想，实际上是照般工业时代大规模工业化生产的思想，把软件当作机器生产。然而一台机器执行的是设计好的简单任务，一旦出厂后不需要什么变化，而现在企业管理软件面对的是快速变化的环境，需要的是随需应变。在当代企业面对高度不确定性的环境情况下，“标准化构件”开发已很难适用。

当前的信息系统架构

当今典型的信息系统架构如下图：





图1当前信息系统架构

我们看到，当前信息系统架构的特点是：
l 各个应用单独开发，各自为政，其数据库也单独设计，形成一个个信息孤岛。
l 开发各个应用所采用的理念、方法、技术不一样，没有考虑应用间流程的集成和交互，没有统一的接口。
l 每个应用都有自己的用户管理和安全控制机制，没有统一的门户 。
l 缺少全面的管理控制功能。
l 应用的业务逻辑大都是硬编码程序，应变能力差。

基于以上架构的信息系统必然存在以下缺陷：
l 每个应用各自为政，形成一个个信息孤岛，应用和业务流程的无缝集成很难实现。
l 系统结构和功能僵化，应变能力差，无法快速应对变化，需要不断投入人力物力进行系统改造和升级，甚至推倒重来。
l 缺少帮助业务人员进行业务创新和管理创新的技术手段。
l 缺乏统一的系统门户，业务人员疲于应付，工作效率低下。
l 随着应用的增多，管理的复杂度增加，管理和安全存在失控的危险。
为什么会出现这么多各自为政的应用系统呢？这是历史原因造成的，当初人们开发应用系统时，受到用户需求、开发理念、方法和技术等方面的限制。
首先，需求方面，当初企业的信息化要求远不如现在的高，企业一般只对少数关键的应用提出了信息化的要求。
其次，开发理念方面，因为用户的需求不高，所以软件提供商实现每个应用时也只考虑其本身，而没有考虑与别的应用的集成，更没有思考整个企业的信息化如何实现。
最后，技术方面的限制，当时的应用系统业务逻辑都是用硬编码实现的，这使我们不可能同时考虑和实现所有的业务应用，那太复杂了，只能一个一个的实现。
软件技术发展到今天，已经经历了半个多世纪。从程序语言和技术发展看，经历了从汇编语言，到过程语言，到面向对象语言和动态语言，再到现在的面向构件的开发。从软件架构的发展看，经历了从主机终端架构，到客户机服务器架构，到以中间件为基础的三层和多层架构，再到现在的面向服务的体系架构（SOA）。软件的复杂度与日俱增，但在软件开发的效率和满足快速变化的需求方面却还是显得力不从心。
对现在的企业用户来说，他们迫切需要用最好的方法，把这些不同的应用、技术、端点进行集成，从而为企业的业务提供最高效的支持。
由于目前的应用系统是由不同的IT供应商在不同的时期、用不同的理念和技术开发的，编程语言可能采用C、RPG、COBOL、C++、VB、J***A、C#等，服务器端可能采用Java EE、.NET、CORBA等，中间件还可能包括BEA的Tuxedo、IBM的WebSphere，甚至还要在大型机上安装包括SAP、Oracle在内的套装软件解决方案。这样复杂的IT系统分布在企业IT系统的不同角落。这些应用就象人类社会早期分布在各地的一个个不同的民族国家，语言不同，文化不同，价值观不同，社会制度不同，法律不同，货币不同，度量衡也不同，它们之间的交往必定会遇到许许多多的障碍，交易成本会很高，而效率极低。显然，要在这些应用之间实现无缝集成，不是一件容易的事情！
为了解决软件开发和应用集成的问题，软件厂商逐渐推出了各种技术和平台。下面简要分析一下当今流行的几类技术及其发展前景。

未来的软件架构—SOA

面向服务的架构（Service-Oriented Architecture，SOA）是近年来提出的最新IT架构概念，它是基于标准的、松散耦合的面向服务的架构。
当今的企业处于快速变化的环境中，信息系统必须提供必要的技术来满足企业发展、法规遵从等要求，并提供更广泛的服务。但是，在目前的软件架构下，IT团队始终处于被动状态，面临的挑战日益严峻，在满足不断变化的业务需求与不能实现随需应变的IT系统之间，存在着越来越大的差距。
企业IT系统当前面临的问题是，没有针对它的一套架构方法，产品孤岛之间的数据使用不一致，无法实现客户的单一视图。渠道集成或“客户接触点”集成可能引起包括高度的复杂性、高昂的成本，缺乏足够的灵活性及可扩展性等诸多问题。
就IT而言，SOA是一种分布式计算方法，它能够将复杂、异构的IT系统抽象为复合的、面向业务的服务。这种观点认为，业务应用的根本是“服务交付”，各种应用被描述为细化的服务，以实现模块化并重复利用，以降低IT成本并提高资源效率。
基于Web服务的SOA架构与过去不同的特点就在于它们是基于标准以及松散耦合的。广泛接受的标准（如XML和SOAP）提供了在各不同厂商解决方案之间的交互性。而松散耦合将分布计算中的参与者隔离开来，交互两边某一方的改动并不会影响到另一方。这两者的结合意味着公司可以实现某些Web services而不用对使用这些Web services的客户端的知识有任何了解。
SOA的强大和灵活性将给企业带来巨大的好处。如果某组织将其IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值，那么，这些服务的顾客（可能在公司内部，也可能是公司的某个业务伙伴）就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。
SOA不仅仅局限于技术，SOA的实现过程中还涉及到人员和流程等方面。事实上，SOA，或者更宽泛的概念，服务导向（Service-Oriented, SO），本身就不仅仅着眼于IT，而是针对整个企业。SOA包括人、流程和技术，它是一种通过把功能描述为服务来管理上述所有企业资源的方法，其中企业用户可以根据业务需求来构建流程。
SOA必将成为未来流行的软件架构。

Java EE，力不从心

“Java Enterprise Edition” （Java EE）是1990年代由Sun公司提出来的。Java EE是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。
Java EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循Java EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，导致企业内部或外部难以互通的窘境。
对于开发人员而言，只需要专注于各种应用系统的商业逻辑与架构设计，至于底层繁琐的程序撰写工作，可搭配不同的开发平台，以让应用系统的开发与部署效率大幅提升。
Java EE的核心规范是 Enterprise Java Beans（EJBs），它是Java EE的核心之一，主要用于服务器端的商业逻辑的实现。EJB规范定义了一个开发和部署分布式商业逻辑的框架，以简化企业级应用的开发，使其较容易地具备可伸缩性、可移植性、分布式事务处理、多用户和安全性等。
Java EE将组成一个完整企业级应用的不同部分纳入不同的容器(Container)，每个容器中都包含若干组件(这些组件是需要部署在相应容器中的)，同时各种组件都能使用各种Java EE Service/API。Java EE容器还包括：Web容器，Applet容器，Application Client容器。
在Java EE提出后8年的演化中，Java EE发生的最大变化可能就在于它放弃了对“分布式对象模型”的强调。EJB2.0引入的本地接口使得Web层与EJB层可以运行在同一个Java虚拟机中，从而使Web容器与EJB容器的物理分离部署变成一种昂贵的冗余；Java EE 1.4以后版本支持的Web Services兼容性，使得客户端可以通过粗粒度的Web接口调用远程服务——这两次变化事实上都是在论证“分布式对象架构”的无用性。
值得注意的是，近年来，还有一股更强劲的离心潮流在深刻地影响着Java EE的演进，它肇始于上文提到的开源软件运动。最初它只在Rickard Oberg的动态代理RMI设计与JBoss服务器的微内核架构中显露过邪恶的一角，但是近两三年来，经过多个项目、各种技术杂志/论坛/Blog的折射和放大，它已经形成一个名为“轻量级容器架构”的完整解决方案，并暴露出完全取代传统EJB架构的野心。
按照这一运动信徒们的说法，Java EE的发展史上只出现过一个错误——不幸的是，这个错误名叫EJB。与EJB提供的重量级架构不同，借助AOP和IoC机制，轻量级容器能够最大程度地降低代码对于专用接口的依赖性，以简短、轻便、专注、可移植的方式实现业务对象。
从“轻量级容器架构”这个词被发明出来的那一刻起，人们对Java EE远景的考虑就发生了根本性的分裂：Sun和大部分主流厂商更多地关注于“Web Services”和“快速开发工具”这些利润增长点，而一部分离经叛道的独立专家和开发者则认为，如果不把轻量级容器纳入规划，Java EE的发展蓝图就注定无足称道。
其实，双方争执的关键是传统意义上的“应用服务器”的存亡——如果所有企业级服务都可以通过AOP机制提供给普通Java对象，如果管理业务对象生命周期的可以是一个最微不足道的“微内核”，那么深盔重铠的应用服务器还有什么存在理由？
而如果失去了应用服务器的这个产品类型，那些靠这项销售起家的厂商又将何以自处？正是在这里，两个阵营之间存在着最深刻的利益分歧；而这场争执的结局当然也将决定Java EE（乃至Java企业开发）的最终走向。
07年7月初,SUN公司宣布加入SCA/SDO国际构件标准组织，标志着Java EE将在未来五年内逐渐退出‘解决客户关键问题的主流技术’的地位。也随着SUN加入SCA/SDO组织的这一刻，Java EE的客户价值领导地位大势已去，Java EE应用服务器将进入低价值和同质化的时代。SUN公司加入这一组织，正说明了两点：一就是在激烈的思想斗争中，加入代表了承认领导地位的失去；二就是将逐步放弃自己的JBI。
由于Java EE在市场上的努力有了一段时间，在新一代(SCA/SDO/BPEL)技术还没有成型前，他们还在扮演着‘解决客户关键问题的主流技术’的角色，可是近几年来越来越显出力不从心。直接导致一大堆五花八门技术的出现来弥补其不足：Spring, Struts, Hibernate, AOP......。这些属于2.5G的技术在一段时间内解决了一些问题，不过也在带来更多的问题(彼此的集成，开源的问题等等)。将来Java EE也许会成为一个企业运营需要的同质化的平台，解决分布式计算的问题，也是一个成熟的平台，就像PC机、操作系统一样，发展缓慢。

SCA，前景难料

虽然面向构件开发的概念提出很多年了，但进展缓慢。于是人们认为，除了构件标准化的问题外，另一个主要原因是，缺乏一个高效、实用的构件平台，即一个以构件为核心的生态系统，包括了构件运行环境、开发环境、应用管理环境、基础性的公共构件库、以及面向构件的方法学和经验论。
于是SCA（Service Component Architecture）被提出来了，SCA即服务组件框架。它是由BEA、IBM、Oracle等知名中间件厂商联合制定的一套符合SOA思想的规范。SCA规范给出了如何创建组件和如何将这些组件装配成一个完整的应用程序的定义。SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。它使开发人员可以将注意力集中在业务逻辑的编写上。
对于企业应用，SCA还提供了关键的一些基础设施，象安全性、事务、可靠调用等，这对于企业应用的开发而言就变得很方便了。SCA是第一项承诺提供一个组合模型以启用服务网络并支持构建下一代面向服务应用程序的技术。
SCA的好处有：
l 使用组件和组合简化SOA实现
l 使用松耦合的组件和参考来支持敏捷特性
l 通过一个综合的调用模型支持事件驱动的行为
l 将开发和集合分开，允许技术不可知的组合
虽然SCA声称它使开发人员可以将注意力集中在业务逻辑的编写上，但SCA是基于组件的，它关注的是如何描述按照各种编程模型和协议编写的组件所组成的程序集。然而，我们不要忘了，组件是属于技术层面的东西，不能把组件等同于业务，用户真正关心的是业务，而不是组件。另外，SCA对组件关系的建模也过于简单，有的实现甚至让组件自动寻找调用关系，这根本无法构建复杂的业务逻辑。在SCA这里，业务与技术之间的鸿沟依然没有被跨越，这显然无法满足用户复杂多变的业务需求。
此外，不同厂商的SCA实现也会有很大的差异，不能直接实现互操作。
另外一个无法回避的至关重要的问题是，如果面向构件开发的前景本身不甚明朗，SCA又能有多大作为呢？

ESB，没有解决主要问题

伴随着应用集成的迫切要求和SOA架构的日益流行，ESB逐渐成为人们谈论的热点。ESB是企业服务总线（Enterprise Service Bus）的简称，是传统中间件技术与XML、Web服务等技术结合的产物。ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态的互连互通。
ESB定义：ESB是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：
· 面向服务的架构 -分布式的应用由可重用的服务组成
· 面向消息的架构 - 应用之间通过ESB发送和接受消息
· 事件驱动的架构 - 应用之间异步地产生和接收消息
用一句较通俗的话来描述它：ESB就是在SOA架构中实现服务间智能化集成与管理的中介。
ESB与SOA的关系：ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。
目前，ESB被认为是解决企业应用集成问题和实现SOA架构的最好方式。
在一些大的IT厂商对ESB的宣传中，认为现在很多大企业里面各部门已经有了非常好的信息系统，但是由于缺乏这些系统之间的沟通，使得这个企业没有办法灵活应变。按照他们的说法，如果用了采ESB，就解决了部门应用的集成问题。
事实真是这样的吗？答案恐怕是否定的。
实际上，现有的应用功能的颗粒度对于处于这样一个快速变化时代的企业来说还是太大了，不足以让部门级应用跟上业务变化。事实上，当今企业中经常发生的信息系统推倒重建事件，很多就是由于应用系统本身不能满足业务需求而导致的。
很显然，各应用系统本身也需要随需应变，也需要SOA化。它们之间的集成也需要更小的颗粒度。
另外，当企业采用ESB进行应用集成时，解决的是应用孤岛的问题，而数据孤岛的问题却依然存在。
所以，ESB虽然在一定程度上解决了应用的集成问题，但没有解决数据孤岛和应用本身的问题。

WfMS，难当大任

在OA方面，由于信息技术的发展和日趋激烈的商业竞争，人们不再满足于独立、零散的办公自动化和应用，而是需要综合的、集成化的解决方案。工作流管理系统（WfMS）作为一种对常规性事务进行管理、集成的技术出现了。
WfMS是一个软件系统，它完成工作流的定义和管理，并按照在系统中预先定义好的工作流逻辑进行工作流实例的执行。
使用WfMS的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和数据库运行在企业内网中。EAI就是通过使用多个专门应用满足新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。
WfMS能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。
工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。
与以往已经被采用的企业 IT 应用系统，例如 MRPII 或 ERP 相比，WfMS是一个相当重要的里程碑。
在传统的软件产品中，系统的设计通常是基于功能分割的，作业项目之间是分裂的。面向对象的技术并不能直接解决这个的问题。从操作上，典型地，我们必须不断地在层次结构的功能表（比如下拉菜单）或对象之间“进进退退”，或者在“神出鬼没”的对象以及相关菜单中捉迷藏。
工作流管理系统是一个真正的“人-机”系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到电脑针对自己列出的“任务清单”，跟踪每一项任务的状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这样，用户的任务分派和任务的完成状态，可以被最大程度地电脑化和受到控制。
使用WfMS能带来以下好处：
1．改进和优化业务流程，提高业务工作效率；
2．实现更好的业务过程控制，提高顾客服务质量；
3．提高业务流程的柔性等。
但目前的工作流管理系统还存在许多的不足：
1．规范还没有成熟，没有标准被大范围采用。各个工作流厂家都声称自己的产品符合WfMC标准，但他们的实现几乎没有共通性。
2．虽然相对于传统的应用软件，工作流的业务建模技术有了很大的提高，但还无法实现复杂的业务流程，只能作为应用系统的补充。
3．现在的业务建模还离不开技术，不懂软件技术的一般用户无法定义，因此项目的实施离不开技术人员，有时需要做大量的客户化编程工作。
4．相对于SOA和WEB服务的发展和用户对应用集成的迫切要求，工作流技术的发展相对缓慢，这直接导致了BPEL等补充技术的出现。
我们看到，目前工作流管理在企业中应用的地方还很有限，大多用在非关键业务（如OA）领域。这不应该是它应有的地位。
近年来提出的协同软件和BPM(Business Process Management)工具，基本是工作流软件的别称或提升，谈不上有本质的进步，也很难进入企业的主流应用。
因此，工作流管理系统如不迅速提升自己的能力，将一直在企业信息系统中担当尴尬的配角。

笨重的IT架构

为了迎合当今的SOA潮流，各软件厂商各显神通，包装推出了各自的SOA平台和产品。
下面是目前占主流地位的面向SOA的IT架构，其它的实现也与之差不多：







图2 当前面向SOA的IT架构

这有点象在建造高楼。
且不论这样的“高楼”是否真能适应迅速变化的环境，光是建造和维护这样的“高楼”，用户的时间、人员和资金投入将是巨大的。
有几个用户能承受这样的代价？
并且，我们看到，在维持各个应用各自为政现状下的应用集成，并没有解决数据孤岛的问题。同时，它还可能引发两个新问题。其一是，IT管理者认为系统最终是可以被整合的，从而无所顾忌地增加新系统。系统数量的增加，意味着整个系统管理复杂程度的提升。另一个问题则是，在增加新系统的过程中，企业在IT方面的投入增大了，而且这种增大是一种“动态”的增大。
所谓“动态”的增大就是指企业针对新系统的投入不是一次性地投入。只要系统存在，人员工资、机房房租、电力费用、软件更新以及硬件维护费用就需要不断地投入。这些成本再加上新建系统给整个系统带来的管理复杂性，就会把企业拖入“IT黑洞”之中。
我们认为，以上的IT架构只是一种治标的方法，SOA的目标是解决应用集成和数据孤岛问题，而现在的做法却是在原有的IT基础上修修补补。对企业来讲，表面上看，“修修补补”似乎保护了原有IT的投资、节约了建设成本，但深入分析，你会发现它可能是得不偿失的做法，并且会将企业引进IT黑洞。因此，从系统思维上来讲，除非因为特殊原因必须保留原有系统，否则，采用这样的方法对企业内部应用系统进行整合，很可能造成弊多利少的后果。
前面提到的SCA、ESB、WfMS、BPM、BPEL等技术和标准，很难说它们的提出是从整体上深思熟虑的结果，一些只是为了应付新出现的问题而提出的，这些标准之间出现了不少混淆、重叠甚至相互竞争的地方。用户要用好这些产品和技术实在是一个巨大的挑战，是一件几乎完成不了的任务。
事实上，SOA概念炒作的成分要大于实际推广。与厂商们情绪高涨相对应，SOA的一些实施案例并没有取得预期的效果，用户对SOA的认可度并不是很高。
SOA确实是好东西，但我们在通往SOA的路上，是否选择了错误的路径？

信息系统建设现状

当前，企业在信息系统的建设上，基本上是由软件厂商在主导，这主要缘于市场供求间的严重不对称。
首先是信息的不对称，由于用户不太了解最新IT技术的进展，基本是软件厂商推什么用户就只能接受什么。
其次是知识的不对称，由于普通用户不太懂IT方面的专业知识，软件厂商说什么用户就只能信什么。
还有就是语言的不对称，本来企业管理有自己的话语系统，但软件厂商使用的是另一套IT话语系统，听得用户云里雾里，很难弄明白管理软件、信息化究竟是什么。
由此，当前企业管理软件的开发和实施过程中存在以下一些通病：
1．百病一方
对一个行业的用户都用一个方子吃药，忽视客户的个性化需求。业务流程的“标准化”被当成通行的“新”思路被广泛接受。实际上，当代企业竞争强调差异化，尽管表面上看来是同一个行业的企业，内部业务管理流程却可能相差很大，实际的核心竞争力会截然不同。企业在行业中的竞争力，可能就取决于那么一点独到的差异。如果管理软件把“非正常”的因素给同化掉，势必带来同质化的企业。
2．削足适履
目前的管理软件实际上太“硬”了，几乎到了在实施中“削足适履”的地步。这可能是管理软件公司热衷于“流程再造”的根本原因。改造企业，使之适应已经编写好的软件，而不管是否符合实际。
3．模块组合。
将管理软件的各个组分“预制”成模块，根据企业支付能力进行“组装”，这实际上是将企业视为积木的简单堆砌。持这种观点的人并不知道整体并不是部分的简单相加，整体含有部分所没有的特质。企业是各个部分有机联系的一个整体，如果抽掉其中的某些部分，其信息还能顺畅流动吗？其整体还能正常运作吗？
并且，系统一旦建设起来，就很难改变，不能在活生生的企业经营管理活动中“学习”。
许多用户虽然已经意识到了以上的问题，但正如某个赌徒所说：“这很可能是个骗局，但它是全城唯一的去处。”
这里不是说，软件厂商都存心要误导用户，他们也有难言的苦衷，因为现今大部分软件厂商开发的软件产品是不能满足客户个性化需求的，要将它们推销给不同的客户，只能这样做了。归根结底，管理软件之所以出现这些问题，还是软件开发的指导思想上有问题。
这种基于“标准化”的管理软件，其指导思想是立足于工业化早期的标准化思想，而实际上我们现在面对的是信息化的时代。时代和对象都不同了，试图重复昨天的故事基本不可能。我们不要指望再做一次福特，不可能像生产T型车那样去大批量、工业化地生产管理软件。我们进入的是信息化时代，是知识经济时代，怎么可能用工业化早期的思路去作管理软件呢？在当代企业面对高度不确定性的环境情况下，标准化已很难适用。
我们必须转变管理软件开发的指导思想。

回归本质

如无必要，勿增实体。
——奥卡姆
公元14世纪，英国的逻辑学家和教士奥卡姆提出：“切勿浪费较多东西去做用较少的东西同样可以做好的事情。”这个原理也可表述为“如无必要，勿增实体”，这就是有名的奥卡姆剃刀定律。
今天，这把闪亮的剃刀又向笨重的软件架构发出了挑战，指出许多东西是有害无益的，我们正在被这些自己制造的麻烦压跨。事实上，我们的软件系统正不断膨胀，层次越来越复杂，技术和工具越来越多，但效率却越来越低。这迫使我们拿起“奥卡姆剃刀”，化繁为简，将复杂的软件系统变简单。为什么要将复杂系统变简单呢？因为复杂容易使人迷失，只有简单化后才利于人们理解和操作。
从根本上看，将复杂问题简单化，就是一针见血地捕捉问题的本质。所谓当局者迷，旁观者清。在繁忙的工作中，IT人员考虑问题容易就事论事，而无法跳出技术的视野看问题。因此，可能最终的问题都并不复杂，但由于没有找到正确的切入点，到最后越搞越乱，谁也解决不了，找不到方向。
我们看到，在过去的时间里，软件方面的进步大都集中在技术层面，而在面向用户的业务建模层面或业务与技术的结合方面却没有什么大的进展。我们一直是在解决IT人自己的技术问题，而不是解决用户的业务问题。
要真正解决用户的业务问题，我们先要思考一下信息系统的本质。
那么，信息系统的本质是什么呢？我认为重要的有以下几点：
1． 信息系统存在目的是为了支持企业的业务，而不是所谓的“标准化”企业的业务。
2． 信息系统的首要要求是要正确反映和记录业务信息，保持信息流与业务流的同步。进一步，按照企业自身的需求，用信息系统来规范、控制和管理业务流程，提高管理效率，让用户专注于业务本身。通过信息系统保存的丰富业务信息，为企业（组织）的决策、经营、管理提供依据。
3． 当环境变化时，信息系统应该能迅速改变以适应变化。
4． 信息系统的实现成本和维护管理成本应尽可能低。
我们不要忘记，信息系统是为业务服务的，而不是反过来。无视和夸大信息系统作用的观点都是不可取的。
人是负熵之源，而软件不是。
老子说，“辅万物之自然而弗敢为”。管理活动是企业经营活动的“附生物”， 管理软件是管理活动的“附生物”，管理软件的附生性决定了其自身处于辅助、工具、平台的地位，它就是处于这样一个地位，不能反客为主。所以，管理软件不能过分的“有为”。
我们要转变心态，为用户做辅助性的工作，不要强为、硬为，不要老想着去再造企业，要做一个支持者，而不是主导者。
我们需要暂时把目光从软件产品移开，投向用户的业务。
企业信息系统的建设，应该从以技术和产品为中心，转变为以业务为中心。
以业务为中心，首先要求我们转变信息系统的业务建模语言，要用用户能懂的语言，而不要用所谓的IT专业语言。
我们需要的是一个健壮的信息系统平台，它是业务人员开始的地方。业务人员不需要实现程序和处理数据，他们需要的是开始组织业务流程。一个良好的信息系统平台，就是要做到这些。拥有良好的业务平台后，在对业务逻辑的实现上，业务人员就能有更大的自由来进行创造和革新。

道仑的“银弹”——ROAD

一切都是任务。
——道仑软件
我们知道，人类的各种行为都由一系列的活动组成。比如，穿衣服可以分解为拿衣服、把衣服套在身上、扣扣子等动作。***一张桌子可以分解为***一个桌面、***四个桌腿、组装成桌子等活动。在企业中，一个定单的处理可以分解为接收定单、作生产计划、采购原材料、组织生产、入库、出货、收款等活动，其中某些活动还可以层层分解为更小的活动。
那么，这些活动有什么共同点吗？或者说，我们可以从这些活动抽象出哪些共同的特性？
首先，所有活动都带有一定的目的和要求，都要有人负责，并有时间的限制，因此带有相应的业务信息和控制信息。
其次，活动还可以分解为更小的活动，或组成更大的活动。
最后，活动与活动之间有一定的关系。
这就是活动的全部属性。
我们要做的，就是如何为各种活动及它们之间的关系建模，然后编写能理解和运行该模型的软件系统。
我们把这种开发方法称之为面向业务开发（Business-Oriented Development，BOD）。
如果把BOD中的业务活动包装成任务，那么任务就是有目的的业务活动，是组成业务逻辑的基本单元。所以，面向业务开发也可以称为面向任务开发（TOD）。
那么，面向业务开发（BOD）与基于构件的开发方法（Component-Based Development，简称CBD）相比有什么优势呢？优势如下：
1． BOD直接反映和表达业务需求，一般用户都可以理解和操作，不需要技术人员的参与，这就消除了业务需求与软件实现之间的鸿沟，能更快更好地满足用户的需求。
2． BOM中的任务比CBD中的构件更“软”和更“轻”。构件是物理上存在的程序代码，需要软件开发人员编程实现，而任务是用户就可以定义的对象，因此更容易改变，改变花费的代价更小，更能适应业务的变化。
3． 业务层的可重用性强。定义好的任务可以很容易地放到别的任务中，就象搭积木一样。
4． 由于BOM不需要沉重的应用服务器和中间件之类的基础结构，因此无论在开发还是运行方面，BOD比CBD需要的环境都简单得多，更容易维护，对用户的要求更低。
5． 用户基于BOD开发信息系统比基于CBD开发所需的成本和费用要小得多。
如果BOD能为所有的业务及其相互关系建模，用户通过BOD就能实现所有的业务逻辑，也就是说，用户根本不需要通过编程来开发一个个独立的应用系统了！
不需要编程就能实现所有的业务逻辑，这就是道仑的“银弹”！
而且，由于各种业务都是基于相同的单元（任务）构建并在同一种平台上运行，它们之间的“集成”将不会有任何障碍，业务流程的集成问题将成为历史。于是那些困扰用户和软件开发人员的所有软件开发和集成问题便烟消云散，不复存在了！
其实让我们静下心来想一想，跨“应用”的业务流程与“应用”内的业务流程有本质的区别吗？没有，只是涵盖的业务范围有所不同而已，而这又是人为设定的！业务流程本来就是一体的，比如一个定单的处理，要经历从接到定单，到作生产计划，到采购原材料，到生产，到出货，到收款，到售后服务等一系列复杂的过程，这些步骤本来应该是有机联系的一个整体，但现在它们被分布到ERP、SCM、CRM、OA等众多分离的应用系统中。而这些应用系统又是由不同的IT供应商在不同的时期、用不同的理念和技术开发的，由此产生了“集成”问题。
道仑公司开发的这种以业务为中心的信息系统平台取名为ROAD。
以业务为中心，这正是ROAD平台的指导思想。

ROAD的设计理念

道法自然

我们人类本身是大自然的产物，让我们先来考察一下大自然生命的奥秘。

生命的组成单元——细胞

细胞
在自然界中，所有生物体都是由细胞构成的，细胞是由膜包围着含有细胞核(拟核)的原生质所组成，是生物体的结构和功能的基本单位，也是生命活动的基本单位。细胞还能够进行分裂和繁殖，是遗传的基本单位，并具有遗传的全能性。各种执行不同功能的细胞汇聚成组织，组织与组织的结合产生器官，器官与器官的结合又产生了各种子系统，各种子系统相互协作，最终形成了有机统一的复杂生物体，再由各种复杂生物体组成了地球上丰富多彩的生命世界。
人脑
在所有生物中，最高级的是人。而人体中最高级的部分是具有高级智能的大脑及神经系统。
人脑是由脑细胞（神经元）构成的一种网络组织，是通过脑细胞之间的信号传导来发挥功能的。显然，脑的基本结构单位非常单纯而明确。
神经元的基本功能是通过接受、整合、传导和输出信息实现信息交换。神经元群通过各个神经元的信息交换，实现脑的分析功能，进而实现样本的交换产出。产出的样本通过联结路径点亮丘觉产生意识。
脑细胞之间的联系
每个成熟的脑细胞有多达二万余条线路与其它的脑细胞有业务联系。这部分细胞为处于工作状态的精英，人类现有的略有难度的工作均由它们来完成。
脑细胞彼此间联络的线路绝大多数在人出生后，受到外界环境的刺激而逐步发展形成的。脑细胞联络线路越多，就越能发挥各细胞彼此之间的分工合作，人就越聪明，智商就越高。
脑细胞之间的如何交流信息
一般人认为，脑细胞密密麻麻地排列着，如电路一般，微弱的电流流过这些脑细胞并传达着大脑的命令。
事实上并非如此，细胞与细胞之间并不直接连结，中间均存在着小小的缝隙。
充当导线作用的是弥散在细胞与细胞之间的荷尔蒙，也叫激素，它们充当着脑内信息的传递者。这种激素分泌于大脑的各个地方，大脑通过它向全身传递指令，于是身体也分泌同样的荷尔蒙，通过这种荷尔蒙接受信息的细胞根据命令采取行动。没有荷尔蒙，人就不会思考、不能行动，人就不会有感觉。
也有人把脑细胞比作一个微小的生物电池，随时准备放电。荷电的元素称为离子，它们在脑细胞内外的数量不等，从而在细胞膜两侧形成微小的电位差。人类脑细胞内部记录到的电位要比外部低70毫伏（以-70mV表示），这种电位称为静息电位，这种细胞膜“外正内负”状态称为极化。
从另一个脑细胞传来的信息改变了静息电位，使其负值改变，到达一个称为阈的水平，引起放电。人类脑细胞的阈约为 -55mV，当达到此值时，脑细胞就产生一种沿轴突传播的电变化，称为动作电位或神经冲动。神经冲动引起递质释放的同时，还伴有电位变化。
脑是由脑细胞（神经元）构成的一种网络组织，是通过脑细胞之间的信号传导来发挥功能的。

生命的复杂性

我们的地球上存在着各种各样的生命：植物、动物、微生物。每种生命都体现了相应的复杂性。
生命复杂性的第一个特征是，生命是一种复合体，不可能由一个成分（一种基因或蛋白质）构成。
生命复杂性的第二个特征——组分之间有着广泛的相互作用。换言之，生命的本质是由组成元素之间的关系所决定，而非组成的物质本身。生命内的这些相互作用不是直线式的，而是交错编织形成的网络。
这种广泛存在的相互作用网络引出了生命复杂性的第三个特征：次序和层次。由于生命中各组成成分有着稳定的相互作用，从而形成了有序的结构，也就是人们常提到的“自组织”。生命自诞生那天起，就是一个与外部环境相对独立的系统，并且通过与外界交流物质和能量维持其有序性。随着生命的逐渐演化，次序发展出了层次：各种生物大分子相互作用并形成了不同的功能区域（细胞器等），这些功能区域组合成细胞，各种执行不同功能的细胞又汇聚成组织，组织与组织的结合又产生器官，最终形成了多细胞的生物体。
生物体的每一个层次都拥有特定的行为或性质。这类行为或性质不存在于构成它的组成成分里，而是由组成成分间的相互作用所形成。
因此，生命复杂性的第四个特征是，整体比它的部分之和更大。研究复杂性系统的科学家把这种现象称为“涌现”（emergence）。生命系统的涌现是属于非线性的，即不能通过简单地叠加构成成分的行为推导出系统的行为。此外，系统组成部分的微小改变常常会被迅速放大并导致系统状态的改变，即所谓的“蝴蝶效应”。这种“整体大于部分之和”和“涌现”性质，是生命诞生及其进化的主要动因，生命通过改变自身以适应变化着的外部环境。这种特性使得地球上形成如此繁多的生物物种，使得人类这样高级的生命形态能够从原始的细菌进化而成。在这个意义上，美国科学家霍兰（J. H. Holland）提出，“适应性造就复杂性”。
因此，生命复杂性的第五个特征是，系统具有开放性，可以在过程中不断地演化。生命不是一种简单的“自稳态”系统——通过负反馈的调节控制来稳定自身的状态，从而适应外界的变化；而是一种远离平衡状态的开放系统——通过不断地形成新性质或新功能来适应外界的挑战或改变。

ROAD的组成单元——任务

ROAD以任务为组成单元为业务建模。任务是一个自包含的对象，既是业务逻辑的组成单元，自身又包含业务逻辑。

ROAD的类生物体特性

对比ROAD中的任务和构成生物体的细胞，我们惊喜地发现，它们有很多相似之处。首先，它们都带有一定的信息，其次，它们都可以分解/分裂为更小的单元，或组成更大的单元，最后，它们都可与其它单元形成一定的关系。
因此，从某种意义上说，ROAD具有与生物体类似的特性。构建在ROAD平台之上的企业信息系统，也就可以象生物体一样具备自组织和自适应能力，并且可以在过程中不断地演化来适应环境的变化。
事实上，ROAD正是将企业看成是一个活的有机体，而这个有机体的组成单元，就是任务。
在ROAD系统中，每个人都可以产生任务。每个任务可以分解为更小的任务，同时又可以是更大的任务的组成部分，任务之间有一定的关系。使用这种方式能够构建非常复杂的信息系统，并能高效利用资源、对内部和外部的扰动保持高度的弹性、适应所处环境的变化。而且在这个系统中，每一个组成部分都有一定程度的自主性，都能够在没有上一层组织的协助下，在其所处的特定层次上掌握环境和处理问题。同时也能接受来自上层整体的指导，在某种意义上受上层整体的控制。自主性保证了部分（小的整体）是稳定的，能够在干扰下生存，而对上层整体的服从又确保了更大的整体的有效运转。

以人为本

信息系统以人为本。
企业是由各种各样的人组成的，每家企业和每个知识工作者都有独特的个性，企业的信息系统只有承认和保持这种独特性，才有可能提升而不是扼杀其核心能力，才有利于提升知识工作者的工作效率，让知识工作者能够更加快乐的工作而不是剥夺他们的尊严。其次，要认识到每个企业和企业中的每个部门、每个知识工作者都是整个产业社会的一部分，需要与其他人、其他部门、其他企业有效的联系和协同工作，而信息化系统应该是增强这种有机联系的重要载体。
然而，这两个互补的因素都被标准化的套装管理软件所忽略了。当前的管理软件，一方面抹杀了知识工作者的个性，限制了他们能力的自由发挥，另一方面，这些软件始终只关注“标准化”的工作流程，没有给知识工作者之间进行交流、碰撞提供有效的人性化的空间。这些软件是冷冰冰的，利用这种软件来工作让人感到孤独、缺乏友谊，不能让人感觉到自己是其中的一部分。因此，用这种管理软件不可能建造出让知识工作者感觉舒适惬意、方便快捷、与他们的日常工作相匹配的信息化系统。知识工作者不得不使用这种名义上是“为”他们建造的信息化系统，然而对于这个他们要每日每时要在此工作的系统却不能进行任何最基本的、令人感到愉悦的设计和改进。
我们必须找到一种企业信息化建造机制，能够照顾到管理活动的各种要素，只有满足了这些要素，才能把每个企业的信息系统建设得“恰到好处”，使信息系统能够准确地适应企业、部门、知识工作者的需要，同时能够发挥自己的核心能力。
ROAD的出现，提供了一个平台，让我们可以在企业信息化中开始尊重每位知识工作者，让知识工作者的创新思维有充分发挥的空间，并体现知识工作者的价值取向、工作习惯乃至感情因素，让我们所建立的信息系统能充分体现管理和知识的真正价值，让知识工作者为在这种信息系统支持下工作而感到骄傲和幸福，让企业信息系统中跳动着知识工作者的生命活力，让他们感觉到的这就是他们“自己的”系统，是他们的有生命的大脑的一个有机组成部分，而不再是一个冷冰冰的体现着“异己力量”的系统。
基于ROAD建立的企业信息系统，将满足知识工作者的各种需要，体现他们的真正价值，让他们从重复、单调、低效和紧张的管理工作中解放出来，从事更富有创造性的工作，并享受全新的生活。

用户主导的时代来临了

ROAD平台的提出，将给信息系统的建设带来革命性的变化。
原来企业先开发或购买互相分离的各种应用系统，再企图用各种中间件将它们的功能集成起来。用这种方式建立起来的信息系统必然难以实现应用间无缝的集成，不能满足企业的各种业务和管理需求，更无法应对未来的变化。各个应用系统的维护和升级严重依赖开发商，随着应用的不断增多，系统的维护和升级也将变得越来越困难，有时甚至推倒重来，造成投资的极大浪费。
有了ROAD平台后，企业先进行全局范围内的业务规划和设计（主要包括业务逻辑、数据库和WEB服务），然后直接从业务出发来构建信息系统。
由于在ROAD系统中，采用普通用户都可以明白的方式为业务建模，不需要技术人员的参与，所有人都使用共同的建模单元——任务。每个人都可以为自己负责的那部分业务建模，而且可以立即投入运行。每个人既是系统的使用者，同时又是系统的建设者。
这样一来，信息系统的建设就完全由用户自己掌控，实现用户想要的任何业务逻辑。这样建立的信息系统一定能够满足企业的需求，更能适应未来的变化，真正成为随需应变的信息系统。
如果再加上管理功能，这样的信息系统就将成为企业的数字神经系统！
欲知企业的数字神经系统如何建设，请看下一篇——《基于ROAD的数字神经系统建设》。

(版权所有，转载必须经过允许）