SOA推进策略的问题，是我们最近被问到最多的问题。有个管理专家用“道”，“法”，”术”,来比喻SOA几个方面，很有意思。“道”的层次可以认为是业务敏捷，IT灵活性等管理目标，”法”是指，SOA的管理与控制规则，“术”，是指各种具体的标准与技术规范。
看到今年以来，媒体上无数技术厂商，应用软件公司，甚至硬件公司都把SOA当作时髦的标签做市场宣传，我不得不自嘲的认为，自己也是学屠龙，卖猪肉。一种技术潮流刚刚兴起的时候，发生炒作和形式大于内容的事，在IT领域已经成为一种传统。从兴趣进入真正的项目推进，才是真正有价值的事。然而认真思考了SOA架构理念的人，很快就会发现，想要把它认真落地，一大堆问题就浮现在脑子中：
|
·如果企业的业务战略都在不断变化，传统的IT规划是否还有应有的价值?
·如何一面开发应用系统，一面建立企业级的服务管控规则?
·现有的生产系统都十分陈旧，如何将他们纳入新的SOA架构?
·如何在开发新的跨业务应用融入SOA的实施方法?
·SOA好像是比EAI更好的一种集成“术”，到底有什么不同?
下面我试着用中间相遇的策略作为一种可行的办法，来回答一些问题。有些企业在推进SOA实施时采取的是“自顶向下”的方式，即从企业的战略开始，逐步向下展开;另一些企业则采用了另一种途径，就是“自底向上”的方式。这里所说的“自底向上”，并不是说由底层的技术推动业务，而是说，从小的项目开始做起，积累经验，然后做大项目，最后上升到战略层面。
然而，无论是“自顶向下”还是“自底向上”，这两种SOA实施策略都各有利弊，很难达到理想的效果。
“自顶向下”是企业实施SOA战略性的策略，其核心思想就是从企业层面做SOA实施的整体规划。它的好处是从企业整体进行考虑，面向业务，企业可以根据其业务的发展情况以及现有的IT情况做一个SOA实施的整体规划。这样可以推动整个企业的标准化，所有的服务模块都基于相同的标准，方便今后的重用。但是它的风险也不小：一方面是范畴涵盖大，周期长，初期的投资大;另一方面是它要求整个企业要有比较高的纪律和技能，有一套完整的组织架构和管理流程。
“自底向上”的实施办法则是战术性的，它强调从小处着手，从一个部门级应用开始实施SOA。这种方法的好处是见效快，风险小，初期的投资也不大。不过这种实施方式的弹性相对比较差，特别是当企业需要在更大层面实施SOA时，可能会产生一些衔接问题。
结合多年来帮助客户成功实施SOA的经验，一种更加切合实际的SOA实施策略，这就是“中间相遇”(meetinthemiddle)的实施策略。在SOA的实施中结合“自顶向下”和“自底向上”的方法，寻求两者之间的结合点，才能最有效和成功地实施SOA。因为对绝大多数企业或组织机构来说，在业务系统实施的初期，存在很多不确定性，包括业务需求和项目所选择的开发技术、平台等都存在不确定性。遵循“中间相遇”的原则，业务人员和开发者都各自循序渐进地做事，在过程中不断沟通，这样就能够使得业务的改变得到最快的响应，并且不会影响开发效率，最终两者能够在某一点相遇，从而搭建起符合需求的系统。通俗地说，“中间相遇”的原则就是我们常说的“大处着眼，小处着手”，在做一个一个项目时，并不仅仅把眼光局限在正在进行的项目，同时也兼顾企业IT系统和业务发展的整体规划。
那么，采用何种软件工程学作为指导推进中间相遇的实施策略呢?
许多传统软件工程学的都是在SOA之前发明的，这里面的大多数方法没办法通过简单的拿来主义，直接用于指导SOA的软件开发。项目群的整体规划，可以采用PMO的办法。但针对SOA应用开发的推进，我们需要一种方式，既能针对SOA实施的特点，又能兼顾特定企业的管理模式和软件开发习惯。
很多大型企业应用系统是一个规模宏大、业务复杂的系统，现在所有从事的架构师都在考虑基于SOA服务的软件工程学。基于“中间相遇”的实施策略，在自上而下地规划了IT战略和参考架构后，企业需要找到一个有代表的应用项目。引入SOA服务工程学来开始此具体项目的实施，通过这个SOA服务工程学的推进方法，企业可以依靠如下三个方向建立自己独有的SOA服务工程学框架：
建立符合企业管理模式的SOA管理架构：每个企业的组织架构，管理策略都不相同，通过SOA服务工程学的推进可以建立针对特定组织的管理原则，纪律，运营和管控
建立符合企业习惯的服务工程：SOA服务工程学可以看作是对企业原有软件工程的一个扩充，它在利用SOA服务的重用，灵活性，业务敏捷，和投资回报等方面增加了一些针对企业级项目群管理服务工程，比如针对SOA开发的，SOA需求管理，服务识别与发现，版本规划，服务定义，设计，实施，部署，管控等等。通过前一到两个项目总结的这些方法和原则可以作为其他项目开发的基准。
SOA基础架构的搭建，选择前一到两个有代表性，覆盖技术架构比较广的应用，同时也进行了针对特定应用的架构验证，在此过程中，一些类似ESB，BPM,数据服务，服务库等SOA基础设施也同时被建立起来。
以下我们举一个例子：(在这里，项目1、项目2和项目3也可以被看做3个典型业务场景)：
在开始具体项目实施之前，企业首先需要先为企业确定一个参考架构(ReferenceArchitecture),相当于我们常说的顶层设计，后面实施的自底而上的项目都要瞄准这个参考架构。下面我们来分析项目1和项目2。虽然这两个项目都是从底层编码开始实施，但是项目参与者已经有意识地在用SOA的思想和参考架构去做，并且在遵循按服务契约设计的实施方式。在这里，项目1和项目2的选择是一个很重要的问题。由于是处于尝试阶段，前两个项目通常会选择比较紧迫、能体现一些用户需求、并且能够体现快速实现ROI的方式。项目1和项目2尽管都是从编码做起，但不完全是自底向上地做，而是遵循一种“中间相遇”的思想，这也是通过实践总结出来的比较安全的推进方法。从项目3开始，参与者就开始有意识地构建那些重要的服务层以及相关的管理控制策略，以形成企业资产。前两个项目中的服务，在后期的项目中被重用的几率可能有一些折扣，比如服务的重用率可能达到70-80%，而不是理想的100%。但是在实施的过程中，可能已经体现出了SOA的优势，如此一来，很容易博得企业决策层的认同，进而支持项目3的推进。
项目3是非常关键的环节，在实施过程中，需要形成一些涉及到战略层面的管理知识和规则。从项目3开始，就要抽象出一个服务层来：即需要在业务层和技术层之间增加一层服务层，以弥补业务与技术之间的鸿沟。也正是由于服务层的形成，能够保证在技术的跳变时不会直接影响到业务需求。
开始做最初的SOA项目时，我们会先解决比较急迫的业务问题，然后根据这些业务问题用SOA方法，如分层的结构、ESB结构，实施一两个项目。此时要尽量具体着眼于项目本身对具体业务的价值。实施完这两个项目以后，就能给整个组织带来信心，尤其是管理高层。随后，就考虑引入一个管理SOA的规则，把前两个项目总结的经验和包装的服务标准化，尽量在后面的建设中应用，即引入SOA管控。所以，这是一个循序渐进的过程。但我们在做第三个项目的时候就不再自底向上，而是开始从SOA实施小组管控中心的规则和最初的两个项目达到磨合，而产生了服务的中间层，包括服务本身具体的架构。
在整个SOA推进的过程中，所有的东西都是在不断迭代的，参考架构，服务定义，实现的技术都是可以不断迭代的，正是因为SOA的松藕合设计，才使得多重迭代成为可能。
