SOA 治理成熟度——一名架构师的观点

我们平常可以看到有很多集成项目都使用 SOA 技术来努力使自己变得更成熟。这些项目交付了一些服务，但是却只有极少数能做到企业级的服务重用。个中缘由往往要归结于组织不知道如何成功地把他们 SOA 的成果由一个集成解决方案扩展至一个企业解决方案。我们认为，要想成功地交付这些 SOA 项目的商业价值，治理是必不可少的；因而，我们将在本文中介绍一种基于生命周期的 SOA 治理成熟度模型。在我们看来，治理可以被视为一种决策制定的框架，而这也与 Weill & Ross 的 IT 治理定义相符：IT 治理是一种规定了决策权力和义务的框架，其目的是为了鼓励 IT 使用过程中的合理行为。 [i] 我们的文章将由以下 3 部分组成： [ii] 。这个模型源自最佳实践和访谈，并且关系到 SOA 治理的范围。它认为，为了获得成熟流程的好处，主体之间的成熟度应该相等。尽管在开发该模型的时候并未有意地使用 SOA，然而我们认为组织范围是 SOA 治理需求的优秀指示器。

我们的模型是特意为架构师准备的；他们往往是 SOA 的拥护者。在企业架构、解决方案架构或领域架构中，你都可以发现他们的身影。架构师对于启动 SOA 治理起到了重要的作用，但是随着企业内 SOA 成果的不断增长，架构师的职责发生了改变，部分这些职责将很有可能转移到一个 SOA 治理委员会身上。

我们的治理模型可以帮助架构师判断其企业 SOA 治理的当前成熟度水平。这个模型还给架构师就其在 SOA 治理向更高成熟度级别前进过程中发挥的作用给出了务实的真知灼见，给他们在组织内增进和拓展 SOA 的成功提供了便利。

SOA 治理的生命周期

SOA 治理相关的活动并不是马上要求构建可工作服务的活动，而是那些所有可以提高 SOA 整体质量并且支持在复杂环境中进行控制的活动。这包括：

• 人员 —— 确保职责已经被分配到合适的岗位，人员已经被培训具有必需的知识和能力。
• 流程 —— 确保已经制订出合适的服务质量保证和监视流程。
• 产品 —— 设置所需服务和它们的文档；策略是一个常见的例子，服务文档模板也属于此类。

我们在一个 SOA 治理生命周期模型中已经说明了这些主题。这个模型定义了实现优秀 SOA 治理所需执行的 6 个主要流程。一个生命周期代表一次迭代，它是面向服务架构实施过程中一个范围限定、实现具体目标的项目。SOA 开发发生在 SOA 治理生命周期的许多迭代中。通过这些迭代，成熟度水平可以（而且应该）得到提高。

头两个流程集中于业务，说明了 SOA 愿景和对组织的影响。接下来的 3 个流程组成了架构师关注的要点：服务组合管理（Portfolio Management）、服务生命周期管理和策略执行。最后一个流程，服务水平管理，属于系统管理员的范畴。但是，在整个生命周期中，活跃于 SOA 治理中的所有团体都必须涉及到。这些团体是如何参与的将在 SOA 治理生命周期的每条流程中进行描述。

SOA 的愿景

迭代的第一部分就是确立 SOA 的长期目标，或修订现有目标。这个流程从组织角度对 SOA 进行了详细阐述，同时还包括设定生命周期当前迭代的目标。SOA 的愿景是业务和 IT 的结合产物，其中业务和 IT 的对齐由架构师负责推动。

创建 SOA 组织

在这个流程中要定义 SOA 治理的角色和职责。这常常导致了某种类型的 SOA 治理委员会（或卓越中心）的建立。这个委员会应该代表 SOA 治理的干系人，既包括业务人员，也包括 IT 人员。这个 SOA 治理委员会决定了 SOA 治理生命周期的实现方式。本文的后续内容将给出相关的指导方针。为了执行当前的生命周期迭代，合适的人员应该出现在合适的位置。这不仅可能需要一些额外的培训，而且资助和激励程序也可能是这个流程中的活动。SOA 治理委员会应该通过在组织中强制标准和提倡 SOA 原则来改善 SOA 原则的采用。

服务组合管理

对于即将开发的服务，综合业务代表和多方意见是必要的。在开发特定服务时，架构师应该权衡 IT 和业务的意见。通过从一开始就介入组合管理，架构师应该能够发现适合重用的服务，因而要优先尽早地开发它们。服务组合管理的一个可能产品是服务路线图，它列出了当前和已规划的服务。

服务生命周期管理

这个流程解决了企业服务的实现、更新和退役。生命周期管理不应该是各项目的事，而应该由 SOA 治理委员会来完成，统一管理 SOA 的变更。SOA 变更涉及概念上的、企业范围内的服务，这些服务被重用并执行业务功能。架构师在 SOA 治理委员中应该协助确保所有服务都被纳入生命周期的管理，防止出现未被治理的服务。

策略执行

这个流程关心的是策略的设计和执行。例如，架构师应该确保人们将自己的服务发布到注册中心中，以便这些服务可被治理和重用。架构师同样还应注意策略在设计层面的应用。设计层面的策略是服务开发的标准，通常以原则或最佳实践的形式出现。与运行时策略不同，设计时策略一般无法被自动监测。因此，需要说服开发者去遵循标准。架构师应该审查交付的新企业服务，并且在审查中，设计时策略的采用应该作为一个重点工作内容。

服务水平管理

不同于其他 IT 架构，SOA 要求不同的服务水平管理，原因在于服务的粒度比应用的粒度更细。同样，要想灵活地消费别人开发的服务就要求消费者能很好地理解服务水平。服务水平管理是一项系统管理员的任务，但是架构师应该注意服务水平的反应，以便可以和企业讨论这些水平是否仍然适合企业的用户。而且，通过审查服务的使用（可能是通过注册中心的工具），有望发现服务重用的机会。

使用生命周期增强 SOA 治理的成熟度

与成熟度模型相结合后，所提议的 SOA 治理生命周期中的那些流程会变得非常有帮助。关于（SOA）成熟度模型已有大量的出版物，基本上任何成熟度模型都可结合 SOA 治理生命周期使用。这些成熟度级别需要有某种类型的规范来说明 SOA 治理每个阶段的预期内容。这可以通过一个矩阵来完成，其中确定了每个成熟度级别的 SOA 治理生命周期流程的范围。在下面的例子中，我们使用了德勤（Deloitte）的业务成熟度模型

• 先驱（Pioneer）：SOA 包含了几个小规模的项目，为确定最佳实践提供了灵活性。这些努力往往是速赢的（quick-wins），而且会带来轻微的组织复杂性。只有极少的 SOA 治理，重点关注项目的范围。因为通常有一个 SOA 的拥有者，控制并不非常复杂。
• 流程（Process）：在此阶段，一个组织单元、产品或流程完全服从 SOA。SOA 常常出于特定目的而被实现，如库存管理。此阶段有一个拥有者总负责，并为 SOA 提高主要的资助。但是，架构和组织中其他地方的 IT 发生关联，因此 SOA 的治理需要多方达成一致意见。由于牵涉的人更多，导致治理的需求增加了。
• 系统（System）：此阶段的 SOA 由多个业务拥有者控制。这意味着 CxO 级别的支持是必要的，而且 SOA 治理需要集中化。SOA 治理指定了组织中所有各方后续 SOA 实现所遵循的标准。
• 网络（Network）：SOA 由不同的、积极参与的组织协调。这些组织彼此提供服务，这些服务相互连接，对端到端的业务流程提供了支持。这意味着这些参与方的 SOA 治理需要一致。缺乏正确的治理，服务变更将对业务运营造成重大不可预知的影响。

下表就每个成熟度级别的 SOA 治理生命周期阶段的需求变更给出了一些提示。它们并不是必需步骤，而是在实践中改进 SOA 治理的可能方法。这些提示可以在其他成熟度模型的类似矩阵中使用。拥有这样一个矩阵的好处是：它形成了一份简单的 SOA 治理发展道路概览。它还给组织提供了某种关于 SOA 成熟度级别的“健康指标”。

先驱

流程

系统

网络

SOA 的愿景

确定概念尝试的范围

小规模 SOA 的业务建议

确立与业务战略保持一致的愿景

通过 SOA 有可能将大范围的业务建议连接起来

创建 SOA 组织

发展技术技能

协调 SOA 治理和其他 IT 治理活动

搭建 SOA 治理结构

和网络伙伴一起创建网络化的治理委员会

服务组合管理

识别导航项目的服务

针对选择的服务更新业务用例

组合流程的规范化

建立服务开发来源的标准

服务生命周期管理

维护服务列表

跟踪服务生命周期各阶段

对存储所有服务的注册中心进行规范化

和网络伙伴一起协调服务生命周期

策略执行

记录最佳实践

规范化使用和开发服务的原则

建立策略执行的过程

确定网络伙伴间的执行点

服务水平管理

确保足够的运行时间

监视服务水平

确定每个服务的 SLA 和报告

和网络伙伴一起确定 SLA 和 SLA 报告

表 1：成熟度级别相关的治理流程范围

使用成熟度开发一个不断成长的 SOA

除了改变 SOA 生命周期各流程，增加成熟度还会改变 SOA 在组织中的影响。下面的模型展示了治理成熟度级别的这种转变。它表明，在第一个成熟度级别中，我们不能说组织中有“一个 SOA”。不同的小规模面向服务解决方案是被单独构建和治理的。为了获得更多企业范围内的好处，对这些先驱 SOA 进行了分组治理。分组可按业务流程进行，正如流程成熟度级别的名字所暗示的，但是按照业务单元或地理区域划分可能也不错。随着 SOA 成为企业范围的解决方案，治理要向一个集中的治理模型靠拢。甚至这个系统治理控制范围显示有边界，这意味着有可能把治理扩展到特殊部分。在最后一个成熟度级别，治理控制是在网络伙伴间协调的。来自不同组织的治理委员会可能会坐在一起，就彼此的框架和方法论进行共享和协调。

图 1：随着 SOA 控制范围的不断成熟，SOA 治理的生命周期在不断演变

一个组织中可能同时存在不同的 SOA 项目。一个 SOA 可能处于比另一个更高的成熟度级别。多个 SOA 域可以单独发展和治理。一旦成熟，它们就可以和另一个 SOA 控制范围合并。成熟度级别可能会随着功能、流程或组织单位不同而不同。例如，通过包含供应商的服务和设置服务开发生命周期的标准，采购部门可能表现为网络成熟度级别的特性。同时，HR 可能仍在使用自己的来自更低成熟度级别的治理结构。这并不见得是件坏事；隔离的环境可以有单独的治理。

另一方面，一个 SOA 域（以治理术语来讲是控制范围）内的成熟度要在治理流程间保持均匀。例如，服务生命周期的治理应该在策略执行上取得一致，因为成熟度低的执行不可能发生在一个复杂、成熟度高的环境中。

那么这又回到了 SOA 治理的生命周期。在“SOA 的愿景”流程中，SOA 治理的目的和成熟度目标应该确定清楚。这时组织可以建立一个系统级别的 SOA 治理委员会，但是标准化也可能按领域架构师在更小规模上存在。这将有助于使 SOA 治理高效，并适合它的目的。裁减过的治理也更可能高效，系统级别的委员会并不一定需要讨论只和一个控制范围相关的问题。

给身处成熟中的 SOA 治理环境的架构师的指导

架构师是组织内 SOA 努力的重要发起者，而且在其后的过程中也举足轻重，因为他们一般既能很好地全面把握，又能看到实际的内涵，但同时也能从战略愿景出发进行行动。架构师还是 IT 和业务之间重要的沟通者。由于这种有利位置，架构师会发现自己在企业内处于拥护 SOA 范式的位置。但是，并非所有架构师都适合所有 SOA 相关的活动。

根据以上的成熟度模型，我们将给架构师提供一些实用的指导方针，好让他们能帮助企业最大化当前成熟度级别的 SOA 潜力，并帮助他们推进 SOA 的成熟度级别。鉴于架构师的类型繁多，职责不同，我们将首先给出 SOA 环境相关的架构师角色的概览。这里，我们将遵照 Mike Kavis 给出的一份实用的架构师角色 [iii] 。

• 首席架构师连接了这些 SOA 架构师，并向 CxO 负责。首席架构师当然要参与定义 SOA 的愿景，但是也应该指出 SOA 治理的方向。
• 企业架构师要使 SOA 中的业务和 IT 需求对齐。这类架构师会通过和业务人员交谈来得到需求。企业架构师要重点参与服务组合管理。
• 解决方案架构师具备实际的技术经验。因为面向服务技术的技术优势，他们可能是 SOA 的拥护者。
• 领域架构师具备他们参与的业务领域相关的知识。这种架构师应该拥护原则，并将它们和业务解决方案挂钩。领域架构师是制订标准的优秀候选人，并决定这些标准在什么情况下可以有例外。

下表显示了在每个成熟度级别架构师可能的关注点。我们补充了架构委员会，它由不同的架构师角色组成，并作为责任主体为组织内的长期架构决策服务。由于我们关心的是治理，因此，这些架构角色的职责和 SOA 设计期是不同的。

下表按成熟度级别显示了这些角色的关注点。

角色

成熟度级别

先驱

流程

系统

网络

首席架构师

从导航项目吸取教训

建立公司的 SOA 愿景，强调标准的重要性

强调服务集成和服务重用的重要性

与关系链中的首席架构师一起积极参与

企业架构师

被告知导航项目的结果

确定组合流程，包括服务需求

管理服务组合；协调不同领域

寻找网络中的服务组合间的集成

领域架构师

确定导航项目的需求和范围

确定领域相关的标准

寻找和其他领域集成的好处

协调网络伙伴间的领域标准

解决方案架构师

尝试不同的支持应用和实现方法

确立服务生命周期管理的标准、策略执行和服务水平管理

协助创建企业范围的服务注册中心

更新标准，创建服务共享注册中心

架构委员会

确定导航项目的后续工作

验证并批准标准

对重要项目进行决策

在协调所有伙伴间 SOA 中的服务过程中提供支持

表 2：不同 SOA 成熟度级别中的架构师角色的关注点

总结

在本文中，我们解决了与 SOA 成熟度相关的治理问题。解决办法是：

• SOA 治理应该关联到主流程的框架
• 使用成熟度模型，将其和所有的 SOA 治理流程联系起来
• 描述架构师在 SOA 治理流程中的参与方式

这些努力中的架构师职责并不是一成不变的。我们对架构师在不同成熟度级别的不同流程中的领导和支持方式给出了一些实用的指导方针。架构师需要解决不同成熟度级别的不同治理问题，因而其要求及必需的素质和技能随成熟度级别的不同而不同。而且，本文给出的指导方针绝非普遍真理。架构师要根据情况随机应变。

架构师是 SOA 项目的优秀发起者，而且他们可以为组织中第一个不断成熟的 SOA 及其治理担负起责任。然而，出于对 SOA 解决方案和治理走向成熟的考虑，业务必需发挥主导作用。架构师要和业务与 IT 代表分享治理委员会的职责。架构师最重要的职责可能是保证业务和 IT 的对齐，这就要求特殊的沟通和协调能力。一旦业务和架构师有了很好的理解和共识，并通过治理使其正式确定下来，SOA 就能长久的发挥作用，实现对企业的业务承诺。

如果您需要这一主题的更多信息，请随时联系我们： tschepers@deloitte.nl 和 bkratz@deloitte.nl .

参考文献

[i]