由于现阶段SOA产品往往要求刚性的全局服务建模，因此误导很多企业实施过程中“削足适履”地对本可以更加动态化的企业架构进行被动的适应性调整。

　　作为一个时代标志，SOA越来越广泛地影响着企业在建应用和既有环境的IT布局。在SOA理念的指引下，IT的计算能力、业务应用的协作关系以服务的方式呈现出来，其应用的实质体现在“业务敏捷”。站在这一角度，SOA为我们呈现了一个美好的场景，但其不足之处是，没有强调具体的实施步骤。

　　通常而言，企业的SOA实施需要结合市场上一系列的SOA产品，并遵循一定的流程和步骤。常规的SOA实施步骤包括，打通上层路线；融会企业业务规划的长短期目标；提高并统一认识，明确SOA建设目标；设立组织建制；梳理既有资源，完成概念上的现有服务布局；查找差距，包括自身差距以及合作伙伴对双方业务链预期IT能力的差距；规划IT布局；完成企业服务总线（ESB）以及关键服务的梳理和部署；基于SOA环境编排业务，查漏补缺。除此之外，SOA的实施还需要一个全程治理的保证体系。

　　理念与现实的差距

　　这样的步骤基于一个假设，即开发、运维以及相关的技术产品是跟着业务发展跑的。很多时候，大部分SOA产品（或框架，可以视为另一种由松散组织开发的产品）都声称他们具有不错的适应能力，而且是从业务角度出发，在“查漏补缺”之后以更加灵活和便捷的方式使企业获得SOA所带来的业务敏捷性。但是从SOA产品（或框架）交付的角度来看，由于其面对全球所有客户的应用环境，而且实际上更多地关注技术共性问题的解决，因此虽然可以较快地适应企业的业务变化，但对企业自行的开发和运维而言，其推进的速度还是相对滞后。

　　现实中的事实与SOA理念所倡导的业务敏捷性之间为什么会出现落差呢？笔者认为，SOA产品“先入为主”的交付模式对误导企业的系统架构设计。这在那些高端SOA产品身体体现得尤为明显。这些产品总是试图将必要的基础环境和高层业务视图打包提供给客户，通过捕捉IT运行中的事件和关系，面向业务流程地从高层完善企业的IT技术架构。但实际上，企业内的运行过程本身就不是一成不变的，它主要包含规范化流程、企业自身变化流程及业务环境变化流程这三类流程。

　　其中，规范化流程是指，流程本身是规定，且完全由企业自身主导或是获得合作联盟、行业明令认可的流程，这些流程中实践、业务对象实体状态的变化在一定阶段内是相对静态的。

　　企业自身变化流程则涉及许多动态元素。通常情况下，业务部门总是先于IT部门发起各种变化，这些变化可能来自于一位新任CEO，也可能来自某个新业务领域的大客户。而即便没有这些因素，企业自身的财务和销售渠道的运行也并不总是顺畅的，用IT术语描述就是“上下文”（Context）总是在变化，虽然从SOA产品角度看没有新的流程和事件约束出现，但业务确在经历实实在在的变革。

　　业务环境变化流程的产生原因更加多种多样。例如社会突发事件对企业业务运营的影响。这些变化并不在SOA产品所覆盖的范围之内，更确切地说，虽然借助各种SOA产品可以快速的找到服务的替代品，但那是企业对外的服务需求，而业务环境的变化所要求的是企业自身服务的变化，这些不是通过某些SOA产品就可以获得的。

　　因此，虽然我们按照上面的实施步骤可以利用SOA产品完成一个“SOA项目”，但这种做法很容易误导我们对“业务敏捷性”的实践。事实上，现阶段SOA产品支持的是瀑布型的建设过程，但正如我们所知，瀑布模型对于规范化流程有着不错的规范作用，但对于企业自身变化流程和业务环境变化流程就不是非常适合了。

　　SOA实施需要动静结合

　　如果类比其他工业，我们会发现现在市场上SOA产品所倡导的建设理念高度类似于早期的兵器工业。如果需要快速武装一支部队，那么需要每个工厂加班加点生产自己的毛瑟枪（整枪）。但是这往往要求一个动态的流程，而且流程需要根据内部和外部制约因素的变化做出相应的调整。为了全面满足三类流程，实施者需要经历如下两个步骤。

　　1.将毛瑟枪的零件全部标准化，让更多的企业参与到各个零件的生产过程，最后由少量企业专门负责组装这些由不同企业生产的配件。将此过程映射在SOA建设中，就是首先把每个信息“孤岛”内的公共能力抽象为服务，并以服务接口的方式对外暴露，然后通过SOA产品完成新服务的组装（或称之为业务流程编排，Orchestration）过程。这个过程主要解决的是规范化流程的问题。

　　2.改变每个协作企业的处理方式，变任务指派为竞标方式，每个企业根据自身的生产能力和外部购买要求（即业务事件）以竞争的方式提供服务，积极发掘市场中的长尾和增值内容。例如，除了竞标标准零配件的生产订单外，还根据自己的技术创新能力提供一次装填多次射击能力的改进型配件。映射在SOA建设中，就是需要在现有“计划性”治理之外，提供虚拟的业务事件能力。至于实际反馈客户的服务结果，则是由消费这些虚拟事件的服务根据事件预定情况、参考当前业务环境和外部制约因素之后联合提供。反馈结果的装配过程是动态的，装配结果本身也是动态的、包括了各种增值的业务内容。

　　必须强调的是，第2个步骤才是SOA建设更加符合“业务敏捷性”精神的关键。它基于动态的前提，而非现阶段SOA产品中所普遍采用的“汇总→集中化→固定→静态组装”的思路。要达到“动态”的目的并不简单，起码对SOA产品而言要更多融入反馈和自适应系统的设计思路，它要在服务注册器和ESB之上实现服务间、服务对业务变化、服务对外部制约因素可以理解的事件机制，并且ESB可以根据动态的事件预定自动协调各个服务。

　　立足企业高层架构的角度，SOA建设不是现有SOA产品所描述的这些静态服务环境所能完成的。它们不足以承担业务服务建模的工作，只是基于业务事件执行模型的功能模块而已，这些产品所要求的稳定化内容恰恰与SOA的“业务敏捷”本质相背离，但可以利用其完成服务环境的治理工作。