访谈：用敏捷方法实现 SOA

现在的 SOA 过程和指导一般都鼓励使用分阶段方法来实现 SOA，在开始实现 SOA 之前，要充分的理解问题并定义好解决方案。Digital Focus 是一个在东海岸的公司，专注于敏捷软件开发和集成，他们坚信敏捷开发实践同样适用于 SOA。在八月，Digital Focus 发表了一份体验报告，名为“ SOA，与敏捷相遇。敏捷团队实现 SOA ”。该文描述了在 Federal Home Loan Bank （FHLB）的金融部门（Office of Finance，OF）（注：以下简称FHLB-OF）如何使用敏捷方法成功实施了SOA。

在下面的文章中，InfoQ 的编辑Deborah Hartmann 采访了两个与这个项目紧密相关的人，以了解他们是如何做到这一点的。首先，Geoff Henton（FHLB-OF 的CIO）回答了一些在这个SOA 开发中使用敏捷实践的基本问题。以前，他们只在软件项目中使用这些方法。随后，Tom Stiehm(该报告的协作者) 告诉我们这个项目是如何开展起来的。

InfoQ：Geoff，对于您的第一个敏捷项目的成功，您认为敏捷指导起了多大作用？

Geoff Henton（FHLB-OF 的 CIO）：敏捷指导与我们敏捷软件开发早期的成功是密不可分的。在我们开始采纳敏捷技术时，有一个经验丰富的专业人士给了我们许多指导意见，使我们从中获益良多。对我们的开发人员来说，依据特定的敏捷原则开展工作是一件不寻常的事。一个能给我们讲解有关敏捷方面的优缺点的资深专家对我们来说简直是无价之宝。在采纳敏捷之前，我们有一个标准的软件开发生命周期管理方法，总是倾向于过分预测和产生过多的预先设计和分析工件。我们的敏捷教练指出我们应考虑把注意力集中在当前重要的事上，而不是试着设计整个系统并制订一个严格的项目计划。如果没有教练的帮助，我相信在我们真正体会到敏捷方法之前就已经放弃了。

InfoQ：SOA 和你们的敏捷软件开发实践是如何结合，来达到业务上的成功的？

GH：我们实现 SOA 的原因是因为我们的独立系统在步趋成熟的过程中，复杂度已经大大增加了。在固定收入的资本市场上，只有反应迅速，才能把机会握在手中。在不考虑系统边界的情况下，以一种更多地基于组件方式来组织管理我们的主要系统功能可以使我们面对变化快速做出反应。可以说，敏捷开发实践就是为业务成功所准备的，因为它把业务溶入了他们的系统开发中，并允许它们在项目中期改变方向，因为他们可以预见这些决定给完成整个项目目标带来的全面影响。

InfoQ：敏捷和 SOA 都涉及业务与 IT 的结合。您能举个例子说明在您的组织中如何进行这样的结合吗？

HG：我们发现，敏捷为我们提供了快速调整业务以应对 Fed 的变化的能力，而 SOA 可以使我们所交付的功能同时为内部和外部提供服务，满足他们的要求。金融部门（The office of Finance，OF）向 12 个区域性 FHLB 提供了服务功能。在 2005 年下半年，我们开始了 SOA 项目，用敏捷方法设计并重构我们的服务系统。在 2005 年早期，业务部门意识到有一个新的难题，是一个有关联邦储备（Federal Reserve）的条款，该条款主要是针对明目张胆的透支制定的。于是，OF 要求向发布计划中增加新的特性，并把这个新特性在开发列表中提到最高优先级。当开发这些新特性时，我们发现需要将一些潜在的特性作为服务向 12 个 FHLB 开放。这些服务使 FHLB 可以很容易地导入那些部门所需要的现金管理数据。敏捷和 SOA 使我们可以按时交付这样的功能需求，同时对于项目的剩余部分来说，这种灵活性也增加了业务部门对 IT 的信心。

InfoQ：非常感谢，Geoff 先生。那么，Thoma，您在文章中也谈到了业务与 IT 的结合。能否谈一点儿关于这个结合带来的益处吗？

Tom Stiehm（Digital Focus 负责人）：业务与 IT 的结合就是要找出在一个公司或项目中做具体决定最恰当的人。这意味着这个最有专业技术和经验的人应该做出决定。我把它归结为：业务决定做什么，而开发决定如何实现。

业务与 IT 结合的益处是做出来的应用正是支持业务流程的，所以可以被业务部门用起来。因为这些应用的确提高了他们的生产率。在加入 Digital Focus 之前，我有过一段令人遗憾的经历，我开发了一个我认为可以做很多事的相当不错的应用，但业务部门恰恰不需要它。它被搁在一边：安装到服务器上，并在服务器升级时被删除，次次如此。

这样的事情常常发生在你有严格的需求，而且变化成本很高的情况下，这其实才是真正的损失。业务部门没有得到他们真正想要的软件，而且又不能拿出资金再做一次。对于开发者呢，他们会感到他们的时间和天才被白白的浪费了，因为他们花时间建造了这个应用软件却没有人用。业务部门为软件买单，却未能得到提高生产效率的好处。

另一方面，当你使业务与 IT 结合在一起，交付可用的解决方案时，双方都获得了成功。用户得到了他们可以使用的软件，业务部门得到了投资回报（ROI），而开发人员看到软件投入生产，得到了满足。

InfoQ：Thomas，你能给我们讲一下这个项目的更多细节吗？在组织中，哪些团队参与其中了？

TS：主要的业务客户是 FHLB-OF 的 Debt Servicing Group 以及和我们一同工作的客户的 IT 部门。开发团队由 Digital Focus 和客户的开发人员共同组成。我们也与系统集成团队一起工作，将发布的软件投入运行。纵向上是 Mortgage-related Financial Services。

项目的目标是取代 FHLB-OF 的 Debt Servicing Sytem(DSS)。这个部门每天使用 DSS 进行公债和其它债务的服务。对于 12 个 FHLB 来说，Debt Service 是非常关键的业务功能，服务必须有效且及时。

InfoQ：在这个 SOA 项之目前，你们与 FHLB-OF 在做哪方面的工作？

TS：在 Digital Focus 做典型的敏捷培训工作。不过我不是教练，另一个名叫 Tony Batucan 的教练在做这个项目。

InfoQ：那么，看来 FHLB-OF 喜欢将你们的敏捷方法充分应用于软件项目中，看看有什么不同。您是如何把敏捷方法引入 SOA 的呢？是你们发明了这种方法吗？

TS：是的，我们有一个四人团队创造了这个 Agile-SOA 方法。我们在 Agile 和 SOA 两方面都有专家。例如，我们使用敏捷方法交付项目已经有 5 年历史了。Jeff Nielsen 是 Digital Focus 的首席科学家和首席敏捷教练。他和我们一起将敏捷的价值带入了 Agile-SOA。我已经交付了很多基于服务的老系统（这些系统所用的技术要比现在的 SOA 工具要老），也有一些使用当前 SOA 技术的面向服务的系统。团队有还有一个人在分布式企业架构方面很有经验。

组建团队以后，我们把自己关在客户的一间会议室里长达一个月之久。在那里揣摩 Agile-SOA 方法的细节。我们甚至用 Agile 方法写了一个 Agile-SOA 方法。由于我们用一个月的时间去开发一种方法，并与我们的客户要在一个随后的项目中实现它，我们决定以每日迭代的方式来工作。我们每天早上有一个 Standup 会议，来讨论前一天的工作和当天的工作。同时计划下一步做什么，以及当天下午的可交付物。每天下午，我们会与客户一起讨论我们的进度，以及从昨天会议以后做完的工作。讨论进度以后，我们还会讨论明天将会交付给客户的功能，并确保我们理解了它们。我们也用这个会议来回顾项目并讨论任何存在的问题。与用户的会议以后，团队内部讨论从客户那里得到的反馈和新的需求。这个最后的会议结束了这个迭代，迎接下一天的开始。

这个项目的最困难的一个方面就是时间短，而团队成员本来已经很满的时间安排使其更加困难。而敏捷实践和极短迭代的就用，使我们可以平衡团队成员的时间安排。例如，Jeff 不能每天在客户现场。但他希望把他的方法的主题直接讲给客户听。所以，我们安排了 topic reviews，以便 Jeff 可以直接从客户那里得到反馈。

在项目最初一个月的月未，我们交付了 80 页的 Aigle-SOA 迁移文档，该文档向客户介绍了 SOA 和 Agile-SOA 实践。从第二天起，我们使用 Agile-SOA 方法为客户开始实现初期的 SOA 应用。

InfoQ：你们的迭代周期是多长时间？如何确定这个时间长度？

TS：在编写 Agile-SOA 方法的时候，我们使用每日一个迭代。选择这个时间长度是因为它让我们可以在有限的时间里可以得到最多的客户反馈。而对于真正的软件开发，我们用两周进行一个迭代。选择两周这个时长是因为它是 Digital Focus 公司默认的一个迭代周期。

InfoQ：这个方法也应用在其它项目上了吗？还是需要根据每个项目的不同都在项目开始开发一套类似的过程？

TS：这个方法与具体客户还是有一些关系的，但受影响的范围不会超过整个方法的 10%。和其它方法一样，这个方法的某个方面可能还是需要根据项目的不同而重新调整一下。

也就是说，我们开发的这个方法是可以应用到其它项目中的。我们开发该方法时考虑到了通用的 Agile-SOA 开发。我们的客户想要一种在未来 10 年中均可以应用到他们项目的方法，所以这个方法中的实践都是纯粹的软件工程实践，是任何 IT 组织都可以使用并可以从中获益的实践。

InfoQ：在文中你提到了频繁反馈循环。那么在项目中，您是如何跟踪您这种混合方法的有效性的呢？

TS：我们使用标准的敏捷实践来跟踪我们的工作和反馈循环。这包括发布计划、迭代计划、迭代 kickoff 会议、需求收集，每个迭代末尾的 UAT（User accessence Test）以及项目回顾。我们还有项目 steering meeting，使客户可以向项目领导层反馈，而不涉及项目团队成员。

有效性使用客户对应用和服务所提供的价值的满意度进行衡量。这属于主观度量，当然还有其它一些度量，包括上市时间、设计的灵活性，业务流程或应用的变化所节省的时间，增加新业务过程和应用所节省的时间等。

InfoQ：你能举个例子说明一下在 SOA 项目中，如何使用“Keep it simple（保持简洁）”原则吗？

TS：对于 Agile-SOA 的“Keep it simple”原则，最好的例子就是直到部署到实际运行环境中才最后确定你的 WSDL（它也是那个 WSDL 的唯一一个版本）。我看到过 SOA 项目在设计阶段以后就把 WSDL 固定下来。在面对灵活多变的需求时，WSDL 就会变得毫无意义。由于 WSDL 是服务提供方和服务使用方之间的接口，所以很难在写任何代码之前一次就把它完全正确的定义下来并一直使用。只有在实际运行环境中，固定不变的服务接口才是合理的（即，真正可以工作并通过了 QA 验证的代码）。而在开发该服务的过程中，一个固定不变却没有经过验证的接口是不合理的。

一个好的“keep it simple”原则是：除非某个功能至少有两个使用者，否则就不应该把功能做成服务。使用了 SOA 以后，就有创建大量不必要的服务的趋势，一种“build it and they will come”的思想。尽管服务很好，它能够使你的应用更灵活，但它也增加了你代码基础和测试策略的复杂性。

InfoQ：这个项目花费了多长时间？您估计项目使用原有的范例会用多长时间？您那时是根据什么做出这个估算的？

TS：创造这个方法用了一个月，但我想你不是指这个。使用这个方法的初始项目还在进行中，我相信它会在一年半内完成。

“原有的范例”是个有趣的提法。您是指原来客户使用的 C/S 结构程序，还是瀑布式 SOA，或严格的敏捷方法（不包含 SOA 的因素）？

客户正打算更换他们的 C/S 应用，而且不想用原有技术来构建新项目。也就是说，我想他们会在两年内重新实现一个现在正在使用的 C/S 应用系统。得出这样的结论是基于我对 C/S 开发方式的了解，以及我与客户方原有 C/S 系统的开发人员的讨论。

根据我对 IBM 公司宣传的 SOA 方法论的理解，我估计使用类似瀑布式的 SOA 方法构建这个项目，至少要花两年的时间，可能会更长。我觉得客户能够看到项目成果并提供反馈就至少是一年以后的事情了。这就带来了一个风险，即在这个应用软件投入使用之前，业务需求可能已经发生了变化，而那时已建好的服务已经没有什么用处了。

而使用敏捷方法重建原来那个 C/S 应用的功能并改为 Web 应用，可能花费的时间应该在一年到一年半之间，其依据就是我评估其它敏捷项目所得到的经验。另外，我相信使用 Agile-SOA 方法可能会在时间上增加 25~35%，但换回来的是可用的服务。

InfoQ：你们真的可以迭代式地交付可以工作的服务吗？也就是说，这些服务在项目结束之前就可以用吗？

TS：是的，我们已经有一些服务发布并正在被使用，而这个项目还在进行中。改进还没有投入使用的服务肯定是很容易的，但是当你考虑服务的版本以及向下兼容性时，你才能不断地交付有用的服务。

InfoQ：非常感谢，Tom。祝项目未完成的内容成功！

对 Digital Focus 案例的研究中发现确保 SOA 成功的关键要素有四个，它们是： - 理解客户需要实现的业务过程；

• 理解 SOA 架构与模式；
• 采纳一个 SOA 平台，使其可以随着 SOA 应用的进化而成长；
• 从客户和开发团队那里得到及时且频繁的反馈，以修正出现的问题。

以下是他们自己做 Agile SOA 项目中开发的六个步骤： 第一步：SOA 的介绍与培训；
第二步：将 SOA 与敏捷方法相结合；
第三步：定义长期的业务目标；
第四步：使用业务流程建模标识待定服务；
第五步：定义一个初始的软件平台；
第六步：定义并实现一个自包含的应用或子应用，作为你第一个发布计划的交付物。

你可以在 Digital Focus 的网站上看到这个案例研究： SOA，Meet Agile - Adopting SOA with Agile Teams

查看英文原文： Interview：Using Agile for SOA - - - - - -

译者简介：乔梁， BJUG 成员，在 IT 领域工作多年，先后从事过软件开发、架构设计、技术管理等工作，目前从事项目管理工作。关心软件技术领域发展，对软件生命周期管理及过程改进方面的内容很感兴趣，对敏捷方法论亦有所了解。他的个人 Blog 为： http://blog.csdn.net/tony1130 。与 InfoQ 中文站分享内容，请邮件至 china-editorial@infoq.com 。