在《敏捷SOA：疯狂科学抑或实用技术》中我们了解了什么样的基础服务是必须的，那么你应该先部署哪类服务呢？应该部署一个应用到另一个应用提供的基于服务的优先权，还是应用提供的基于服务的优先权，这会导致创建更多的SOA基础架构。又或者推迟业务需求？敏捷成为协作方法，SOA应有业务来驱动，结果就是业务需求。要想了解这些，就要深入业务流程管理。

　　BPM曾经只对于定义流程支持的应用之间的集成点很重要，然而现在，在驱动SOA的过程中它扮演了更加杰出的角色。这种转移是积极的，但很容易以被误解，这源于业务流程在没有注意到支持应用或者这些应用是如何发展的的事实。控制、业务规则，甚至是用户接口经常应用与流程来解除应用独立性，因为应用仍然不能尽快的改变来支持业务。不幸的是，这也命中了SOA的目的。

　　TT SOA编辑推荐：SOA与敏捷开发实战演练

　　虽然完整的SOA实施可以提供灵活度的水平，合并流程生命周期以及应用开发可以使业务敏捷性进入一个全新的世界。这种方法的好处就是使团队（BP和AD）同流程和应用同步，也可以利用应用通过决策和驱动流程采纳度指导用户。

　　SOA和敏捷的共同点远多于第一眼给我们的感觉。它们都要求模式转移，但是这种转移是互补的。它们都给予业务协作、治理方法、灵活性，而且对于业务是有价值的。但是SOA中的敏捷原则可以肯定增量迭代的好处。有了这个原则，ROI更容易实现，SOA对于业务和IT的价值也得以证明。

　　SOA并不是长毛象，像一种昂贵、过度的复杂巨兽，要求每一个组件在恰当的地方并确实看待利益。事实上，他可以增量地创建并通过业务项目潜在地投资。敏捷方法论成功的而业务功能也是这样。

　　敏捷SOA是关于业务的，并不是停留在方法论层面上。继续关注通常交付的业务，支持SOA功能和特点的交付的应用，这对于多数敏捷模型也是这样的。

　　设计一个健全的架构，但是增量地交付。始于基础服务组件，在适应业务应用的同时，增量地实现他们。很有可能你的这些组件已经可以使用了，同样这也适用于敏捷。

　　其他流程和服务将随着企业的发展和SOA的成熟度逐渐确立。这是一个学习的过程。

　　首先，敏捷SOA看起来像一个不协调的搭配，甚至是令人讨厌的不经大脑的IT，但是随着你的实施，它将变得更加丰富，绝不是邪恶的技术，更像是一种只应天上有的技术。