【IT168 技术文章】
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 团队将会取得成功。他们一定不能将自己视为专家:他们需要认识到自己最终是为业务服务的。认识到这点将最终带来成功，而也正是这一点让组织进入下一个体系结构成熟度级别。
