由于标准化的最佳实践、深层通信及数据协议和工业“开放性”的发展方向，SOA几乎经历了一场敏捷性的完美风暴。

　　对于企业业务来说，面向服务的架构(SOA)最大的优点就是灵活的响应能力。企业经常受到各种各样变化的影响：市场、供应链、战略流程、规则等。SOA可以建立一个灵活的环境，可靠地应对各种变化。原因在于SOA将自动化功能以可重用的方式重组，这样便可快速配置新的或修正的流程。

　　但仅仅依靠一个架构来实现敏捷性是不够的。敏捷性来自可提供敏捷流程的各个方面。开发、重构或者建立正确的服务都需要对业务有很深的了解。

　　在过去几十年里，人们开发了许多将自动化转变为敏捷性的模型。简单的主机应用使大量集成程序可以在中央主机上运行，获得各种功能库。客户端/服务器系统以及后来多层次系统可以实现更有目的性的部件替换或升级，也称为“关注分离(separation of concerns)”，这都是敏捷性的特征。

　　然而，这些敏捷技术的发展却经常受到多系统下操作中心的影响，它们各自有自己的敏捷方式，却无法共同协作以实现“敏捷企业”。一些如兼并或收购来的这类业务发展经常带来没有互操作性的系统，甚至更糟糕，以至于这些厂商在开发时都没有考虑创建能适应业务变化的集成系统。虽然企业集成套件成功地解决了许多问题，但集成各种单体接口的基本方法仍然成本昂贵并有潜在的问题。

　　由于标准化的最佳实践、深层通信及数据协议和工业“开放性”的发展方向，SOA几乎经历了一场敏捷性的完美风暴。企业集成的努力及面向对象等理论的发展逐渐形成了最佳实践。由于因特网的发展，管接技术(plumbing)成为深入了解和普及集成的必须。而客户的需求、开源及信息公开运动则促成了开放性的发展。

　　为什么说几乎是一场完美的风暴呢?因为与之前的技术一样，SOA只是一种使能技术。如果没有对当前业务流程的深入了解，或对流程变化的总体认识，便不能正确地选择组件，也就不能形成完美的敏捷性。

　　SOA不只是怎么做的问题，真正的业务规划应该从做什么开始。简单地说，如果不知道该“做什么”，那么即使知道该“怎么做”，做出来的东西也是不相干的。

　　用蓝图(Blueprints)实现“中间相遇”

　　有什么可以指引这些新架构方法和底层技术的应用呢?

　　有什么可以防止SOA实践者只是简单地进行整理而没有取得SOA真正的敏捷性和业务目标的一致性呢?

　　有什么能保证整理好的“SOA”架构能带来可观的效益呢?

　　在SOA领域里，关于治理的重要性已经讨论了很多，但这仍然是一个怎么做的问题，而不是做什么。比如设计时的治理，要支持组件的重用，这是SOA的一个重要方面。如果不能重用为什么还要花钱进行这种重用性开发呢?但对决定重用哪些部分的过程的讨论却很少。而且，成功的先决条件应该是一个可以指导选择或创建能真正实现敏捷性的组件的模型，这样组件才能支持新的或更高层次的业务流程。

　　关于以自上而下(top down)还是自下而上(bottom up)的方式采用SOA也有许多讨论。两种方式都有不同的优缺点。自上而下的方式可以让你“感觉不错”，因为这种方式是基于充分分析与调查的基础之上，但却容易导致无限制地进行描述或制定标准，即“分析乏力”，以至计划赶不上需求与技术的更新。

　　自下而上的方式便于迅速着手，通常是为了追求新技术，并有“有机(organic)”方法的优点。然而，这种方式也常常导致不可重用的组件或没有组织性的服务，虽然符合部分面向服务的规则，却不能提供真正的敏捷性或再现业务服务一致性。

　　还有一种“中间相遇”(meet in the middle)的策略可以将两者的优点很好地结合起来。深入了解业务目标并将其重组，以及支持这些目标的过程是最容易控制和规划的方法。但“最好的规划”也可用于自下而上的方法，即先开始，然后在过程中重构、学习经验，并支持根据不断变化的优先级、需求和技术进行细粒度的调整。

　　由于支持平行开发，“中间相遇”的方法通常具有时间上的优越性，而自上而下的方法通常代表不同的组织和规则。但这也正是需要解决的问题。两个为“中间相遇”而努力的团队需要精准地了解彼此之间将怎样连接。这可不是马马虎虎就能解决的问题。

　　一个代表当前及期望状态的全面的分层模型(一般称为蓝图)可以有效地支持“中间相遇”的方法。这个方法需要自上而下方法的清晰的追踪性，而蓝图正好可以提供这一点。有了这样一个蓝图，最终将使“宏伟目标”发挥最大效益，并可以根据基础设施与流程需求进行平行开发。

　　这是SOA实践者提供的建议，可以建立有着很好可视性并且需求简单的观点验证(proof-of-concept)，以保持注意力。在交互开发的蓝图中采用这种方法可以从业务目标到帮助实现目标的基础设施自上而下地探索追踪性。以进行足够的高层建模与定义作为基础，确定早期开发的关键过程;但要及早进入开发过程为下一步积累经验，做到见多识广并且信心十足。

　　因为蓝图良好的可追踪性，可以察看当前实现或观点验证(poc)所满足的需求。还可以作为捕捉实现SOA化企业过程中每一步中变化的规划，并提供合适的组件以获得最大的敏捷性。蓝图是一种通用语言，定义了顶端的业务结构与底层的系统架构之间的接触点。蓝图可以确保计划能真正的“中间相遇”。

　　实质上，蓝图也就是各企业的“架构复本”，并且由于实际上它是由软件工具启动的，因此称之为数位模型更为贴切。在蓝图中，治理成为一种实现这个“复本”的控制和通信架构。计划可以提供进度与资源以进行蓝图中“现状(as is)”模型与“将来(to be)”模型之间的差距分析(gap analysis)。

　　由于蓝图中各层之间的可追踪性，可以通过经过优化的业务目标确定需要变化的业务流程，再根据业务流程确定底层的自动控制和组件，最后确定需要变化的基础设施。有了蓝图，便很容易根据业务范围、投资回报率、可用资源或其它非直接与架构和技术有关的因素对项目进行优化。这样便能并行执行计划，并保证可根据进度提供所有组件，实现IT与业务目标的一致性。