敏捷和 SOA 是好兄弟？

很多人都认为 SOA 和敏捷开发水火不容；对敏捷开发者来讲，架构代表了大量预先的设计以及“PPT 癌症（Death by PowerPoint，译注：泛指枯燥无味的烂幻灯片。参见： http://zh.wikipedia.org/zh/Microsoft_PowerPoint）” 。对架构师来讲，敏捷开发者就像是海盗一样，无视规则和制度。但要是你抛开这些成见，你会发现它们实际上有很多共同之处。我们认为双方都各自有很大的价值，我们非常热衷于和你一道将这两个表面上存在极大差异的世界连接到一起。

出于这样的目的，我们会在这篇文章中审视 SOA 和敏捷开发的相容性。在此之前，让我们先简短地定义两个概念。

面向服务架构是一种架构风格，其目的是使用交付业务价值的服务来实现业务机动性。

敏捷开发是一种软件开发方法论，其关注点是人们可以快速地交付业务价值。

敏捷、SOA 和管理

面向服务架构和敏捷开发过程问世的时间都不太长，并不符合象科学管理或官僚机构这样的传统管理范式 [Taylor、Weber、Simon]。

我甚至认为它们超越了同时代的管理理论，如权变（Contingency-）（Vroom）和系统理论（Checkland）。两者代表了人们做事和看待事物方式上的根本改变：

• 组织（‘职能和官僚政治’ VS ‘跨职能和以流程为中心’）
• 所有权（单一 VS 共享）
• 责任（‘强加和划分’ VS ‘承担和共享’）
• 管理（‘自上而下和权力’ VS ‘中层会师和促进’）
• 以及最重要的看待人的方式（‘作为组织资源的人’ VS ‘人即组织’，[P. Senge，M. Buelens]）。

因此，我们讲它们有很多共同之处：让我们来检验前提，对比 12 条敏捷原则（ http://agilemanifesto.org/principles.html）和 SOA 原则。看看彼此的匹配程度，以及哪些地方存在潜在的失配。

不象敏捷原则，SOA 原则并没有一个统一来源，因此我们选择一个架构师经常用到的来源，即 Thomas Erl 已经发布的那些原则。（ http://www.soaprinciples.com/default.asp）。

通过及早并持续地交付有价值的软件来满足客户是我们最优先关注的事情。

这条原则不象在我们的世界中看起来那样容易理解。在盎格鲁 - 撒克逊国家（USA、UK），客户就是最终顾客，即买产品的那个人。在荷兰国家（挪威、德国），客户不见得必须是公司的顾客。例如，若是你为一个在线书店构建软件，客户可以是这家在线书店的销售部，而不是买书的人。

“有价值”一词往往被误读了。在书店这个例子里，如果书店的顾客可以用它来方便地买书，或是由于并不需要书库，因此书更便宜，那软件就是有价值的。取决于公司的经营模式，我们需要的是一个便宜的解决方案或是一个非常复杂的解决方案。

“及早”同样也经常被误读。如果在线书店提供在线支付，要是你交付的软件缺乏适当的安全性或是经常变动用户界面，书店的顾客就会不满意。但是客户（销售部门）需要及早不断地交付来划定需求优先级、运行 beta 测试、调整销售流程等。因此，对我们来说，这条原则讲的是让软件对业务有价值。

SOA 关心的是企业架构，使用服务作为定义概念。服务是给流程增加价值的活动。这个活动可以由一段软件代码自动化，可以是一个人类活动或者是二者的结合体。将软件绑定到服务，可以确保它增值，因此这条原则非常适合 SOA。但是，区别仍然存在：在 SOA 里，你会在构建服务之前先检查服务是否已经存在（ http://www.soaprinciples.com/service_reusability.asp ），即便重用服务可能要比重新构建它要花更长的时间。开发时间并不见得是最重要的因素，而只是一个快速进入市场的重要因素。在 SOA 中，你会对企业采用一种全局的方法，而不是局部开发的视角。这意味着许可证费用、维护成本和可使用性（Reusability）都在考虑之列。因此，你有时可能会因为它没有给业务带来任何价值而决定不构建任何东西。然后，你去配置目前已经有的东西。

尽管敏捷更关注于（单个）项目或产品，SOA 则重点将服务和企业作为整体对待，但是这条敏捷原则和 SOA 原则是完全一致的。

欢迎需求变更，即便是在开发的后期。敏捷过程利用变更为用户创造竞争优势。

将 SOA 作为一种实现业务价值的方法，我们创造了一个由更小型、可跟踪的服务组成的世界，这让你可以根据市场和顾客需要不断地装配业务流程（ http://www.soaprinciples.com/service_composability.asp），重新调整和组合它们。由于代码没有跟各流程发生紧密耦合（松耦合，http://www.soaprinciples.com/service_loose_coupling.asp），并且服务是自治的（http://www.soaprinciples.com/service_autonomy.asp），所以你可以轻易地重用服务。SOA 的一个重要业务驱动力就是公司的机动性。通过解耦服务提供者和消费者，让实现的变更更简单；使用标准，实现变得更容易改变；使用分离关注点，同样也让实现更方便修改。SOA 讲的全是变更……正如敏捷之于开发。

本文的编辑想让我谈一谈‘泛化（Generalization）’，因为这两种方法似乎在该主题上有矛盾。光从字面上来谈，对于“何时进行泛化”这一问题，SOA 的回答会是“任何时候”。这当然没有任何意义。有时，问题对于某个部门或能力非常特殊，或者是它才刚刚出现。在两个情况下（当它非常特殊的时候，或者是问题还没有被很好理解的时候），泛化解决方案根本没有意义。对于同一问题，敏捷开发的答案会是“从不”。这同样也没有意义。有时，问题在企业中非常普遍。比方说要得到消费者的数据。假如你已经可以从一个开放、运行良好的应用里获得这些数据，那在每个需要消费者数据的应用里复制这些数据当然毫无意义。集成现有应用，把重点放在手头的业务问题要简单得多。

那么，敏捷和 SOA 的极端都有不利之处。结合两者，将消除两种方法的风险。

附带说一句，SOA 不只是关心重用和泛化；它还关心创建交付价值的小型单元（服务），而不是去创建难以改变的筒仓。这种方法同时简化了变更和重用。这条设计原则非常类似敏捷经常用在软件开发中的设计原则（分离关注点，避免浪费等）。

总而言之，我们可以从两者学到很多：SOA 的了解整体情况，敏捷的小步交付（大处着眼，小处着手；全面考虑，局部行动）。这把我们带到了另一个敏捷原则。

频繁交付可工作的软件，时间周期从几周到几月不等，优先采用小时间段。

为了得到大量的动力和证明服务有效，你最好定期交付可工作的软件和褒奖，这有助于对人们产生激励和动力。这是通过迭代递增地工作来实现的。

得到由上而下的支持，依次识别有价值的业务流程，把它们转换成（非常值得一提）可重用的技术转化物和数据服务。从小处做起，一次实现一个服务和一条流程来构建你的 SOA。

在敏捷软件项目里，通常交付的是小（基本）的服务。Standish Group 把这些称为踏石（stepping stones）。为了确保这些踏石确实在把你引向要去的方向，而不是原地打转，这就需要坚持相当严格的原则。服务的目标架构和方针可用于这个目的（ http://www.soaprinciples.com/standardized_service_contract.asp for example）。这意味着架构需要由产品负责人考虑，而且是产品 Backlog 的一个约束。由于 SOA 里的松耦合（ http://www.soaprinciples.com/service_loose_coupling.asp），技术可以在具体问题出现时才选择，但是架构是针对全局的方针。通过一个一个地定期频繁地在你的敏捷项目里交付这些踏石，你可以逐步构建你的 SOA。一个大型组织的面向服务架构不可能一次就建成。举个著名的类比：吃掉大象的方法就是一次一口。再次提醒，要千里之行始于足下。

来自敏捷开发的一个好实践就是每次努力都会立刻给消费者带来价值。如果我们把它应用到 SOA，我们只构建企业所需项目背景下的必要服务。识别服务既可以采用自顶向下，也可以自底向上。但是它们总是在拥有端到端需求的项目环境下构建。这减轻了任何 SOA 项目的风险：构建大量从来不会被用到的服务。

敏捷和 SOA 的共同挑战是将迭代计划与编程管理和组合（Portfolio）管理集成起来。将发布调整为运营、业务用户和管理员所能管理的单元同样也具有挑战性。这些环境往往需要根据交付的不同步骤和更小的功能块（服务）进行调整。

业务人员和开发人员平时在整个项目中必须一起工作。

这条原则暗示了软件开发过程。你可以声称这也同样适用于架构；业务人员和架构师平时必须在一起工作。信息和技术在很多行业里对战略的重要性越来越大，如政府、金融服务、公共事业公司等。因此，业务和 IT 必须一起组成公司的战略。项目只有在多学科的人一起工作的前提下才能成功。服务只有在 IT 和业务中的人合作的前提下才能实现。服务对业务很重要，必须要有业务价值；架构师、开发人员和测试人员必须理解这一点才能给企业交付这些宏伟的服务。这应该应用于任何项目。一套公共词汇或共识可以全方位帮助沟通。

因此，合作是敏捷开发和 SOA 都认同的。当然，一些重大区别还是存在。最大的区别在于，架构是一个过程，而非项目。当然，你可以启动项目部分地实现架构，架构也是一个项目的重要组成。SOA 在这一点上的附加价值就是，架构师和其他业务人员一道讨论和工作，而不仅限于项目干系人。这可以让他们发现产品 Backlog 中特性里的潜在改进和不一致。

围绕被激励起来的个人构建项目。给他们提供需要的环境和支持，相信他们可以把工作做好。

敏捷明确地提到人的价值和他们的技术。只有清晰理解愿景、使命和符合公司目标的战略，以及被他们的领导同事鼓励和促进的被激励的人才能把工作做好。但是，SOA 并没有提到这点，毫无疑问，不同流程及领域的所有者只有被激励才会使用彼此的服务。为了协同和重用服务，你需要相信所做决策，依赖他人交付的服务。在具体项目中，要重用不是由自己设计的服务，开发者需要相信同事的专长。服务契约本身或强制的重用永远无法替代激励或信任。这是生活中再明白不过的道理。

在现实生活里，‘敏捷’和 SOA 都面临因不了解而带来的恐惧，怀疑敏捷和 SOA 原则对实现而言是否是正确的东西。因此，你必须教导和培训，然后让你信任的人决定如何实现。

向开发团队以及其内部传递信息最有成效的方法是面对面交谈。

对于良好的沟通，这是必须的。开发团队内部，面对面交流的效果相当好。团队之间（不论是时间上还是地点上），你需要以不同的方式交流。重点是你只是增加价值。为了可以重用服务，可发现性是一条重要原则（ http://www.soaprinciples.com/service_discoverability.asp）。你记录他人重用你的产品和服务时必需的任何文档。不多，也不少。同样，这是关于产品 Backlog 的另一术语。当然，这并不是你为了确保人们理解服务内涵必须做的全部事情。架构师应该把他们的时间大部分花在面对面沟通上。与业务交流，了解战略和目标；与开发者交流，在快速交付和易于维护之间权衡、解释现有服务的含义和用例等等。高度面向技术的 SOA 人员的缺点是他们认为 SLA 和注册库可以代替人类交流。然而 SOA 不仅讨论成功的条件，就像其他成就一样，它还依赖面对面的交谈。

可工作的软件是首要的进度度量指标。

在项目里，为了实现服务或 SOA，最终目标是构建给业务带来价值的业务流程。这可以由一段软件代码来实现，也可以由人工服务来完成。在 SOA 里，你不用构建任何东西就可以取得进展，而只需改变某些人工活动就行了。这种进度指标是业务指标：就像销售量、利润率或成本消减。

因而，这就是一个范围问题：敏捷开发讲究的是软件开发。要是你构建软件，可工作的软件应该是首要的进度度量指标。SOA 讲的是企业架构，因此，进度是由整体所取得的业务目标来度量的。

敏捷过程提倡可持续的开发。发起人、开发人员和用户应该能够持续维持一个恒定的步调。

这条原则讲的是让工作者的生活变好还是变坏。快乐的工作者，不论他们是架构师还是开发者，只要他们不必在压力之下工作，不必工作很晚，不必同时参与多个项目，或是工作时间超过影响其健康的限度，要成功得多，工作得更聪明，而且交付的工作质量更好。这条原则应该在任何项目中提倡。这非常合理，不于 SOA 发生冲突。

持续关注提高敏捷的技术优势和优秀设计。

敏捷团队要让技术满足业务的预期并使之工作：普遍存在和可靠。SOA 需要高级别的技术优势和设计，因为它要求松耦合、可使用性和抽象。这些原则要求额外的关注和学习。敏捷开发者不仅需要设计他们的类和方法，他们还必须通过帮助架构师和业务设计整个系统，亲自参与到整个系统的设计之中。这给敏捷设计会话设置了一个强制性目标：眼光要超越单个项目的范围。

某些开发者告诉我，高等级的标准化（在这里指的是架构）可以被认为是一个不必要的约束，它吞噬了他们的生产力。这里再做一个类比：如果你需要一个包裹尽快地快递，没有限速可能会更好。对于各快递公司而言，无视所有规则似乎可以更快。但对于订购该包裹的顾客来说，生命要比单纯地快递一个包裹要重要得多。他也期望你的孩子能安全的步行到学校。因此，尽管包裹快递公司可以达到技术优势和好的设计，他们还要把环境作为整体因素来考虑。这便是 SOA 可以发挥作用的地方。由于小单元的概念，只有少数方针才需要每个项目去遵守。当然，这些方针需要随时被评估和改进。标准本身的作用应该是促进，而不是限制。将这跟瑞典做个比较，当地人觉得在路右侧驾驶要更方便些，就像欧洲的其余国家一样。当这是一件正确的事的时候，他们改变了规则。

对 SOA 和敏捷两者来讲，一致且有序地应用和采用实践和原则都非常重要。

简化（最大化不完成工作量的艺术）是必须的。

SOA 把服务定义为主要的可交付件。这是一种简化的实现，拥有符合某些原则（松耦合、自治、可组合性等）的小型构造单元。这种方法也帮助定义了实际需要软件的时间和类型。当你只构建对已识别但尚未实现的服务进行支持的软件的时候，你才能最大化不完成工作量。我们有句话：“Je gaat niet iets bouwen als je het ook op de achterkant van een sigarendoosje kunt bijhouden”. 它字面上的意思是：“如果某件事你通过把它记在烟盒背面就能跟踪，那么你就不会打算去构建它（软件）”。我们同样可以把它应用到我们的 SOA 实践之中。

最好的架构、需求和设计产生自自组织团队。

这条原则既适用于敏捷软件开发，同样也适用于 SOA。事实上，SOA 本身并没有规定它应该如何实现。你可以通过自组织团队来完成这件事，也可以通过规定采用由 CIO 颁布的架构来完成。

实现 SOA，如同其它成就一样，需要来自多学科且在各自领域拥有丰富经验的人。如果他们喜欢彼此合作，这样的人不需要去驾驭。协调业务人员、架构师、流程建模人员、测试人员和服务开发者是必需的，而且综合学科的团队也需要成立。这里的重点在于，架构是必需的，因为解决方案（服务）必须符合整体蓝图。架构必须是自组织团队的一部分。这必须以某种方式组织起来，团队和团队之间所采用的方法各不相同。单单的敏捷实践和自组织无法解决这些架构挑战。

例如，解决方案架构可以经由应用敏捷方法，通过重构、小步增量设计，以及主要以代码形式表达。接着架构就浮现出来了。这是由下而上的架构部分，它与自顶向下的部分在中间层会师。

团队定期就如何变得更敏捷进行反思，然后相应地调整其行为。

由于 SOA 并没有论及任何关于实现它的方式，仅仅讨论了我们需要的原则和构造单元，这条原则可以轻易地被应用到架构工作中。

通常来说，为了设计和构建可重用有价值的服务，你必须持续测试和评估你的劳动成果、度量质量、不断学习和重构。某些高级但是确定的质量标准必须就位。SOA 让团队有具体的产品（服务）去讨论，以及一组原则去度量其质量。集中对构建服务的回顾可以包括类似的问题：

• 我们如何改进可使用性？
• 我们如何让我们的服务在干系人（消费者）眼中更有价值？
• 系统的哪部分可以让我们用现有服务代替？我们怎样才能更快更好地交付下个服务？
• 我们可以进行泛化吗？

每天站立会议，持续集成和迭代演示不仅可以帮助软件开发，也可以有助于架构的检查和改进。

总而言之，敏捷如同手套中活动的手指。SOA 则是这个手套，范围便是整个企业，敏捷开发关心的是那些由软件支持的部分的开发方法。SOA 和敏捷的大多数原则并不矛盾。当它们同时出现的时候，它们会相互促进。敏捷开发若是缺乏清晰的目标愿景和公司目标就会徒劳无获。SOA 要是不知道如何利用敏捷原则使目标成为现实，将会浪费时间和金钱。

SOA 和敏捷都关心机动性。（这适用于大量不冲突的原则）SOA 关心的是架构结构，敏捷开发关心的是快速交付。这种方法让它们彼此保存平衡。两者缺一不可。

关于作者

Mary Beijleveld 毕业于格罗宁根大学的企业管理（MScBA）专业。她目前是位于荷兰奈凯尔克地区的 Approach 的高级业务咨询顾问、业务架构师和敏捷项目经理。广泛的讲，她关注的领域是架构的业务价值，特别是 SOA 和 BPM。她偏爱在业务和技术结合的工作，在这种场合中，必须解决复杂的问题，而且完成实际改进的压力很大。此外，她还对敏捷项目和开发方法、网络、博客和写作具有鲜明观点的文章有很大热情。她拥有 ScrumMaster 认证证书，在项目管理、问题控制有长期的经验，拥有项目管理方法的广泛知识。访问她的最新博客可以有助于您对她的了解。

查看英文原文： Agile and SOA, Hand in Glove?

感谢黄璜对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。