SOA 成熟度模型 是我提出的一个术语，用于帮助您定义体系结构指南和流程，以在总体信息技术 (IT) 体系结构活动中实现较高的成熟度和可猜测性级别。我在本文中描述的模型可以帮助您的组织标识自己所处的级别(一到五级，五级是体系结构成熟度级别最高或最成熟的级别)。该模型还可以帮助您实现真正的面向服务的体系结构 (SOA)，这在成熟度曲线上定义为第 5 级。SOA 成熟度模型的迭代应用程序答应 IT 组织向前发展，从而经济高效地满足快速变化的业务需求。通过使用此模型，我演示了可以如何在每个成熟度级别实现更多的架构目标。
成熟度模型的重要性
在较低的成熟度级别，个体项目团队使用非标准技术定义自己的体系结构。这些技术导致解决方案的可猜测性和可重复性都较差，通常难于治理，对更改的适应能力也不强。随着组织不断成熟，成熟度达到了第 3 级和第 4 级，将出现强大的企业体系结构(EnterPRise Architecture，EA)组的参与，控制相关的体系结构原则。出现了可重用体系结构的元素，可以灵活地满足其服务的每条业务线 (LOB) 的需求。此解决方案通常十分高效，提供了一定水平的互操作性，为“面向服务”打下了基础。我将第 5 级组织定义为成功实现了其 SOA 活动的组织。此类型的组织具有绝对的自主权，已经发展到在 LOB 间真正构建和共享服务的程度(甚至能与客户、合作伙伴、供给商和竞争对手进行此类活动)。
此模型应用于公司 IT 体系结构的各个方面。它不仅对开发方面有很大的影响，对 IT 组织内的体系结构(例如，部署、逻辑、物理和流程)也同样重要。
SOA 成熟度模型
能力成熟度模型 (CMM) 用于测定组织软件开发流程 的成熟度，而 SOA 成熟度模型则以测定组织的 SOA 开发流程 的成熟度为目标。我将 SOA 成熟度级别定义为五个步骤。图 1 显示了一个基本 SOA 成熟度模型。
图 1. SOA 成熟度模型
第 1 级:初始化
第 1 级的组织通常没有正式的体系结构流程。体系结构没有从项目分离出来。通常，这些组织不具有 EA 团队;每个项目团队通常根据 LOB 划分，彼此独立地进行工作。精力主要放在交付单个项目上。
此级别的结果包括项目计划不可猜测、预算超支而且代码质量差(通常不能重用，且难于维护)。各个项目重复相同的任务——这将导致交付和维护成本的增加。在此成熟度级别(相当不成熟)，IT 通常对业务灵活性具有决定性，而不是别的情况。
第 2 级:可重复
在此级别，进行了一些体系结构方面的工作。项目团队通常定义一个可重用体系结构，在多个项目间使用。项目团队之间建立了非正式的通信渠道。一个 EA 团队将帮助在较为混乱的环境中形成结构，促进项目团队间的通信;不过，在此阶段，仍然很少存在此类团队，通信是临时性的，较为混乱。
此级别的结果包括对体系结构组件的一些重用。临时流程和较为混乱的通信路线使体系结构解决方案中具有一定的可重复性，因而降低了软件的交付成本和维护成本。不过，从资金的角度而言，此成本节约不甚明显。
此级别的成熟度的最大优势在于实现了结构化的流程可以提供的优势。例如，项目团队正逐渐熟悉到软件开发的协同方法的潜在优势。他们熟悉到可以防止巨额的成本超支、创建可猜测的软件开发计划并提高软件的总体质量。在项目团队之间创建这些临时的通信线路的支持者可以就此向治理层寻求支持，以向 EA 组织发展，或至少获得对更佳的体系结构活动的正式认可。
第 3 级:已定义
第 3 级的组织在 EA 活动方面进行了一些投资。配备了 EA 团队，为其指定了对体系结构元素进行标准化的任务，负责进行创建参考体系结构的活动，就此体系结构对项目团队进行培训，并定义控制和执行策略。通常，EA 团队将创建一组技术组件和框架，然后标准化各个项目团队间对这些框架的使用。
不过，EA 团队活动所带来的开销可能超过其增加的价值。EA 团队带来的最大的单项成本是体系结构维护成本。在目前紧张的经济环境中，EA 通常不会进行维护，因为核心体系结构团队将回头进行项目交付。这将降低了 EA 的价值和适用性。此级别的另一个问题是团队之间的“拔河”问题。项目团队并非真的尊重或喜欢 EA 团队的“窥探之眼”。与此类似，EA 团队成员可能缺乏给定 LOB 的具体业务知识，可能无法与执行 LOB 服务的项目团队有效地进行通信。那么，此级别的成熟度的吸引力到底何在呢?
此级别是识别 SAO 需求的第一步。EA 工作似乎没有效果，因为这些工作通常不够灵活，不足以满足跨多个 LOB 的需求。缺乏业务领域知识是 EA 团队的一个大问题。熟悉到这个不足的 EA 团队将会取得成功。他们一定不能将自己视为专家:他们需要熟悉到自己最终是为业务服务的。熟悉到这点将最终带来成功，而也正是这一点让组织进入下一个体系结构成熟度级别。
第 4 级:已治理
当 EA 团队开始定义 SOA 路线时，就达到了这一级别的成熟度。今天，每个大型组织都有一群架构师在谈论 SOA。最起码的，这些架构师看起来已熟悉到 SOA 的价值，并在尝试形成 SOA 策略。
假如组织的 SOA 活动主动参与为 LOB 服务的项目团队的工作，则此组织可归到第 4 级。项目团队和 EA 团队需要进行协作，以定义组织的 SOA，包括流程、技术和组件。应该定义控制和“奖励”策略。需要建立支持级别，且要清楚地了解何时联系某人以及进行联系的原因。必须配备分析人员用来定义服务的框架，如:
LOB 或项目团队如何表示可以公开或需要其他项目团队提供的潜在服务?
谁负责构建和维护此服务?
谁支付其费用?
这些是此级别的 SOA 计划需要回答的问题。
此成熟度级别有很多风险，也有很多好处。尤其需要注重，务必熟悉到第 4 级的短期成本优势很小，甚至没有短期成本优势。对于任何组织而言，达到第 4 级和执行该级别的活动开销都非常大。假如做法得当，它将使组织达到 SOA 成熟度模型中的第 5 级。假如做法欠佳，组织很有可能降到第 2 级，因为将解散 EA 团队或该团队对业务的支持几乎为零。
第 5 级:优化中
第 5 级是“极乐世界”。体系结构流程和策略都已制度化。对服务价值有了清楚的熟悉。配备了框架，供每个团队公开和使用服务。在此级别，组织可以真正地充分利用 SOA 的价值。他们开始了解如何与其业务合作伙伴、供给商和客户交换服务。
为了实现最大业务灵活性，业务服务级别的重用(不限于技术组件)成为了体系结构的核心。在此级别，组织将看到拥有可以迅速响应业务需求的灵活 IT 组织的成本优势和时间优势。
此级别的主要目标是定义体系结构活动的终结点。需要明确地定义高标准和目标，从而加以实现。假如没有此级别，组织通过第 4 级所带来的开销将不能得到回报。
每个级别的特征和影响
现在您已经了解了 SOA 成熟度模型的五个级别。表 1 从一个概要地说明了成熟度的每个级别的特征和影响。
表 1. SOA 成熟度模型级别概述
级别
特征
影响
第 1 级:初始化
没有正式软件开发流程。只存在很少的体系结构文档。项目团队之间不进行通信
项目之间不具有体系结构一致性。难于理解和修改生成的系统。只存在很少的可重用构件。团队为每个项目都重复相同的工作。
第 2 级:可重复
有一些体系结构文档。体系结构在项目团队内执行。项目团队之间有临时的体系结构通信。
相对于第 1 级而言，有一些小改进。一些成功的实践是可重复的。熟悉到 EA 工作可能很有价值。
第 3 级:已定义
配备了 EA 团队，该团队定义了参考体系结构和一些软件开发实践。鼓励项目团队使用此结构，但不会因为使用此结构而得到奖励。EA 并不满足每个 LOB 的所有需求。
难于达到一致:EA 团队和项目团队的协作不甚理想。体系结构维护的问题很大。体系结构的有效期为 6 到 12 个月。
第 4 级:已治理
SOA 被认为是体系结构活动的终结点。LOB 和 EA 团队定义了一个 SOA。配备了支持和控制模型。LOB 会因公开和使用服务而得到奖励。
早期的成本似乎太高昂。它降低了由于体系结构层不一致而导致项目延迟的风险。组织内的 SOA 看起来似乎有一些冲力。
第 5 级:优化中
SOA 成为一个起点。组织希望探索与其客户、供给商和合作伙伴相关的服务定向。有持续的体系结构优化。
业务具有灵活性。能与来自客户、合作伙伴、供给商和其他方面的服务进行互操作。推向市场的时间更快。总体拥有成本 (TCO) 更低。
总结
本文介绍了 SOA 和 SOA 成熟度模型的基本概念。直接着手 SOA 项目并非始终是最好的出发点。组织必须确定在其 SOA 活动中首先要进行的步骤是什么。为了成功地在组织中实现 SOA，首先需要了解您组织的 IT 状况和总的体系结构。SOA 成熟度模型正是用于此目的:一种帮助您确定组织的 IT 体系结构的成熟度级别的方法。完成此评估后，您将获得确定组织的最佳 SOA 路线所需的信息。
通过应用此模型，EA 组可以确定其需要向各个 LOB 提供的服务。此外，咨询和外包公司可以使用此模型来构建希望加入到其提供的服务中的服务的列表。
