面向服务架构（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如今必须处理这个问题：到底把多大权力交给业务分析人员及其上司，还要考虑治理领域的范围和界限；每个领域里面谁有权施加影响、提供咨询，以及最后作出治理方面的最终决策。

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

　　成本分摊

　　分布式经营单位和部门在IT服务使用方面必须具有成本效益。与此同时，IT服务要物有所值–把两者结合起来是个挑战。这时候，成本分摊（chargeback）可以派上用场。

　　IT服务的成本分摊用来通过收回成本来修改使用IT服务的行为。它向用户表明了他们所用IT服务的成本。不过，这也会导致围绕成本分摊如何计算的争论、部门之间的紧张局势，还会衍变成围绕从别处购买IT服务成本更低的争论。

　　成本分摊只是企业用来在IT服务使用方面获得所需行为的工具之一。要让成本分摊发挥成效，就要从IT治理环境来看待它。

　　若想实施成本分摊体系，就需要分成三个步骤：第一步是确认IT服务成本；第二步是成本分摊；第三步是成本收回。服务成本的确认非常复杂，本文不加讨论。

　　分摊标准

　　成本分摊主题很复杂，搞好这项工作的过程通常是个反复的过程。成本分摊决策的标准包括但不仅限于：

　　原因和结果――按提供的服务来分摊相应成本。
　　得到的效益――按得到的效益来分摊相应成本。
　　承担能力――按成本目标的承担能力来分摊成本。

　　另外，如何分摊成本还取决于以下这些因素：

　　你是否想对服务使用进行惩罚（收费）或者奖励（付费）？
　　你的系统是不是在满负荷运作？
　　你的系统采用什么样的架构？
　　贵公司SOA的投资规模（很小、中等、很大、超大）是多少？

　　成本分摊是CIO和财务首席官（CFO）需要共同来制订策略的另一个方面。

　　行为问题

　　分摊策略本质上是个行为问题。如果有了分摊策略、管理及收取的成本数额，经理们的行为会帮助公司实现利润最大化（成本最小化）吗？经理们会觉得成本分摊体系公平、合理吗？

　　因为这个基本问题是行为方面的，所以没有放之四海皆准的解决方案。每家公司要制订出适合本公司经理们的解决方案。不过，有一些指导原则有助于解决这个困难方面。

　　如果根据实际使用量分摊固定成本，一个部门使用量方面的变化会影响分摊给另一个部门的固定成本。当实际使用量是分摊基础时，那么使用部门直到预算年度结束才会知道分摊给自己的成本。另一方面，当预算使用量是分摊基础时，那么使用部门事先就能知道分摊给自己的成本。这样有助于使用部门进行短期和长期规划。

　　利用预算使用量来分摊固定成本的主要理由与长远规划有关。公司使用长期规划远景（planning horizon）来作出已承担成本（如服务部门的固定成本）方面的决策。利用预算使用量来分摊这种固定成本与这种长期远景相一致。

　　如果固定成本基于长期承诺或者规划来分摊，有些经理忍不住会低估规划使用量。这样一来，他们就会承担总成本中比例较小的部分。高层管理人员可以通过对实际使用量和规划使用量进行系统比较，遏制这种倾向。

　　有些公司可能会有明确的回报，具体表现为对准确预测的经理进行加薪和提拨。另外，有些成本分摊方法包含了对预算使用量预测不正确的惩罚机制。举例说，如果某部门超出了预算使用量，可能要支付比较高的可变费率。

　　最后，要成功采用SOA，基层员工的行为也要考虑在内。对IT治理流程进行数字化处理时，使用方便和直观的界面必不可少。不过，软件也要有"强制实施的有效手段"。比如说，要是任务没有在分配的时间内完成，拥有自动上报问题及通知上司等功能的执行机制就开始发挥功效。这种"软硬兼施"的方法可以促使员工们带来可取的行为。
成本收回和SLA

　　IT部门是向整个公司的客户（即市场）推销产品和服务的部门。在这种环境下，成本分摊只是针对产品和服务的价格而已。成本收回（如上所述，成本分摊方法的第三步）实际上在预算之间移动资金。这必然会引起关注利润的各经营单位经理们的注意。

　　为了改用成本收回，你需要在合规办公室下面设立成本分摊委员会，要有各经营单位的代表，并由CFO担任负责人。这个委员会负责设立及运作成本分摊机制。CIO也要参与这个委员会，不过仅仅扮演顾问的角色。

　　服务级别协议（SLA）和绩效协议是有效管理IT服务和良好客户关系的关键。好的SLA能够权衡客户需求和IT部门的功能、权衡客户预期目标和IT部门的投入。

　　协作

　　CIO和CFO之间的有效协作是决定基于SOA的应用项目成败与否的一个重要因素。CFO需要为分摊开发、运作及维护SOA应用所有的成本制订策略，以便给整个公司带来最大效益。

　　同时，CIO、首席技术官（CTO）必须创建及管理一个生态系统，其中SOA的短期和长期成本都实现最小化。这项任务的一个重要部分就是精心挑选使用SOA开发哪些应用，然后选择完成这项任务的架构。这时候，项目组合管理（Project Portfolio Management，PPM）可以派上用场。

　　虽然采用SOA给IT带来的效益本身就常常能收回项目成本，但需要公之于众的更重要的度量标准是给业务带来的效益。你必须与业务部门一起重视基于SOA的项目，正如你总是重视IT资产组合管理那样。

　　特别重要的是，任何新的IT治理必须能够适应公司文化，以缓解从旧系统迁出去的工作。几乎每个公司自然都会出现反对变化的现象，而许多员工会找借口避免使用让他们觉得不舒服的技术。