将SOA与敏捷方法相结合

　　很大程度，SOA正是为解决上述基础架构问题而做的一种尝试。将软件分成小块实现，这使得所有服务都有更大的可能以不同的方式重用，甚至是以设计服务时未考虑到的方式重用（见图1）。这样，大型系统可以分成小的部分实现，而应用程序也从必然的静态转向设置性更强的动态。将软件交付项目分解为较小组成部分的另一个好处是，它使团队成员能够更容易地设计并实现软件的具体部分，而且设计与测试对其它的组成部分没有依赖性。

　　敏捷方法论

　　方法论的讨论需要对软件项目的构建方式，以及与其它有形产品在生产上的不同有一个理念上的转变。以往，人们认为软件是一种“虚拟的”东西，因此应该采用与实物（比如摩天大楼）相反的流水型设计方式（见图2）。

　　这一方式的缺点在于，软件的底层技术基础是不断变化的，从而会给软件交付过程带来不可预料性。

　　敏捷方法在解决这些基本问题时采用了与SOA类似的方法。首先，这是一种不同的方法，它不会在计划与实施之前尝试描述所有的细微差别和具体细节。然后，它在线型开发实践中引入迭代这一基础单位。之前的线型开发方法在遇到非线型事件时通常会对项目造成毁灭性的负面影响，比如需求变化或者技术发展引起的变化。从根本上讲，这种转变是与SOA相似的。它将项目分成较小部分并按优先分级，在完成整体设计之前把优先级最高的部分作为重点先完成。这使初期需求收集中的浪费降低到最小，并让团队能够集中精力尽早实现可用、并且可验证的软件模块。

　　缺少的环节

　　粗略一看，对于部署SOA并且在交付环境中采用了敏捷方法的企业来说，业务与技术之间似乎已经是无缝连接。然而，虽然空白被填补，其中却还缺少一些很重要的部分，并且这一问题变得越来越明显。

　　虽然SOA和敏捷方法都在向着正确的方向发展，仍然有一系列因素限制着它们取得最终目标的能力：需求文档编制与软件实现方式仍然不完善。这是因为方法与架构虽然都有所改善，但两者之间的联系却并未改变。软件产业的第三次发展浪潮正在进行中，这次发展一定会改善这最后一环，使SOA和敏捷方法能够发挥最大的潜力。

　　声明式软件交付

　　许多人一直尝试着在业务需求与技术实现之间建立一种固定的联系。UML最早便是用来以文档编制的方式创建这种联系，然后根据文档进行一系列相应的构图，直到能够充分描述系统需求。早期的软件项目不仅因为需求变化，也会因为需求完全没有描述出来而受到灾难性的影响。因此，为了解决这一难题而创建的一系列技术与文档实践让团队能够在项目开始前充分地考虑到所有方面的需求。这是软件发展里程中很重要的第一步，但也仅仅是第一步而已。

　　软件建模与需求文档编制管理上的根本问题相对结构与方法来说远没有引起足够的重视，也一直没有很好地解决。不过，在产业逐渐适应了结构和方法向SOA和敏捷的转变之后，它将开始把软件建模和声明式(delcarative)软件交付作为第三种必要的方式来完善交付过程。