SOA 治理的仙境

引言——掉进兔子洞

Harry W. 曾在论坛里说到“爱丽丝并非掉进兔子洞。而是，一只小白兔引起了她的兴趣，于是她愿意跟随兔子深入兔子洞”。没错，“仙境”的秘密就在这些文字的含义之中：Harry 坚持认为爱丽丝“愿意跟随”兔子深入兔子洞，而爱丽丝则显然“发现自己已经掉入洞中”。SOA 治理的“仙境”中也发生着相同的故事——它就像兔子洞一样，人们心想的是治理而谈论的却是管理或其他完全相反的事情……[译注：本文的爱丽丝，兔子洞源自经典童话《爱丽丝漫游奇境》]

我们通常认为管理包括治理。该理解没错：牛津字典和Merriam 韦氏字典以及英语同义词字典都把“治理” 放在“管理”的近义词中。然而，反过来则不正确，治理不是管理。治理关心的是政策和控制规则，而管理的含义则是政策执行和控制。管理需要治理，否则就无从知道如何运行，执行以及保护。

我了解到在过去两年间，至少有3 本书为SOA 治理而著，infoQ 上至少发表了8 篇关于这个主题的文章。然而，我发现在绝大多数出版物中，SOA 治理都直接关联政策加强或管理。迄今为止，只有 OASIS SOA 参考架构（Reference Architecture），公众评阅草案 1 中认识到“兔子洞”的影响，并将 SOA 环境中的治理和管理清晰地分离开。

你也许会问，为什么把治理从管理中分开那么重要？我的回答是：分离就能让我们更好地理解它们分别是什么，为什么需要那些工作，必须由谁来做并对治理及其交 付件负责。再者，分离还有助于我们组织治理控制、合规报告以及通过治理政策对企业战略计划的敏捷性进行监督。图1 描述了治理和管理的权力分离在SOA 项目 和普通项目中都需要实行。因此，政策和规则的制定者不一定是其执行者——这是简单的权力平衡。换言之，管理本身必须要符合治理政策，然后它又能够在治理的 主题上加强政策的执行。

另一个问题是我们为什么需要治理SOA 以及为什么我们以前没有谈过其他技术的治理，如CORBA，和面向对象（OO）设计。很好，问题的后半部分并不完全 正确——我记得有些人尝试过为OO 应用开发建立政策和最佳实践，但这些话题从来没有走出过IT 部门。而面向服务的架构为什么这么特别需要我们做出以前没有 做过的工作呢？

图 1

本文中，我将详细介绍治理和管理分离的结果，并尽力解释是哪些面向服务的具体方面让治理在SOA 环境中受到如此重视。在展开细节之前，我希望每个人都清楚 SOA 治理并不是关于政策开发和服务执行的。相反，它关注的是通过以下几个方面的最佳实践形成战略战术的业务方向及目标：a) 关系，b) 架构，c) 设计，d) 实施，e) 复合应用开发，i) 敏捷的企业业务，j) 敏捷应对市场需求。所有的这些都是为实现企业的根本业务目标所需的创造性精神。

SOA 治理定义漫游

在写这篇文章之时，至少已有两家标准化组织发布了他们对 SOA 治理的定义——OASIS 和国际标准化组织（The Open Group）。后者（对 SOA 治理）有两个定义，其一在 SOA 治理框架标准中 ，其二在 TOGAF 9 中。OMG SOA SIG吸收了来自行业分析家，媒体成员和用户的18 条SOA 治理的定义。 我认为绝大多数定义都认同SOA 治理的目的是通过政策和合规控制的手段尽可能地减少违背面向服务的概念和破坏业务目标的风险。不幸地是，由于治理和管理的混杂，我们的SOA 治理弄得一团糟。

例如，标准化组织的SOA 治理框架标准声称：“通常，治理指的是建立并加强人员和解决方案如何合作才能实现企业目标、强调实现控制、并区别治理和日常管理活动的差异。” 。我很想知道作者是怎么思考的，治理的加强不在日常管理活动中，难道是在假期活动中？

标准化组织的TOGAF 9 中是这样描述治理的：“它要 较少地公然控制和严格参照规则，而更多地是引导资源的有效和公平的使用，从而确保企业战略目标的可持续性” 。所以，看起来标准化组织还没有拿定主意——到底治理是“实行控制”还是“较少地公然的控制和严格参照规则”？在“较少地……严格参照规则”的上下文中 ‘加强’的含义何解？

OASIS SOAR A 定义：“SOA 系统的治理需要决策者的能力……去设定参与者，服务以及他们之间的关系。他需要确保有效地描述和执行政策的能力。它还需要有效方法以保证 服务及参与者的过去和当前的效率”。这种说法要求确保政策加强的能力却没有描述 SOA 治理中执行本身的含义。

谈论到 SOA 治理和管理的关系时，OASIS SOAR A 做了如下概述：

在治理和管理周围总存在一些疑团。……治理关心的是决策。而管理关注的则是执行。换种说法，治理描述了领导者所希望的世界；而管理则执行活动去实现管理者 想要的世界。[补全——通过加强治理政策的遵行]。治理所确定是，谁具有权力并负责下决定以及为要下的决定制定向导。管理是决定，实施和度量这些决定的实际流程。

SOA 治理的责任是建立政策和规则，治理（包括管理）主体的职责和责任是在此之下定义的。这包括了“在必须透明的地方要透明、不偏不倚的信任、治理的统一施行以及确保 SOA 生态系统中的可靠且有力的活动。”[OASIS SOAR A]。

没有管理则治理一文不值（除非受管人员极为规矩）；没有治理的管理是不可控和无方向性的。如图 1 所示，治理提供了不同类型的政策并定义了执行和控制的过程，而管理则实现政策（实施和加强政策）并提供政策合规的监控机制。政策被应用到多种事物上，包括服务、服务开发、人员、流程和过程。治理要立足于本地法 律，行业制度和来自企业管理层以及受管对象的反馈。

治理在企业架构中的定位

在给 SOA 治理定位之前，我必须要先解释这里所指的 SOA 和企业架构。我理解的 SOA 作为一个面向服务的架构，它是对具体技术和业务实现不敏感的。在我谈到 SOA 时，我将依照 OASIS SO RM 标准和 OASIS SOAR A。而企业架构指的是跨业务 -IT 边界，包含了企业的业务架构和技术架构在内的企业范围的架构组织。如果你的企业期望最大限度地利用 SOA 却没有这样的结构，那我建议创建一个这样的架构。

尽管 SOA 是企业架构的一个非常重要的组成部分，但是它不能代替企业架构。同时，在架构组织中，不一定所有的事物都是或都应该是面向服务的。SOA 为真实 业务世界建模，在这里业务服务是最重要的实体，但并非唯一的。作为一个架构方法论，SOA 影响业务和技术方法，但并不具体指定技术。在从面向流程的组织结构（典型地，价值链模型）到面向服务的组织结构（典型地，价值网络模型）的转型过程中，SOA 扩展了企业架构。在转型过程中转入的或在SOA 下创建的那些组织的部分，如产品，功能和服务等，必须是端到端面向服务的，上至用户接口，下至数据存储访问层。这是SOA 成功实现的前提条件。

SOA 治理并非孤立存在，它是企业治理的一部分。一方面，在逐步增加基于 SOA 的解决方案时，我们一个接一个地解决业务任务（如 SOA 最佳实践推荐的那 样）。但是，SOA 治理不能也这样一个项目到另一个项目，这样它将不起作用。具体来说，如果我们在一个业务部门（BU）的项目中实现服务 ，SOA 治理必须位于部门级，而不是项目级。如果多个部门实施 SOA，则 SOA 治理一定要位于业务线（LOB），部门或跨部门级。这样才能让治理政策均衡 地应用在所有的项目和服务中。

所以，SOA 治理一定要在建设和实施 SOA 人员之上的一个级别。解释这个需求很简单——SOA 治理的权力必须要大于受管对象的权力。这里问题的是不仅仅在权力的加强（这是管理的特性之一）上，还要在服务组合和聚合的观念上。SOA 治理设定了调控服务组合和相关服务协作的规则。比如，某 SOA 政策可能规定了 组合本身容许实现的业务规则的最大复杂度，而更复杂的业务规则应该转移至专门的“规则引擎”。基于以上解释，我们可以描绘一个 SOA 治理的结构图，如图 2 所示。

图 2

应该特别注意 SOA 政策职权级别与政策范围之间的关系。我们假设有如下四条政策：

政策 1：

‘所有的技术业务服务必须部署在 IBM 的 WebSphere 应用服务器上，依据 2009 技术路线图的规定确定版本（如 6.1 或以上）。这项政策无需应用于使用动态服务调用的组合服务’。

政策 2：

‘所有使用动态服务调用的技术业务服务必须部署在 IBM 的 WebSphere Business Service Fabric 上，参照 2009 技术路线图规定的版本’。

政策 3：

‘所有技术服务的发布测试必须包含被测服务所依赖的所有服务的端到端的测试。’

政策 4：

‘对所有技术服务的发布测试所遵循的技术和业务执行的政策必须要和这些服务应用在生产环境时一样。’

取决于组织的 SOA 实施深度（有时也称为 SOA 成熟度模型），如 1，2 这样的治理政策可能应用在部门级、LOB 级或企业级。然而，如果不同的 BU/LOB 使用不同的技术来实现 SOA，前面提到的政策 1 和 2 就不应该应用在企业级或 LOB 级，因为某些 BU 可能使用的是其他技术而不是 IBM 的 WebSphere 产品。与此同时，政策 3 与 4 与实现技术无关，所以它们可能要坚决地应用在企业级。

SOA 治理可能在各个级别影响企业架构。如我们前面提到的，取决于公司内 SOA 实施深度，一些高级别的政策可能暂时不会受到影响，直到 SOA 发展到企业 级。然而，强烈推荐的开展 SOA 治理的方式是自顶向下的方式，从企业级架构到项目设计。这样，起初 SOA 治理可能只占业务和 IT 治理的一小部分，但却是端 到端的——从业务功能和用户接口直至业务员数据模型和数据存储访问层。当 SOA 采纳扩展到更多的业务和技术领域时，就要对起初建立的基本的 SOA 治理进行扩展，使之兼备所覆盖的新业务域的具体情况。

我希望我正在讨论的东西是相对容易理解的，而且我也曾期望 TOGAF 9 在讨论治理和SOA 时也采用相似直接的方式。然而，我发现事与愿违。

TOGAF 9 对治理有很好的词藻：

“治理是一种能力，它规定参与行为并支持所有参与者并鼓励他们对确保实现企业的利益和目标而要付出的努力有兴趣并负责任”，而在另一个地方它是这么说的： “架构治理是企业架构及其他架构在企业级范围内被管理和掌控的实践和方向。它包括：实现一个控制系统，用于控制所有架构元素并监控这些活动，以此实现组织 的架构有效地引入、实施和发展……”

每个句子都是正确的而且我也赞同它们。但是，描述了开发企业架构并成为 TOGAF 核心的架构开发模型（ADM）中的 SOA 和治理又是怎样的呢？他们是向兔子洞里嬉皮笑脸的猫那样在空中做了一个怪异的表情后消失了吗？

如果TOGAF 的ADM 仅有实现治理阶段，那么由谁又如何来治理企业架构的其他方面呢？SOA 治理究竟藏在哪里呢？

图 3.

我曾参与过一个项目并从SOA 的角度对ADM 进行了重定义，如图3 所示的。我认为图中的架构愿景（Architecture Vision），架构治理（Architecture Governance）和企业级的分析和机会（Analysis and Opportunities）要先于任何其他的架构开发阶段。这三个功能是面向服务的范型（Service Orientation Paradigm）的直接提供者。一个承载面向服务的概念的架构治理必须要高于其他架构建设功能，否则它们将背离制定的方向。

架构愿景（Architecture Vision）必须要与组织的业务战略平行。其意思是任何企业架构中的业务更新都不会看似“从空中掉下来的”；它们必须先在架构先见阶段给审视。而且，在 更新通过了ADM 周期的业务，信息和技术架构之后，再执行架构机会是不是有点晚了呢？这时侯，架构解决方案应该已经准备好， 在此之后只需要通过迁移计划（Migration Planning）优化一下即可。

架构愿景（Architecture Vision）和分析及机会（Analysis-and-Opportunities）不一定需要在每次ADM 循环中建立或更新。这就容许我将它们移到其 他阶段之上且与架构治理（Architecture Governance）放在一块儿。面向服务的范型（ Service Orientation Paradigm）对它们三个都有影响。你会发现实施治理（Implementation Governance）的位置与修改之前一样，还是在G 处，但是它受到架构治理的控制；该结构更符合SOA 治理的层次关系。

治理的责任和所有者

已经 有很多出版物从不同的方面 探讨了 SOA 治理的实施细节。一方面这些出版物包含非常有价值的信息，可是他们并没有强调一些 SOA 治理的细节，如 SOA 治理必须能跨所有者边界划分：

• 资源
• 人员和系统安全地交互
• 和管理的方面

即使在小企业的环境中，“事实上，不同的组织和部门的行为常常显示出部门之间存在所有者的界限，这反映了组织实践以及真实的动机和经营这些组织的人的意愿”[OASIS SOAR A]。为了更好地理解所有者边界如何影响 SOA，有必要走近企业环境中的社会结构去看看。

社会环境定义了其中发生的任何行为（包括参与者通过服务的交互）的意义。社会环境的形式化表达就是社会结构。社会结构代表着参与者之间关系的某些文 化方面的特征。“社会结构允许任意多的参与者，并且特定参与者又可能是多个社会结构的成员。因此，在社会结构之间存在频繁地交互，有时当社会结构的目标不 一致时就会产生分歧。” [OASIS SOAR A]

每个社会结构都有一个目的，有时称之为目标。例如，一个实现了价值链业务模型的企业，其社会结构就有助于提高单个业务活动的业务价值。如果这个社会结构中存在的任何关系对某特定活动的业务价值产生了潜在的风险，那么该关系就可能会被停止。

社会结构定义了一些参与者需遵循但不一定明文规定的规则。若试图建立一个不符合社会结构的“精神”的规则，其结果只能是强烈的反抗或无视其存在。这 解释了为什么要把不合适的规则放在合适的权力级别。如果一个企业架构已经建立了评审所有 IT 项目并检查其是否符合企业技术政策的机构，并拥有停止任何合规 项目的机构，那么这种不符合的规则将导致社会结构的修正。

实践证明在有适当的机构存在的情况下，不必加强政策。因为对于要遵循政策人们来说，他们足以认识到不遵守政策将产生的不良后果。然而，这种非加强的实践还不能成为取消这种权力的理由。

特定的社会结构会影响所有者对某资源或能力拥有的权力，这不仅关系到权力本身，还关系到所有者的责任。换言之，所有者隐含了责任和权力；后者用于设 定政策，而政策往往与责任一起应用于相应的资源或能力。如果所有者不拥有资源和能力，这就要求使用资源和能力的权力最终必须回归到所有者那里。对于基于价 值链模型的社会结构而言，对所用的资源不具有所有权的效果构成了利用该资源交付业务价值的风险。这就解释了为什么价值链模型总是设定足够紧密的治理政策来 保证所有权，或者，至少直接控制所有相关的资源和能力。对于 IT 而言，这导致了竖井的形成并极大地孤立了单个所有权下的应用。

如我们所知，SOA 不适用于独立应用，或者整合的目的不是改变所有者模型而是保护它的场景。由于所有者总是与所有者边界相关联，在所有者边界内的参 与者对属于不同所有者的资源和能力的使用权力是受限制的。这解释了为什么基于价值链模型的企业通常在实施 SOA 时存在严重问题。它不仅仅是关于限制在所有 者边界内的服务的重用，而且还关于为别的所有者边界创建服务的管理上的制约。这还导致了选择服务的实现技术时不会考虑来自其他所有者边界的潜在服务消费 者。这些竖井和孤立就是 SOA 解决方案要斗争的对象。

我要说的是价值网络的业务模型几乎摆脱了上文所描述的价值链模型所面临的问题。我使用“几乎”的原因是任何模型都不能改变人的本性和所有权的诱惑。然而，价值网络为业务所有者和相关管理制定了不同的所有者内容与职责。

如前文提及的，有效的治理采用自顶向下的权力，它可以被看成是某种特定的权力和责任向下一级的代理，从而达成最初级别上一致的一部分。例如，一个 LOB 可能包含多个 BU，而每个 BU 管理这它本职范围内的事务，这些事务与该 BU 本身的任务关联的同时还与 LOB 的目标一致。另一个 LOB 也可能拥有其自 身的企业级代理给它的治理权力。合在一起就创建了符合整合企业组织的治理链的结构。如果某企业实现了价值网络，它就会收获更多的业务价值，它们来自不同参 与者的活动和合作。经实践证明，该价值超越了类似场合中由价值链模型带来的个体业务价值总和。相反，如果某企业实现了价值链模型，那么它将始终面临不同治 理链之间的利益冲突的风险，那么企业执行官们将忙于将价值链同企业战略计划对齐，而非提高公司在市场上的地位。

那么，SOA 治理委员会在价值网络模型中的目标是赢得个体和工作单元的集合效应（如果不是这样，那应让其这样）。该事实符合服务组合的 SOA 观点， 服务组合最大限度地实现了 SOA 的业务价值。协同工作的需求首先是通过将 SOA 治理功能委托给企业内跨部门和跨功能的业务组织实现的，逐步分至功能单元。 跨功能域的业务组织的治理权力拥有对多个治理域的权威仲裁并协助避免和解决所有权冲突。

SOA 治理在价值网络模型中再分发会导致个体业务团队及其经理的权力和义务的变化。在这种情况下，治理政策要求团队为业务服务的所有消费者担当义其务，而其权力和所有权却缩小到只与该团队 / 服务本身相关的活动。

如果某人认为这种治理幻境只存在于兔子洞中，那么他们应该去学习那些最成功的企业是如何管理他们的内部机构的。在电信行业，金融行业和零售行业里就可以找到这样的成功企业。

SOA 治理细节

SOA 治理细节并不在某些特殊的治理方法中，而是在整个企业中从业务到技术的受管对象中。这样的分布要求特别关注治理政策一致性。例如，如果某人为 用户接受测试（UAT）制定了政策而没有为测试环境设定政策要求它必须包含所有支撑性服务，那么就存在 UAT 测试结果的不一致的风险，并且在将来会为此付 出代价。

SOA 治理应用于以下列出的 SOA 环境的主要方面：

• 服务结构——包含服务以及它在服务交互域中的关系最小元素集。相关的政策关注开发，整合和部署。
• SOA 基础设施——“提供支持和促进服务使用的工具和产品”[OASIS SOAR A]，这里我们解决部署和运行时政策。
• 服务目录——“要求运行服务在基础设施内可通过手动或自动地公开接口进行访问”[OASIS SOAR A]，它关系到服务的管理政策。
• 参与者交互——希望所有参与者遵守的一致约束 [OASIS SOAR A]。该领域的政策关注服务的可达性和运行时行为。

以下列出的是 SOA 治理中常被错误的忽略的一些方面：

• 服务设计——这里的政策一定要求定义服务范围，边界以及标识服务描述和服务契约的必备元素和可选元素。
• 服务开发——此处的政策提供了服务开发流程的定义、最佳实践规则、推荐的工具和服务创建的项目管理实践细节和服务测试和发布的方向等。
• 服务组装——在这里，政策定义了聚合协作或符合服务的规则以及组合更改的规则（流程、过程及所有者关系等）。
• 服务资源访问——相关的政策描述了哪些内部共享的资源（如数据存储，遗留系统等）是否被使用及如何使用。
• 服务生命周期管理政策包含服务的版本机制和过程。
• 服务监控和审计。
• 企业的各个级别的服务管理角色以及服务契约协商过程。
• 交互渠道限制包含自动和手动的 UI 接口。

该列表并不意味着 SOA 治理不关心也不包含没有列出的其他方面。

虽然看起来上述列表管理了 SOA 环境中的所有方面，以至于没有创新发展的空间，然而这并非事实。SOA 政策是用于引导 SOA 及其实现，而不是决定怎么实现。而且，有些政策仅仅是暂时的，因为一旦有了足够的 SOA 实践，这些政策就将退役。

这里是我个人的一个经历。几年前，我工作的公司在 IT 部门有一些特殊的卓越中心（Center of Excellence, CoE），其中一个负责 SOA，而另一负责开源软件的使用。有一次，开源 CoE 运行使用 Apex Web 服务 V1.1，而另一个 CoE 必须要提出一个临时政策来限制在 WebSphere 5.1 的 Web 服务开发工具上使用 Web 服务。 后来，Apex V1.1 Web 服务又在另一个 WebSphere 版本上通通允许使用，所以相应的策略也就消除了。

优秀的 SOA 治理细节不仅能应用于服务的技术实现，还能用于它们的业务领域。这表明了上文列表中的名词“服务”所代表的不仅仅是自动服务，还包含半自动服务甚至人工服务。这类服务的描述可以在《通向SOE 的梯子》一书中找到。

SOA 治理负责定义跨所有域的控制以及跨所有域的交互规则。如果所有的服务交互参与者都认同单一的治理机构，这才可能实现。这并不是多所有权场景的 最可能方式。相反，所有参与者的治理实体不得不设定双方协议和政策映射机制。这类似于跨多个独立实体的企业安全控制——存在很小并集中的安全策略标准集和 许多横切的协议以及对特殊安全策略的映射。建立如此架构需要特定的治理流程和合适的权限。因此，“SOA 治理的主要区别是，对企业合作本身的正确评价和为 维持高效合作，它需要依赖于长远的共同目标”[OASIS SOAR A]

SOA 治理手段

SOA 治理在 IT 面来看仍然被视为奇怪的活动范围，而在业务面看它是夹在治理和管理中间的一段模糊地带。当执行者进入这一领域时，很多人会问“我们 该怎么做呢？”或“我们该用什么技术和工具呢？”。作为回答，提供商提供了一大堆的工具，它们可被视为对“如何进行治理”这一问题的回答。很多工具都打出 了能够“记录服务”的标语，而这其实与治理并不相干。这非常类似于爱丽丝在奇境中玩槌球游戏时所见到的，她说“他们都在嘈杂地相互争吵，每个人都听不到别人说的话，并且似乎不存在任何的规则。”。那么，SOA 治理应该遵循什么样的规则呢？

第一条规则，我的理解是，要理解 SOA 治理可以缓解或解决哪些我们在使用服务时已有的问题或将出现的问题。只有这样我们才能知道要治理什么。对此，Dave Linthicum曾提到 ：“关注 SOA 治理的方法和实践，而不是 技术。首要问题是创建 SOA 治理战略并保证它在每个环节中起作用”。

在弄清了必须要管理的事情之后，第二条规则是在服务和服务组合中找到确切的需要加强政策的点。加强本身并非治理的责任，而是实现管理的职责。

第三条规则是鼓励政策合规准则和校验方法的定义。

规则四要求你思考先行，理解为什么以及你在做什么。因为，治理是一个双刃剑，它能为企业交付业务价值带来很大帮助，也能破坏它。

只有此时才是回答如何进行治理的时机。Dave Linthicum 解释到“只有在当你对问题域的语义层、服务层和流程层有了全面的理解之后，如果实在需要治理技术，才应购买 SOA 治理技术。而不要在此 之前”。遵照上述规则，你就能定义治理工具所需的功能。适当的 SOA 治理始于你需要什么而不是你拥有什么。

很不幸，在实践中情况却是相反的，就像这一领域中常常出现的一样——我们购买了承诺支持 SOA 治理的工具，而治理却没有发生。SOA 治理的工作是应该由我们来完成，不管有没有工具。如果我们清楚我们在做什么，那么工具会有所帮助，而如果我们不清楚，工具反而会让我们困惑。

我们在前面讨论过治理流程包含一组手动和自动的活动，从创建政策和注册开始，然后是政策应用，合规检验和报告等。IBM 的 Muhammed Yaseen Muriankara 认为，治理实现或治理框架必须要自动化才能提供治理流程的功能。

他说：

一个启动项目要包含的不可或缺的自动能力如下： - 用于发现和发布服务相关构建和元数据的服务注册存储库，用于：

• 查找适当的已授权服务
• 避免重复工作
• 促进重用
• 标识服务在 SOA 生命周期中的当前状态
• 为服务订阅者提供可视性
• 了解关联服务以及服务变更的影响
• 互通服务变更完成的信息
• 理想情况下注册库应该可在运行时优化，这样，存储其中的元数据可在运行时用于通过动态路由提供信息扩增的能力……

没错，集中的服务注册很重要，但是其重要性出现的前提是所有权益人都同意为当前和将来的服务使用它。例如，注册库对于“避免重复工作”的必要性就不 清晰；可以提出应用于避免重复劳动的特殊购买（即购买服务注册库）申请的主体是治理政策。所有这些意味着第一个治理手段是治理政策注册库，而然后是服务注 册库。

服务政策元数据是另一个暗礁。为了让其发挥作用，应该要求所有潜在参与者共享政策本体和语义。我们已经谈到，达到如此的共享并非易事。

服务注册和存储方面的引领工具是HP Systinet /S2，SAG Centrasite，SOA Software，TIBCO，ActiveMatrix 和Oracle-BEA。然而，服务注册可以从普通的Excel 表格开始。具体选择哪个工具合适 取决于个体公司的情况和需求。这些工具有助于“对服务元数据进行收集和编目”，但我不同意一些提供商 所宣称的编 目工具应该用于“组织相互依赖，它们[服务] 互相依赖，按照SOA 政策文档的描述定义了如何通过服务组合实现业务需求”。我认为这些提供商跨越了能力边界 ——服务之间如何相互依赖和“如何通过服务组合实现业务需求”属于业务需求与其实现的特权，（而非编目工具的）。不过，政策编目工具非常有助于在一个集中 的地方维护SOA 治理的政策以实现更好地观察，维护和管理。

SOA 治理中反映了 SOA 的一个非常特殊的方面——服务执行过程中所遵循的政策必须要外部化，而不是插入到服务实现之中。该细节的结果是，某些已经 嵌入其执行政策的遗留系统不管使用何种接口都不适合担任“服务”的角色。事实上，这样的系统应该由实际的服务应用进行包装，只用作服务资源。该逻辑导致了 创建插入政策的接口需求（每种政策一个）。SOA 治理必须要考虑这种接口并指明支持这种政策实现方式的合适工具。插入政策的接口允许在不修改服务的情况下 新增或修改需执行的服务政策。

最后，我想对“务实 SOA 治理”运动发表一下我的观点。正如该运动的名字所言，它并非关于 SOA 治理本身，而是为人们已经做的事情冠以“SOA 治 理”的名号。举例来说，如果 IT 开发人员先创建了域对象，然后思考这些对象如何被转换成业务服务，“务实 SOA 治理”只能“祝福”它，而尽管这种做法可能 会导致很多跨服务边界的问题，这正是 SOA 实施中的一个主要谬误之一。MuleSource 的 CTO 和合伙创立人 Ross Mason 支持这种“实用”，他说“在当今世界，传统自顶向下的SOA 明显已经过时，今天的企业要看到真正的价值需要一种新的实用 方法” 这对我来说又是一个兔子洞中的测试，因为由OMG 签署的“ SOA 导航协定”，The Open Group 和 OASIS 都明确地说明面向服务的方法论是自顶向下的，而 SOA 的实现可以从任何方向开始。

Mason 曾质问过自顶向下的 SOA（包括 SOA 治理）的效力问题，该问题源自“只有 20% 的企业从 SOA 获益”这一事实。对我来说，这听起来就像抓住兔子的“耳朵和胡须”显示自己是绅士。该数字只反应一个简单的事情：只有 20% 的企业拥有正确的 SOA 和 SOA 治理。

Mason 认为，为了使用这些 SOA 治理工具，SOA 治理需要用来避免人们的“重大的行为改变”。进一步说，“任何变更的引入，都要在尊重受影响的 角色和程序的方式下完成。对于 SOA 治理政策，架构师的冗长的需求文档几乎被会大多数开发人员忽略。相反，那些需求可以也应该实现成自动政策 ……只有当日常 IT 从业人员看到新方法对于开发带来的益处时，企业才能看到整体价值”。

一方面，把不受欢迎的变更放进自动政策的想法是个很好的点子；另一方面，隐藏不受欢迎的变更并不能改变人们的行为，如果没有合理执行变更的话，总会 人找到方法绕开它。例如，Parasoft 用于编写 java 代码的 JTest 工具拥有数以百计的编写风格政策。如果代码违反了风格政策，则无法通过编译， 即开发人员就无法交付工作。我亲眼见过开发人员关闭这些政策控制，因为在不同的代码开发阶段需要不同的风格政策，而工具本身无法足够聪明地适应真实的开发 流程。

面向“日常 IT 从业者”的问题是：正确的 SOA 和 SOA 治理的确要求对开发流程周期的理解上 进行重大改变。然而，这并不是新鲜事物或者首次登台容易被打断的演员。从CS 结构到多层结构模型的转化一样需要来自开发人员的不同理解，多层模型被广泛采 纳也经历了一段时间。我只能说，对于必要的改变，SOA 治理政策将不会为了那些不具备面向服务概念的人的防范而作出修改。也就是说，如果某开发人员尝试 用，比方说，面向对象的方针进行服务开发，那么他只有两条出路，不是他改变自己的思维，向面向服务的方式改变并领导其公司走向成功；就是破坏SOA 项目并 承担相应的后果。

我对SOA 治理的定位如此自信的原因是面向服务关心的是真真切切的业务产品和过程。它为如何做事增添了更强的控制。任何不适合保护SOA 业务价值的事物迟早都将撤退。因此，真正意义的务实SOA 治理应该保护并提高业务面和技术面的业务目标。

总结

尽管有SOA 治理标准的多方努力，但是仍然需要一些概念方面的改进。因此，我在文中提出了一些观点供大家参考和讨论。

最基本的观点是SOA 治理和隶属于管理功能的治理执行二者之间需要分别对待。

第二个观点提出了SOA 治理必须要在企业范围内引导所有的SOA 相关项目，因此，要放在它们之上。这就产生了我对TOGAF ADM 的修改并对相应的架构开发阶段的重新定位。

第三个观点讨论的是SOA 治理跨越部门所有者边界和业务面和技术面之间的人为边界的重要性。如果正确实现了SOA 治理，就会对企业的社会结构，包括人员，资源和功能关系产生影响。

第四个观点建议SOA 治理应该始于以下方面：为什么需要它、它是什么、应该在哪些领域进行以及谁提供它。在此之后再讨论支持工具和手段。昂贵的服务 注册/ 存储系统甚至免费的开源产品，在人们意识到需要它们之前，是不会有任何帮助的。SOA 治理较之把Web 服务接口注册在某地要复杂很多；最小的SOA 治理也需要一个存放SOA 政策的存储库以及相应的维护和管理机制。

最后，我希望大家打破技术的“框框”去理解SOA 治理；尝试思考它并循序渐进且准确地应用在底层业务流程和相应的业务活动中。这才是SOA 治理前进的方向。

查看英文原文： Wonderland of SOA Governance 。

感谢胡键对本文的审校。

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