面向服务架构（Service-Oriented Arthitecture，SOA）提供了一种方法，可以把企业的业务战略和必要项目与IT项目结合起来。因而，SOA治理不但涉及技术，同样涉及组织问题以及人员如何协同工作来实现业务目标。

IT治理涉及获得进行变更的批准，涉及权力，涉及谁拥有这种决策权，涉及在业务迅速变化的形势下这类决策需要多长时间。SOA通过减少决策的发生，从而大大减少了IT治理的需要。不过，为了获得这种好处，贵企业必须首先采用SOA。

SOA的演进

采用SOA并不能让你迅速获得投资回报，反而需要战略性投资，包括在结合IT和业务的治理和文化变化方面进的投入。不过据Gartner公司的分析，这不是SOA会不会取代如今架构的问题，而是完成这种演进需要多长时间的问题。

想要采用SOA的许多公司面临的一大绊脚石，那就是目前的IT成本分摊模式。许多公司把项目开发和支持的成本与批准项目的业务部门一一对应起来。在SOA中，服务常常在多个应用和业务部门之间共享，这就意味着你可以就参与SOA战略的某个项目向以后使用服务的每个人收费。

一种比较好的方法是为SOA应用资产设计共享分摊结构，甚至抵消可能高于采用非SOA方式的独立开发所需成本的SOA开发成本。因为只有服务被多方使用后，才能够得到重复使用的好处，所以要有激励措施确保来发布及设计可重复使用的服务。同样，也要有激励措施来促进充分利用现有的企业服务。如果你正在实施外包项目，对于应当加以的积极管理，特别难以实现。

公司在与负责实施的合作伙伴打交道时，似乎更容易忽视治理和执行方面的工作。举例说，常常由IT部门外的个别业务部门决定把某些项目外包出来。即使在IT部门里面，针对批准厂商列表和采购的重点往往与内部治理流程和决策机制相脱节。

IT治理和SOA采用

SOA面临的挑战之一就是实施不是一蹴而就的，而是要通过跨越空间和时间的多个不同项目才能实施完毕。SOA项目的这种空间和时间分布使得治理对SOA的成功而言更加至关重要。SOA治理和可执行的策略是确保跨地域和跨时域，这也符合SOA的两大关键。

空间分布、数量激增的服务（需要由企业内外的不同部门来维护）以及时间分布（随着支持的业务流程不断变化，服务本身或者服务组合随之不断变化），这一切使得治理特别具有挑战性。从很大程度上来说，只有服务符合服务级别协议（Service Level Agrement，SLA）在安全、可靠性、性能和成本等方面规定的要求，跨组织边界分布的这些服务才能够正常、有效地使用。只有设立合规办公室，对整个企业进行监管，并且由业务分析人员和软件开发人员等代表组成，才能最有效地进行识别、指定、创建，然后部署企业级服务，从而实现SOA治理。

人们很容易纠缠于实施SOA方案的技术细节。幸好，SOA治理使得业务和技术之间合作的重要性重新受到关注。到最后，重要的不是技术，而是客户是否采用。如果最终用户认为自己能因而创造经济效益，才会采用及使用基于SOA的应用。

传统和联合的治理方案

过去有两种IT治理方案：集中式和分散式。

至于前者，IT部门对开发预算及技术标准的采用保留控制权。业务和IT部门之间的这种关系有时很紧张。业务部门需要迅速实施新战略的敏捷性，于是把需求交给IT部门；不但实施所需的功能似乎需要很长时间，许多信息也常常会在需求文档到可执行系统之间的转变过程中丢失。至于后者，预算和技术事务方面的一定权力交给经营单位，甚至交给这些单位下面的单个部门。由于相对缺乏集中监管，这批独立用户最终开发出来的系统从长远来看协同工作的效果很可能不是特别好。

由于只有这两种IT治理方案，IT部门只好面临这种取舍：要么现在牺牲响应时间，让权力集中在中央的IT部门，要么之后面临失去控制的分散环境带来的后果。

不过，SOA有望采取中间路线。这是一种基于标准和服务的方案：注册中心（repository）和平台作为系统核心，而服务使用方进行的建模和应用开发为业务分析人员及其他分布的战术用户给予了很大的自由度。战术使用和战略监管的这种分离也为在特定情况下实行治理带来了机会。在这种联合架构中，SOA把IT方面与业务方面分离开来，为各自提供了一直寻求的东西。企业首次能够获得统一IT架构带来的优点，同时又能在IT方面获得新的灵活性，足以满足业务要求。

SOA的一条根本原则就是业务逻辑与应用逻辑相分离。业务分析人员得到了这种能力：定义、变更及修改SOA服务支持的业务流程。IT部门的责任同样明确：它必须管理从应用逻辑直到物理基础设施的整个部分。IT要负责SOA的底层平台，即注册中心。

这并不是说IT和业务以后根本不再协商；而是通过为业务部门提供使用关键业务流程、利用现有企业服务组建应用的敏捷性，从而减弱对接口的需要，并且减少相关问题。

业务部门获得了这种能力：进行战略性变化，又不危及应用生态系统，无须通过IT部门对整体式应用（monolithic application）进行重大改动，再次让每方各取所需。

当然，这种联合架构自身也带来组织难题。除了由传统的治理委员会监管服务和平台的完整性外，公司和CIO如今必须处理这个问题：到底把多大权力交给业务分析人员及其上司，还要考虑治理领域的范围和界限；每个领域里面谁有权施加影响、提供咨询，以及最后作出治理方面的最终决策。

仍必须进行取舍，不过这回是在灵活性和组织复杂性之间进行取舍。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号