iweroulsdjf

面向服务体系结构（Service-Oriented Architecture，SOA）具有显著提高 IT 效率的潜力。但是要在组织中实现它，仅仅了解技术是不够的，还必须精通管理。在本文中，Yvonne Balzer 会描述能帮助您成功实现任何 SOA 项目的治理原则。

如今，业务和 IT 价值链开始在行业中融合。我们现在所说的 企业体系结构和 面向服务体系结构(SOA) 都与 IT 的实现无关。因此，我们也需要建立业务和 IT 之间的横向联系，定义和开发诸如 SOA 这样的体系结构，并运行专门针对企业的客户端项目。

出于这些原因， 治理在如今的 IT 行业中的角色变得比以前更为重要。在本文中，我将介绍在 IBM IT Management Consulting (ITMC) 开发组的最佳实践治理方法，这些方法都已在几个客户端项目得以开发和实现。我们将从已经过检验的 IT 治理结构和实践开始，增强治理模式以满足 SOA 的需求。

动机和问题

由于行业中出现的问题和挑战， IT 在现代组织中的角色发生了根本上的变化。现在，IT 必须以接近实时的速度非常迅速的反应并灵活的启用业务。IT 必须设计和管理一部分高度集成的复杂企业体系结构，并且业务和 IT 组件之间的界线也越来越模糊。本文将介绍关键的治理功能，它能够帮助您达到这些目标并成功实现 SOA 项目。

治理提供了一种拱形（overarching）的结构，其目的是为了从战略性、功能性和操作性层次上支持用户的业务目标。它为有效的规划、决策制定、操纵以及 SOA 项目控制而定义了规则、流程、度量和组织结构，以达到用户的业务需求和目标。最后，治理模型定义了以下内容：

• 需要做 什么。
• 如何去做。
• 应该由 谁来做。
• 应该 如何进行度量。

该模型同样也为有效的规划、决策制定、操纵以及 SOA 项目控制而定义了规则、流程、度量和组织结构，以达到用户的业务需求和挑战性的目标。

以下是在 SOA 项目内定义适合的治理结构所涉及的一些关键性问题：

• 客户端从该项目中能获得哪些好处？客户端的目标和期望是什么？
• 在进行 IT 规划、操纵和决策制定时，有哪些角色、职责、结构和流程是已经存在于客户端站点的？
• 如何提高技能和领导能力？
• 需要哪些原则和指导方针来优化业务和 IT 之间的关联？
• 为了企业和 IT 能够进行交互，以维持一致性并保持足够的灵活性来快速适应新的变化，什么样的构造方式才是适合的？
• 什么样的服务规范、服务定义和描述才是适合的？
• 如何控制和度量服务及服务提供者？由谁来对现有服务所进行的修改进行监控、定义并授权？
• 如何决定服务的原始策略？
• 存在哪些问题？项目如何支持客户端来解决这些问题？

基于我们的经验，我们相信公认的、正式的治理模型是成功实现业务目标的关键。因此，我们建议在 SOA 项目中建立治理功能。该治理模型应该也处理 渐进式改造的基本需求，即集中使用每个步骤中学习到的内容来定义和执行下一步。创建用于 SOA 的改造和实现的治理程序体，是治理模型的核心需求。为快速可靠的完成该项工作，我们提倡使用客户端现有的结构并共同工作，以改造该结构并使其适应 SOA 项目。

治理模型：SOA 项目的正确形式

IT 治理有一些不同的定义。IT Governance Institute（请参阅 参考资料以获得相关链接） 给出了一个对 IT 治理的较好的一般概述：

IT 治理是指导部门及执行机构的职责。它是企业治理的主要组成部分，由领导阶层和组织结构组成，它确保组织的 IT 能够维持并可以扩展组织 IT 的策略和目标。

IT 治理的目的是指导 IT 以确保它的性能可以满足业务目标，因此：

*IT 和企业的联合会使预期的利益变为现实。
*IT 使企业的机遇得到开拓，并使企业的利益最大化。
*IT 资源能够可靠的使用。
*IT 相关的风险被合理的控制。

图 1 的治理模型是组织结构、连接流程和相关联系的结合。它基于战略方向和被称为 治理原则的公认的基本原则。在大量复杂的项目中，该方法通过我们的经验得到了不断的改进。由此，我们认识到这些要素是任何类型项目的基础。

图 1. 核心治理要素

战略方向及指导原则

客户端战略方向的定义是成功发展适合的 SOA 及持续专注于业务需求的关键。对业务策略和目标的普遍理解是业务单位和 IT 的基础。

治理的原则和指导方针是任何决策的基础。这些原则和指导方针将规定解决方案的范围并定义协作的方式。因此，执行部门应该很好的理解接受它们。其中一条主要的指导方针就是 治理方式。两种主要方式的区别是：

• 中央式治理：这对企业而言是最好的方式。治理委员会拥有来自每个服务域（以后对此将有更多介绍）和专家的表述，这些专家可以与实现解决方案关键技术组件的人进行对话。中央治理委员会将在对实现修改授权之前，评审任何对服务的添加、删除以及对现有服务的变更。
  
  
• 分布式治理：这对分布式团队而言是最好的方式。每个业务单元都能够控制在自己的组织内部如何提供服务。这需要功能性的服务域方法。中央委员会可以为不同的团队提供指导方针和规范。

每个原则都应该依照基础理论来定义，这些理论用于说明该原则的目的和含义。指导原则定义了 SOA 的开发、维护和使用的一些基础规则。特定原则用于体系结构设计或是服务定义，也就是说，这些指导原则专注于特定的主题。这些原则具有以下特性，它们能为设计样式提供固有特征，并应该包括项目的以下几个方面：

• 指导原则：
  • 重用（Reuse）、粒度（granularity）、模块性（composability）、 可组合性（composability）和组件化（componentization）
  • 与标准（一般的或是特定于行业的）一致
  • 服务的识别和归类、提供和传递、监控和跟踪
• 特定体系结构原则：
  • 封装
  • 业务逻辑和基础技术的分离
  • 单一实现和组件的企业观点（enterprise-view）
  • 机遇存在时利用现有资产
  • 生命周期管理
  • 系统资源的有效使用
  • 服务的成熟度和性能

通过理解体系结构和设计的 SOA 样式的原则，以及这些原则对业务和 IT 的联合所带来的好处，您就能在设计解决方案时确定 SOA 的适用性。这些原则驱动服务设计明确的基本特性。您可以将每一个特性对应到一个或多个提供给原则和特性以完整性的 SOA 原则。

治理流程

治理流程是战略性的 IT 规划和操纵所需的流程，比如：

• 策略的发展
• IT 规划
• 业务量管理
• 资源
• 创新管理
• 体系结构管理。

在 SOA 项目中，需要在项目的一开始就建立 体系结构管理流程(AMP)。 AMP 主要的目标是确保已定义的 SOA 的一致性、有效开发以及持久性。

基于我们在许多项目方面积累的经验，我们开发了一个标准 AMP，您可以在客户端项目内快速简单的使用它。该流程由四个子流程组成，如 图 2所示，这些子流程使用 IBM LOVEM 表示法，定义完善且可用。（ LOVEM即 line of visibility engineering methodology，请参阅 参考资料以获得更多信息）。

图 2. 体系结构管理流程

下面更详细地介绍图中的一些要素：

• 体系结构的评审及批准流程：
  • 定义构造好的方法来评审和批准现有 SOA 的变化，做出与 SOA 的路线相一致的决策。
  • 设计和服务的正式评估审核是关键的控制点。
• 体系结构的例外以及渐进发展流程：
  • 提供请求体系结构决策的方法。
  • 允许 SOA 体系结构的例外以满足独特的企业需求。
• 体系结构维护流程：
  • 当新的服务添加到体系结构中时，确保 SOA 已被维护且修改已经传达到风险承担者。
  • 体系结构的变化都有备有文档说明且被传达。
• 体系结构通信流程：
  • 确保 SOA 对每个需要访问的人都是可用的。
  • 加深对 SOA 重要性的理解

组织结构

为提供体系结构治理，必须在组织内部确立一些结构，定义所有需要的角色和职责，以及定义适当的制定决策的组织结构。经验显示，建立 体系结构办公室很有用，特别是在复杂且庞大的项目中。体系结构办公室职责是保持 SOA 在战略、战术、操作层次上符合业务需求。该办公室应该包括体系结构设计权威人士，他是体系结构管理流程的所有者。此外，每个层次都定义了角色和职责。

根据我们在客户端所做的工作，有两个有效办法可以用于建立和运行这样的体系结构办公室：

• 如果客户端组织已经有了和体系结构办公室类似的制度，那么您应该结合这个现有的组织结构。应该确保所有的功能和职责都能够明确的用于制定体系结构决策。对于 SOA 项目，这些功能和职责应该涉及到 SOA 决策，并随时保持联络。
• 如果客户端站点没有治理委员会，我们推荐您在 SOA 项目的上下文中建立体系结构办公室，并通过它来决定关键的可交付项目。用 SOA 项目中的客户端和项目人员暂时充当该体系结构办公室的工作人员。这些人员应该是决策制定者，并且应该包含 CIO。在项目的最后，体系结构办公室可以被集成到客户端组织。

图 3 说明了体系结构办公室以及每个层次上的角色和职责。在战略层有体系结构部门，它是一个决策部门，负责提交标准和原则，并通过业务和 IT 策略来进行服务的优先级排序。在战术层，体系结构组作为体系结构设计权威来运作，负责定义体系结构管理流程，以及定义修改、删除或添加服务和管理域的决策准则。在操作层，项目组开发和实现服务。

图 3. 体系结构办公室

每个项目组都需要角色描述来定义其任务和职责以及操作的模式。

SOA 治理引入 域所有权的概念， 域管理一系列共享常用内聚业务的可重用服务。在很多情况下，这些是业务服务的子集，比如用户信息、案例信息、商业竞争统计信息等等，以及竞争参考，比如商业风险等级、产品分析和规划服务。每个域负责维护自己的业务对象，也负责对其他的域发布服务接口。域为业务对象提供服务检索和维护、封装业务逻辑、定位以及与对象和服务相关联的格式。当主管某个产品或产品领域的人希望从域获得服务时，他们生成一个请求并且两个组确定相互联系，创建服务层次协定。这些联系和协定也存在于域之间。

根据域所有权的概念，一些新的角色和职责应被提供给在 SOA 项目中的开发生命周期，如下面的 表格 1所描述。

表格 1. SOA 项目中的角色和职责

角色	描述
域所有者	管理域的方向，域包含了一个或多个服务的聚集，也包含了业务联系以帮助多个业务单元中的所有者理解业务透视。数据和流程的所有者使用业务分析员来阐明业务目标和需求。跟踪 ROI 计算服务的使用。
域的面向对象业务分析人员	开发人员使用没有假定使用者接口的服务功能性案例。确保完全提取的规格化业务服务都被识别并指定。必须坚持严格且灵活的服务定义和开发生存周期。
业务代表	为域识别和分析业务服务。
域开发人员和维护人员	与面向服务开发生命周期一致的创建和维护服务。创建并实现符合开发规则的服务（例如，服务设计注意事项或 Web 实现指南）、 SOA 以及参考体系结构。
服务测试人员	确保服务经过严格的测试，以获得合适的业务价值。为功能性接口以及它的独立实现创建测试案例。

在给定服务域中工作的人员负责开发业务和技术的集成，以提供可以跨业务界线共享的业务服务，使成员和区域受益。当他们将应用程序中开发的功能转换成服务域中开发的功能时，便会在组织结构（角色和职责）中为应用程序的开发引入变化。

将治理模型投入使用

开发治理模型的流程基于一个具有三个步骤的方法。该方法基于时间约束（time-constrained）客户端项目而开发。成功的关键是治理功能的建立。

• 步骤 1：实施
  • 在适当的位置设置核心治理功能，并支持客户端业务操作。
  • 边做边学，才能迅速成功。
  • 使用经验丰富的专业人员担当高层管理角色。
• 步骤 2：专业化
  • 建立必要的结构、流程、方法和工具。
  • 吸取步骤 1 中的经验。
  • 使用有经验的架构师和专业人员。
• 步骤 3：稳固
  • 传授并培训客户端人员运行操作。
  • 将操作模式变为指导模式。
  • 使用有指导经验的顾问和专家。

图 4 对这些步骤进行了更详细的描述

图 4. 将治理模式投入使用

提示和技巧

以下是我们从实际项目中获得一些实践经验：

• 有规律的通知每一个需要访问的人（通过项目通讯稿，或者也许是开会）。SOA 创立了组织文化也改变了技术，这可能会产生沟通障碍，因此互相通信非常重要。
• 将每个决策、约束和设想记入文档，以确保决策制定的说服力和透明度。
• 定义关键的交付以及必需的工具集和模板。
• 为生存周期的管理和方案设置实践工具。
• 用基本原理定义决策，并文档化和传达这些决策。
• 必须保持所有风险承担者的有力支持和决策制定者的说服力。

结束语

本文说明了治理为什么重要以及 SOA 项目中需要什么。并对我们 SOA 治理模型的一些关键要素进行了概述。从以 SOA 原则为导向开始，接着描述了体系结构管理流程作为一项关键流程确保了面向服务体系结构的相容性和一致性。还描述了如何为适合的决策制定和开发建立组织结构，以提供所需的角色和职责。最后，本文还讲述了如何将治理模型投入使用，并为您提供了我们在该领域所获得的提示和技巧。