InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

Zapthink:敏捷和企业架构并不矛盾

作者 胡键 发布于 2009年5月26日

领域
企业架构,
过程 & 实践
主题
敏捷宣言 ,
SOA ,
架构 ,
TOGAF ,
企业架构 ,
敏捷

最近,ZapThink发表了一篇讨论敏捷和SOA的文章:敏捷企业架构并非矛盾修饰法!。其独特之处在于从SOA的角度对敏捷宣言(Agile Manifesto)进行了重新诠释,提出了应用于SOA领域的4项原则。

在回顾了敏捷宣言的4项核心原则(作者这里所指的4项原则,实际是指敏捷宣言中的4项价值观)之后,作者Jason Bloomberg认为,部分原则是适合EA/SOA层面的,但并非全部,而且必须进行新的解释。接着,Jason对这4项核心原则进行改造,给出了SOA环境下的敏捷原则:

  • 业务驱动的应用优于服务抽象:在SOA核心,业务服务抽象的一项基本作用就是能够以业务流程为中心来组合增强业务和实现业务机动性的服务。这项原则重新解释了敏捷宣言中的客户合作部分,强调了业务交互优于服务抽象。
  • 架构驱动的迭代方法:采用迭代方法来处理不明确或持续变化的业务需求是一项久负盛名的技术。毫无疑问,所有敏捷方法论都具有迭代特性。同样,组织采用迭代方法来进行他们的SOA项目也是至关重要的。
  • 治理驱动的重用:对SOA来说,服务重用业务驱动力本质就是一项敏捷原则,因为它关注利用软件去满足相异的、持续变化的需求。治理在这里有一个特殊的作用,因为经过适当治理的重用可以给业务带来积极影响,可以使组织从IT资产获得的价值最大化。
  • 元数据驱动的开发:文档和服务元数据是有关联的,因为它们都代表了在服务生命周期内发挥重要作用的制品。但是它们之间有一个重要的区别——软件是给人消费的,而元数据基本上是给机器消费的。换句话说,聚焦元数据就是聚焦驱动开发出可以工作的软件。象元数据这样的文档越多,你就越符合敏捷原则中的“可用软件重于完备的文档”。

在他看来:

……SOA是一种EA风格,而且把EA框架、SOA最佳实践和一种理论联系实际的方法论结合起来是实现SOA项目成功的所有要素。正如象TOGAF这样的EA框架兼容SOA、象SOA这样的EA风格兼容敏捷方法论一样,没有理由认为EA框架一定和敏捷方法不和谐。

在文章的末尾,Jason强调了“多解决些问题,少谈些主义”的观点,并给出了一种解决“分析瘫痪(analysis paralysis)”的建议。

比起搞清楚实践技术属于哪个阵营,应用合适的实践去解决实际问题要更重要。因此,你正在从事的到底叫敏捷、TOGAF,还是SOA,真的不重要。只要你做的是解决手头问题的最佳实践,那么你的路子就走对了。

过于架构教条主义的一个常见风险是“分析瘫痪”。太早就把大把时间花在治理之上,几乎无任何意义可言,例如在你还没有任何东西要治理的时候。也就是说,你在每个迭代中需要少许治理。这里的核心最佳实践是采用一种迭代方法,对其他大多数任何事物,对治理,都一样。这是避免分析瘫痪的关键,并且通常用于处理不明确、定义不完整或不断变化的业务需求。这就是为什么迭代方法明确地在敏捷和TOGAF中都出现的原因,并且它也是SOA的一个核心部分。

InfoQ上已经报道了不少讨论SOA和敏捷之间关系的新闻和文章,如早期的Agile: The SOA Hangover CureSOA和敏捷:是朋友?还是敌人?访谈:用敏捷方法实现SOA,以及较新的Martin Fowler:SOA的敏捷之路

胡键 热心开源技术,《开源技术选型手册》作者,《SOA实践指南》译者。目前致力于Groovy/Grails的研究和推广。