SOA治理成熟度——一名架构师的观点

我们平常可以看到有很多集成项目都使用SOA技术来努力使自己变得更成熟。这些项目交付了一些服务，但是却只有极少数能做到企业级的服务重用。个中缘由往往要归结于组织不知道如何成功地把他们SOA的成果由一个集成解决方案扩展至一个企业解决方案。我们认为，要想成功地交付这些SOA项目的商业价值，治理是必不可少的；因而，我们将在本文中介绍一种基于生命周期的SOA治理成熟度模型。在我们看来，治理可以被视为一种决策制定的框架，而这也与Weill \u0026amp; Ross的IT治理定义相符：IT治理是一种规定了决策权力和义务的框架，其目的是为了鼓励IT使用过程中的合理行为。[i]我们的文章将由以下3部分组成：[ii]。这个模型源自最佳实践和访谈，并且关系到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要求不同的服务水平管理，原因在于服务的粒度比应用的粒度更细。同样，要想灵活地消费别人开发的服务就要求消费者能很好地理解服务水平。服务水平管理是一项系统管理员的任务，但是架构师应该注意服务水平的反应，以便可以和企业讨论这些水平是否仍然适合企业的用户。而且，通过审查服务的使用（可能是通过注册中心的工具），有望发现服务重用的机会。

\

使用生命周期增强SOA治理的成熟度

\

与成熟度模型相结合后，所提议的SOA治理生命周期中的那些流程会变得非常有帮助。关于（SOA）成熟度模型已有大量的出版物，基本上任何成熟度模型都可结合SOA治理生命周期使用。这些成熟度级别需要有某种类型的规范来说明SOA治理每个阶段的预期内容。这可以通过一个矩阵来完成，其中确定了每个成熟度级别的SOA治理生命周期流程的范围。在下面的例子中，我们使用了德勤（Deloitte）的业务成熟度模型

\

• 先驱（Pioneer）：SOA包含了几个小规模的项目，为确定最佳实践提供了灵活性。这些努力往往是速赢的（quick-wins），而且会带来轻微的组织复杂性。只有极少的SOA治理，重点关注项目的范围。因为通常有一个SOA的拥有者，控制并不非常复杂。\
• 流程（Process）：在此阶段，一个组织单元、产品或流程完全服从SOA。SOA常常出于特定目的而被实现，如库存管理。此阶段有一个拥有者总负责，并为SOA提高主要的资助。但是，架构和组织中其他地方的IT发生关联，因此SOA的治理需要多方达成一致意见。由于牵涉的人更多，导致治理的需求增加了。\
• 系统（System）：此阶段的SOA由多个业务拥有者控制。这意味着CxO级别的支持是必要的，而且SOA治理需要集中化。SOA治理指定了组织中所有各方后续SOA实现所遵循的标准。\
• 网络（Network）：SOA由不同的、积极参与的组织协调。这些组织彼此提供服务，这些服务相互连接，对端到端的业务流程提供了支持。这意味着这些参与方的SOA治理需要一致。缺乏正确的治理，服务变更将对业务运营造成重大不可预知的影响。\

下表就每个成熟度级别的SOA治理生命周期阶段的需求变更给出了一些提示。它们并不是必需步骤，而是在实践中改进SOA治理的可能方法。这些提示可以在其他成熟度模型的类似矩阵中使用。拥有这样一个矩阵的好处是：它形成了一份简单的SOA治理发展道路概览。它还给组织提供了某种关于SOA成熟度级别的“健康指标”。

\

\ \	\ 先驱 \	\ 流程 \	\ 系统 \	\ 网络 \
\ SOA的愿景 \	\ 确定概念尝试的范围 \	\ 小规模SOA的业务建议 \	\ 确立与业务战略保持一致的愿景 \	\ 通过SOA有可能将大范围的业务建议连接起来 \
\ 创建SOA组织 \	\ 发展技术技能 \	\ 协调SOA治理和其他IT治理活动 \	\ 搭建SOA治理结构 \	\ 和网络伙伴一起创建网络化的治理委员会 \
\ 服务组合管理 \	\ 识别导航项目的服务 \	\ 针对选择的服务更新业务用例 \	\ 组合流程的规范化 \	\ 建立服务开发来源的标准 \
\ 服务生命周期管理 \	\ 维护服务列表 \	\ 跟踪服务生命周期各阶段 \	\ 对存储所有服务的注册中心进行规范化 \	\ 和网络伙伴一起协调服务生命周期 \
\ 策略执行 \	\ 记录最佳实践 \	\ 规范化使用和开发服务的原则 \	\ 建立策略执行的过程 \	\ 确定网络伙伴间的执行点 \
\ 服务水平管理 \	\ 确保足够的运行时间 \	\ 监视服务水平 \	\ 确定每个服务的SLA和报告 \	\ 和网络伙伴一起确定SLA和SLA报告 \

表 1：成熟度级别相关的治理流程范围

\

使用成熟度开发一个不断成长的SOA

\

除了改变SOA生命周期各流程，增加成熟度还会改变SOA在组织中的影响。下面的模型展示了治理成熟度级别的这种转变。它表明，在第一个成熟度级别中，我们不能说组织中有“一个SOA”。不同的小规模面向服务解决方案是被单独构建和治理的。为了获得更多企业范围内的好处，对这些先驱SOA进行了分组治理。分组可按业务流程进行，正如流程成熟度级别的名字所暗示的，但是按照业务单元或地理区域划分可能也不错。随着SOA成为企业范围的解决方案，治理要向一个集中的治理模型靠拢。甚至这个系统治理控制范围显示有边界，这意味着有可能把治理扩展到特殊部分。在最后一个成熟度级别，治理控制是在网络伙伴间协调的。来自不同组织的治理委员会可能会坐在一起，就彼此的框架和方法论进行共享和协调。

\

\

图 1：随着SOA控制范围的不断成熟，SOA治理的生命周期在不断演变

\

一个组织中可能同时存在不同的SOA项目。一个SOA可能处于比另一个更高的成熟度级别。多个SOA域可以单独发展和治理。一旦成熟，它们就可以和另一个SOA控制范围合并。成熟度级别可能会随着功能、流程或组织单位不同而不同。例如，通过包含供应商的服务和设置服务开发生命周期的标准，采购部门可能表现为网络成熟度级别的特性。同时，HR可能仍在使用自己的来自更低成熟度级别的治理结构。这并不见得是件坏事；隔离的环境可以有单独的治理。

\

另一方面，一个SOA域（以治理术语来讲是控制范围）内的成熟度要在治理流程间保持均匀。例如，服务生命周期的治理应该在策略执行上取得一致，因为成熟度低的执行不可能发生在一个复杂、成熟度高的环境中。

\

那么这又回到了SOA治理的生命周期。在“SOA的愿景”流程中，SOA治理的目的和成熟度目标应该确定清楚。这时组织可以建立一个系统级别的SOA治理委员会，但是标准化也可能按领域架构师在更小规模上存在。这将有助于使SOA治理高效，并适合它的目的。裁减过的治理也更可能高效，系统级别的委员会并不一定需要讨论只和一个控制范围相关的问题。

\

给身处成熟中的SOA治理环境的架构师的指导

\

架构师是组织内SOA努力的重要发起者，而且在其后的过程中也举足轻重，因为他们一般既能很好地全面把握，又能看到实际的内涵，但同时也能从战略愿景出发进行行动。架构师还是IT和业务之间重要的沟通者。由于这种有利位置，架构师会发现自己在企业内处于拥护SOA范式的位置。但是，并非所有架构师都适合所有SOA相关的活动。

\

根据以上的成熟度模型，我们将给架构师提供一些实用的指导方针，好让他们能帮助企业最大化当前成熟度级别的SOA潜力，并帮助他们推进SOA的成熟度级别。鉴于架构师的类型繁多，职责不同，我们将首先给出SOA环境相关的架构师角色的概览。这里，我们将遵照Mike Kavis给出的一份实用的架构师角色[iii]。

\

• 首席架构师连接了这些SOA架构师，并向CxO负责。首席架构师当然要参与定义SOA的愿景，但是也应该指出SOA治理的方向。\
• 企业架构师要使SOA中的业务和IT需求对齐。这类架构师会通过和业务人员交谈来得到需求。企业架构师要重点参与服务组合管理。\
• 解决方案架构师具备实际的技术经验。因为面向服务技术的技术优势，他们可能是SOA的拥护者。\
• 领域架构师具备他们参与的业务领域相关的知识。这种架构师应该拥护原则，并将它们和业务解决方案挂钩。领域架构师是制订标准的优秀候选人，并决定这些标准在什么情况下可以有例外。\

下表显示了在每个成熟度级别架构师可能的关注点。我们补充了架构委员会，它由不同的架构师角色组成，并作为责任主体为组织内的长期架构决策服务。由于我们关心的是治理，因此，这些架构角色的职责和SOA设计期是不同的。

\

下表按成熟度级别显示了这些角色的关注点。

\

\ 角色 \	\ 成熟度级别 \
\ 先驱 \	\ 流程 \	\ 系统 \	\ 网络 \
\ 首席架构师 \	\ 从导航项目吸取教训 \	\ 建立公司的SOA愿景，强调标准的重要性 \	\ 强调服务集成和服务重用的重要性 \	\ 与关系链中的首席架构师一起积极参与 \
\ 企业架构师 \	\ 被告知导航项目的结果 \	\ 确定组合流程，包括服务需求 \	\ 管理服务组合；协调不同领域 \	\ 寻找网络中的服务组合间的集成 \
\ 领域架构师 \	\ 确定导航项目的需求和范围 \	\ 确定领域相关的标准 \	\ 寻找和其他领域集成的好处 \	\ 协调网络伙伴间的领域标准 \
\ 解决方案架构师 \	\ 尝试不同的支持应用和实现方法 \	\ 确立服务生命周期管理的标准、策略执行和服务水平管理 \	\ 协助创建企业范围的服务注册中心 \	\ 更新标准，创建服务共享注册中心 \
\ 架构委员会 \	\ 确定导航项目的后续工作 \	\ 验证并批准标准 \	\ 对重要项目进行决策 \	\ 在协调所有伙伴间SOA中的服务过程中提供支持 \

表 2：不同SOA成熟度级别中的架构师角色的关注点

\

总结

\

在本文中，我们解决了与SOA成熟度相关的治理问题。解决办法是：

\

• SOA治理应该关联到主流程的框架\
• 使用成熟度模型，将其和所有的SOA治理流程联系起来\
• 描述架构师在SOA治理流程中的参与方式\

这些努力中的架构师职责并不是一成不变的。我们对架构师在不同成熟度级别的不同流程中的领导和支持方式给出了一些实用的指导方针。架构师需要解决不同成熟度级别的不同治理问题，因而其要求及必需的素质和技能随成熟度级别的不同而不同。而且，本文给出的指导方针绝非普遍真理。架构师要根据情况随机应变。

\

架构师是SOA项目的优秀发起者，而且他们可以为组织中第一个不断成熟的SOA及其治理担负起责任。然而，出于对SOA解决方案和治理走向成熟的考虑，业务必需发挥主导作用。架构师要和业务与IT代表分享治理委员会的职责。架构师最重要的职责可能是保证业务和IT的对齐，这就要求特殊的沟通和协调能力。一旦业务和架构师有了很好的理解和共识，并通过治理使其正式确定下来，SOA就能长久的发挥作用，实现对企业的业务承诺。

\

如果您需要这一主题的更多信息，请随时联系我们：tschepers@deloitte.nl 和 bkratz@deloitte.nl.

\

参考文献

\ [i]\\