SOA治理的仙境-CSDN博客

本文链接：https://blog.csdn.net/cpongo4/article/details/89112952

引言——掉进兔子洞

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中文站用户讨论组中与我们的编辑和其他读者朋友交流。