使用生命周期增强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成熟度级别的“健康指标”。

    表 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治理应该关联到主流程的框架

    使用成熟度模型，将其和所有的SOA治理流程联系起来

    描述架构师在SOA治理流程中的参与方式

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

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