由于标准化的最佳实践、深层通信及数据协议和工业“开放性”的发展方向，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与业务目标的一致性。

　　合适的蓝图

　　蓝图与其追踪性对可重用部件的开发有直接影响。持续的需求收集与优化有助于决定哪些组件能提供最大的投资回报率。与变化一样，需求也从企业的各个方面产生。现有组件与流程资源，也称为“现状”模型，可以帮助确定企业的现状。这样便可使用成熟的模型进行先前提到的差距分析，获得需要进行的改动。

　　蓝图可以展示可重用的业务流程模式，使以后蓝图与开发的交互更为简单，并有更高的回报和更低的风险。蓝图中的业务目标可以在确定业务流程的同时指引架构建设，而其中的模式则可以指引组件的设计与优化。“现状”模型中确定的现有资产可与流程建模进行对比，确定是否需要重组以满足“将来”的状态。

　　SOA作为一种架构方式更多的是一种技术问题。SOA运动的一个积极方面是它让人们认识到所有影响到业务的方面必然会影响到IT，反之亦然。许多成熟的模型都包含了组织和基金等方面。由于重用的重要性，必须考虑到支持开发、购买与可重用组件的组织与基金。这与使用独立开发的应用程序的企业模型是不同的。

　　虽然有些有核心IT技术的企业可以根据这个模型找到合适的位置，分布式架构的企业却面临一些其它困难。通常公共部门都是基于所提供服务的分布式结构，比如执法部门和法院。蓝图可以确定潜在的问题并集成所需的功能。比如，基于蓝图的司法信息系统可以让警察了解各种许可证的不同权限，有利于确定是否侵权，最终减少这方面的犯罪。

　　通过为各种规则建立水平连接，蓝图可以揭示各种利害关系，提供减少风险的办法，并将机会转变为资本。

　　成功的标准：真正的敏捷性

　　如果只是看看IT基础设施的架构图表，包括所开发的Web服务，看看有多少是可重用的，然后宣布SOA的成功是一件很简单的事。或许从技术的角度上来讲是成功的。但真正成功的标准是：根据蓝图进行的下一步要变得越来越简单。这才是真正的敏捷性。

　　之所以会越来越简单是因为你对过程中的模式了解越来越深，是因为你从上一步中发现你选对了越来越多的组件服务，是因为你做好了了解如何购买及集成所需服务的准备，是因为你将预期流程变化的业务逻辑具体化并做了调查，而现在这些新的需求唾手可得。如果过程没有变得更快更简单，可能是你太执著于技术设计原则，而错过SOA真正可以实现的功能。

　　蓝图可以提供开始的基础、建立交互式计划的目标和从业务层次上判断成功与否的标准。它提供了所有采用SOA所需的基础：技术、治理和迭代改进。

　　你可以不用蓝图，但这就和盖房子却没有准备施工图纸一样。你最终可能建成温彻斯特迷宫似的怪房子：多年的修建，许多漂亮但不相关的景色，不能通向任何地方的楼梯，以及许多由于对世界的错误认识而建成的迷信景点。