文章:SOA 和敏捷:是朋友?还是敌人?

阅读数:35 2007 年 4 月 21 日

话题:SOA敏捷方法论架构文化 & 方法

SOA 的目标是以服务作为构建企业应用的“积木块”,使整个企业敏捷起来,而敏捷软件开发则是通过引入一些最佳实践来增加沟通与反馈,以达到同样的目的。InfoQ 贴出这篇文章的目的是归纳在这一主题上的观点,以便社区进一步交流与沟通,即SOA 和敏捷:是朋友?还是敌人?

这篇文章给出了对上述两种技术正、反两方面的观点,读者们已经开始讨论,并表述各自的观点。

该文建议说,尽管 SOA 是一种架构,而敏捷是一种开发方法论,但它们并非是完全正交的。

一方面,敏捷方法(例如 XP)直接关注设计,不是特别同意预先做大量设计 (BDUF) 的观点。另一方面,大多数 SOA 团队主要是围绕构建一系列服务而组成的功能性团队。SOA 本质上鼓励有特性的团队结构和团队间的沟通方式,而这两点又都属于方法论的范畴。

根据这种评判原则,该文提出了它们的主要重合点——即二者都关注“使业务敏捷起来”,随后深入讨论并提出了这两种实现方法的三个主要交叉点:

  • SOA 鼓励架构设计在前,而敏捷对这种称为“BDUF”的方法持相反观点。
  • SOA 鼓励按功能线索来划分团队,而敏捷倾向于以交叉功能式组建团队。
  • SOA 中,服务一旦建立起来,SOA 就不再对服务的变化做出相关的反馈,而敏捷则强调及时反馈,无论是技术层面,还是人的层面。
  • 关于这个主题已经引起了广泛的讨论。主要的讨论思路已经在这个贴子中提及。所以接下来的引证直接来源于这一主线。至今,大多评论者都未发现 SOA 和敏捷之间的交叉,当然,有一部分人同时支持这两种方法。

    Frank Grossman 认为,在企业中,根据 SOA 的本性,很多的敏捷实践(如代码共享)可能被改变:

    代码共享制也上升了一个层面。在项目层面的敏捷实践中,整体团队拥有所有的代码。而 SOA 层面的敏捷实践中,设计规约的交叉功能团队拥有 XML 软件层所有权。事实上,可以认为它是 SOA 所有者(就像是 Scrum 中的产品所有者),代表整个企业的目标。这个 SOA 所有者负责维护 SOA 列表, 并通过 XML 软件层的一系列的迭代,来指导一个或多个“XML 开发团队”。这个 SOA 列表包括已划分了优先级且能满足市场要求的业务需求。

    而 Howard Deiner 认为,不应该草率地分解 SOA:

    根据我的经验,一次就正确地分解一个 SOA 是非常困难的。在一个商业性企业中,存在很多不确定因素。在那样的环境下,大多数情况是在最终把业务流程实现成一组服务之后,却发现这些服务并不是我们真正想要的基本业务组件。所以,如果我们希望 SOA 一开始就成功,就必须理解并承认使用敏捷技术的重要性,敏捷技术使我们可以设计、构建、测试并验证每个 SOA 组件的可用性。当然,这也需要一点 BDUF,但边界可能要宽松一些,以便在后续的迭代中做架构刺探(architectural spike)时,各组件边界间的空隙足以将代码形成解决方案。

    这是一个目前关于软件开发社区中两大阵营交锋的有趣话题。

    阅读全文并参与评论:SOA and Agile: 是朋友?还是敌人?