实施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实施活动本身的成功起着重要作用。