BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

访谈:用敏捷方法实现SOA

| 作者 Deborah Hartmann Preuss 关注 0 他的粉丝 ,译者 乔梁 关注 7 他的粉丝 发布于 2007年5月27日. 估计阅读时间: 17 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

现在的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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT