评论专栏: Scott Simmons：SOA 治理与预防面向服务的混乱

治理需要

客户采用 SOA 的一些早期结果阐明了SOA 的承诺：通过提高灵活性和适应性来改变组织。虽然这其中有些只是奇闻逸事，但是存在实际的例子，证明采用 SOA 提高了对业务要求的响应能力，降低了新出现的开发成本。 与此同时，这些发现必须与现实一致——SOA 的成功不“只是发生”。发现 SOA 成功的客户都具有共同的特征：他们已实现了治理方法来支持 SOA 解决方案框架的设计、开发、部署和操作。

SOA 带来了跨信息技术解决方案的开发、部署和管理的扩展要求。虽然 IT 的总体挑战和治理要求仍然相似，但服务概念提高了 IT 功能与业务的相关性。IT 不再被视为管理一组竖井式应用程序的功能；启用 SOA 的组织的 IT 组合建立在一组不断发展并与 LOB 和系统无关的公共基础功能和服务的基础上。因此，SOA 治理以多种方式扩展了 IT 治理，例如通过以下方式：

• 改变源自于新的设计和建模范例、服务重用注意事项和组合应用程序开发的传统开发生命周期。

• 扩展操作管理的概念以处理分布式部署和管理的问题、测量服务接口及其基础实现级别的有效性、性能和安全性。

• 在角色和职责方面（例如，需求评估、交流、服务所有权和项目资助）更改传统组织模型，从而推倒以前隔在业务和 IT 之间的墙。

SOA 治理是否必须强制执行现有的 IT 治理方法尚不确定，但非常明显的是，有效的治理可以为 SOA 治理方法提供一个初始框架。

回页首

治理方法：良好、糟糕、差劲

在我作为 IBM 的 SOA 架构师的工作中，我处理过成功的——以及失败的——SOA 实现。客户要求我指出 SOA 成功所需的要素和（同样重要的是）导致失败的因素。这两个问题的常见答案都可归结为治理。虽然我可以编制一个 SOA 治理功能列表，但是我将把讨论限制到四个核心领域：

• 策略和过程的定义和强制执行以支持服务的 SOA 设计、开发、部署和管理，以及一组对应的方法、技术和工具以支持业务的 SOA 和战术及战略要求。

• 同时代表 IT 和业务的资质中心（或卓越中心）的建立，以作为整个组织中的共享资质来维护和推动 SOA 计划。

• SOA 目的和目标的持续的管理层和业务资助，并强制支持与组织涉众进行有关 SOA 开发、实现和管理的连续交流。

• 组织级别的理解，以对 SOA 采用进行战术执行和战略计划；SOA 是对 IT 和组织的渐进和不断发展的改变，并从迭代实现中获益。

应该明确指出的是：SOA 改变了 IT 使命和 IT 与业务的关系。

SOA 指引了一种不同的 IT 开发和管理方法，使得解决方案能够跨越组织业务单位，而不是像基于竖井的应用程序方法那样链接到特定的业务部门。如果组织不同时理解和协调这些注意事项，SOA 就不会在企业级取得成功。

SOA 案例 1：Acme Assurance

IBM® 在金融业的一个欧洲客户（以下称为“Acme Assurance”）于 1999 年开始构建一种结构化的集成方法，并从那以后已发展为企业 SOA 框架。该项目起初作为一个消息集成体系结构，以跨越大型机（IMS™、CICS® 和现在的 WebSphere®）、AIX®/UNIX™、Windows® 和 iSeries®。Acme Assurance 使用 DB2® 和 Oracle 作为主要数据库，应用程序（自定义或现成的）运行于各种各样的实现（包括 COBOL、PL/SQL 和 Java™）之上。作为初始框架的一部分，他们构建了一个使用 XML 来定义公共消息格式的框架、一个用于对消息流组件分类的内部自定义注册中心和用于定义流操作的语法 (pre-WSDL) 。他们当前的解决方案包括 300 多个公共服务（现在正在迁移到 WSDL），总体重用率超过 50%。更重要的是，他们日常事务的 40% 都流过这些服务中的一个或多个，从而在 IT 开发方面产生了 300 多万英镑的估计节省（基于重用和质量度量）。

当我访问 Acme Assurance 并问他们认为成功的因素是什么时，他们回答说成功与他们从该工作一开始时就拥有的管理层支持有关，并且该体系结构的渐进式定义和交付使他们能够快速为业务产生结果。通过与业务的紧密联系，他们通过卓越中心（Center of Excellence，CoE）定义了技术和业务级别的服务和操作特征，卓越中心跨各个专门从事消息、Java、XML 和安全性的团队交互。CoE 负责：

• 定义设计流程、基础设施组件和总体框架。
• 定义和实现服务管理流程，包括服务的定义、文档记录和发布。
• 定义用于测量重用的流程和操作实现。

Acme Assurance 方法的优点可总结如下：

• 生产中运行的 70 多个应用程序使用一个或多个服务。
• 40% 以上的后端事务通过 SOA 来发起。
• 他们的业务服务目录中的 300 多个可重用服务的管理。
• 50% 以上的业务服务实现了重用。

该解决方案的成功很大程度上是通过对强有力的治理方法的投资来实现的，即通过 CoE 来定义策略和流程。过去七年来，该组织紧随技术和组织的变更而不断取得成功，很大程度上是由于在确保体系结构治理方面的纪律和严格性。此外，IT 在项目早期就保证管理层的承诺，从而使得解决方案能够在整个组织中都具有信誉。最后，在跟踪和管理解决方案的部署和操作方面，他们所做的工作一直是非常杰出的。Weill 和 Ross（请参见参考资料）认为，跟踪和管理这些方面的能力与成功的治理关系最大。

SOA 案例 2：Worldwide Resources

另一个客户在项目开始时遵循了类似的路线，但是没有获得相同的结果。这家世界级的全球 100 强公司（我们将称之为“Worldwide Resources”）管理着在世界上几乎每个国家的业务运营。为了支持更灵活的 IT 体系结构，Worldwide Resources 对其五个重要 IT 项目的投资进行重新评估，我作为该工作的一部分应邀执行了体系结构评估复查。

一方面，该公司成功组建了一个内部组织来建立围绕集成概念的策略和过程。遗憾的是，资质中心变成了技术智囊团，并很快脱离业务部门，从而使总体管理层资助未发挥应有的作用。基于一组没有既定业务价值的项目的战术性执行，开发很快转向了自底向上的开发工作。许多非最优的设计决策进一步延误了交付实际短期成功的能力，从而使这一问题复杂化。在开始该项目两年以后，面对战略功能未交付、围绕集成的预算纠纷和对技术团队未从资源投资中实现价值的整体沮丧，业务用户对这些问题怨声载道。

Worldwide Resources 犯了什么错？从上面的讨论中可以看出，答案是很明显的：

• 业务案例定义和业务涉众的参与非常少。
• 涉众没有定义目的和目标以及跨组织的角色和职责。
• 缺乏对服务和组件的重用，每个团队都各自为政地创建解决方案，而没有用于跟踪重用或定义利用率的有效方法。
• 由于缺乏治理，对解决方案定义、部署和 QA/测试过程方面的标准和过程的遵守非常有限。
• 一个严重的问题在于，从来就不存在跨实现的资助定义——请求某个解决方案的组织成了没有成本回收的资助点。

最后，Worldwide Resources 尝试将以部门为中心的分散开发流程替换为一种成本昂贵的方法，指望某种基于技术的方法能够纠正组织功能紊乱。这些问题加上可靠 IT 治理方法的缺乏，导致了业务与 IT 之间的信誉危机。应该补充说明的是，他们现在“更健康”了，但是许多基础组织问题仍在困扰 IT/业务关系；实现治理和转变 IT 也不是那么轻松的任务。

Worldwide Resources 是个案吗？非常遗憾，并不是这样。许多公司都遇到了类似的问题。缺乏精心设计的正式治理方法仍是个困扰，并会继续阻碍组织的 SOA 采用。

SOA 案例 3：Tech Equipment Inc.

另一家公司（“Tech Equipment Inc.”）是一家总部设在美国的大型全球性公司，并且是他们的特定高技术行业的市场领导者。他们的业务问题是大型组织普遍存在的：他们有 15 个以上的不同渠道来与 1000 多个战略合作伙伴进行企业对企业的交互，范围从 FTP 和 EDI 到 Rosetta Net。实现这些交互的内部专用流程包含在单独的系统中，这些系统源自于支持业务要求的外购和战术性解决方案。结果，由于没有协调这些不同系统的输出，Tech Equipment Inc. 缺乏对操作的可见性。遵循一个扩展的评估流程，IBM Global Services 受雇管理 B2B 合并流程和面向服务的系统开发方法的制定。

依我看，Tech Equipment Inc. 取得持续成功的关键是业务资助者在起初就介入进来，定义了问题并与技术团队合作制定战术方法，以及用于推出该解决方案体系结构的多次迭代的战略计划。作为分阶段的开发和设计方法的制定和属于其 IT 治理方法一部分的策略和流程的早期定义的结果，该项目不断地实现了他们的承诺。除了预先确定业务目标以外，该项目还做了大量的工作来让整个公司中的涉众对项目进度进行评价，其中包括销售、市场和合作伙伴管理部门。对项目的热情评价并不忽视存在定期遇到的业务和技术问题，但是项目的总体治理确保问题在发生时得到处理——而不是在它们已经恶化之后。目前，该 B2B 合并项目正在按计划进行，并将 B2B 渠道数量减少了一半，很大程度上是通过同时对战术和战略计划的治理和管理来实现的。

SOA 案例 4：Exchange Unlimited

作为我的最后一个客户示例，我参与了 Asia Pacific 交换中心的开发，以下称为“Exchange Unlimited”。该公司拥有现有的交换中心，用于通过各种各样的接口为“订阅组织”执行企业对企业的事务，其中包括 FTP、Rosetta Net 和基于门户的交互。该项目的意图是使用 J2EE、门户和合作伙伴管理技术（与 Tech Equipment Inc. 类似）来将该中心转换为面向服务的解决方案。

虽然在项目开始就定义了该解决方案的业务要求和总体上下文，但是业务涉众和技术团队之间缺乏有效的交流。我们与项目团队合作，在九个月的周期内执行了多次体系结构复查，并开始建立“卓越中心”方法的基础。在体系结构复查之后，系统设计中存在有关性能、安全性和管理的问题就变得明显了。核心问题在于，这些问题没有传达到业务涉众那里。除了遭遇大批有经验的人才流失到其他公司外，业务预期与技术可行性之间也存在差距。由于 Exchange Unlimited 的不同职能部门之间缺乏真诚的交流和信任，并且没有用于组件和服务的开发和设计的正式流程定义，该差距被进一步恶化。即使有了治理框架，Exchange Unlimited 的问题也可能无法消除，但是问题会更快浮出水面并得到处理。

下面让我们检查一下记分卡：

表 1. SOA 成功条件

回页首

通过 SOA 治理获得成功

有关 SOA 治理的成功方法的要素是什么，我想提供一些指导。尽管有在不成熟或不存在治理方法的情况下开始的“创新小组”(skunk-works) SOA 研究项目，但是我发现 SOA 计划的成功需要对治理的组织承诺。

在我的工作中，我发现建立 SOA 治理以支持 SOA 通常是通过创建（或扩展）“卓越中心”来实现的。在许多情况下，组织在 CoE 创建中利用外部顾问的经验，以从通过其他 SOA 约定来学习到的累积最佳实践中获益。应该指出的是，建立 CoE 本身并不足以保证 SOA 成功；支持 SOA 的策略、流程和方法的定义也是治理所不可或缺的部分。此外，管理层和业务涉众对计划的持续资助以及积极的交流是成功的关键要求。最后，渐进地采用 SOA 的能力是成功的重要方面；强制作为单个（或作为多个，例如在 Worldwide Resources 所看到的）难以克服的项目来采用 SOA 是个错误，并在几乎所有情况下都会导致失败。

虽然许多公司都准备了 IT 治理，并着手扩展这些框架以支持 SOA，但是经验表明，成功的 SOA 治理通常需要外部协助，以确保与公司治理和 IT 治理框架的一致性和适应性。

回页首

结束语

在许多组织中，SOA 采用可以在部门级别有机地进行，但是当它扩展为企业方针时，SOA 需要企业承诺和跨业务和 IT 涉众的持续参与。为了成功实现 SOA，组织必须定义和实现 SOA 治理。正如 Eric Mark 所言，“面向服务的文化将企业的远景、战略和目标与其 SOA 战略、远景和治理模型绑定在一起”。

SOA 治理需要大量的规划和准备才能确保成功。在许多情况下，SOA 治理可能产生于 SOA 项目团队；然而，业务涉众成为治理框架的活跃和持续的一部分，这对于确保交流和支持业务的总体目的和目标是非常重要的。

总之，SOA 治理不只是可选的——它对于支持 SOA 采用和发展至关重要。SOA 治理不是赠予——拥有现有组织和 IT 治理的组织不会自然地拥有 SOA 治理。最后，SOA 治理不是一次性的解决方案——SOA 治理需要持续的评估和反复的提炼才能确保 SOA 成功。“有备无患”——若要取得 SOA 成功，应及早做出正确的治理决策。