实施 SOA 治理

许多人说过，成功实施 SOA 最难之处不在于技术，而在于改变文化。无论你是要推行一种与开发者特点相悖的“分享”文化（他们喜欢对自己的方案有完全的掌控能力），还是要改变项目立项与拨款的方式（以确保战略服务的创建），或者是要正确管理在运行时建立的新的依赖关系，这些改变仅靠技术是完成不了的。要确保顺利完成文化的改变，关键在哪里？关键在于管理行为改变的过程，也就是治理（governance）。

机构是利用人员（people）、策略（policies）和流程（processes）来实现期望行为（desired behaviors）的，而治理（governance）正是人员、策略与流程的组合。SOA 治理的目的是为了实现有关 SOA 实施或源自 SOA 实施的期望行为。这些行为涉及普通的软件开发工作（称作项目治理），生产环境中服务消费者与服务提供者之间的交互（称作运行时治理），以及有关项目立项、审批、拨款的流程（称作项目前期治理）。在开展这些工作的过程中，必须设置并利用好人员、策略和流程，才能确保成功地改变文化。

SOA 治理的第一步就是实际制定期望行为（desired behaviors）。你不能将“成功实施 SOA”作为期望行为，因为它没有说出成功的含义。我们需要用一种可度量的结果（measurable outcome）来表达机构希望通过实施 SOA 达到什么目的——这才能算做期望行为。媒体老是在重复一些不够具体的优点，比如“提高了 IT 与业务的齐合（alignment）”，不过这需要进一步明确定义度量它的方法。齐合（alignment）意味着项目可被更快地执行吗？如果是的话，那么它是可以度量的。什么叫敏捷性？敏捷性可被理解为机构快速响应变化的能力。机构是否知道，冗余实现同一项功能会降低它修改功能的速度？冗余实现的数量减少同样是可以度量的，因此可将它作为期望行为。

制定期望行为的任务通常是由机构里的领导们（通常是项目发起者或利益相关者）完成的。他们的工作是制定方向，一旦方向制定好了，治理的第一步——为达到那些期望行为而制定策略——就要开始了。为此，我们需要设立相关的治理机构。这在一定程度上跟许多政府中的权力分割是比较相似的。在美国，总统无权制订法律，法律是由国会制订的。总统负责签署法律，但他是有名无实的，他只负责制定方向（相当于期望行为），然后，由国会来按它们觉得有利于达到期望行为的方式进行有关立法。然而这里的问题是，党派政治可能会导致立法机构与总统的分裂。毫无疑问，企业里也存在这样的风险，因此很重要的一点就是：被选出来制定策略的人应当全力支持期望行为。美国总统是无权解雇国会议员的，但企业里不同，公司 CIO 有权挑选 SOA 治理团队的成员。

这里的难题在于挑选正确的人员来制定那些策略。显然，这里需要的人员涉及多个方面。可以让企业架构团队来制定跟项目治理相关的技术策略；但对于那些指导服务所有者决策的策略、以及会影响项目定义方式的策略，交给他们制定就不太合适了。最常见的做法是设立一个卓越中心（Center of Excellence，简称 CoE）。卓越中心由多个部门的领导组成，包括 IT 经理、项目经理、应用架构师、信息架构师、高级开发人员、业务分析师和营运经理等。他们各自负责自己所辖范围内的策略。虽然 CoE 要负责制定策略，但他们可以把制定策略的任务交给其他具有丰富经验的人来完成。

策略的制定，必须能够指导项目的行为、系统的运行时行为、以及有关项目立项的项目前期流程。这些策略的目标是将机构的目标（goals of the organization）与对人员的期望行为（desired behavior of the staff）联系起来。例如，如果 SOA 项目的目标是降低交付 IT 方案的时间，那么有助于实现该目标的一个因素是重用现有服务。为此，各团队必须通过除部落知识（tribal knowledge）以外的其它途径得知有哪些服务可用。由此可以得出这样一条策略：必须把服务发布到可公开查询的地方，比如服务注册中心或注册库。虽然这是个简单的例子，但它举例说明了策略与行为的关系。运行时策略与项目前期策略亦是如此。例如，若运行时目标是不允许任何消费者危害服务的可用率（availability），以免影响其他消费者的使用；那么，有助于达到这一目标的策略是：所有消费者必须设定期望的使用特性，包括预警阀值和节流阀值等。再如，若项目前期目标是加快交付 IT 方案的速度；那么，虽然我们已经为发布服务制定了运行时策略，但还需要相应的项目前期策略：所有提案都必须列出将利用哪些现有服务。该策略本身可以在机构里引起行为的改变。仅仅要求把服务发布到注册库并不能达到目标，要将该策略与一个指导人们如何实际使用注册库的策略捆绑起来才行。

制定好策略后，治理的下一步不是贯彻策略，而是培训与交流。常常，治理团队自己对策略十分熟悉，但他们未能很好地把这些策略灌输给那些被期望遵守策略的人员。此外，期望行为本身也许没有被有效地传达，这会导致竞争优先级的问题。一个最常见的例子是：当一个团队正在进行一项有进度和预算限制的项目时，他们往往不注重决策对架构的影响，从而导致冲突的产生。这不是说进度和预算不重要，只是其他方面也需要考虑。仅当那些项目团队理解了机构的期望行为、并懂得了策略与那些行为的关系，才能指望他们能够遵守那些策略。

卓越中心（CoE）必须制定一个计划来开展关于行为与策略的交流和培训。做个一次性的报告是不行的，应该有一个正式计划，并利用所有能用上的交流机制对 SOA 项目将波及的各个角色开展有针对性地交流。这里，也许让专业公关团队（比如企业公关部）来制定这个正式计划是比较明智的。交流与培训技术包括午餐时间培训、为机构内部的各个团队作巡回展出、博客和 wiki、正式的白皮书等等。这些讯息必须针对期望的受众，无论它是午餐时间培训的一大批人、还是来自各个团队的小开发群体。

跟制定策略一样，交流工作也会涉及卓越中心以外的人。让高级管理人员（如 CIO）来做关于“SOA 为什么对机构很重要”的初次宣传是相当常见的。随着 SOA 计划的发展，可以召集来自各个成功项目的代表，让他们跟大家分享经验以及策略是如何帮助计划成功的。最后，除了提供内容以外，卓越中心还必须确保这些交流在培训方面是有效的，而且将在整个 SOA 计划期间有效。你可以通过在 SOA 实施过程中多次通过调查、面谈或问卷的形式来达到这一目的，因为你必须评价交流的直接有效性以及信息的长期保持性。

任何治理工作，无论规定得多好、策略传达得多有效，都需要一定的贯彻。否则，很可能会出现相抵触的策略，从而需要有某种协调机制来决定遵循哪条策略、何处允许例外等等。比较好的情况是，制定项目前期、项目及运行时策略的人有遵守策略的意愿，而且由于策略是事半功倍的而且符合公司文化，因而能够自动得到贯彻。然而，这并不是说我们不需要治理。社会的犯罪率低，并不意味着它没有警察机关。机构里必须有审查及遵守规定核查，以便帮助最后的流程——度量和反馈。

必须进行度量（measurement）和反馈（feedback）以确保对策略的遵守能够实际产生期望的行为并达到目标。按照前面的例子，如果经度量发现交付项目的速度还是跟过去一样，那么肯定在某个方面没有做好。所有团队都遵守了为实现期望行为而制定的策略吗？如果不是的话，那么也许执行过程需要改正；如果所有团队都遵守了那些策略的话，那么也许是策略本身有问题（有的策略可能会实际产生相反的作用）。正如前面那个例子一样，也许只要增加一些策略就行了。如果我们只是规定要把服务发布到注册中心或注册库里，但没有要求各团队去注册中心或注册库查询，那么期望行为就不会实现。

人员、策略和流程的正确运用是实现行为改变和 SOA 实施目标的关键，希望本文的简单介绍讲清楚了这一点。这些技巧同样可被任何治理活动所运用，只是策略的领域不同。就 SOA 实施而言，这些策略全是关于服务定义，以及关于服务消费者与服务提供者间交互的。SOA 治理要做的，就是正确表达这些服务的技术成分与它们的消费者及负责定义、创建、运行这些服务的团队之间的正确行为。成功的治理活动，对决定 SOA 实施活动本身的成功起着重要作用。

阅读英文原文： Implementing SOA Governance 。

志愿参与 InfoQ 中文站内容建设，请邮件至 editors@cn.infoq.com 。也欢迎大家到 InfoQ 中文站用户讨论组参与我们的线上讨论。