最近， 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 Cure 、 SOA 和敏捷：是朋友? 还是敌人? 、访谈：用敏捷方法实现SOA ，以及较新的 Martin Fowler：SOA 的敏捷之路。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论