SOA 治理：实现并维持业务及 IT 的敏捷性

在本文中，InfoQ 发布了《SOA 治理：实现并维持业务及 IT 的敏捷性》第 4 章“治理服务工厂”的整章内容，本书由 William A. Brown ， Robert G. Laird ， Clive Gee ， Tilak Mitra 等合著。

此书的第 3 章“创建服务工厂”讲述了建设“服务生产线以使 SOA 开发活动自动化，并为此服务工厂设立明确的任务，角色和责任”的重要性。

本文（即此书的第四章）给出了服务工厂治理的实践建议，介绍了一个案例分享，提出了服务定义、开发、测试、部署和运维等方面的指导原则。

“现代的编程就是软件工程师和宇宙之间的一场竞赛，软件工程师努力地编出更大、更安全可靠的程序（就是傻子都能用的程序），而宇宙则要努力创造出更多更傻的人，目前为止，后者是赢家”

——里奇·库克

在第三章“构建服务工厂”中，作者探讨了建立服务生产线对于 SOA 开发活动的自动化的重要性，因为文中提出的任务、角色、职责等需要这样的服务工厂。第三章还描述了一组产出件，它们的采用有助于实现第二章“SOA 治理的评估和计划”中介绍的实用 SOA 治理的计划（Plan ）域，组织（Organize）域以及程序管理控制（Program Management Controls）域。

本章介绍了治理服务工厂的运行以及在服务部署到生产环境之后对服务进行治理的实用方法。

SOA 成功实施的核心竞争力

企业要想成功实施 SOA，就需要若干核心技术竞争力。好的 SOA 治理就是要发展这些竞争力，创造出确保服务工厂尽可能顺利并高效运转的治理机制。本章后续内容给出了这些核心竞争力的定义。

有效的需求收集

古语有言，“错进，错出！”，它完美地描述了正确收集需求的重要性。没有精确地功能需求和非功能需求（即技术性需求），就不可能创造出好软件。 SOA 的主要优势之一是，服务应该代表消费者和提供者之间清晰的协议或合约。因为，若使用了很好的命名标准，每次服务请求（或操作）的目的就能立刻为业务和 IT 人员理解。

对于新建的候选服务，在收集并调和来自各服务需求方的需求时要做的一个重要决定的是：收集到何种全面程度。在理想情况下，需求应覆盖服务的所有潜在消费者的个别需求，而且，考虑所有需求而设计出的服务：

• 在理论上有两个优势：消除了未来更改此服务进行的需要；最大程度地促进了重用。二者都是主要的积极目标。
• 可是，它也存在实施上的劣势：严重消耗分析资源，而且还可能为第一版服务的开发带来了额外的复杂性和成本。

目前的较为平衡的观点是 80/20 法则：若穷尽服务的需求需要 100% 的时间的话，一个有经验的分析师花 20% 的时间就能明确服务的 80% 的潜在需求。 除穷尽最初的需求分析之外，设计最优的服务粒度、服务的设计以及服务文档的质量同样能够促进服务在将来的重用。

创建发布需求目录对于促进重用、避免不必要的冗余非常重要。而创建需求目录的重要的前提条件是创建高层业务流程模型和通用的业务词汇表。

一个很好的实践是，在收集服务的需求的同时，定义非功能需求和服务测试及验收的准则。

服务设计的竞争力

尽管服务架构及技术细节超出了本书的讨论范围，我们仍然就服务设计流程治理提出一些补充意见：

• 为服务设计者提供一套正式的核心架构设计工作件非常重要。这些工作件包括必须遵循的架构原则，应该遵循的架构决策、推荐设计模式以及正式目标生产环境。许多大公司遵循的最佳实践是，成立一个架构评审委员会（Architecture Review Board，ARB），由该团队维护这些架构资产的活性。
• 我们强烈推荐的最佳实践是（最好是强制性的）在常规的服务设计评审中尽可能多地让技术精英参与其中。该做法有很多好处，既能优化服务的设计、提升一致性、确保服务符合标准与最佳实践，又能通过工作中的导师关系帮助初级成员在架构设计技能方面的成长。

服务开发的竞争力

当代的服务开发工具包（SDK）使得 SOA 的开发过程非常直接了当，而且它们提升了技术方法的一致性和质量。在本章中，我们将探讨一些能帮我们监控和辅助服务开发的工作件。

服务测试和部署的竞争力

品质的口碑难得却易失。详尽的测试与高效不出差错的部署过程是赢得并保持好品质的关键所在。同样，我们将描述一些有助于治理该过程的工作件。

操作管理和监控服务的竞争力

丢掉品质声誉的最简单的方式是使用质量差，不断出错的产品，所以我们也将从治理的角度强调该领域的重要性。

服务开发生命周期的控制点

虽然多数企业都引入了某种系统开发生命周期（system development lifecycle，SDLC）以及开发过程方面的方法论，但在实践中我们常常看到不同业务单元间无法保证这些方法论的执行，或者即使它们定义了一组最佳实践、标准、策略以及模式，可是它们却总是不起作用 。

虽然与 SDLC 中已有的功能没有太大的差别，但是有效地加强最佳实践与系统开发生命周期统一地执行却为真正的治理带来了合理的切入点。与此同时，如果治理的成熟度级别可以提升到能够治理 SDLC 的程度，那么企业在向 SOA 治理周期的下一阶段（并制定企业中程序和组织的治理）前进时，就能占据更有利的位置。

SOA 治理，即便是最初的尝试都会面临的威胁是，一些关键人物往往认为任何流程和治理的加入都是用来约束别人而不是自己的。对他们而言，这是个过度工程化、无实用价值的东西，是他们按期完工之路上的绊脚石。因此，许多治理流程被忽视，或者被人们漠然地遵守着。主要的原因是治理是由外部强加的， 而且执行起来非常繁重。

如果治理几乎是自治的、简单的、对开发流程带来价值而且的确有助于项目的进度，情况是怎样呢？如果它能缓解那些悲观者的痛处，他们是否更愿意接受这一剂良药呢？

为了 SDLC 的充分治理，让人们尽可能高效地行使他们的治理角色和职能，同时又不会带来过度官僚化的过程，有必要建立度量方法、策略、标准和控制机制。

SDLC 的治理的特点是，在服务开发过程中特定的“控制点”添加一组决策。控制点用来判断决策是否遵循已设立的流程，即决策是否与先前设定的目标保持一致？流程的执行和管理需要作出怎样的调整？治理过程中关键的方面有，明确该过程中有哪些关键决定、何时做决定、采取何种测量方法去监控这些过程。

对于任何过程，其中某些特定的活动可能需要关联控制点。在每个标识的活动结束之后，都会有一个控制点，治理功能在此做出是否应向下一活动前进的决定。每个这样的里程碑都是控制点。

本质上，SDLC 的治理提供了设定控制点并定义治理规则的方法。在每个控制点，必须明确以下内容：

• 在该控制点，哪个角色可以做哪些事情
• 作用在该控制点的策略
• 该控制点使用的测量方法，以及为后续的治理动作收集的测量结果
• 建立合规性验证记录并存档

在流程中的任何位置，如果即便考虑了需付出的时间、精力和可能造成的项目滞后，控制带来的标准化和效率有明显的优势，那么此位置就需要定义控制点。控制点使得 SOA 的治理能够明确进展、与流程进行交互、基于范围和所发现的问题提醒下一个 SDLC 阶段的任务、检查和报告合规性，有助于在过程中注入专业的知识，来自开发团队的对构件、流程或决定的合理意见。

控制点不一定要进行庞大而正式的会议。大多数服务和自动化流程都是规模小于项目的实体，而且数量很多。所以，现有治理方法必须要实行流水作业，不然它就可能会停滞不前。我们在实践中发现，有效的控制点评审会可以分期地举行，譬如一周一次。为提高这种控制点评审会的质量，较为高效的办法是使用先前完成的清单，由一个或多个资深成员签字以标识相应的任务已经成功完成，服务、流程和其他工作件与目标相符且已经为治理流程中的下一阶段的工作做好准备。这些清单应当被视为服务开发流程中不同专家之间的契约。该清单的的最重要的部分是签名区域，它表明都有哪些人执行了评审决定，一旦涉及个人名誉问题时，人们通常都非常谨慎。

另一高效的方法是使用自动化工具，治理控制点能自动就自动。这样有助于向服务开发者和提供者提供几乎实时的反馈，提供了对已完成的工作再检查的简易途径。此外，人们都很忙，而且应用治理（规则）时还可能前后不一致。机器是一致的，但是有时又不那么灵活。所以二者的组合是最佳的治理方式。

下面我们看一下治理通用开发周期（至少在一个较高层次上）所需的控制点。图 4.1 显示的是监控典型的 SDLC 的“治理仪表板”，它就像眼睛一样盯着必须执行 SOA 治理的关键概念和关键点。

图4.1 软件开发生命周期的治理仪表板

如前文所述，我们需要一个流水化的治理流程，它能处理大量服务和自动流程（我们实现这些流程的目的是提高业务敏捷和灵活性）。然而，流水化流程一定不能因为速度而牺牲治理的质量，这种牺牲是不可取的。

一些企业处理的是与公司的使命和生存息息相关的需高度管理的业务流程，所以需要应用高度规则的、可审计的治理来管理这些风险。另外一些企业的流程的风险较低则可以轻度管理。在实践中我们发现，同样的治理流程对于这两类流程都能处理得很好。如果需要较严格的治理，则在控制点设置更严格的策略并加强策略的执行和合规检查。如果需要的较宽松的治理，那么在相同的流程中，使用较宽松的策略、较少的审计、和级别低一点的清单签名过程。

即便在一个企业内，不同的业务流程也可能需要不同的治理风格。有些流程，如服务认证流程，可能需要比其他流程（如解决方案架构）更严格的治理 。不同的企业文化需要的决策自动化程度也不尽相同。好治理需要好判断！

首先，我们更新一下图4.1，在上面标识这些控制点的位置，这样在下面对它们进行描述时你的脑海中就会有一个直观印象。图4.2 展示了这些控制点在开 发周期中发生的位置。

图4.2 带有SOA 控制点的软件开发周期

以下是这些控制点的描述：

业务需求和服务发现控制点

SOA 方法强调创建能带来敏捷和重用的业务服务。第一个控制点是业务需求和服务发现控制点，这里需要根据我们在第三章“建设服务工厂”中描述的服务选择策略和优先级策略对发现的服务进行评审。

该控制点应该解决以下问题：

• 业务目标。业务期望实现的业务目标是什么？如何通过 KPI（关键性能指标）度量实现业务目标的过程中收获的回报和提高？
• 我们目前所了解的需求是否明确地支持那些目标？他们是否与第三章中介绍的业务热点组件图对齐？
• 人们充分理解并认同需求吗？它们是否用诸如用例、业务流程建模、序列图，或类图等符合 SOA 开发方法的形式描述的？
• 如何对需求进行跟踪，以保证服务的开发过程中的确实现了需求？需求是否加入了企业范围的需求和业务规则目录之中？与目录中的现有条目是否冲突？
• 哪些需求可以转化成候选服务，或者根据它们提供的能力是多个消费者所需的，或者可能为流程自动化所用？开发应用、自动流程、或人工流程可以更好地支持哪些需求？
• 候选服务是从何处发现出的，确认了潜在服务消费者了吗，他们有没有需要特别考虑的需求呢？
• 对于有限的 IT 资源，我们应怎么设置优先级呢？明确了每个新建的候选 IT 资产的负责人？所需开发资金可用了吗？

解决方案架构控制点

如果所有的设计决定都由他们自己做主，那么不同的 IT 开发者和团队可能会不可避免地使用完全不同的平台、编程语言、工具、风格、方法和技术。多样性为将来的变化增加了成本和复杂性，增加了维护工作的难度和成本。此外，它还降低了企业的 IT 资产的可靠性、稳定性、互操作性等。我们在很多企业中碰到了这个问题。简言之，解决方案架构控制点的目的是阻止昂贵的冗余一次又一次地发生。

本质上，任何通过该控制点的 IT 资产都是 IT 建设计划的一部分。就解决方案架构而言，其治理过程需要的控制准则如下：

• 提案书中的标准、策略和参考架构是否与服务实施中遵循的标准、策略和设计模式一致。这里包括参考架构、平台标准和硬件，软件使用标准。
• 有没有标识出可重用的资产及其合适性的评价？有无遵守服务采购策略。
• 有没有标识并评估非功能需求？非功能需求包括单位时间内的交易数、峰值分析、要求的服务性能、服务功能的展现、数据管理、服务安装所需的空间以及任何依赖关系和配置需求。治理时必须要考虑并解决所有这些非功能需求。
• 必须要考虑并处理所有的安全策略
• 必须要考虑并处理所有法律和政策相关的策略。
• 在 IT 资产（服务或业务流程等）开发这个阶段，参与其中的技术人员应该对工作的复杂度以及完成开发所需的资源有很好的认识。需要对资产的开发进行确认，范围降低了，或资产被抛弃了？

服务规约控制点

每个批准开发的服务都需要创建一个服务规约。在设计服务接口和能力时，最佳实践是整合 IT 和业务的两方面的视角。因为，实际上，服务规范就是企业向合作伙伴、客户和其他相关人员展现的门面，所以服务外在（Service Externals）——公布的服务细节——成了服务整体服务设计中重要的一部分。服务设计应该考虑所有潜在消费者的（合理）需求，设计能产生最大的价值的服务粒度。在服务标识和规约阶段，其治理过程中需要控制如下准则：

• 标识的服务有意义吗，其粒度合理吗，有没有与现有符合重复呢？
• 服务规约符合所有的 SOA 标准和策略？
• 服务规约遵循消息模型？如果不是，是否需要特批？

服务设计控制点

在服务解决方案架构转到设计团队之后，很多设计决定需要进一步细化。总体上，这些构成了服务内在（Service Internals），即一组设计模型、标 注、以及其他能够给开发者（在编写和测试服务代码时）提供指引的建议。在服务设计阶段，其治理过程中需要的控制准则如下：

• 服务的设计能否满足功能性需求和非功能需求，有没有架构师做了确认？
• 服务设计者和数据架构师认为服务能够符合在服务在外（service externals）中描述接口名（输入和输出）吗?
• 如果服务是从现有应用的或待建的应用程序包装而形成的，针对那个应用的必要的接口是否是良好定义的并且是稳定的（即，如果该应用的新版本部署时，接口不需发生变化）?
• 建立了监控指标吗（如，使用情况，QoS 等）？
• 如果是自动流程，有没有定义并制定监控需求？
• 对于长流程，有没有针对流程出错或技术性错误发生定义必要的动作来执行补偿呢？
• 服务规约包的整体质量和完全程度是否足够服务开发人员或流程开发人员（在不需更多信息输入的情况下）完成开发工作？

服务实现控制点

在服务设计转到服务实现团队之后，在编码或可执行模型的开发之前需要做一些实施决定。出于一致性和质量的考虑，我们强烈建议使用代码走查 （walkthrough）的审查方式，也就是由伙伴（另一服务开发者或流程开发者）检查代码并提出建设性批评意见的方式。

服务实现控制点实际上是这种代码走查的最后一步，所以执行起来应该更加正式一些。在该解决需要解决的问题有：

• 资产的编码是否与设计保持一致？
• 编码是否符合认可的编码规范？
• 是否为所有相关的构件（如加载库、元数据文件和资源）创建了可以移植的构建包？这些构件的版本有没有检查，是否与生产环境中的版本冲突？

服务测试控制点

服务测试不同于测试完整的 IT 解决方案或应用程序。因为服务和自动流程并没有用户接口，所以不可能为它们直接执行用户验收测试。这需要一些代码框架或专门工具对服务和自动流程进行详尽的测试，以确保在（用到这些服务和流程的）整体 IT 解决方案完成后的用户验收测试中不会出现未被覆盖的问题。

SOA 治理必须保证服务测试要有助于服务开发方法的方式进行，而且在 SOA 资产发布到生产环境之前，对服务进行全面的功能性和非功能测试。服务测试团队必须创建并使用合适的服务测试环境、工具和数据去进行完全的测试。这应该包含以下：

• 使用最佳的服务测试工具和框架组合
• 使用能够更快适应测试软件和回归测试变化的自动构建和测试环境。该环境必须与生产环境非常相似。
• 使用压力测试工具去测试非功能需求和规约，设计并加载模拟真实环境的测试数据。
• 使用测试管理报告工具，用于通报测试状态。
• 将测试用例追溯到用户的原始需求。

服务认证和部署控制点

部署的目的是将服务移植到生产环境，力求客户端宕机时间以及对业务造成的影响最小。该过程如果人工执行则可能会出现许多错误。在这个过程中，部署正确服务版本以及快速正确地部署与其他服务和应用程序相关的服务极为重要。此处的治理需要检查的内容如下：

• 自动化部署和备份流程所使用的工具。
• 确保对服务进行了最后的确认检查，验证服务符合所有的策略和标准，确认通过测试的资产不仅与最初的需求相匹配，还要与最后交付的资产一致，保证在测试过程做的纠正不会使其他测试结果无效。
• IT 运维已经完成了验收测试并正式接受资产，并且表示他们有信心成功担当保证相关的 QoS 运维工作。
• 服务注册主管和业务服务主管已经在服务注册库中审查了服务的描述并批注了该服务。

对服务或自动流程的认证是一个正式的“成功通过”仪式，授予证书表明 SOA 使能团队乐意接受与新资产的表现相关的荣誉。

服务活性控制点

服务活性检查是 SOA 治理中周期性执行的工作，它并且根据检查的结果对治理的流程、程序、策略和标准进行核对及更新。活性检查包括运用在以往的 SOA 规划、程序控制、开发和运维活动中得到的经验教训逐项验证；还包括其他诸如来自利益相关者的反馈和建议，某个常见模式的检验（如，常见的特权请求或无法通过一个或多个控制点的常见原因）等需要采取补救措施的内容。在服务开发流程的每个阶段所需的工作量指标可以显示服务活性的提升或降低的趋势。

正式的服务活性控制点的检查应该每三至六个月执行一次，这样就可以明确 SOA 转型是否脱轨，或治理级别或风格是否是最佳的。

个别服务或自动流程应该每六至 12 个月就应该审查一次。每个服务的各版本的用法信息有助于确定可被废弃或删除的“过时”版本，也可以确定所使用的部署方案和对服务所有权及访问权的设置是否是最优的。

服务开发域

“人性的另一缺点是，人人都喜欢创造，而没有人希望去维护”
——库尔特·冯尼格特

服务开发域包括服务或自动流程的生命周期，从最初的概念到生产环境中部署的完成。本节为此开发域的治理提出了一些建议。第六章“管理生命周期” 将对治理的一些具体步骤做进一步阐述。

我们碰到的多数 IT 部门在系统维护上都消耗了很多人力。原因之一是多数 IT 系统的应用系统对于业务逻辑，用户接口管理和工作流没有清晰的界限。对这类应用程序的任何修改都可能会破坏这三样东西，这样如果没有好的设计文档，维护工作就变得复杂，虽然不是个大问题，但却常常发生。

SOA 让业务逻辑和工作流明显地区分开。SOA 就是要将纯粹的业务逻辑和可重用的交易服务打包，并用可执行的模型来管理工作流。SOA 不会陷入任何特定的 GUI 或 GUI 的控制风格。在完全与 SOA 对齐的世界里，人们将使用任何最适合他们工作的 GUI 向 IT 系统发出请求以执行任务、做决定，或启动流程。自动化业务流程反过来也可以通过调用服务，或请求与人员交互来完成一项任务。

在这个世界，IT 解决方案随着业务流程逐步自动化而逐步成长，与第三方的交互逐步通过服务的执行而非人的直接参与就可完成。在任何时候，只要新业务需求、市场推力、或政府条例需要求对运行的流程进行变更，新流程或修正流程就能够通过重编或扩展现有自动流程的方式很快搭建起来。我们还可以想象技术仍然会不断地更新，那么人们将来就会以完全不同的方式与 IT 系统交互。由于 SOA 的方法将用户接口与业务功能的物理实现分离开，我们就可以猜想，不论人们使用何种接口访问服务，今天创建的大多数服务在 20 年后甚至更长的时间里将继续存在。

端到端的服务开发是一个复杂的过程。计划和治理必须要极为仔细，因为这里面有许多相互依赖的复杂的任务。在服务开发的治理时，治理专员需要解决一些关键问题，而且与其他项目计划一样，以过渡期计划的方式进行。

治理服务开发所需的关键能力

服务开发域非常复杂，而且其中技术变迁极快。对如此复杂的域的治理需要高度的组织和政治上的技能，以及很好的知识，不仅仅是 SOA 技术本身，还包括如何最优地使用它。很少有人能将二者结合到世界级水平，所以在实践中治理依赖于关键技术和非技能的结构的紧密合作。治理成功的关键是 SOA 治理主管、业务服务主管、首席 SOA 架构师以及首席服务架构师之间的紧密合作和完全信任。

表 4.1 描述了企业治理服务开发时所需的能力，也推荐了一些能够辅助此项复杂工作的工作件。它的组织结构与第三章的表 3.1 一样。

表 4.1 服务开发域——能力、风险以及治理工作件

能力

相关问题和风险

风险级别

治理工作件

治理成本

1. 服务开发生命周期控制

需要有一个流水作业的可靠的端到端开发过程，更早发现问题并及时纠正。IT 资源用得越有效越好。

关键

• SOA 开发方法
• 服务构建计划
• 服务建设的 metrics 评估
• 服务建设监控计划
• SOA 开发业绩报告
• SOA 重用和 ROI 报告
• SOA 开发经验总结
• 控制点讨论会
• SOA 治理策略豁免
• 服务实际走查意见

高

2. 需求收集和优先级排序

• 除非有准确的需求，不然 IT 解决方案不会有任何价值；需要应该越简单越好，避免不必要的修饰。
• 如果忽视了政府规定，则会面对尴尬或被处罚的风险。
• 业务流程模型应该逐步发展成可执行的模型。
• 不要违反安全，导致数据的完整性和私密性收到破坏。

关键

• 功能和非功能需求
• 企业级需求和业务规则目录
• 功能性和非功能需求清单
• 管理条例合规检查方法
• 管理条例合规检查清单
• 可执行建模方法

高

3. 服务标识

• 不同的潜在消费者可能有冲突的需求。
• 如果在交付服务或应用程序时做了不正确的决定，资源可能会浪费。
• 以最经济的方式采购功能，有时选择一个满足大多数需求的商业套装软件，有时则需要自己开发。
• 需要定义适当的服务粒度以最求重用的最大化。

关键

• 服务力度、可视性以及可达性清单
• 服务重用指导原则
• 服务采购政策

适中

4. 服务规约

• 需要确保 QoS 的设计和文档以避免错误发生导致重做一遍。
• 好的服务设计可以最小化管理多个服务版本的需要。

关键

• 服务规约
• 服务规约清单
• 服务设计清单
• 服务安全方法
• 服务安全清单

适中

5. 服务实现

• 有效的软件开发工具会明显地提高生产力和准确性。
• 应彻底地测试服务以确保它满足了所有的功能性和非功能需求。
• Bug 导致尴尬，修复 Bug 费用高，如果测试得详尽，零错误不是没有可能。
• 有效的配置管理 / 构建流程对于代码在开发、功能测试、性能测试、登台以及生产环境间的迁移是至关重要的。

关键

• SOA 开发工具
• 服务构建管理方法
• 服务安全清单
• 服务版本管理方法
• 服务测试计划

高

6. 服务认证

• 服务的测试可能需要与运维系统类似的系统和数据的连接。如服务器，主机以及虚构且逼真的测试数据。
• 任何部署之后出现的问题都可能会破坏 SOA 使能团队的声誉。
• 建议一个正式的认证流程用于建立企业对质量和价值的承诺。

关键

• 服务验收清单
• 服务开发方法
• 服务部署清单
• 服务水平协议（SLA）
• 服务版本管理方法
• 服务测试结果

适中

服务开发域的工作件定义

在前一节，我们介绍了一些经验证明有助于治理成功的 SOA 转型的工作件。虽然在下面的介绍中，我们把他们当作独立的文本文档或图表，但是在实践中，最好在专门为管理这些工作件而开发的工具中以模型的形式管理它们。以服务内在（service internals）模型为例，它应该在一个专门的工具中编辑和下发，这样的工具可以对服务组件间的交互进行可视化并验证其有效性，之后还能生成大部分代码。文本文档和简单图表是无法做到这一点的。

需求记录工作包含许多细节，同时也带来了许多误解产生的机会。就流程模型而言，与使用纯文本描述方式相比，使用专门的流程建模工具，由它保证逻辑的延续性以及所有可能的逻辑分支都有相应的处理，这样建模的流程更容易正确的理解。如果建模工具支持整个流程步骤的仿真，便是锦上添花。

大多数工作件都是在服务生产线上从一个人手中传到另一个人手中的中间交付件。这些工作件必须作为它的生产者与消费者之间的正式契约，在传递过程中应该正式地通告它的质量以及完整程度，传递一个不够标准的工作件是一种严重的违例行为。本章前面描述的控制点就是评估这些工作件质量的校验点。

第三章已经描述了一些有助于服务开发域治理的工作件，也定义了它们在生产环境中的角色。在建立 SOA 治理计划时，SOA 治理主管需要选择并建立能够最有效地管理 SOA 的服务开发活动且不至于影响项目进度的工作件。有些工作件已经在前一章给出了定义，这里按英语的首字母顺序对一些新工作件作出描述。

控制点备忘录（Control Point Minutes）

描述：该工作件记录关键的 SOA 治理评审结果，它可作为任何系统级问题输入，为 SOA 治理方法带来活力。SOA 治理主管或项目管理办公室 （PMO）应检查这些备忘录，并从中寻找任何能通过额外的架构决定、设计标准、最佳实践或增加培训解决的常见问题。

目标：确保 SOA 开发方法持续有效。

何时需要：应在每个服务控制点之后立即完成。

责任人：控制点审核员，PMO

负责人：SOA 治理主管或 PMO

咨询谁：控制点审核员

告知谁：SOA 使能团队

可执行建模方法（Executable Modeling Approach Work Product）

描述：它为开发可执行业务模型定义了标准和最佳实践，保证其一致性和质量。

目标：定义创建自动业务流程的方法。

何时需要：在 SOA 开发方法工作件批准后尽快创建。

责任人：服务架构师、流程建模员、流程开发者、业务分析员和监控开发者。

负责人：首席 SOA 架构师，首席服务架构师。

咨询谁：SOA 使能团队。

告知谁：流程建模员、流程开发者和监控开发者。

功能性和非功能需求（Functional and Nonfunctional Requirements Work Products）

描述：这些工作件定义了每个服务需要实现的功能。非功能需求包括诸如性能、可用性、系统管理和安全等方面的要素。大多数服务通常有一组标准的非功能需求集，针对个别服务仅需定义其附加的，特有的需求。一些目标（如延迟）应该使用可衡量的指标定义，如“该操作的 95% 的单次执行的延迟不能超过 1 秒；门户页面上的 90% 的执行所需的时间不应超过 1.5 秒。”

如此前描述的，功能性需求编目的最佳实践之一是在数据库中维护需求和业务规则目录，并使用相应的（企业数据模型 EDM 中）业务实体或消息模型 （MM）作索引。这样可以避免做重复的需求分析工作。需求应该分成强制的、有价值的和可选的。当需求只属于某个特定的业务线时，就应该在需求的文本描述中说明清楚。

目标：管理好需求能避免重复还能促进重用。

何时需要：SOA 开发方法的工作件通过之后就应该立刻创建标准的非功能需求集。功能性需求应该在业务需求和服务标识控制点进行评估，非功能需求应在解决方案架构和服务设计控制点进行评估。

责任人：服务架构师和业务分析员（针对非功能需求），业务分析员和流程建模员（针对功能性需求）。

负责人：业务服务主管

咨询谁：所有的服务架构师，业务分析员，流程开发者，服务开发者

告知谁：SOA 使能团队，QA 和测试团队

功能性和非功能需求清单（Functional and Nonfunctional Requirements Checklist Work Product）

描述：在业务需求和服务标识控制点评估功能性需求，在解决方案架构和服务设计控制点评估非功能需求。它旨在确保所有服务消费者的具体 需求或者得到满足，或者明确地表明不再在此次服务发布的计划之中；还要确保该服务的设计方法能够满足 NFR 和 SLA 术语和条件。

目标：尽量获得最高的服务质量

何时需要：在业务需求和服务标识控制点评估功能性需求，在解决方案架构和服务设计控制点评估非功能需求。

责任人：SOA 治理主管创建清单模板，首席业务分析员和服务设计员完成每个服务的清单。

负责人：业务服务主管。

咨询谁：业务分析员。

告知谁：SOA 使能团队。

法规遵从办法（Regulatory Compliance Approach Work Product）

描述：指定在何种情况下（例如，如果服务请求者来自某个国家？）应遵守何种法规，通过相应的流程确保符合法规。

目标：避免因没有遵循相应的法规而造成的尴尬和处罚。

何时需要：应在 SOA 开发方法批准后立刻创建。

责任人：首席 SOA 架构师，PMO，业务服务主管，安全架构师。

负责人：SOA 总执行或现有的 IT 治理岗

咨询谁：SOA 使能团队

告知谁：PMO

法规遵从清单（Regulatory Compliance Checklist Work Product）

描述：清单模板由安全架构师和任何现有的 IT 治理团队设计的，再通过首席 SOA 架构师的批准。具体清单由服务设计者完成并由安全架构师批准 。给定服务的法规遵从清单应该在多个控制点签字以确保破坏安全一致性的更改不会发生。

目标：避免因没有遵循相应的法规而造成的尴尬和处罚。

何时需要：最初应该在服务规约控制点预备好，之后在服务开发、服务测试和服务认证和部署等控制点重新审核。

责任人：首席 SOA 架构师，PMO，服务设计者，服务架构师

负责人：安全架构师

咨询谁：SOA 使能团队

告知谁：PMO

服务验收清单（Service Acceptance Checklist Work Product）

描述：在 IT 运维团队确认可以成功地运维和管理特定服务并满足它的 SLA 需求时使用该清单。

目标：确保尽可能高的 QoS

何时需要：应该在服务认证和部署控制点之前完成，因为这是先决条件。

责任人：IT 运维人员

负责人：IT 运维人员

咨询谁：服务架构师，服务设计员，服务测试人员

告知谁：SOA 使能团队

服务构建管理办法（Service Build Management Approach Work Product）

描述：开发管理办法必须保证 SOA 组件能够在开发、测试、登台和生产等环境中方便地移植，而且不出现错误和遗漏。

目标：维护运维的持续性，建设管理办法准确无误很关键，而且总能重新创建给定的建设配置文件。

何时需要：SOA 开发方法批准后应立即创建。

责任人：首席 SOA 架构师，现有构建管理员

负责人：首席 SOA 架构师

咨询谁：IT 运维人员

告知谁：服务开发者，流程开发者

服务构建计划（Service Build Plan Work Product）

描述：这是由候选的服务和自动业务流程组成的正式 SOA 资产构建计划。该工作件是管理 SOA 开发关键工具，因为：

• 它定义了服务优先级排序结果。
• 它是服务开发项目管理的关键控制文档。
• 它向企业的其他部门传达 SOA 开发的计划和状态。

需要注意的是服务通常有多个操作——例如，Customer 服务可能会有这样的操作：lookupCustomer 和 modifyCustomer。并非每个操作都要相同的开发优先级；也没有必要同时开发每个服务的每个操作。

目标：管理服务开发优先级并将这些优先级向利益相关者传达。

何时需要：应在做完服务开发计划后就要创建它，而且每周更新。

责任人：首席服务架构师，服务注册员，SOA 业务分析员。

负责人：业务服务主管

咨询谁：PMO，服务架构师，服务开发者，服务设计者，流程建模员，流程开发者

告知谁：SOA 使能团队，PMO

服务建设的估计指标（Service Construction Estimation Metrics Work Product）

描述：这些指标是服务建设加监控计划中需收集的资源指标。它们为新服务和新 SOA 项目的管理提供了宝贵的输入。这些指标的稳步改进是 SOA 不断成熟及有效 SOA 治理的标志。

目标：它们使服务工厂有效治理的重要指标。

何时需要：应在计划开发服务时创建，为每个创建的服务收集数据。

责任人：首席服务架构师，SOA 治理主管，PMO

负责人：首席服务架构师

咨询谁：SOA 使能团队，PMO

告知谁：PMO

服务建设监控计划（Service Construction Monitoring Plan Work Product）

描述：该计划要求在服务和自动流程开发的生命周期中对采集资源使用情况并持续地更新。通常，每个建设阶段的资源估算被分成复杂的、适中的、简单的服务 / 流程三类。

目标：它们使服务工厂有效治理的重要指标。

何时需要：应在计划开发服务时创建，为每个创建的服务收集数据。

责任人：首席服务架构师，首席 SOA 架构师，SOA 治理主管，PMO

负责人：首席服务架构师

咨询谁：SOA 使能团队

告知谁：SOA 使能团队，PMO

服务部署方法（Service Deployment Approach Work Product）

描述：现有 IT 部署方法应根据服务的特征进行调整。在传统 IT 开发方法中，出于运维系统稳定性的考虑，部署周期通常是一年执行几次大型增量部署；而在服务的开发方法中，几乎可以每天执行一次服务部署。

目标：确保在最有利的情况下实现最佳服务部署。

何时需要：在 SOA 开发方法通过之后立刻创建。

责任人：IT 运维人员

负责人：首席服务架构师

咨询谁：IT 运维人员

告知谁：服务开发者

服务设计清单（Service Design Checklist Work Product）

描述：该清单确保服务规约中的服务内在是最高规格的、完全的、无二义的。

目标：确保最高的服务质量，减少重复工作。

何时需要：清单模板应该在 SOA 开发方法通过创建，每个服务的清单实例应该在服务设计控制点之前完成。

责任人：服务架构师，QA，安全架构师创建模板； 服务开发者完成具体清单。

负责人：服务架构师

咨询谁：服务设计者，服务开发者

告知谁：SOA 使能团队

服务设计走查清单（Service Design Walkthrough Notes）

描述：它们是描述服务设计走查讨论会（如，针对个体服务，架构师、设计师和开发者汇集一堂开的讨论会，即对设计进行优化又可指导经验不足的成员）结果的较正式清单。

目标：通过把常见问题（它们可能需要额外的架构决定、设计标准、最佳实践和培训等）标识出来，保证 SOA 开发方法持续有效。

何时需要：应在每次服务设计走查讨论会结束后完成。

责任人：服务设计员，服务开发者

负责人：服务架构师

咨询谁：首席 SOA 架构师

告知谁：SOA 治理主管

服务部署清单（Service Deployment Checklist Work Product）

描述：该清单用于确保服务以部署方法中描述的方式进行。这需要考虑一些实际情况，比如，根据服务架构师或服务设计者明确的需求， 服务可能有多个实例、多种访问渠道、针对不同消费者的不同的 QoS 级别。

目标：确保服务已最佳的方式部署。

何时需要：应在服务的验收流程之前完成。

责任人：IT 运维人员在服务架构师的协助下创建清单模板。服务开发者与服务架构师为每个服务填写清单实例。

负责人：服务架构师

咨询谁：IT 运维人员

告知谁：服务开发者，服务注册员

服务粒度，可视性和访问控制清单（Service Granularity，Visibility and Accessibility Checklist Work Product）

描述：该清单用于确保服务具有最佳的范围，让需要访问某服务的消费者看到并能访问到它。

目标：确保最高的 QoS，实现商业价值和重用可能性的最大化。

何时需要：在解决方案控制点之前完成，并在服务设计控制点再次验证。

责任人：SOA 治理主管创建模板，首席业务分析员和服务设计员为每个服务完成具体清单。

负责人：业务服务主管

咨询谁：业务分析员，服务注册员，服务设计员

告知谁：SOA 使能团队，PMO

服务级别协议（Service Level Agreement Work Product）

描述：SLA 代表者服务消费者和服务提供者之间企业的条款和条件。IT 运维人员负责监控双方是否遵守契约中规定的属于和条件。SLA 应包含：

• 基于相应的服务非功能需求保证 QoS 级别
• 技术支持上的条款和条件（服务台工作时间，对突发性紧急事件的响应时间等）
• 对服务消费者的限制（如，指定如果服务消费者的请求率超过预先设定的预制，不能保证 QoS）
• 对于收费服务，对内或对外，确定服务请求的计费结构
• 版本管理对消费者的影响，如支持几个服务版本，将废止服务的继续服务时间， 服务消费者能收到的多少关于服务更改（或服务退休）的警告信息

目标：定义服务使用合约条款。

何时需要：只要可能，SOA 治理主管就应该尽早制定标准 SLA 条款和条件。

责任人：SOA 治理主管，业务服务主管

负责人：业务服务主管

咨询谁：SOA 使能团队， PMO

告知谁：服务所有者，服务消费者，PMO

服务重用准则（Service Reusability Guidelines Work Product）

描述：基于 SOA 开发方法，该工作件包含指导服务设计员设计出最大可重用性的服务。

目标：力求设计的服务具有最大的复用潜力。

何时需要：应在 SOA 开发方法通过后创建。

责任人：首席 SOA 架构师，服务架构师， SOA 治理主管

负责人：业务服务主管

咨询谁：业务分析员，流程建模员

告知谁：SOA 使能团队，QA

服务安全方法（Service Security Approach Work Product）

描述：实施 SOA 安全的最优方法，SOA 安全包括加强以下几个方面：

• 对所有服务消费者的认证和授权
• 对服务请求执行的不可否认性。
• 企业数据资产的保护。
• 加密在各种通道上（如 Internet）传输的数据。

目标：建设并维持安全的 SOA 生产环境。

何时需要：应在 SOA 开发方法通过后创建。

责任人：安全架构师，首席服务架构师

负责人：安全架构师

咨询谁：运维管理员

告知谁：SOA 使能团队

服务安全清单（Service Security Checklist Work Product）

描述：该清单的个别实例由服务设计者完成，由安全架构师批准。服务安全清单应该需在多个控制点签字以避免可能破坏安全一致性的变更的发生。

目标：保证不符合安全需求的服务永远不会部署到生产环境。

何时需要：最初应在服务规约控制点准备，然后在服务构建、测试、认证和部署等控制点再次审核。

责任人：该文档的模板由安全架构师设计，并由首席服务架构师批准；具体的清单实例由服务开发者和服务测试人员完成并由安全架构师批准。

负责人：安全架构师

咨询谁：IT 运维人员

告知谁：SOA 使能团队

服务采购策略（Service Sourcing Policy Work Product）

描述：基于 SOA 开发方法，服务外部策略描述的是，一旦明确了需要特定服务或服务操作，企业应从以下方案中做出选择：

• 从无到有开发服务功能。
• 使用现有资产或应用程序，包装成服务。
• 购买可能包装成服务或已包装成服务的商业现货（COTS）。
• 向提供该能力的软件及服务（SaaS）供应商购买服务。

目标：确保服务采购决定（购买 VS 自建）的一致性。

何时需要：应在 SOA 开发方法批准后创建。

责任人：SOA 治理主管

负责人：采购

咨询谁：业务服务主管

告知谁：SOA 使能团队，PMO

服务规约（Service Specification Work Product）

描述：服务规约不是单个文档，而是与服务或流程的使用、构建、测试和认证相关的所有信息的打包。它应包含：

• 前面讨论的服务外在（Service External）和服务内在（Service Internal）。
• 需访问的每个现有 IT 资产的接口细节。
• 功能性和非功能需求。
• 安全信息（谁可访问、认证、加密，不可否认性）。
• 部署属性（如，地理上差异；“铂金级”，“金牌”，“银牌”等支持等级）
• 监控和系统管理需求。
• 测试计划和测试数据。
• 服务规约包的完整性和准确性是个严峻的考验，它应该没有二义性，而且提供必要的信息，只要是有适当经验的远端开发者，就能在不需要澄清任何内容的情况下开发出高质量的代码。就此而言，含有各种模型的精密工具比单纯的文字和图片在多数情况下会更胜一筹。

目标：确保最高的 QoS。

何时需要：服务外在应在解决方案规约控制点之前完成，完整的服务规约需在服务设计控制点之前完成。

责任人：首席服务架构师，QA，SOA 治理主管设计模板；服务设计者和服务架构师完成每个服务规约包。

负责人：业务服务主管

咨询谁：SOA 使能团队

告知谁：服务消费者可以访问服务外在（Service External），而且只有 SOA 使能团队（特别是服务开发者和服务测试人员）才能访问服务内在（Service Internal）。

服务规约清单（Service Specification Checklist Work Product）

描述：该清单保证所有的服务规约包都按可能的最高标准建立，包含所有需要的信息，清楚而明确。

目标：确保最高可能的 QoS。

何时需要：应在解决方案规约控制点之前完成。

责任人：服务设计者，QA，and 服务注册员

负责人：业务服务主管

咨询谁：SOA 使能团队

告知谁：SOA 治理主管

服务测试计划（Service Test Plan Work Product）

描述：详尽的功能性和非功能测试对于服务质量极为重要。每个服务的测试计划应描述要做的所有测试以及期望的结果。

目标：确保最高可能的 QoS

何时需要：应该在服务设计控制点之后立即建立。

责任人：服务测试经理，业务分析员

负责人：业务服务主管

咨询谁：服务架构师，服务设计者与业务分析员

告知谁：服务测试人员

服务测试结果（Service Test Results Work Product）

描述：他们记录了测试计划执行的结果，包括功能性测试和非功能测试。在服务通过服务测试控制点之前必须要成功完成所有相关测试。

目标：确保最高可能的 QoS

何时需要：应在测试成功完成之后，服务验收控制点之前完成。应定期检查测试结果，从中寻找待解决的系统问题，也许通过额外的培训，或修改标准及最佳实践。

责任人：服务测试人员，QA

负责人：服务测试经理或 QA

咨询谁：服务架构师，服务设计者与业务分析员

告知谁：SOA 治理主管，PMO

服务版本管理方法（Service Version Management Approach Work Product）

描述：该方法定义了服务和流程应如何管理，为该方法的实际执行和验证设置相应的责任人。它应包含服务设计的建议，如将服务设计成向前兼容的，换言之，服务可在不影响现有消费者的前提下递增地扩展。第六章将详细描服务的版本管理。

目标：定义服务如何进行版本管理。

何时需要：应在 SOA 开发方法批准之后立即创建。

责任人：首席 SOA 架构师，服务架构师，SOA 治理主管

负责人：业务服务主管

咨询谁：IT 运维人员

告知谁：IT 运维人员，服务消费者

SOA 开发效率报告（SOA Development Performance Report Work Product）

描述：该报告是对服务和流程的建设过程中相关的分析、设计、建设以及测试等活动的持续监控而得到的。

该报应该记录实际使用的资源，解释它们与估计值的偏差，描述发展趋势。最佳情况下，它们能反映出生产力的提高和重复工作量的减少！

目标：确保 SOA 开发方法和 SOA 治理的持久活力。

何时需要：每一至三个月就应该完成一次并分发出去。

责任人：首席 SOA 架构师，PMO，SOA 治理主管

负责人：首席服务架构师

咨询谁：服务测试人员

告知谁：SOA 使能团队，PMO

SOA 开发工具（SOA Development Tools Work Product）

描述：它们是有助于服务和流程开发和测试优秀工具，任何意在向 SOA 转型的公司都应该选择一组能提高生产力的好工具。最有效的工具是支持模型驱动开发原则工具，即定义服务或自动流程的模型，并不断优化，直到完善，此时由工具自动生成代码。第六章将对此作详细描述。

目标：建设并维持高效的开发和测试环境。

何时需要：应在 SOA 开发方法工作件创建之后创建。

责任人：首席 SOA 架构师，服务架构师

负责人：首席 SOA 架构师

咨询谁：服务开发者，服务组装人员，SOA 业务分析员，流程建模员，流程开发者，监控开发者，企业架构师

告知谁：SOA 使能团队

SOA 开发经验总结（SOADevelopment Lessons Learned Work Product）

描述：在服务或流程开发生命周期中任何重要工作完成之后，主持一个非正式讨论会并探讨在实践中学到的经验是很有价值的事情。经验总结应该包含 SOA 开发流程、工作件、治理方法、治理严厉程度、工具和技术等方面。不论这些总结是积极的或消极的，它们都能为 SOA 开发和治理的有效性带来有价值的看法。

目标：确保 SOA 开发方法和治理的持续有效性。

何时需要：应该每 1 至 3 个月执行一次并分发结果。

责任人：所有控制点审核员

负责人：SOA 治理主管或 PMO

咨询谁：SOA 使能团队

告知谁：SOA 使能团队，PMO

SOA 治理策略豁免（SOA Governance Policy Exemption Work Product）

描述：该工作件为某些重要的业务需求定义的可以不遵守通用标准、最佳实践、或策略的豁免权，豁免过程以及谁有权授予豁免权必须要定义在 SOA 治理计划中。豁免类型、级别以及他们为何授权或为何拒绝授权等都是 SOA 治理效力的重要的度量方法：

• 如果只有少数豁免申请，则可能是应为标准太宽松、治理度不合适、或某些开发者忽视了治理方法和规则。
• 如果豁免申请过多，或授予了太多的豁免，则表明标准可能太严格。

目标：记录（不遵守标准或最佳实践的）豁免申请的授予或拒绝。

何时需要：应在每次收到豁免申请是完成。

责任人：首席 SOA 架构师，SOA 治理主管，QA，PMO

负责人：首席服务架构师或企业架构师

咨询谁：服务架构师

告知谁：豁免申请人（通常是服务架构师或服务设计者）

SOA 重用和 ROI 报告（SOA Reuse and ROI Report Work Product）

描述：根据 SOA 重用和 ROI 监控计划，该定期性报告应该尽可能客观地评估真实的重用度和获得的 ROI。其中一些数据来自 IT 项目，从项目的收益表和 ROI 工作件中获得。

目标：度量并报告 SOA 转型项目的实际商业价值。

何时需要：每 1 至 4 个月报告一次，或通过实时的治理仪表盘展示。

责任人：SOA 治理主管，首席服务架构师，PMO

负责人：业务服务主管

咨询谁：SOA 使能团队，服务消费者，IT 运维人员

告知谁：总执行，PMO，SOA 使能团队

这些工作件间的依赖关系如图 4.3 所示，其格式与第三章中的图 3.3 一致。同样，标“*”号的工作件需每 6 至 12 个月修订一次才能确保持续的有效性。

图 4.3 服务开发域：工作件间的依赖关系

服务运维域

“文明是通过增加那些我们不加考虑就能实施的行为的数目而进步的。”
——阿弗烈·诺夫·怀海德

该节介绍服务和自动流程的在生产环境中的治理。SOA 为 IT 运维人员不仅带来了好处，也提出了挑战。好处有：

• 更容易监控服务的使用情况和 QoS，有一些很好的商业工具可以做到这点，甚至有些还能提供实时展现 QoS，使用情况等统计信息的“仪表板”。
• 服务比应用程序提供了更丰富的部署时机会及“谁能使用”等更多信息。
• 通用安全机制能够保护所有服务免受安全暴露和恶意攻击的危害。

挑战有：

• SLA 需要持续监控，并且记录违反 SLA 的行为。
• 除非服务质量、构建管理和部署流程极其有效，不然单个服务的频繁部署可能对生产环境的稳定习惯造成威胁。

服务运维涉及的关键治理任务

确保 SOA 运维有效治理的关键任务包括：

• 为服务提供有效的技术支持，快速有效地解决软件质量的突发事件。
• 监控服务和自动流程的执行，特别是监控它们对 SLA 条款的符合。
• 维护运维系统的活性、可靠性、可用性及性能。

多数企业都有负责管理生产 IT 系统的独立 IT 运维部门。 表 4.2 描述了能有效地治理服务的 IT 运维部门的关键能力。

表 4.2 服务运维域：能力、风险和治理工作件

能力

相关的问题及风险

风险级别

治理工作件

治理成本

O01. 服务执行监控

服务消费者期望高可用和高 QoS，SLA 保证他们获得。

关键

• SLA
• QoS 目标
• QoS 监控计划
• QoS 报告
• 服务使用情况
• IT 能力管理计划
• SLA 合规报告
• SLA 监控计划

相当高

O02. 服务运维活力

服务消费者不希望在每次新服务版本出现时修改应用，除非新版本中包含他们所需的功能。

关键

• 服务运维活性报告
• 废弃或退役服务列表

适中

O03. 服务支持

如果与服务相关的 bug 或问题产生时，消费者需要技术支持。

关键

• 技术支持方法和目标
• 问题发生日志

相当高

服务运维域工作件定义

本节描述有助于治理服务运维域的工作件。任何适当治理的 IT 生产环境都应该具备这些工作件中的大部分，但是其中的一些需要增加对 SOA 的扩展。它们依然是按英文字母的首字母顺序排序的。已经在第三章定义的工作件不再重复定义，同时还给出于这些工作件相关的角色。

弃用或退役服务列表（Deprecated or Decommissioned Services Work Product）

描述：这是一组已经弃用或即将弃用的服务列表。弃用服务应该仍然要支持，但是新服务消费者应不再能访问它了。这些过时或废弃服务数目能够反映出服务版本管理方法的效率——理想情况下该数目较小。

目标：监控 SOA 运维有效性。

何时需要：每 4 至 6 个月

责任人：服务注册员

负责人：业务服务主管

咨询谁：服务消费者，PMO

告知谁：SOA 使能团队，PMO，服务消费者，IT 运维人员

问题发生日志（Problem Incident Log Work Product）

描述：它是 IT 治理中的一个基本工作件，其内容应根据服务消费者及流程用户的具体需求调整。它记录了所有的技术问题的发生细节及解决过程。

目标：用于提供已部署服务质量的珍贵信息。SOA 治理主管和首席 SOA 架构师从中找出系统质量的问题并做紧急处理。

何时需要：应在 SLA 发布之前完成，而且 SLA 应该包含显示技术支持级别的条款

责任人：服务台或技术支持人员

负责人：IT 运维经历，技术支持经历

咨询谁：SOA 治理主管

告知谁：问题报告人，PMO

服务质量目标（Quality of Service Goals Work Product）

描述：QoS 目标明确地设定了服务和自动流程需达标的性能目标和运维效率。该目标应比具体服务的非功能需求和 SLA 需求稍为超出一点，这样才能保证合同条上的条款能够安全着陆。

目标：监控服务运维的性能。

何时需要：服务第一次部署时创建，此后每 6 个月左右更新一次

责任人：首席服务架构师，首席 SOA 架构师，SOA 治理主管

负责人：IT 运维经理

咨询谁：业务服务主管，PMO，个别业务部门

告知谁：IT 运维人员，SOA 使能团队，PMO

QoS 监控计划（QoS Monitoring Plan Work Product）

描述：该文档指定为实现 QoS 目标而对服务和自动业务流程实施监控的计划。该计划应该记录监控每个 SOA 的问题对业务造成的影响。单个网络组件出问题的影响可能不大，如果它是一个主要服务或功能的单点故障点，废除运行模型有完全备份，不然其商业影响就不可小觑。

目标：确保满足 QoS 目标。

何时需要：服务第一次部署是创建，此后每 6 个月左右更新一次

责任人：首席服务架构师，首席 SOA 架构师，SOA 治理主管，监控开发者

负责人：IT 运维人员

咨询谁：业务服务主管，QA，PMO

告知谁：SOA 使能团队

QoS 报告（QoS Report Work Product）

描述：它是基于每个服务将实际 QoS 和目标 QoS 进行比较的定期报告（理想情况下可能是一个实时治理仪表板）。

目标：确保实现 QoS 目标。

何时需要：至少每月一次，理想情况下实时在线更新

责任人：首席服务架构师，SOA 架构师，SOA 治理主管，监控开发者，IT 运维人员

负责人：SOA 治理主管或 IT 运维经理

咨询谁：IT 运维人员

告知谁：SOA 使能团队，SOA 执行

服务运维活性报告（Service Operational Vitality Report Work Product）

描述：该报告提供了 IT 运维活性的预览，包括服务使用的增长（即包含新增服务消费者有包含服务请求的增长）、QoS 报告以及报告间隔内新部署的服务。其内容来自多个出处，如 QoS 报告，SLA 合规报告和 IT 运维人员提供的服务部署和服务使用状态数据。

目标：传达 SOA 运维获活性。

责任人：SOA 治理主管、监控开发者和 PMO 定义报告的结构；IT 运维人员和服务注册员提供数据

负责人：IT 运维经理，SOA 治理主管

咨询谁：业务服务主管，IT 运维人员

告知谁：SOA 使能团队，SOA 执行

服务使用情况数据（Service Usage Data Work Product）

描述：SOA 较传统软件开发方法的主要优势之一是它可能获取很多服务和自动业务流程使用情况的运维信息。事实上，只有获取或记录了使用信息，才可能进行服务运维域的治理，或向第三方收取服务使用费。

服务使用情况的统计信息可以手工获得，所以 SOA 基础设计自动化该认为变得至关重要。需收集的服务和自动业务流程的数据包括：

• 谁调用哪个服务操作或自动流程？
• 有无非法访问请求了服务或流程？
• 请求执行的总时间，该时间是否满足 QoS 和 SLA 目标？
• 每个服务的每小时总体交易量是多少？
• 对于业务流程，需额外收集以下信息：
• 在几个逻辑分支中，执行了哪个分支？
• 自动流程调用人工任务时，该任务多久完成？
• 有无“耽搁的”人工任务，即该任务没能在规定的 QoS 时间阈值内完成。

这么大的信息量看起来非常困难，故而需要用报告或仪表板的形式展现。

目标：收集并总结服务和流程的关键性能和使用数据。

责任人：SOA 治理主管、监控开发者和 PMO 定义报告或仪表板的展示结构；IT 运维人员提供数据

负责人：IT 运维经理或 SOA 治理主管

咨询谁：业务服务主管，IT 运维人员

告知谁：SOA 使能团队，SOA 执行

SLA 合规报告（SLA Compliance Report Work Product）

描述：SLA 合规报告有两类：

• 定期报告的 SLA 合规确认信息。大多数（理想情况下，所有的）SLA 合规监控报告应该展现符合 SLA 条款的实际实现的 QoS 数量。
• 更重要的报告——SLA 合规失败报告，虽然我们希望有，但是很少见。在 SLA 合规失败时，应该向服务消费者、首席 SOA 架构师、业务服务主管、和 SOA 治理主管发出紧急通知，通告发生的情景以及避免再次发生应采取的措施。

目标：监控 SLA 合规并处理突发事件。

何时需要：为支持即将描述的 SLA 监控计划，定期 SLA 合规报告应按月执行。在 SLA 违例事件发生时，应立刻采取修正措施，尽快通知所有影响到 的服务消费者。

责任人：IT 运维人员，监控开发者，SOA 架构师，服务架构师

负责人：IT 运维经理

咨询谁：服务架构师，服务设计者，SLA 违例时咨询 QA

告知谁：PMO，SOA 使能团队，服务台 / 技术支持人员，服务消费者

SLA 监控计划（SLA Monitoring Plan Work Product）

描述：该计划对每个消费者监控所有服务及流程执行，并确保每个消费者都享受了适当的 SLA。SLA 监控需用正规的系统管理工具和框架进行。这项工作无法手工完成。

目标：如果你不知是否满足了 SLA，那么 SLA 就没有存在的意义。没有正式的 SLA 执行，就失去了 SOA 治理的意义。

何时需要：与定义 SLA 同时。

责任人：PMO，首席服务架构师，首席 SOA 架构师，IT 运维人员，SOA 治理主管，监控开发者

负责人：SOA 治理主管或 PMO

咨询谁：业务服务主管，IT 运维人员

告知谁：IT 运维人员，QA，PMO，SOA 使能团队

技术支持方法和目标（Technical Support Approach and Targets Work Product）

描述：这是 IT 治理工作中一个基本的工作件，其内容根据服务消费者和流程用户的具体需求而调整。它定义了内部或外部消费者期望的技术支持级别和响应速度。高安全问题和价值高的服务的支持级别也较高。服务和流程的 SLA 文档中应包含有保障的支持级别。

目标：确保基础支持和 SLA 受到重视，服务消费者享受充分的技术支持。

何时需要：应在任何 SLA 发布之前完成，而且，SLA 应包含技术支持级别的相关条款

责任人：首席服务架构师，SOA 治理主管，PMO

负责人：IT 运维经理

咨询谁：业务服务主管

告知谁：服务台 / 技术支持经理，QA，PMO

以上工作件间的依赖关系见图 4.4，同样，该图的格式与图 3.3 与图 4.3 一致

图 4.4 服务运维域：工作件依赖关系图

案例分析

“后悔自己的经历等于束缚自己的发展；否定自己的经历等于将谎言放进生活的嘴唇，它不亚于对灵魂的否定。”
——奥斯卡. 瓦尔德

服务转型规划是 SOA 治理需要的优先能力之一，有了它治理团队就可以与 EA 团队一起治理其他业务服务任务。服务开发生命周期控制（SDLC）是又一关注的领域。毕竟，我们需要遵循最佳实践并跨部门遵守统一方法，这尤其有助于加强服务转型规划的产出。

服务开发生命周期控制

Ideation 希望用通用的、结构化开发流程的想法已经有一段时间。某些团队偶尔对代码进行结伴审阅，但是这种审阅往往是无计划的，不完整的。

Ideation 的另一团队正在考虑标准化开发方法，他们对你的 SOA 治理团队提出的要求是，为以下服务开发生命周期中的环节制定治理控制门：

• 业务需求
• 解决方案架构
• 服务表示和规约
• 服务构建
• 服务测试
• 服务认证

Ideation 的控制门

在于开发部门相关人员磋商之后，你决定为 Ideation 的 SDLC 建立如下控制门：

• 业务需求控制门
• 解决方案架构控制门
• 服务设计控制门
• 服务构建控制门
• 服务测试控制门
• 服务认证和部署控制门

你的第一步是创建业务需求控制门模板并征求反馈意见，如表 4.3 所示。

表 4.3 Ideation 业务需求控制门

区域

包含

定义

动机

该控制门的业务理由

为创建具有最大敏捷及重用可能的服务，我们必须要有一致且格式良好的业务需求。这要求我们用一致的，可重用的方法描述业务需求，该描述为开发周期中的其他环节提供必要信息。

目标

输出目标

业务需求应包含足够与格式无关的内容，从而保证服务的开发按照需求进行；IT 应有业务需求和目标的真实描述。这有利于 IT 部门更好地设定项目规模并作出评估，有利于跨业务部门提交业务需求的一致性。

触发

触发事件

从业务向项目经理提交的完整的业务需求。

规模及适用性原则

指定该场景适用的规模 / 评审风格

适合在大于 100K$ 的项目中执行

评审风格

评审类型的一般分类：

• 结伴评阅
• 提交—批准
• 研讨会
• 正式会议

研讨会的内容是评审需求规约，为后续的设计职责标准确定合理的细化程度。出席研讨会的人员有：

应用架构师
流程分析员
业务架构师
业务分析员
需求分析员
解决方案设计员
项目经理

概念 / 方法

描述如何评审，评审如何支持目标

项目经理组织并主持研讨会。
应用架构师、业务分析员、需求分析员和解决方案设计者必须验证需求是否满足开发周期中后续阶段的要求。换言之，他们知道需要哪些信息才能做好工作，才能理解需求。
业务架构师必须通过架构评审委员会需求标准验证需求：在需要更新的地方作标记并确定跟进动作；或批准 / 拒绝需求（需要更新）。

治理权威

业务架构师是治理权威，他们负责验证需求的格式以及是否所有业务需求都符合标准。

责任 / 管理

项目经理安排并主持研讨会

负责人——批准 / 条件批准 / 决绝

业务线的主管必须对需求负责，并在最后的签核时作出批准。

咨询谁 / 谁支持 / 谁执行

应用架构师要理解需求并确保高层解决方案架构（架构解决方案文档）需要的需求信息都已备齐。
流程分析员回答业务流程相关的问题 ，保证其他需求符合业务流程。
业务分析员负责提交需求，随时回答需求相关的问题，并跟踪需求变更。
需求分析员理解需求，创建需求描述，并确定与每个开发团队相关的需求描述（让开发团队了解哪些方面受到影响）。
解决方案设计者理解需求，从应用架构师处拿到架构解决方案文档，创建解决方案设计（端到端的解决方案）。解决方案设计者还需负责组件设计。
测试 /QA 负责判断需求文档是否足够清晰。

告知谁

所有参与者，治理专家

可用物件

所需输入

业务需求应该研讨会之前递交到所有与会者手中。（需要理解客户的服务级别协议 [SLA] 并达成一致意见）对需求的验证应采纳来自应用程序架构师、业务分析员、需求分析员和解决方案设计者的意见。

参考哪些意见

应用程序架构师、业务分析员、需求分析员和解决方案设计者必须验证需求是否满足开发的后续阶段的要求。换言之，他们知道需要哪些 信息才能做好工作，才能理解需求。

关键评阅准则

凸显关键准则

必须符合业务需求标准，包括：

• 业务需求包中的需求的一致性
• 业务需求忠于业务流程
• 业务需求遵守法律和企业的规范及标准。

工作件的关键验收准则

成功评阅工作件的关键验收准则

业务需求必须满足的一致性和完整性。指出任何矛盾、缺口或有改进或返工可能的需求点。记录后续步骤、工作分工、达成一致的进度表以及达成一致的跟进动作。

清单

选定一个推荐评阅流程。为建议、返工和签核提供客观支持

将使用业务需求清单

升级流程

对控制门结果申请特例时使用的升级流程的名称

为驱动业务需求达成结论，将决定升级到 PMO

度量指标

在此控制门执行过程或结束是采集的度量指标

此控制门的治理指标，包括增加此门实施的次数，增加业务单元通过此门的次数，结果（通过，失败，条件通过）以及清单得分。

产出

谁负责最后签核，通知谁，结果向谁呈递？

最后签核——业务线主管。通知——通知列表中的所有成员和服务注册员。 呈递——PMO 是正式所有者。

第二步，你要建立解决方案架构控制门并得到反馈。如表 4.4 所示。

表 4.4 Ideation 解决方案架构的控制门

区域

包含

定义

名称

控制门名称

解决方案架构

动机

此控制门的业务理由

根据技术标准和原则对解决方案提案作出批示。标准和原则有：

• 确认交付件是否具有包容性且“符合目标”
• 推进交付件的整合和支持
• 在进一步投资之前主动理解影响

目标

输出目标

评估交付件的成效分析和对成员域的影响：

• 在整合、接口和交付件支持上达成一致。
• 确保替代方法和解决方案。
• 对新建 IT 解决方案作出批示。

触发

触发事件

项目经理收到完整的解决方案架构文档。

规模 / 适用性原则

指定该场景适用的规模 / 评审风格。

适合在大于 100K$ 的项目中执行。

评审风格

评审类型的一般分类：

• 结对评阅
• 提交—批准
• 研讨会
• 正式会议

研讨会的内容是评审需求规约，根据指定原则确定合理的细化程度。出席研讨会的人员有：

应用架构师
流程分析员
业务架构师
业务分析员
需求分析员
解决方案设计员
业务线主管

概念 / 方法

描述如何评审，评审如何支持目标

业务分析员必须验证需求是否符合标准，继而引发业务需求评审研讨会的安排及完成。

参与者，角色和权益

治理权威

架构评审委员会（ARB）

责任 / 管理

项目经理——触发会议并提供跟进和结果。

负责人——批准 / 条件批准 / 决绝

首席架构师——负责报告架构解决方案文档并回答相关问题。

咨询谁 / 谁支持 / 谁执行

解决方案设计员——负责报告标准和策略的技术专业知识，评估架构解决方案文档和端到端的解决方案是否可行。

业务分析员——代表业务用户，验证解决方案是否满足业务需求，接受或拒绝架构方案提案中的取舍。

架构执行——提供指导、评阅输出、保证获利。

基础设施架构师（如果解决方案中基础设施较重）——负责架构方案文档中的基础设施 架构，并根据需要回答相关问题。

基础设施设计员——验证架构方案的结构可行性。

需求分析员——评阅并理解高层解决方案架构，下游需求的上下文以及分析建议。

数据架构师——负责架构方案中的数据架构并回答相应问题。

告知谁

所有参与者，CoE（卓越中心）。

要创建的物件

所需输入

可用的架构解决方案文档。

参考哪些意见

解决方案设计员、解决方案架构师、基础设施架构师、基础设施设计员和需求分析员必须验证架构方案文档是否满足后续开发阶段的要求 。换言之，他们知道需要哪些信息才能做好工作，才能理解需求。

关键评阅准则

凸显关键准则

架构方案文档必须遵守架构标准、策略和模式。

架构方案文档符合现有应用程序的将来视图。

架构方案文档凸显关键基础设施影响和需求。

是否标识出服务并进行了服务分类，服务粒度是否合适（服务石蕊测试）。

工作件的关键验收准则

成功评阅工作件的关键验收准则

必须遵循的高层设计的一致性和完整性；指出任何矛盾、缺口或有改进或返工可能的点；记录后续步骤、工作分工、达成一致的进度表以及达成一致的跟进动作。

清单

选定一个推荐评阅流程；为建议、返工和签核提供客观支持

遵循架构方案文档清单

升级流程

对控制门结果申请例外时使用的升级流程的名称

请求返工的例外可由 ARB 批示；而对于服务发现上的分歧，ARB 需要将此问题提升至 CoE 来解决。

度量指标

在此控制门执行过程或结束是采集的度量指标

此控制门的治理指标，包括增加此门实施的次数，增加业务单元通过此门的次数，结果（通过，失败，条件通过）以及清单得分。

产出

谁负责最后签核，通知谁，结果向谁呈递？

最后签核——ARB 主管。通知谁——通知列表中的所有成员和服务注册员。 向谁呈递——PMO 是正式所有者。

结论

“人类一切和平合作的基础首先是相互信任， 其次才是法庭和警察一类的机构。”
——阿尔伯特·爱因斯坦

本章描述了治理高效的服务工厂的实践工作件方法——通过软件工程的方法进行服务和业务流程的定义、开发、测试、部署并运维。

工作件方法帮助管理相关工作的复杂度和相互间依赖关系，它引入了若干中间交付件，记录了服务及项目开发周期中各种状态之间的转换，通过创建一组控制点作为治理机制来确保交付件按质量构建。治理过程通过工作件创建者与消费者之间的正式和非正式契约实现，这种机制有助于较早发现及解决质量问题，而不仅仅依赖于死板的中心控制的干预。

我们的方法并不是权威独断型的——这样的方法并不能应用于任何像 SOA 转型一般复杂的项目。相反，该方法使用工作件和简单、高效的控制点评审，通过它们的协作进行检验和权衡，通过持续反馈改进企业部署的 SOA 资产的质量和完整性。

在第六章，我们将再访服务工厂，走近生产线，看看它是如何运作的，看看治理如何应用于服务和流程生命周期的状态间转换。

查看英文原文： SOA Governance: Achieving and Sustaining Business and IT Agility

本章是《SOA 治理：实现并维持业务及 IT 的敏捷性》的节选，该书由 William Brown，Robert Laird，Clive Gee 和 Tilak Mitra 等合著，IBM 出版社 2008 年 12 月出版，ISBN 号：0137147465，版权归 IBM 公司所有。欲了解更多信息，请访问出版社网址 （ www.ibmpressbooks.com ）。该书可以从 Safari 在线书库中找到，读者可以从这里 http://www.safaribooksonline.com/informit/customize?cid=200911-informit- blog-custom 下载 15 天的免费试用版。

感谢黄璜对本文的审校 。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。