本文探讨了各种方法，例如 Scrum、极限编程（Extreme Programming，XP）、Crystal、动态系统开发方法（Dynamic Systems Development Method，DSDM）等等，它们专注于精益软件开发（Lean Software Development，LSD）的概念。在这个由两部分组成的关于敏捷软件开发的系列中，作者详细地评估了它们对于开发面向服务的体系结构（Service-Oriented Architecture，SOA）的适宜性。
引言
正如我们在本系列的第 1 部分中所阐释的，面向服务的体系结构 (SOA) 和敏捷开发两个概念都旨在用于可适应的企业 IT 系统。然而，在关于 SOA 开发和敏捷方法的主题的 CBDI 说明中提到，敏捷开发和 SOA，就如同油和水一样，不能溶合在一起。所以，如果头脑中已经有了这样的想法，您还真的可以像 SOA 那样来将敏捷开发原则扩展到多应用程序环境中吗？在本系列的这一部分中，我们提供了证据来证明答案是“肯定的”。
SOA 和精益软件开发：Fit-Gap 分析
通过依次介绍每个精益软件开发原则，我们研究如何使用它们来使 SOA 的开发从中受益。除此之外，我们还讨论了它们在使用敏捷方法的环境中的好处。下表给出了 LSD 原则与其在敏捷方法的环境中带给 SOA 开发和交付的基本好处之间的初始高级映射。
表 1. LSD 与 SOA 原则的初始映射
|
LSD 原则
|
SOA 的好处
|
| 1. 消除浪费 |
- 宽度优先的服务模型开发有助于识别正确的服务候选者和重用能力。
-
值流映射 (Value stream mapping)，一种用于系统地检测没有价值的处理步骤的技术，使您能够识别有价值的服务。
|
| 2. 加强学习 |
- 反馈有助于定义重用的服务。
- 同步在服务的实现阶段特别有用。
|
| 3. 尽可能晚地决定 |
不确定服务接口的细节使得有可能通过实践来学习。 |
| 4. 尽可能快地交付 |
- 使用服务的情节串连图板 (Storyboard) 和“SRC 卡片”（服务 (Service)、责任 (Responsibility)、协作 (Collaboration)）来创建更小的工作单元和更高的吞吐量。
- 创建约定的一个简单的经济模型，可以用于驱动开发决策。
|
| 5. 向团队授权 |
通过授权和委托微观设计决策给负责交付 SOA 中的服务的专业人员，您增加了交付服务的能力，该服务满足当前的业务需求，而不是先前预测的或者规定的业务需求。 |
| 6. 构建完整性 |
- 通过简化端到端的通信流程，确保业务流程和交付的 IT 服务之间具有更强的耦合性以及期望的服务质量（Quality of Service，QoS）。这种方法使开发人员能够确保交付的服务具有所需的完整性。
- 通过解构代码和体系结构，确保开发和部署的服务能够交付所期望的 QoS，同时支持业务环境的持续改变。使用这种服务模型使受控解构成为可能。
|
| 7. 眼观全局 |
就其真实的本质来说，SOA 专注于业务流程联合，重点在于企业。通过确保工作团队坚持把工作重心放在全局性的问题上（眼观全局），您实现了用于确保服务验证和编排与核心业务流程紧密配合的最佳实践。 |
让我们进一步详细地讨论上面的表 1 中定义的映射：
原则 1：消除浪费
宽度优先服务模型开发
为了理解什么是重要的以及什么是多余的，使用宽度优先 (breadth-first) 取代深度优先 (depth-first) 是明智的，先取得总体认识，然后再深入细节。当开发企业级 SOA 时，您应该避免以遗漏关键部分为代价来预先构建系统无关紧要的部分的详细分析文档目录。当然，很难预知未来和灵活性的需求；因此，快速反馈是必要的。
一些来自面向服务的建模和体系结构方法（Service-Oriented Modeling and Architecture Method，SOMA）的技术很好地支持“宽度优先”方法，即：自顶向下 (top-down) 域分解、自底向上 (bottom-up) 现有系统分析以及目标-服务建模（请参阅文章“Service-oriented modeling and architecture”）。在经过总体观察以后，决定在服务组合 (Service Portfolio) 中包含哪些服务。只有到这个时候，您才能详细地定义服务。
值流映射
映射值流是开始发现流程中的浪费的一种好方法。它把重点放在用户的产品及其价值上，而不是组织、资产、技术、流程和人员上。利用值流映射的结果，您可以将精力投入到给组织带来最多价值的流程和服务上。挑选最大的机会去增加流动和增值时间 (value-added time)。您可以利用这项技术来分析业务流程（将由 SOA 支持）或者软件开发流程（用于开发 SOA）。
原则 2：加强学习
反馈
服务的“用户”是应用程序。预先设计一个用于所有应用程序的最佳重用的服务接口是不可能的。实际上，您是从初始的接口和演示程序开始，然后部署服务，最后从使用的应用程序获得反馈。一个小先遣队开发了一个简单跨系统的试验应用程序：
- 采用一个业务流程
- 分析和设计它的服务
- 原型化用户接口
- 与后端集成
- 跨整个流程
如果可能，试验应用程序应该变成产品。当这种跨系统的应用程序在生产中得到证实时，您就知道了您有了可工作的应用程序。到了那时，多个小组就可以使用一样的方法并且每次进行多项工作。
与采用瀑布方式开发整个 SOA 相比，依赖于快速交付和频繁反馈甚至更为重要，这是因为您不可能第一次就做出正确的设计。敏捷方法推动了快速反馈和热点 (Hot Spot) 的出现，这里需要灵活性。工程实践（例如测试优先开发和持续集成）减少了开发人员获得反馈的时间。增量功能的频繁交付支持来自客户或用户的直接反馈。
同步
敏捷方法至少使项目间的依赖关系可见，并且还有一些处理它们的工具（请参阅本系列第 1 部分中的 Scrum 部分）。项目间频繁同步的想法在服务的实现阶段特别有用，这里可能发生服务范围内的改变，因为正是在这一阶段详细地分析服务。
原则 3：尽可能晚地决定
不确定服务接口的细节
在像 SOA 这样企业级的约定中，似乎最好是在非常详细的层次上设计服务接口，让不同的项目来实现它们。这种方法的优点好像是服务应用程序可以独自工作，而不需要长期地与其他项目同步。遗憾的是，这并不能正常工作，因为您无法预先确定所有的细节。面对不确定性，这样做的结果就是导致浪费（以错误的细节的方式）。长期进行来实现错误细节的项目将难以使它们的代码解构变得简单。这会产生一个未达到最佳状态、却又固定的服务模型。
尽可能晚地决定意味着，在有证据可以清楚地判断服务应该是什么样子之前，不确定服务接口的细节，而不是假装无所不知。这就促使开发小组与公司的其他部门经常性地保持步调一致，而且它还产生更好的服务模型。
原则 4：尽可能快地交付
拉系统
敏捷开发中的拉系统 (Pull System) 借助于信息发射源 (Information Radiator) 使人们能够自己确定去做什么（例如，走廊上可能有一个白板，所有相关的用户素材都写在上面的卡片上；分配工作意味着将素材卡片 (Story Card) 从白板的“to-do”区移到“checked-out”区）。
在 SOA 环境中，您可以在卡片上编写用户素材和服务。通过添加服务，工作单元甚至变得更小，因为正如本系列的第 1 部分的 SOA Application 部分中所述，功能性是在用户界面应用程序、服务编排以及服务应用程序之间分配的。排队论指出，更小的工作包产生更高的吞吐量，例如功能的更快交付。
众所周知的用于面向对象 (OO) 设计的 CRC 卡片（类 (Class)、责任 (Responsibility)、协作 (Collaboration)）技术（请参阅 A Laboratory for Teaching Object-Oriented Thinking 以获得背景信息）可以修改成 SOA 设计中的 SRC 卡片。“面向服务的分析与设计原理”包括这种技术的初始示例。
约定的经济模型
传统上，软件开发有时被看作是产生成本。近来，软件开发被看作是产生收入，可以帮助利用经济期权。基于期权的软件经济从金融市场提取出相似之处：交付运行的软件的短期迭代被看作是实物期权 (Real Option)。就像金融期权 (Financial Option) 一样，实物期权通过现在非常少量的投资，来向您提供可能从未知的将来获得收益的机会。
但是并不需要走那么远：如果您创建约定的简单经济模型并使用它来驱动开发决策，甚至 SOA 约定也将从中受益。有了这个经济模型，就可以向团队成员授权，让他们自己明确什么对于业务是重要的：他们可以都从相同的假定开始工作。如果您考虑减少一些特性，销售部门可能推测出，没有这些特性，他们将少销售百分之“X”单位的产品。
原则 5：向团队授权
对于任何软件开发，最有资格作决定的人就是在第一线工作的人。在解决方案体系结构层次上仍然需要严格的控制，而基础服务开发应该尽可能地灵活。通过授权给最接近实现的专业人员去做微观决策，您可以确保服务的最终代码满足所需要的功能性。在企业 SOA 中，您可以从授权和委托设计决策给服务的开发人员（在定义的范围内）中受益。
无论何时沿着层次结构向下委派决策权，您都必须确保所有的决策者都理解了统帅全局的愿景。通常，决策应该始终的是大家共同参与的活动，而不是孤立的活动。跨功能团队的环境（出现在敏捷项目中）促进了决策协作。
原则 6：构建完整性
构建在概念上具有高度完整性的 SOA 的方法是从客户到开发团队、以及开发团队的上游流程和下游流程之间都有良好的信息流。从我们的角度来看，我们认为这一原则在服务开发层次以及服务编排中具有很高的价值。通过维持业务和 IT 专业人员之间良好的通信水平，可以确信您所交付的 IT 解决方案满足当前以及未来的业务流程和需求。随着结构良好的 SOA 中的业务和 IT 之间的联系越来越紧密，逐渐要求所交付的服务能够满足和紧密配合超出目标的业务流程。如果没有这种高层次的完整性，那么交付的服务不满足必要的业务要求或 QoS 的风险将会增加。
解构
现在，在 IT 产业中解构开发代码的实践得到认可已经有一段时间了。在 SOA 的环境中，这种实践同样重要。由于与业务的配合越来越紧密，以及需要确保所交付的服务可以支持不断变化且敏捷的业务环境，因此需要从本质上确保持续地评审和解构基础服务的设计。如果不能做到这一点，就将导致服务僵硬、不灵活，这对支持不断变化的业务环境没有益处。正如本系列的第 1 部分中的 Agile architecture 部分所述，该服务模型是控制持续解构的出色工具。
原则 7：眼观全局
SOA 的一项基本原则就是企业层次上的业务联合。对于任何企业体系结构 (Enterprise Architecture) 约定，都存在一个内在的需求，即确保始终维护统帅全局的“城市规划 (city planning)”视图，并专注于将在 SOA 中部署的单个服务的详细设计。如果陷入以牺牲整体为代价来换取最佳的单个部分（或者服务）的诱惑中，您将承受交付不灵活的 SOA 的风险，它与企业中的关键业务流程是不相配的。
结束语和展望
正如我们在本系列中展示的，SOA 可以从敏捷软件实践和 LSD 的已证明有效的原则中获得极大的好处。敏捷和 SOA 这两种实践的匹配基于一个共性——两者都极力设法处理变化。服务接口应该当作实现可能将改变的应用程序的必要条件。敏捷项目为要求它们实现的服务接口的改变做好了准备。
SOA 的“持续的”解构意味着经常更改服务接口和服务组合。SOA 中的这种敏捷需要实现项目中的敏捷。基于本文中所强调的要点，我们要说，当实现项目采用敏捷方法并接受改变时，SOA 中真正的敏捷将起作用。
通常油和水并不能溶合在一起。不可否认，极限编程的想法和以可控的方式建立企业级服务体系结构之间存在着文化差异。但这仅仅是初步估计，在写完本文之后，我们可以声明存在一种乳化剂，即 LSD 的原则。
所以，最后我们将声明，在 SOA 和 LSD 原则的上下文中，“油和水确实可以溶合”！