实际上我觉得做任何事情，本人都有一些规律。比如说你的老板，交给你一个任务去做，或者你自己制定一个目标去实现，都要考虑两方面的问题。第一，你要制定一个切实可行，合理的目标。第二，就要有一系列计划完成你的目标，SOA也是一样的。我在过去的三年里边，就参与了14个SOA的项目，就是全球的，我们发现对于企业SOA实现，就是成功最重要的两个因素，第一，它是不是可以去参考的架构，第二，它是不是有一个切实可行的路线，这两方面是最重要的。

    今天我的演讲，大概分成三个部分。第一个部分，我想跟大家探讨一下，就是为什么企业SOA参考架构，对SOA的成功是至关重要的。第二部分，我想跟大家介绍一下，第一所认可的，包括我们所推荐的参考架构是什么样的。第三部分，我想跟在座各位探讨一下，我们如何制定一个符合企业需求的SOA的路线。BEA实施的项目当中，我们总结经验教训，发现有很多模式可以去借鉴。首先在实施SOA项目方面，有三个领域，三个层面的问题，我们必须考虑。

    第一个，如何去制定符合整个企业需求的IT基础架构，以及IT的蓝本，这是比较关键的一步。另外，往往在三年前，我记得那时候上了很多跟SOA类似的项目，企业应用集成，基于SAP，我在国内也参加了四五个这样的项目，那时候大家很模糊，但是有几个咨询公司进来，告诉大家要有一个完整的规划。但是在后面实施的过程中，没有明确提出一个专一的方法论支持它，根据BEA的经验，这部分也是非常重要的。

    第三个，基于这两个目标基础上，我们怎么样迈出业务的需求。怎么达到一个业务的目标，也是我们要去考虑的问题。今天由于时间限制，我们关注第一个层面的问题，如何制定企业SOA的参考架构，以及这个路线图。在讨论具体的企业SOA架构之前，我想跟大家先澄清一个概念，企业级的SOA架构规划和应用的架构设计，它是不是同样的概念，根据我们的经验，这完全是两个不从的概念。可以举一个不是特别妥当的例子，企业SOA架构规划，就是城市具体建筑设计一样。
因为我们知道，一个城市在设计总体规划的时候，就考虑很多城市的定位，包括人文环境，它的文化背景、政治色彩等等，要站在一个很高的层面考虑问题。设计企业基于SOA架构，这个过程也是一样的。我们首先要站在企业级的高度，甚至要超脱某一个具体的项目，超脱于自己部门的层面，去考虑为整个企业，是不是可以有一些可重用的组件，所以就要从很高的层面考虑的问题。

    在三年前，基本上不管国内还是国外，基本上都没有这个技术，首先IT部门，基本上还是属于重组地位。往往这种很高层面的项目，需要公司的决策层，这几年我比较欣喜，这几年我做了很多的项目，发现中国CIO，确实在企业里面起到绝对的作用，所以在现在才有SOA项目的基础。

    具体到应用的设计里面，就有一点涉及到建筑物，比如我设计一个国家大剧院，关注一定时间、人力、成本的情况下，如何保证质量。也许这个建筑很漂亮，但是它跟整个城市的规划，是格格不入的，甚至不会考虑到社会的因素，绿化，城市交通等等。所以我举这个例子，就说明企业SOA架构设计，跟具体的应用，项目里面的架构完全不同。坦率的说，针对国内项目里边，大家还是在摸索的过程，基本上没有可借鉴的因素，因为大家以前就是在做项目，具体的做CRM，我做一个OA，做客户服务端的系统，做一个业务部门，一个单元的角度去看。这种，基本对大家来说，都是第一次。

    为什么要SOA的参考架构，这里边我就不长篇的说，我给大家举一个例子。在三年前的时候，我帮助英国电信做整个IT规划。当时概念还是很模糊，我跟它寻求服务部门探讨的时候，大家觉得各个部门，各个系统之间有一些东西，可以提出来重用。计费系统黑名单查询的服务，在三年前基本上这样的概念，然后后来BEA，然后觉得它制定了四个阶段SOA的演进路线。第一步，把共用的服务提出来；第二步，做组织流程再造；第三步，把参考架构提出来，这样从国外的引进路线来看，参考路线也是摸着石头过河，发现参考架构非常重要，这是在企业内，各个IT系统建设共同的目标。

    就我帮助英国电信、法国电信建构的目标，数据模型的设计，以及流程整合的理念等等。接下来我就是给大家介绍一下。那么第一个，推荐的SOA参考架构，到底是什么样。我觉得一般是这样，下午做演讲，对听众是一个考验，因为下午可能刚吃完，比较容易睡着。

    因为SOA不是凭空而起的概念，因为大家所提起的概念，就和以前的ERP、CRM这些概念一样，所有的概念都是为了解决IT的问题出现的，SOA也不例外。我们来看看，SOA要解决的是哪些问题，SOA的参考架构，到底要提供哪些组件。

    各个企业应用系统里边，形成了很多遗留系统，这个系统往往是预购的系统，有的两层结构，有的三层结构，各种各样的，所以它存在一定议购性。各个系统很分离，没有很统一的调用的组件，首先要解决这样的问题，根据我们的经验，我们解决的第一步，能够通过一些新建系统，我举一个例子，就是现在我们中国电信做BSS改造的时候，存在两个情况。第一个，CRM要上，就是按照一种面向服务的架构设计的，在设计过程中就把共用的组件提出来。

    同时有很多遗留的系统里边，在这个项目范围里边不包括，怎么办，诸如此类的应用去开发，完全没有共用的逻辑，可以进行服务的包装，去包装这些业务逻辑，包装成其他可以调用的方式。所以这些可以让服务快速增长，企业可以重用服务大量的出现。产生另外一个需求，对这个服务需要重新的管理。

    第三部分，我们把这个服务提升上来之后，我们就会发现这些服务之间，调用的逻辑的编排，实际上需要有专门的层次来做，那么就出现了服务总线。因为总线结构，大家可以理解，从数学的理论上来说，至少第一步，减少接口的数量，就是把N系统和L系统结合，是N加L，所以这是第一个好处。第二个好处，就是让它的接口标准化。

    再往后，我们把这些业务流程做了编排，这些业务逻辑可以跑在总线上，我们可以做自动化流程的调度，最后真正融入企业流程的改造。因为实现企业SOA上面，自动化流程和人工流程的权衡，也是至关重要的因素，最后有一系列的工具来实现这些。在这之前，你各个应用系统在开发的时候，必须遵循的标准，比如说服务化，一方面，我们有一个好的平台，另外一方面，我们就要按照一定的规矩做事情，可能每个系统带来的，都是一点点额外的工作，好处就是后面可以重用，业务的敏捷性，得到很大的保证。

    这张图，就是BEASOA参考架构的逻辑图，但是坦率的说，根据我实施项目的经验，其实没有什么可以真正参考对照的版本，每个项目都是千差万别，我们只能是我们只能是谈一些通用，或者常见的情况，这是一个典型的参考架构。这个参考架构，基本上也是按照层次化的理念，按照一个模型，就是保持一个简单而且整体的架构，而设计的。那么最底层，我们对传统的应用套装软件，以及遗留的数据源，我们首先要提供访问与集成，就是我能够通过一些适配器，能够把这些数据和遗留的系统进行上载。

    但是这一部分，往往是原子服务。然后在原子服务上，我就是对数据作一些集成，就会有一个专门的层次。在这之上，实际上我们可以作业务服务的分装以及组合，业务可以定制。最后我们通过统一的门户系统，展现给应用平台。



    下面我们简单看一看各个层次。访问与集成服务层，最早这个概念来自于BEI，企业应用集成的概念，企业应用集成的项目，
我做了二三十个，包括我这个团队，是一个非常老的概念。但是现在变成非常成熟的技术，这在三年前不可想象的。所有的JAVA的开发人员，想到自己要去写一个非常复杂。

    另外，在上一个层次，就是数据服务，这个数据服务，我本人来说，就是最喜欢的方向，因为在五年前，我们BEA的创始人，他说的有点极端七年之后（英文）就没有了，会被一些新的理念所取代的，他当时看好两个方向，就是企业信息集成，我们率先推出了这个产品，统一数据试图这样的工具，当时在国内推非常困难因为我们当时做几个试点。

    举个例子，北京移动，我相信在座有很多北京移动的用户，您最开始你会发现，你们打电话去查询你的花费信息的时候，原来要晚一天的，因为完全是两个分离的数据库，每天晚上更新一次。

    所以就会存在这个问题。当时我们试图用这种实时，数据视图的方式来解决，当时这个试验比较失败，因为当时确实量比较大，超乎想象。而且当时经验也不够，但是后来两年之后，我们在山西移动做同样的项目，同样的需求非常成功。所以在这个过程中，在这里边也是有很多学问，讲究数据怎么去做，包括一些架构怎么去设计，然后怎么尽量去降低它的耦合程度等等。 

    界面服务，可能是另外一个概念，因为我们可以找一个时间去探讨一下，ESB，这两年也是在SOA项目里边不可缺少的部分，实际上整个SOA项目的心脏，一个最核心的组件，因为它要去定义所有的业务服务，甚至要编排业务服务，对它要进行管理。
另外，就是一些附属设施，就是一种服务的目录，服务库的管理等等。所有这一切，然后就构成了参考架构，就是你去设计，真正要在企业级去设计SOA实施架构，这些都要考虑。我们通过不同的组合，可以形成符合应用，就是业务流程再造的项目。比如企业信息门户的项目，我们是通过不同的架构组合而形成的。这是一个非常简单的例子，可能当我们按照这样的参考架构实施这个系统，每一个层面对下一个层面，相对都是透明的，而且是耦合的结构。我录入一个订单，通过门户里边一个组件，我可以去调用那个订单的业务流程，但是这个业务流程，符合应用的业务流程，因为它相对来说，是人工要去参与的业务流程。总会有一些员工代表，客户人员参与到这个流程当中，所以这种应用，在企业里面都不存在。

    然后业务流程和业务流程之间，可以通过标准SOA的方式，从技术的角度，也许是其他，然后可以互相去调用。然后业务流程，在相关的节点上，可以处理它的数据，也是通过这种服务的方式来调研，我并不关心服务真正存在哪个系统里边，我只关心我要这个服务，这就是高层的设计。我可能在应用节点里边，软件和数据库做操作。今天不会涉及任何产品的内容，这张图大家看看的就好了，前面一张图是电力公司的实施架构，这是我们在BEA产品的映射关系，大家有兴趣，会后可以下载到这个4S。
前边我们所倡导的架构到底是什么样，后面我们简单谈一谈，SOA演进路线规划的方法。我觉得国内，这一点我感觉特别强烈，国内和国外很大的不同，国内做一个比较大型的项目，总是想在一个项目里边，把所有的问题解决掉。在国外做项目最通行的理念，特别是做SOA项目过程中，我做这个项目不是为了一次性解决这个问题，我只是为了两年后有解决这个问题的基础。在国内，你要把这个系统，举个例子，可能又要举北京的。因为我两年前在做北京通信的企业应用集成，以及后面的SOA项目。实际上它规划有56个系统，当时我记得请埃森哲做咨询，做整个接口分析，就花了一千多万人民币，当时就要做一个项目，把56个系统全部整合在一起，这是典型国内的现状。

    我们从第一个情况来看，我们必须要确立起点，这个起点，必须要遵循小步快跑的方式，把它纳入到SOA管控范畴来，然后我们再指定一个愿景，我们再设计一个SOA的架构。此外，我们必须是为了大家去定义这种演进路线的方便，我们总结了一些模式，六大维度，我们在定义演进路线的时候，我们可以去考虑这六个方面。

    第一，我们必须要确定SOA建设的目标和范围，往往不要太大。当时北京通信的项目，第一期就是计费大客户，以及一个97系统，就是你们去申请电话的系统，这是它的第一步，必须压缩在可以实现的目标下。第二个，你一定要评估你的业务需求，因为你的IT业务和业务系统，所去服务的，所以你必须评估业务系统。业务需求，因为我看中国电信，在这方面做的比较好，我上这套系统，我的详细时间要到多少秒，后面我觉得就不做详细的论述了。

    这个我简单谈一下，其实现在实现SOA，通常想到两种方法，一种是自底向上，一种是自顶向下，发现各有缺点。对你企业要求特别高，有很强的IT管控能力，成本特别高，投入相当大，自下而上，往往你做一些项目就迷失了，要做一个多宏大的目标，没有一个公司级别的东西，知道你很快就做偏了，中间相遇的方式。

    我这边举一个例子，这也是实际的例子，客户的名字我就不说了。首先我先选取两个应用，在整个SOA架构有代表性的应用，这两个应用自己做自己的，同时在公司层面会有一些SOA参考架构，以及演进路线来指导它，在做的过程中，就会考虑怎么去按照企业总体规划，来完成企业的目标。往往你做这个项目，你会有一些新的需求上来，产生第三个项目，叫应用3，当时也是整个IT规划中。应用3，由于你应用1和应用2，按照企业总体目标去设计，你很难得到公司决策层的认可，你真的把应用三，按照总体SOA设计的项目。

    我可能说的简单，但是大家在做项目过程中，细细去体会一下，必须要这么去做。所以通过以上的这些SOA参考架构，以及逐步演进的实施路线，我们实际上取得的是一种渐进式的项目，可能我翻译不太准，可能叫项目成果，这是我们的一个理念