2008 和 2009 年间从面向服务架构 (SOA) 的角度建立的重要的一点是，SOA 的成功与否可以通过制定可靠的治理策略进行预测。尽管 SOA 的成功不通 过实现治理策略也可以达成，但其可能性却可能因为潜在的错失了主要目标（开发一种单一的方案来交付服务）而有所折扣。因此，IT 服务管理论坛的 IT 基础设 施库 (ITIL) 为 IT 服务管理定义了一系列的最佳实践框架指导，它是 IT 治理的一个框架，而它的第三个版本，尽管是专为 IT 而开发的，却可以用作 SOA 治理的一般性策略。
那些仅仅熟知 ITIL V2 的人通常会嘲笑将 ITIL 用作 SOA 治理框架的这种思想。从他们这种角度出发，他们可能是对的，因为 V2 更多的关注在运作流程上而不是服务生命周期。 在 ITIL V3 中，该框架的重心已经转移，而这种转移只能用面向服务来真正描述。5 本 ITIL V3 的核心书籍被恰如其分的命名为：服务策略、服务设计、服务转换、服务运营以及持续服务改进；证明了 ITIL 对于面向服务生命周期的理解。
治理在 SOA 中的角色
因为对于 SOA 并没有一个单一的，明确的资源，所以 SOA 这个术语被多方征用来代表他们的利益或安排，就像其它有计划而明确订立的标准一样的问题。然而， 这一主题有足够多的文献可以进行分析，并且从数据上可以得出 SOA 的两个站得住脚的立场：业务与 IT 对齐以及软件系统的开发。 在这两种情况中，松耦合，巩固以及共享等等相同的目标都是显而易见的。因为这些方面都是值得去做的，而且应用它们也的确能提升服务交付和整体的灵活性，因 此治理为确保所有的工作都能以这样的方式交付提供了必需的流程、政策、角色和工具。
治理不会魔幻地带来成功；它只是对于那些最容易造成瓶颈或阻碍 SOA 项目的问题提供了一个框架性的答案。治理提供了一种责任，并且针对与构建和交付服务相 关的决定提供了指导。举例来说，可以赋予治理流程一定的权力来决定业务是否需要投资某一类型的服务，以及这种服务是否符合合理的需求或机会。不仅如此，治 理流程还可以包括业务各个方面的个人，对于开发特定类型的正反两面都能提供更宽阔的视野。
有趣的是，说到提供服务这方面，许多业务都十分复杂因此该服务需要跨部门的参与。举例来说，保险公司对于检查他们是否会提供一项新的保险业务投入力度很 大。他们的决定从检查这个市场开始，分析客户以及之前的清算场景和潜在利润。这一研究的成果又会交给一个多方合作的小组，并对这一新服务从客户服务、会 计、财务管理和技术等角度提供反馈。最后，这个小组将会对有权力的运营执行官提供建议，由他们作出最终决定。
然而，被认为是部门内部的决定通常是由有限范围内的少数人决定的，通常是部门执行官，就算这样的决定将会影响其它部门的成果或能力也是一样。这就是说，如 果一个部门拥有整个服务供应，比如说 IT 部门，那么要扩展到其它的部门来对于将这一特定的服务提供给业务客户是否能为业务带来价值而作出决定就不太可能 了。当这发生在 SOA 中时，你最终得到的是狭隘的面向服务，很有可能不能满足业务的预期。
ITIL V3 对 SOA 的支持
首先，ITIL 关注于将 IT 作为服务交付，这抓住了 SOA 的经常缺失（或者被误解，被忽略）的真正本质之一。那就是，相对于那些将 SOA 看作是交付软件系 统的一种方法的人而言，ITIL 关注的是服务本身。在 ITIL 中，服务包括了软件、基础设施、帮助台和资产管理等等。因此，这可能是一个治理框架的最佳表 现形式，因为它纯粹是从以服务为中心的角度去关注服务，而不是从技术的角度。
ITIL V3 的核心是服务策略的概念，其重点是价值的创造。许多 SOA 的文献都推崇中间会合的 SOA 开发方法，以此不得罪任何一方特定的受众。中间会合的方法在设 计服务时，既关注自底向上，也关注自顶向下。然而，这样的自底向上是远远不够的，并且缺乏对业务质量的理解，因此如果包含这样的知识来开发实际上是对创建 新服务的一种损害。ITIL 对于价值创造的关注意味着服务交付的第一步，要从一个策略观点出发，而不限制于过去提供这一服务的尝试而产生的结果。
ITIL V3 同时还关注服务设计，它使用服务设计包的概念来封装所有的需求，处理依赖与延伸、架构、流程、衡量与矩阵。这一概念是思考如何组织一个 SOA 项目中产 出的所有工件的一种良好方式。 包含在服务设计中的是服务组合管理和服务目录管理的概念，这与 SOA 服务注册，服务目录，以及变更与授权的管理是一致的。
最后，服务转换，服务运营和服务提升，关注于将服务交付到市场的流程，保证它的运营性能并对服务进行持续的调整优化。那些通过技术的滤镜来看 SOA 的人们 会错失这些实践所带来的差别，因为这是在软件工程努力范围之外的。一个服务在部署后可以正确的得以管理的唯一方式就是支持与服务消费者的沟通和监控服务的 使用。再次强调的是，SOA 是一个战略计划并需要许多业务人员的努力，它不应当一蹴而就。这一观点在下面的大 SOA 和小 SOA 一节中将得到更多说明。
此外，开发者通常假设测试与度量能够得以完成，而且服务本身不需要包括对这些活动的支持。这些短视之处正是着重于以 SOA 构建软件服务的人们需要运用 ITIL V3 框架的原因，由它来保证服务开发不会因为软件工程的偏见而招致不好的后果。
ITIL V3 不关注如何构建服务，虽然它本身也很重要。关于交付 IT 服务方面，有后续的更细节的标准可以遵循，比如 TOGAF，ISO/IEC 20000，CMMI，COTIT 以及 Six Sigma。然而，V3 可以指导服务本身的生命周期，这正是我们对 SOA 的期望，一个统一的达成一致的框架，来定义和指导整个服务的生命周期，从摇篮到坟墓。
大 SOA，小 SOA 以及 SOA 治理
一个关于 SOA 治理的讨论如果不涉及关于大 SOA 和小 SOA 的争论的话就是不完全的。有一些人认为 SOA 可以通过一种战术的，IT 为中心的方式来实现，即 “小 SOA”这个术语的意义，而企业级的 SOA 就被称作“大 SOA”。我相信将 ITIL V3 应用于 SOA 治理问题上将会一劳永逸的解决这个争端——只有一种 SOA。就算一个组织决定实现以 IT 为中心的 SOA，ITIL V3 也证明了将 IT 作为一种服务交付仍然需要极大的努力和纪律来保证服务的消费者获得合理的服务，并且保证服务满足他们的需求。就算是比整个企业要小的一 个规模，它仍然要求业务实现遵循整个实践模型以确保成功。
任何小规模的 SOA 都把重点放在应用开发上，并换了一种说法用 SOA 来表示组件软件架构。最终，这将不是 SOA，因为它并没有关注服务的生命周期，而是关 注在定义软件组件间接口和支持模块化的方法。模块化与 SOA 不是同义的，而其结果与 ITIL V3 治理驱动下的 SOA 也是截然不同的。
总结
对于 SOA 治理解决方案的关注和投资一直都很火爆。在许多这样的情况中，业务都想要找到对于它们自身的 SOA 而言的最好的治理方法——其中一些疑惑仍然来 自于对 SOA 本身的疑惑。ITIL V3 提供了一个综合的方案来治理一个服务的创建、设计、开发、部署、运营、变更管理以及最后的终止。
关于作者
JP Morgenthal 是 QinetiQ North America 的 Misson System Group 的资深架构主任，为联邦民用事务提供 SOA 架构指导，同时也是一名独立的分析师。在加入 QinetiQ NA 以前，JP 创立了 Avorcor，开发基于 SOA 的零售 / 制造业 PaaS，这成为了三个获奖的业界解决方案的根基。他同时也经常写关于企业架 构，SOA，云计算等主题方面的博客和文章。Morgenthal 也是"企业信息集成：一种实用的方式"一书的作者，该书介绍了使用 SOA 和语义来简化集 成的方法论。
查看英文原文： Using ITIL V3 as a Foundation for SOA Governance 。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论