SOA 治理基础

** 采用面向服务的架构（SOA）的企业通常很快会发现，为了成功管理或者启动一个 SOA 项目必须迅速建立 SOA 治理。然而由于种种原因，在很多的企业内成功建立 SOA 治理并非一件容易的事情。

为了弄明白什么是 SOA 治理及其如何能在企业中成功启动，对 SOA 治理的原则和全面有效的 SOA 治理模型有清晰的定义和理解是非常有必要的。清晰的治理原则和面向组织的治理模型的建立能为更进一步的治理活动打下良好的基础。这里，清晰的治理原则是指在组织内部对 SOA 治理有一个共同的定义。

这篇文章的重点是解决在建立 SOA 治理过程中最基本的一些问题。首先，通过比较“战略治理”和“战术治理”，给出了 SOA 治理的定义。第二，展示了一个 SOA 治理框架，此框架是可定制的，它可以根据企业实施 SOA 成熟阶段的不同而做出相应的调整。文章的最后列出了实施 SOA 治理的一系列切实可行的步骤，这些步骤对企业 SOA 治理的起步和持续推进是非常有裨益。** * * *
负责治理的人员每个月碰次面、讨论一些有关 SOA 的议题、建立企业 SOA 策略然后再缩回到 SOA 象牙塔里头，这种工作模式是无法适应 SOA 治理要求的。事实上，建立 SOA 治理在企业所有的 SOA 努力中不仅仅是具有挑战性的工作，稍有不慎它就可能成为一项对企业非常具有破坏性和分裂性的工作。

SOA 过程人们这几年一直在强调，在企业启动 SOA 的过程中最大的障碍将存在于文化和政治层面上，SOA 要想在组织内部取得必要支持并获得成功，必须要克服这些障碍。因此，建立 SOA 治理——或者说组织一批精通 SOA 各个领域的专家来建立企业 SOA 策略——将是企业在实施 SOA 过程的早期不得不面对的一个问题。毕竟，政治是与生俱来寓于治理之中的。

政治斗争是不可避免的，并且其在很大程度上决定了 SOA 各个领域的人员安排和相应的治理责任。然而，在建立 SOA 策略的过程中，如果各个领域都有清晰的界限并且争夺对象有明确的定义，斗争的激烈程度是有可能减轻甚至斗争本身都有可能避免的。本文的目的就是要让读者了解有关此方面的一些基础知识。

SOA 治理：战略 VS. 战术

令一些人感到吃惊的是，成功地领导建立 SOA 治理的往往并不是那些自称是“SOA 治理委员会”的小组。在很多企业中，“SOA 治理委员会”往往倾向于从战略的高度去思考问题，他们对 SOA 治理缺乏必要的战术性考量，而这种考量却能对所有的企业 SOA 活动提供支持，并且这种支持是贯穿于其整个生命周期的。事实上，能在企业中成功实施 SOA 的小组要能正确地定义什么是 SOA、明确 SOA 应该得到什么样的支持，并且清晰地阐述小组在 SOA 治理模型中所处的地位。对 SOA 治理进行精确的定义和建模使得有关 SOA 的讨论和决策目的明确清晰，易于理解——这些正是避免组织分裂的关键性因素。

是的，在企业中领导 SOA 治理的小组可能不止一两个。事实上，许多企业采取分层的治理模型。虽然看起来比较复杂，但是只要认识到 SOA 治理从根本上分为战略和战术这两个层面，问题就会简单许多。

实施 SOA 的企业中需要一个由 SOA 实践专家组成的有代表性的社区，这个社区负责决策并且解决 SOA 的实施过程中发生的冲突。这个负责“战略性治理”的社区往往是组织中第一个进行 SOA 治理活动的小组。这个小组制定企业 SOA 策略，选择 SOA 实施的平台，并且给出企业 SOA 的参考架构。这些可都是大的决策！

实施 SOA 的企业中还需要一个由精通 SOA 各个领域的专家组成的小组，他们负责制定层次稍低或者说更细粒度的策略。这个小组实施“战术治理”，在新的 SOA 计划、工程或者项目准备实施时成立，其成员通常来自“战略治理小组”之外，并且分布在企业中的不同部门。因此，这个小组更加面向实现，更关注交付使用和最终的业务结果，同时他们要做大量与“战略”治理沟通一致的工作。

说明白一点，“战略治理”的结果通常就是一套完美的企业 SOA 策略，这些策略往往是基于尖端技术、仍在演变的标准和最新最伟大的市场架构，有时甚至是开发商刚刚宣布过此版本要一个季度后才能稳定下来。另一方面，“战术治理”的结果是在某个特定集成项目中，为每个治理策略配置具体的 SOA 平台。这两个方面必须保持一致才能使治理落到实处。

让我们举个实际例子给大家以感性的认识。FastCom 是一个虚拟的通信公司，为了在某些市场投放某款产品，它需要与另外一个名为 SpeedyCable 的虚拟的通信公司进行业务集成。这两个公司的“战略治理”小组都各自有一套完美的企业 SOA 架构和策略。在首次“集成碰头会”上，架构师们将分别阐述各自的“战略 SOA 策略”。这时很有可能发生的情况是两个企业在技术能力与策略上都有一定的差别。

此时，架构师们将会离场，只留下各个领域的专家去就策略进行谈判，从而形成一个“战术性”的集成方案。随后两个公司的开发人员和项目经理们会每周碰面，就安全、计划、标准、数据转换以及其他一揽子需求进行讨论磋商。“战略小组”决定策略的定义和策略审查的地点，而“战术小组”则决定具体采取哪些策略，在哪里制定这些策略以及策略用以哪些方面。

一言以蔽之，战略治理和战术治理不同之处在于对待企业 SOA 策略的方式不同。

SOA 的六根支柱

对一个成熟 SOA 项目的各个模块或者支柱有全面的理解是取得良好治理效果的另外一个关键因素。一个企业的 SOA 项目当然可以只有基本的支撑机制，但是随着企业 SOA 项目规模的增加和不断成熟，更多的支撑是必不可少的。SOA 不同方面需要不同的 SOA 治理方法，同时它们对策略的影响也会不同。

在这里需要强调一点：策略是 SOA 治理的关键所在。因为所有 SOA 治理努力无非就是想给出企业自身的 SOA 策略的定义，规定哪些人来制定这些策略，这些策略存放在哪里，策略更改所需步骤，对策略进行复审的场所以及实施这些策略所需要的系统和工具，编制策略文档的团队成员等等。

这么说吧，支撑 SOA 策略的有六根支柱。下面就让我们简要介绍一下它们：

1. SOA 生命周期模型
2. SOA 组织结构
3. SOA 过程
4. SOA 服务集成组合
5. SOA 工具
6. SOA 技术

这些支柱支持“自上而下”和“自下而上”两种 SOA 项目开发模式。理解这些支柱可以对“自上而下”或者“自下而上”的 SOA 治理有更清晰的定义。“自上而下”的治理从战略出发。它始于模型，着眼于多个项目，然后一路向下，依次定义支撑企业 SOA 的人员、过程、服务、工具和技术。与此相反，战术治理小组自下而上，往往只定义某一个项目的技术、工具及其需要创建的服务。如果一个实施 SOA 的组织比较草根化，结果往往就是从单个领域面向服务的努力出发的“自下而上”的模式。此种企业通常的做法是在单个部门或业务单位做试点，首先开发出项目原型，然后再着手制定 SOA 战略，但是这么做的结果往往是增加了建立治理从而启动企业 SOA 的复杂性。

基于上述原因，我们从“自上而下”的 SOA 治理模式开始，首先定义 SOA 治理生命周期的概念。

SOA 的第一根支柱是企业 SOA 生命周期模型。“SOA 生命周期模型”简单地讲就是支撑和定义一个企业 SOA 工作的模型。需要强调的是 SOA 治理本身也是一个支柱。事实上也正是这个生命周期模型详尽地说明了治理对任何的 SOA 项目或者努力来说都是一个非常重要的模块。这个模型往往会详细阐述以下几个方面的内容（过程、组织、工具和技术会依次对应到相应的方面）：

1. SOA 业务管理
2. SOA 计划
3. 服务开发
4. 客户发展
5. 集成配置
6. SOA 平台、服务与集成产品的支持
7. SOA 项目市场推广
8. SOA 报告与分析
9. SOA 治理

典型的 SOA 生命周期的概念这里就不多谈了，如果有兴趣可以参考 http://en.wikipedia.org/wiki/SOA_Lifecycle 。

SOA 的第二根支柱就是企业的“SOA 组织结构”，即从事 SOA 的人员以及其组织方式。此方面既可以按职能划分也可以按机构部门进行划分，但最好是能以书面的方式确认各个人员的职能，然后将人员分散到各个部门中，形成人员与部门的松散耦合。以这种方式形成“SOA 组织”有很大的灵活性，因为机构部门内部总是在不断变化，但是从事 SOA 治理的人的职能却不会变，即使他们的头衔发生了变化。通常，“SOA 组织结构”将规定哪些人能参加 SOA 策略的讨论，谁将进行策略的最后决策，谁对配置 SOA 策略进行配置，谁有进行复审的权限等等。

第三个支柱就是企业的“SOA 过程”，也就是 SOA 在企业中的运作方式。非常重要的一点是，这些过程必须能映射到刚刚提到的 SOA 运作生命周期的各个方面。建立服务、集成配置、客户端开发、服务规划、将服务添加到服务目录、策略的制定与更新、SOA 平台和工具的产品支持等等都需要 SOA 过程的支持。这样才能将任务分配到人，规定开发规程中需要形成的制品，以及实施过程中需要交流沟通的地方和每个步骤所需要的时间。其实，在将 SOA 过程文档化的同时，治理也就慢慢以一种更加具体的形式建立起来。过程中的决策点将成为所谓的“治理门”，而且需要跟“战略治理”本体以及复审会话相一致。总之，建立“SOA 过程”对于企业由“部门 SOA”向“企业 SOA”的成熟过渡来说是至关重要的一环。

SOA 的第四根支柱是企业的“服务与集成组合”。这个支柱定义企业 SOA 所能提供的服务，这些包括已经部署、正在计划和业已产品化的等各类服务。这个支柱将企业服务映射为企业的业务功能，它将企业服务变为企业业务的一个实体单元和展示。这一块的治理主要是规定谁去创造和支持服务以及服务的部署时间。实质上，这个方面的治理就是围绕服务什么时候建立和如何验证服务的正确性上来制定策略。这往往是一个被遗忘的角落，以致相关的策略往往是最后才会制定出来。这里也正是既进行“自上而下”又进行“自下而上”治理的企业中这两者的汇聚点。

第五个支柱是企业的“SOA 工具”，简单地说，也就是一个企业用于支持 SOA 工作的工具和系统，其包括一些概念上的参考架构和在架构蓝图范围内的系统实现。它是一些 SOA 基础设施所要求的，目的往往是为了前期研究和存档需要。编制文档用以详细阐述系统需要支持的过程和在 SOA 中使用工具的人员，此项工作对实施 SOA 的企业来说是非常有用的，编制的文档为企业 SOA 中正确地选择工具提供了“用例”和“功能需求”。工具往往可以用来强制地实施策略或者成为储存策略的地方，这样看来编制这些文档变得至关重要。有三个用以存储 SOA 策略的工具，四个强制实施这些策略的工具，另外还有两个去建立这些策略的工具，这样的做法使情况变得复杂并且阻止了强有力的 SOA 治理的进行，因为不同的系统使企业的 SOA 策略变得无法管理，这些减轻治理手工劳动的自动化工具反而使治理的管理复杂化。基于此，我们建议，如果想要好的治理效果能尽快显现出来，治理工具应该在其他 SOA 的支柱都定义完成之后再行购买。

第六根支柱是企业的“SOA 技术”。这是指企业选择的用以支持 SOA 实施的技术标准。这个方面的治理围绕特定技术标准及其版本的选择展开。如果组织内部能舍弃刚刚发布的崭新的新标准，而就使用成熟而且具有最小共同性的标准达成一致的话，此方面的企业 SOA 策略的制定变得非常容易。这里最关键的工作是“战术小组”给出自身的技术选择，并且与“战略小组”配合使这些技术选择得以批准通过、在部门间得以标准化并且存档等。这些工作使得 SOA 服务得以汇聚，因为企业的服务组合能够得到时间的验证（组合服务也能更快捷简便地建立起来）。

治理的下一步

既然对不同类型的治理和治理对 SOA 六根支柱的支持有了清晰的理解，我们就对 SOA 治理建立起了基本的概念。

下一步，可以遵循一系列的步骤来使 SOA 治理工作变得规范化并且验证治理的目标是否得以实现。我们需要从回答以下这些重要的问题并且将其存档开始：

1. 在我们的组织中“战略治理”体是什么？他们现在是否负责 SOA 治理决策的制定?
2. “战术治理”小组都有哪些人组成？是哪些人在负责 SOA 项目策划及其启动工作？他们是否对技术标准或者过程编制了文档？
3. 企业中是否有人对企业 SOA 模型进行了概念化工作？如果有的话，在哪里可以找到这些模型，在哪里可以对模型进行学习？
4. 对企业目前支持的 SOA 功能是否进行了存档？谁负责将这些功能分配给具体的部门或者小组？
5. 对支持企业 SOA 模型的过程是否进行了存档？建立服务、设计服务、部署服务、注册服务、配置服务以及得到帮助支持或者说询问策略中的异常情况处理方式的过程分别是怎样的？
6. 对企业已经提供的服务是否进行了存档？是否能将这些服务与我们的某一业务领域，产品或者功能进行对应？是否有人对服务的发布进行计划并能说明计划中的不足？
7. 是否有人对企业 SOA 的工具与 SOA 参考架构进行了对应工作？目前的 SOA 工具集能为企业提供些什么？是否遗漏了什么功能？是谁负责工具的选择工作？
8. 是否有人对技术标准和具体的技术选择进行了存档工作？对技术上异常情况的处理方法是什么？如果有人未能遵循企业 SOA 策略须围绕 SOA 技术进行制定的规律，其结果会怎样？如果遵循了技术标准结果又是怎样？

结论

良好的治理一个重要方面是分清“战略治理”和“战术治理”的区别。成功地启动 SOA 治理的企业往往会在承认“战略治理”小组的权威性同时赋予“战术治理”小组实现商务价值的权利。两个小组都要对策略的异常处理路径提供支持。为了能达到互相配合，协同一致，避免不必要争论的目的，“战术治理”团队必须支持“战略治理”制定的策略标准集并且将其提供的“异常路径”过程落到实处。

剩下的一些治理工作都是脏活累活了。在企业里对治理进行定义往往是一项非常棘手的工作，它包括角色和功能以及人员、过程、工具、技术、服务的详细说明、存档、梳理以及将其集成到组织模型里等工作。虽然很多人认为这纯粹是在浪费时间，但是回答这些问题对企业 SOA 治理进行完整定义非常有用，我们坚信花在这个上的时间比寻找一些根本不存在的问题的答案的时间要少得多。如果能提出正确恰当的问题并且将其答案简单存档，基本的治理工作会在数周内实现。

关于作者

Ed Vazquez 是 MomentumSI 公司主管 SOA 业务创新的副总裁，目前主要领导企业的改革实践工作。Ed 有着超过十年的 Web 应用管理经验，其中的六年在从事 SOA 和 Web Service 实现管理工作，曾领导过 Sprint, Pfizer 等大公司的企业业务与 IT 组织改革项目。在专注于企业改革和创新工作之前，Ed 从事过 SOA 生命周期、SOA 治理和业务驱动 SOA 等方面重大专家课题的研究工作。Ed 毕业于堪萨斯大学 (University of Kansas)，在那里他相继取得了学士和硕士学位。

查看英文原文： Service Oriented Architecture Governance: The Basics - - - - - -

译者简介：孙涛，华中科技大学物理电子学专业硕士毕业，现就职于 9spaces 网络中国分部，从事 Java EE 应用开发和管理工作。目前主要关注基于 SOA 的软件架构设计，RIA 以及信息检索和信息抽取等技术的发展和进步。曾发表有关电磁波算法应用类论文两篇，其中一篇被 SCI 索引收录。参与 InfoQ 中文站内容建设，请邮件至 china-editorial[at]infoq.com 。