Thomas Erl和Anne Thomas Manes探讨了他们合著的新书《SOA治理：治理云端预先定制共享服务》（《SOA Governance: Governing Shared Services On-Premise and in the Cloud》Prentice Hall出版社，2011年四月）。他们钻研了SOA治理采用曲线趋势、敏捷治理以及正在形成的云计算治理任务。

　　你如何定义SOA治理？

　　Anne Thomas Manes:快速定义就是“治理创造规则。”很多人认为治理会强加给人们更多的工作，但是最佳治理系统会是一种大家感激的系统，这个系统可以协助大家以最高质量完成工作，对于业务是有益的。任何治理系统的本质是相同的；SOA治理的区别是当我在应用组合中使用SOA治理时，我需要治理哪些内容。什么是需要额外负担的？这些都是在开始治理之前，和SOA提议相关的重要决定，因此，SOA治理是你如何定义和这个内容相关的规则。

　　很重要的一点是：SOA治理模型和系统必须和组织中所有其他的治理一致。不可以脱离，创建一堆流程和新的权力层，这和你之前所做的相抵触。

　　组织处于SOA治理采用曲线的什么位置？

　　Manes:许多公司几乎不会接触这个层面；还有一些仅仅能够治理，从而保持一种控制。很多公司认为治理是需要购买的，要有注册表、存储库、管理部门，然后你才能拥有治理。那并不是治理。那些都是协助你管理信息和运营的工具；你可以执行安全和运行时策略，但是这对于定义策略和谁来做决策并没有帮助，或者是对创建流程来调整SOA投入以及执行SOA提议也没有帮助。

　　Thomas Erl:我们还没有在适当的地方看到真正的SOA治理，为了项目交付生命周期和方法论，一些东西很实际地显现出采用和应用面向服务的不同方面。结果，你还会呆着这样一种信任下面，就是他们正在做SOA治理，但是还没有得到期望的结果。他们对SOA项目应用了其他的IT治理模式或者其他的方法，而且不一定时正确的匹配。最后以冲突的优先权或者需求而告终，得到令人失望的结果。

　　在用正确的方法进行SOA的核心部分，你也听到过很多标准化的内容，在采用产业标准上仍旧一篇混乱。你需要定义标准，自定义你的需求/环境/业务目标，以及采用SOA的范围。这些标准类型是成功的关键，在这些地方有真正的机会来确立你所交付的服务的一致特性。如果你应用SOA治理，就要被迫区别早期计划和建模，因此这些标准也是系统的一部分。

　　书中，你描述了数个SOA治理类型——中央集权的、联合的、独立的。有没有哪一种类型更有利呢？

　　Manes:大多数人认为联合模型更有效，但是并不是每一个组织都适用。治理风格必须和组织风格匹配。

　　Erl:这取决于采用的范围。采纳SOA时，尤其是在大型的IT企业中，通常不可行的就是用一次性集成（big bang）式的方法，进行整个企业的转换。这样的花镜中比较好的方法是采用基于域的方法，这种方法可以独立自主治理。理论上，这需要提前计划。可以用一个根源SOA治理办公室用其自己的治理系统监督不同的域，根源办公室确保确定的应用基线标准。

　　你讲到SOA治理的第一步是确立SOA治理计划办公室。整个办公室由什么组成呢？

　　Manes:一个有权利的工人办公室是用来确立规则的，是任何计划的必要条件。这是从多元观点进行投入的好主意——熟悉流程的人检查，从而决定在如何批准任何软件项目上的投资。同样的，你要有精通这个计划的人来部署和开发应用。同样的人来确立软件来发治理计划有可能涉及在SOA治理计划的创建中。

　　Erl:SOA治理计划办公室首先带领这些人理解SOA和面向服务，这些人专门研究IT治理。SOA治理计划包括治理系统，但是也包括这个系统的所有其他逻辑层面，所以也包括项目计划、蓝图、工具以及步骤，来使其成为全部的一部分，这也意味着哪个项目要被规划。

　　是否有敏捷治理这样的概念呢？

　　Manes:在定义你的规则的时候，你需要不断的再评估是否达到目标，通过在评估和理解他们是否在帮助你更快速地交付更好的解决方案，然后如果没有回溯并解决掉。这就是敏捷的定义。

　　Erl:SOA提议治理系统需要更实质的响应业务改变。对我而言，治理系统改进了功能的响应能力，因为已经做出如此多的决定。一个比较好的类比是Leo Shuster想到的（此书合著者）：治理系统就像高速公路的护栏。将系统放在适当的地方需要努力和投资，但是一旦你拥有了，反复地追随它就能交付更多的服务。就像护栏一样，治理就是这样一种改进敏捷性和降低交付服务风险的东西，增加了现有系统对改变的响应。如果治理系统在维护规则和一致性的需求水平时很灵活，就会最大化这种效果。

　　转对基于云的服务，治理要考虑哪些事项？

　　Erl:当你的资源由第三方云厂商把控，对于这些资源如何治理的控制程度就受到了限制。对于治理系统这是有价值的因素。如果你的治理说必须遵从产业标准并且厂商不支持，你必须说“考虑到这些约束条件，还要支持我们的业务需求，我们如何在云端治理呢？”另一个极端就是当你在云端部署整个服务，治理系统本身是对特定环境自定制的。这比较少见。

　　Manes:在云端部署会有更多的固有风险，而且通过部署特定的云端治理戒律，采取适当风险消减。