【IT168 技术文章】
我们平常可以看到有很多集成项目都使用SOA技术来努力使自己变得更成熟。这些项目交付了一些服务，但是却只有极少数能做到企业级的服务重用。个中缘由往往要归结于组织不知道如何成功地把他们SOA的成果由一个集成解决方案扩展至一个企业解决方案。我们认为，要想成功地交付这些SOA项目的商业价值，治理是必不可少的；因而，我们将在本文中介绍一种基于生命周期的SOA治理成熟度模型。在我们看来，治理可以被视为一种决策制定的框架，而这也与Weill & Ross的IT治理定义相符：IT治理是一种规定了决策权力和义务的框架，其目的是为了鼓励IT使用过程中的合理行为。[i]我们的文章将由以下3部分组成：[ii]。这个模型源自非常好的实践和访谈，并且关系到SOA治理的范围。它认为，为了获得成熟流程的好处，主体之间的成熟度应该相等。尽管在开发该模型的时候并未有意地使用SOA，然而我们认为组织范围是SOA治理需求的优秀指示器。
讨论SOA治理的生命周期流程
SOA治理如何才能变得更加成熟，以及如何使用成熟度模型来给这种成长助力，
架构师在SOA治理中所起的作用，并给身处一个成熟中的SOA环境的架构师提供了实用的指导方针。
我们的模型是特意为架构师准备的；他们往往是SOA的拥护者。在企业架构、解决方案架构或领域架构中，你都可以发现他们的身影。架构师对于启动SOA治理起到了重要的作用，但是随着企业内SOA成果的不断增长，架构师的职责发生了改变，部分这些职责将很有可能转移到一个SOA治理委员会身上。
我们的治理模型可以帮助架构师判断其企业SOA治理的当前成熟度水平。这个模型还给架构师就其在SOA治理向更高成熟度级别前进过程中发挥的作用给出了务实的真知灼见，给他们在组织内增进和拓展SOA的成功提供了便利。
SOA治理的生命周期
SOA治理相关的活动并不是马上要求构建可工作服务的活动，而是那些所有可以提高SOA整体质量并且支持在复杂环境中进行控制的活动。这包括：
人员 —— 确保职责已经被分配到合适的岗位，人员已经被培训具有必需的知识和能力。
流程 —— 确保已经制订出合适的服务质量保证和监视流程。
产品 —— 设置所需服务和它们的文档；策略是一个常见的例子，服务文档模板也属于此类。
我们在一个SOA治理生命周期模型中已经说明了这些主题。这个模型定义了实现优秀SOA治理所需执行的6个主要流程。一个生命周期代表一次迭代，它是面向服务架构实施过程中一个范围限定、实现具体目标的项目。SOA开发发生在SOA治理生命周期的许多迭代中。通过这些迭代，成熟度水平可以（而且应该）得到提高。
头两个流程集中于业务，说明了SOA愿景和对组织的影响。接下来的3个流程组成了架构师关注的要点：服务组合管理（Portfolio Management）、服务生命周期管理和策略执行。最后一个流程，服务水平管理，属于系统管理员的范畴。但是，在整个生命周期中，活跃于SOA治理中的所有团体都必须涉及到。这些团体是如何参与的将在SOA治理生命周期的每条流程中进行描述。
SOA的愿景
迭代的第一部分就是确立SOA的长期目标，或修订现有目标。这个流程从组织角度对SOA进行了详细阐述，同时还包括设定生命周期当前迭代的目标。SOA的愿景是业务和IT的结合产物，其中业务和IT的对齐由架构师负责推动。
创建SOA组织
在这个流程中要定义SOA治理的角色和职责。这常常导致了某种类型的SOA治理委员会（或卓越中心）的建立。这个委员会应该代表SOA治理的干系人，既包括业务人员，也包括IT人员。这个SOA治理委员会决定了SOA治理生命周期的实现方式。本文的后续内容将给出相关的指导方针。为了执行当前的生命周期迭代，合适的人员应该出现在合适的位置。这不仅可能需要一些额外的培训，而且资助和激励程序也可能是这个流程中的活动。SOA治理委员会应该通过在组织中强制标准和提倡SOA原则来改善SOA原则的采用。
服务组合管理
对于即将开发的服务，综合业务代表和多方意见是必要的。在开发特定服务时，架构师应该权衡IT和业务的意见。通过从一开始就介入组合管理，架构师应该能够发现适合重用的服务，因而要优先尽早地开发它们。服务组合管理的一个可能产品是服务路线图，它列出了当前和已规划的服务。
服务生命周期管理
这个流程解决了企业服务的实现、更新和退役。生命周期管理不应该是各项目的事，而应该由SOA治理委员会来完成，统一管理SOA的变更。SOA变更涉及概念上的、企业范围内的服务，这些服务被重用并执行业务功能。架构师在SOA治理委员中应该协助确保所有服务都被纳入生命周期的管理，防止出现未被治理的服务。
策略执行
这个流程关心的是策略的设计和执行。例如，架构师应该确保人们将自己的服务发布到注册中心中，以便这些服务可被治理和重用。架构师同样还应注意策略在设计层面的应用。设计层面的策略是服务开发的标准，通常以原则或非常好的实践的形式出现。与运行时策略不同，设计时策略一般无法被自动监测。因此，需要说服开发者去遵循标准。架构师应该审查交付的新企业服务，并且在审查中，设计时策略的采用应该作为一个重点工作内容。
服务水平管理
不同于其他IT架构，SOA要求不同的服务水平管理，原因在于服务的粒度比应用的粒度更细。同样，要想灵活地消费别人开发的服务就要求消费者能很好地理解服务水平。服务水平管理是一项系统管理员的任务，但是架构师应该注意服务水平的反应，以便可以和企业讨论这些水平是否仍然适合企业的用户。而且，通过审查服务的使用（可能是通过注册中心的工具），有望发现服务重用的机会。
