建立服务治理组织

Service，物理上类似海运服务，或被软件代理商所实现的服务，总是被设计与提炼成被尽量多的消费者所重用。这是面向服务架构的本质：降低成本、风险以及通过分解和实现可重用的 IT 资产来减少构建解决方案的延迟，这些通常在设计阶段处于未知状态。同样的 SOA 治理与数据和 IT 治理没什么区别，数据和 IT 治理致力于设计信息模型或选择超越给定项目边界的可重用技术。服务必须被治理为可重用的：所有可预见的消费者必须能表达他们的需求，这些需求接下来被划分出优先级和阶段，同时服务拥有者被指派且投资模型被建立。

在前一篇文章中，Stefan Tilkov 更多关注的是 SOA 治理中的角色 (1)。我这里的目标是帮助你按照人员、过程和技术情况建立一个服务治理组织。

服务治理宪章（Charter）

服务治理的主要目的是通过培育可重用的、企业级服务来获得面向服务架构的好处。作为一个功能交叉的组织，服务治理确保及时解决在定义共享需求时由所做的必要折中带来的问题和冲突。

尤其是，服务治理组织被赋予特权以定义清晰的服务所有权边界和指定一个公正的投资模型。

服务治理监控着横贯组织服务的部署和重用。一个高的服务重用度、一个稳定的企业级服务部署流程、以及无痛的服务退隐是治理成功的指示器。

服务治理不应该与传统 IT 治理及企业架构（Enterprise Architecture）重叠；它们定义了 SOA 技术标准和引导增加 SOA 成熟级别的路线图，同时服务治理组织被委以进化服务全貌（landscape）的重任。

通常，服务治理的角色是被动的，过程候选服务通过特定项目或在业务单元级被识别。只有当一个组织已经达到了高成熟度级别，服务治理才可能启动一个系统的自上而下的企业服务辨别并许可它们的实现不依赖于任何项目。

在任何情况下，治理组织应该被授权不依赖于最初消费服务候选的项目预算和资源限制来建立企业级服务。因为可重用性通常伴随着更大的范围发生，这将导致更高的价码。

治理组织管理服务定义（它们期望被作为公司资产来管理）。它还负责维持其他企业资产（如业务过程模型和参考数据模型）的可追溯性和一致性。我们将在本文的最后一部分回到参考或企业数据模型上来。

人员

前面提到的文章是从服务实现的角度描述了角色涉及的服务治理活动。当一个组织开始其面向服务架构时，这些角色足以保证企业级服务交付，尤其是当他们属于一个卓越的 SOA 中心时。

角色 描述 业务服务所有者 - 指导并控制服务实现、进化及退隐

• 拥有服务的功能范围、服务级协定
• 有效管理服务性能以满足治理要求并确保适当级别的重用
• 向治理组织报告服务活性

技术服务所有者 - 执行服务实现、进化和退隐

• 拥有操作级别协定并管理服务以满足其在可用性、性能、安全方面的目标
• 监控服务以识别潜在的关于 SLA 和 OLA 的问题
• 向业务所有者报告服务活性

SOA 平台架构师 - 与 IT 和 SOA 治理组织一起建议并讨论 SOA 技术标准

• 确定服务实现是符合标准的

服务开发者 - 帮助领域架构师和平台架构师从事治理相关活动

• 实现治理策略和推荐

当一个组织走向成熟且众多服务候选逐日递增时，引入一个治理领导是有益的，他将拥有过程和资源以确保治理活动被适当的执行，而问题在某种程度上被及时解决。他应当得到一个功能交叉的治理委员会和一个服务库管理员的协助。

角色 描述 治理领导 - 从人员、过程和技术角度全面管理治理活动

• 对服务生命周期负责
• 对服务重用程度负有责任
• 这一般不是一个全职角色，可由领域或平台架构师担任

治理委员会 - 回顾服务候选提议

• 推荐服务所有权及投资模型
• 解决与消费者需求优先级、服务所有权、投资模型、进度表、SLA 和 OLA 相关的问题
• 这是一个功能交叉的团队，覆盖尽可能多的领域

服务库管理员 - 管理关联服务注册和服务仓库的服务生命周期活动

• 维护注册分类法
• 确保正确的数据及元数据存储到仓库中
• 同样，这一般也不是一个全职角色，可与架构师角色混合

我们看到了关于服务治理组织的三个主要成熟度级别。

成熟度级别 组织 设立 - SOA 项目最近已经开始

• 一个卓越的 SOA 中心沉着冷静的管理 SOA 项目的所有方面，包括平台定义和部署、服务构造和所有权、以及 SOA 治理
• 正被构建的服务数量相对较小
• 还不需要注册，因为所有服务相关活动还是发生在一个小团体内部

执行 - 注册和仓库被部署，用来管理治理过程和元数据

• 治理领导和一个服务库管理员被指派
• 服务仍在 SOA CoE 之内构建，但是是以每月几个服务的速度支持关键任务解决方案
• 在有些情况下，形成一个 SOA 委员会是为了讨论特殊问题

优化 - 一个 SOA 委员会被指定并定期开会讨论服务候选提议

• 由 SOA 治理组织定义并管理一个服务路线图，以帮助在项目需求之前启动服务实现

图 1 描绘了涉及服务治理的角色之间的一些交互。

Figure 1. 不同治理要素之间的交互

构建一个成功服务治理组织过程中的关键也是敏捷的，并且汇聚恰好足够（不要过多）的资源、过程和技术以满足你的需求。一个没有合理服务候选管道的大型服务治理组织很快就会泄气并错过给一些服务候选足够反馈的机会。

你只是想不多不少构建一个将能促进服务重用的组织。

过程

过程和活动

有 5 种活动需要由 SOA 治理组织来履行：

• 服务候选管理
• 服务变更管理
• 服务消费者管理
• 服务路线图管理
• SOA 治理策略变更

图 2 展现了一些可以在服务候选管理过程期间执行的活动。一个项目团队可能识别了一个服务并创建了一个服务提议。接着该提议被送审，可审核为更正或拒绝（作为一个企业服务来说，当该服务候选没有被企业其它部分重用的潜在可能时，被审核为拒绝）。

一旦服务候选被接受，服务所有者和投资模型被定义，并且在服务所有者和潜在消费者的帮助下指定 SLA 和 OLA。

一旦服务被实现，它的元数据被发布在注册和仓库上。在大型组织中，建议在构建过程中保持对这些服务的跟踪，以免出现重复的服务提议。

变更管理活动通常与服务候选复审期间所执行的活动是相同的。像服务所有者、投资模型或 SLAs/OLAs 描述这样的活动是可选的。

变更管理的一个关键方面是有效管理向前兼容服务（2）。

服务消费者管理活动大都由服务库管理员来执行，除非为了使新消费者消费服务必须进行变更。管理员可以帮助服务消费者识别目标服务并获取其元数据的一份拷贝。

如果服务治理行动提前识别了没有特定项目需求的服务，服务路线图管理活动将被提供。这时候，服务治理应该有预算得以在要消费它们的项目开发之前开发这些服务。这是治理成功的关键因素，因为可重用服务的设计和实现可能超越了给定项目的范围、手段及进度表。治理活动本身需要花费时间并且可能对一个服务候选推荐了冗长的升级。这就是为什么它如此关键，治理组织用一种及时的方法来管理进度表和阶段消费者特定需求，将交付解决方案的进度表所带来的影响降至最小。

图 2. 服务候选管理活动

最终，一个治理组织可以从事 IT 治理以定义或改变其操作策略。

服务元数据

服务候选提议中包含服务接口的描述（不一定非要用机器可读格式）以及涉及该服务的所有功能和非功能需求，这些将用于定于如 SLAs 和 OLAs。CBDI 论坛 SOA 服务架构和工程元模型 (3) 就提供了一个很好的与服务有关的信息视图，这些服务在生命周期早期阶段被捕捉并随时间推移不断提炼。

CBDI 论坛 SAE™元模型包含了服务定义，它包括建议操作、策略和相关服务、以及服务分类。CBDI 论坛的推荐还包括业务级别服务定义，它将业务过程、业务能力、业务规则等与服务定义关联起来。

当消费者正在搜索一个特定服务时所有这些信息可以潜在地被使用。这就是为什么以结构化的方式捕获它很重要，即使是如 WSDL 这样机器可读描述不支持这种类型的信息。

CBDI 论坛 SAE™元模型为服务规范提供了一个单独部分。有意思的是，这一部分元模型跟踪在涉及服务中作为操作参数的的信息类型。WSDL 不能很好的支持这一能力，例如，它只定义了作为操作调用一部分进行交换的业务类型表示，而不是定义业务类型本身。

信息类型的可追溯性是关键，因为它防止引入操作特定的语义。一个消息类型应该总是被定义为接近于参考数据模型。事实上，当与参考数据模型比较时，SOA 治理过程应该确保没有附加的语义被定义在消息类型中。

CBDI 论坛 SAE™元模型还跟踪用于服务实现的业务组件。

服务可重用因素

当帮助推广可重用服务规格时，有三个重要因素需要考虑。首先服务接口必须对于其当前和潜在消费者来说是完整的。对于向前兼容还是不向前兼容两种做法，一个好的衡量标准是当一个新消费者出现时需修改的接口和实现的个数。

第二，我们必须考虑适当的服务和操作级别协议（SLAs 和 OLAs）。一些 SLA 可能对一个消费者工作良好，但对另一个消费者却有问题。SLAs 和 OLAs 可能也难以达到。SOA 治理组织应该跟踪所发生事件并监控由这些事件引起的改变 SLAs 和 OLAs 的数量，以及为有效满足其 SLAs 和 OLAs 而对服务实现改变的数量。

最后，服务治理组织应该尽力识别一个服务候选的所有潜在消费者，在批准该服务接口建议的过程中将他们考虑在内。一个好的衡量标准是在服务被设计之后没有预料到的消费者数量。该标准应该被小心解释，因为它可能意味着服务设计很好并吸引了众多消费者，亦或没有花足够的时间识别正确的消费者从而导致了后来大量变更。

服务治理活动和角色通常被治理解决方案所支持，该方案围绕一个服务注册和仓库来构建。尽管它说起来相当简单，但是始终紧记资产只能在所能发现的范围内被重用是十分重要的。一个注册是目录或索引，为 SOA 服务担当“记录系统”的任务 (4)。

一个典型的 SOA 注册和仓库支持如下功能：

• 存储服务元数据如描述（消息格式和操作）、绑定（通讯协议）、端点（实现该服务的网络可访问资源）
• 提供一个分类机制，帮助分类和组织服务
• 允许用户发布新服务（按照他们识别、实现、发布的样子）到注册并浏览查找已有或已计划提供的服务
• 通知服务消费者已计划的变更
• 管理 SLA 和 OLA 报告以及消费统计
• 管理安全治理过程和可交付物
• 提供审计能力以跟踪变更和授权申请资产描述的痕迹

治理过程本质上是地理分布和协作的过程。管理这些过程是引领不同部门在服务定义和实现上达成一致的关键。

因为注册和仓库是设计和运行时服务信息的记录系统，围绕“服务记录”的安全性是至关重要的，如端点的替换。

服务治理是一种新类型的治理，作为更广泛的 IT 治理活动的一部分，由企业架构小组领导。IT 治理本身应该依旧在 SOA 平台治理控制过程之中，而服务治理应该将其工作重点放在企业级可重用服务设计、服务实现和方案交付级别的活动上 (图 3)。在企业级别，服务治理应该与 IT 治理紧密工作，自顶向下进行分析以获取公司的业务过程模型来帮助识别服务候选，并为这些服务的部署建立路线图。正如我们在前面过程章节所看到的，服务级别是大多数 SOA 治理活动发生的地方。所有这些活动都由注册和仓库提供支持。

在方案级别，服务治理组织应该评估并指导该级别符合 SOA 底层基础架构和服务指导原则。

通过使用企业参考数据模型，服务治理与数据治理有很强的联系。服务治理团队应该加强利用参考数据模型语义来设计操作消息类型。

这里的目标不是创建一个“正规信息模型”。在面向服务架构中，认为消费者总是采纳提供者的观点或者提供者和消费者总是采纳相同的观点都是幼稚的。即使今天这些都成立，随着时间推移，消费者和提供者可能在同一时间不在同一位置来评估一个新版本的接口（向前兼容或是向后兼容）。

图 3。 SOA 治理和其它治理活动之间的关系

这种分裂演化经常使用仲裁者来处理，特别是消息转换。即使仲裁在 W3C 的 Web 服务架构中没有显示说明 (5)，SOA 从业者很早以前就开始系统地使用获得更高级别的松耦合，并使得消费者和提供者之间的进化是自治的。这些转换是必然的，而且这一能力应该被构建到你的 SOA 底层基础架构中。顺便提一下，仲裁不需要“公共信息模型”。如果你使用过这种不依赖于提供者和消费者接口的“公共信息模型”，并仍想达到减少耦合的目的，你将导致两个转换的花销，更不用说你仍需将你的消息格式转换到提供者和消费者实现可以消费的数据集。

走向可管理的转换的第一步是从参考数据模型中派生出消费者和提供者接口。在参考数据模型中，数据结构不如语义标准化重要。这些语义经过数据治理被精确管理。通常，参考数据模型对物理产品建立可追溯性，如数据库模式和 COBOL CoopyBook。该可追溯性可以在服务实现期间提供方便，而使用标准化语义将帮助简化在消费者和提供者之间转换映射的开发。

结论

服务治理是一个成功的面向服务架构的基本方面。它的建立必须在 SOA 项目的初始阶段尽早进行计划和检验。然而，一个完整的由一个严格的过程所驱动的治理组织应该在服务管道足够大时被启动，以维持团队士气和知识。如果治理活动在时间上遥不可及，团队可能失去兴趣和正确执行活动的关键知识。注册和仓库是成功治理的关键组成部分，因为它管理“服务记录”。服务治理的最终目标是使规范可行、实现和可重用 IT 资产的操作。随着时间的推移，预期服务治理将朝着前期开发大量的关键服务委托实现的方向进化。

参考资料

1. S. Tilkov“ SOA 治理中的角色”
2. J.J. Dubray “ W3C 发布 XML Schema 1.1 版本指南更新”
3. J. Dodd et al “ CBDI-SAETM META MODEL FOR SOA VERSION 2.0 ” （需要注册）， Everware-CBDI Inc
4. webMethods, “SOA 治理，能够支撑 SOA 成功”，白皮书，2006 年 10 月
5. D. Booth et al “ Web 服务架构”，W3C

查看英文原文： Establishing a Service Governance Organization