实际上我觉得做任何事情，本人都有一些规律。比如说你的老板，交给你一个任务去做，或者你自己制定一个目标去实现，都要考虑两方面的问题。第一，你要制定一个切实可行，合理的目标。第二，就要有一系列计划完成你的目标，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参考架构的逻辑图，但是坦率的说，根据我实施项目的经验，其实没有什么可以真正参考对照的版本，每个项目都是千差万别，我们只能是我们只能是谈一些通用，或者常见的情况，这是一个典型的参考架构。这个参考架构，基本上也是按照层次化的理念，按照一个模型，就是保持一个简单而且整体的架构，而设计的。那么最底层，我们对传统的应用套装软件，以及遗留的数据源，我们首先要提供访问与集成，就是我能够通过一些适配器，能够把这些数据和遗留的系统进行上载。

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