[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放

[p=30,2,center]

[p=30,2,center]

2008和2009年间从面向服务架构(SOA)的角度建立的重要的一点是，SOA的成功与否可以通过制定可靠的治理策略进行预测。尽管SOA的成功不通过实现治理策略也可以达成，但其可能性却可能因为潜在的错失了主要目标（开发一种单一的方案来交付服务）而有所折扣。因此，IT服务管理IT运维管理社区的IT基础设施库(ITIL)为IT服务管理定义了一系列的最佳实践框架指导，它是IT治理的一个框架，而它的第三个版本，尽管是专为IT而开发的，却可以用作SOA治理的一般性策略。

那些仅仅熟知ITILV2的人通常会嘲笑将ITIL用作SOA治理框架的这种思想。从他们这种角度出发，他们可能是对的，因为V2更多的关注在运作流程上而不是服务生命周期。在ITILV3中，该框架的重心已经转移，而这种转移只能用面向服务来真正描述。5本ITILV3的核心书籍被恰如其分的命名为：服务策略、服务设计、服务转换、服务运营以及持续服务改进；证明了ITIL对于面向服务生命周期的理解。

治理在SOA中的角色
因为对于SOA并没有一个单一的，明确的资源，所以SOA这个术语被多方征用来代表他们的利益或安排，就像其它有计划而明确订立的标准一样的问题。然而，这一主题有足够多的文献可以进行分析，并且从数据上可以得出SOA的两个站得住脚的立场：业务与IT对齐以及软件系统的开发。在这两种情况中，松耦合，巩固以及共享等等相同的目标都是显而易见的。因为这些方面都是值得去做的，而且应用它们也的确能提升服务交付和整体的灵活性，因此治理为确保所有的工作都能以这样的方式交付提供了必需的流程、政策、角色和工具。

治理不会魔幻地带来成功；它只是对于那些最容易造成瓶颈或阻碍SOA项目的问题提供了一个框架性的答案。治理提供了一种责任，并且针对与构建和交付服务相关的决定提供了指导。举例来说，可以赋予治理流程一定的权力来决定业务是否需要投资某一类型的服务，以及这种服务是否符合合理的需求或机会。不仅如此，治理流程还可以包括业务各个方面的个人，对于开发特定类型的正反两面都能提供更宽阔的视野。

有趣的是，说到提供服务这方面，许多业务都十分复杂因此该服务需要跨部门的参与。举例来说，保险公司对于检查他们是否会提供一项新的保险业务投入力度很大。他们的决定从检查这个市场开始，分析客户以及之前的清算场景和潜在利润。这一研究的成果又会交给一个多方合作的小组，并对这一新服务从客户服务、会计、财务管理和技术等角度提供反馈。最后，这个小组将会对有权力的运营执行官提供建议，由他们作出最终决定。

然而，被认为是部门内部的决定通常是由有限范围内的少数人决定的，通常是部门执行官，就算这样的决定将会影响其它部门的成果或能力也是一样。这就是说，如果一个部门拥有整个服务供应，比如说IT部门，那么要扩展到其它的部门来对于将这一特定的服务提供给业务客户是否能为业务带来价值而作出决定就不太可能了。当这发生在SOA中时，你最终得到的是狭隘的面向服务，很有可能不能满足业务的预期。

ITILV3对SOA的支持
首先，ITIL关注于将IT作为服务交付，这抓住了SOA的经常缺失（或者被误解，被忽略）的真正本质之一。那就是，相对于那些将SOA看作是交付软件系统的一种方法的人而言，ITIL关注的是服务本身。在ITIL中，服务包括了软件、基础设施、帮助台和资产管理等等。因此，这可能是一个治理框架的最佳表现形式，因为它纯粹是从以服务为中心的角度去关注服务，而不是从技术的角度。

ITILV3的核心是服务策略的概念，其重点是价值的创造。许多SOA的文献都推崇中间会合的SOA开发方法，以此不得罪任何一方特定的受众。中间会合的方法在设计服务时，既关注自底向上，也关注自顶向下。然而，这样的自底向上是远远不够的，并且缺乏对业务质量的理解，因此如果包含这样的知识来开发实际上是对创建新服务的一种损害。ITIL对于价值创造的关注意味着服务交付的第一步，要从一个策略观点出发，而不限制于过去提供这一服务的尝试而产生的结果。

ITILV3同时还关注服务设计，它使用服务设计包的概念来封装所有的需求，处理依赖与延伸、架构、流程、衡量与矩阵。这一概念是思考如何组织一个SOA项目中产出的所有工件的一种良好方式。包含在服务设计中的是服务组合管理和服务目录管理的概念，这与SOA服务注册，服务目录，以及变更与授权的管理是一致的。

最后，服务转换，服务运营和服务提升，关注于将服务交付到市场的流程，保证它的运营性能并对服务进行持续的调整优化。那些通过技术的滤镜来看SOA的人们会错失这些实践所带来的差别，因为这是在软件工程努力范围之外的。一个服务在部署后可以正确的得以管理的唯一方式就是支持与服务消费者的沟通和监控服务的使用。再次强调的是，SOA是一个战略计划并需要许多业务人员的努力，它不应当一蹴而就。这一观点在下面的大SOA和小SOA一节中将得到更多说明。

此外，开发者通常假设测试与度量能够得以完成，而且服务本身不需要包括对这些活动的支持。这些短视之处正是着重于以SOA构建软件服务的人们需要运用ITILV3框架的原因，由它来保证服务开发不会因为软件工程的偏见而招致不好的后果。

ITILV3不关注如何构建服务，虽然它本身也很重要。关于交付IT服务方面，有后续的更细节的标准可以遵循，比如TOGAF，ISO/IEC20000，CMMI，COTIT以及SixSigma。然而，V3可以指导服务本身的生命周期，这正是我们对SOA的期望，一个统一的达成一致的框架，来定义和指导整个服务的生命周期，从摇篮到坟墓。

大SOA，小SOA以及SOA治理
一个关于SOA治理的讨论如果不涉及关于大SOA和小SOA的争论的话就是不完全的。有一些人认为SOA可以通过一种战术的，IT为中心的方式来实现，即“小SOA”这个术语的意义，而企业级的SOA就被称作“大SOA”。我相信将ITILV3应用于SOA治理问题上将会一劳永逸的解决这个争端——只有一种SOA。就算一个组织决定实现以IT为中心的SOA，ITILV3也证明了将IT作为一种服务交付仍然需要极大的努力和纪律来保证服务的消费者获得合理的服务，并且保证服务满足他们的需求。就算是比整个企业要小的一个规模，它仍然要求业务实现遵循整个实践模型以确保成功。

任何小规模的SOA都把重点放在应用开发上，并换了一种说法用SOA来表示组件软件架构。最终，这将不是SOA，因为它并没有关注服务的生命周期，而是关注在定义软件组件间接口和支持模块化的方法。模块化与SOA不是同义的，而其结果与ITILV3治理驱动下的SOA也是截然不同的。

总结
对于SOA治理解决方案的关注和投资一直都很火爆。在许多这样的情况中，业务都想要找到对于它们自身的SOA而言的最好的治理方法——其中一些疑惑仍然来自于对SOA本身的疑惑。ITILV3提供了一个综合的方案来治理一个服务的创建、设计、开发、部署、运营、变更管理以及最后的终止。

关于作者
JPMorgenthal是QinetiQNorthAmerica的MissonSystemGroup的资深架构主任，为联邦民用事务提供SOA架构指导，同时也是一名独立的分析师。在加入QinetiQNA以前，JP创立了Avorcor，开发基于SOA的零售/制造业PaaS，这成为了三个获奖的业界解决方案的根基。他同时也经常写关于企业架构，SOA，云计算等主题方面的博客和文章。Morgenthal也是"企业信息集成：一种实用的方式"一书的作者，该书介绍了使用SOA和语义来简化集成的方法论

前排支持下