SOA治理的基石：服务需求与供应

 

    在过去一年里，越来越多的企业开始或考虑实现SOA，这为SOA的发展带来极大的推动力。通过对一些案例的研究，我们发现,SOA面临的关键问题是如何设 计一个有效的治理机制。要成功地实现并管理SOA，必须对治理概念有清楚地认识。可靠的SOA治理可以引领企业获得多方面的提升，最终通过SOA实现业务 敏捷性。

    IT治理协会（IT Governance Institute）把IT治理定义为：“一个关系与过程组成的企业管理架构，它通过IT与流程增加收益、平衡风险，最终完成企业目标。”Peter Weill则这样描述IT治理：“清晰地描述如何制定正确的决策和工作内容，从而利用IT实现预期行为的框架。”

    IT治理的目标是协助企业利用IT取得业务目标，而治理实质上是一种架构、功能和责任，负责提高IT服务的效益和效率。可以帮助企业成功实现业务目标的治 理机制通常是简单而透明的。高层治理执行人员有50%可以清楚地解释治理，而底层只有不到30%的执行人员可以做到这一点。

    SOA治理场景与难题

    当今的IT机构都由一个核心IT部门控制着。这个IT部门几乎承担着全部的治理责任。然而，许多企业业务部门都建立了内部IT部门，与核心IT部门协调工 作来满足特定的需求。内部和核心IT部门在分工与职责上的分歧很容易出现，因为大多数应用都是某个控制着设计、开发和支持特定应用预算的业务部门所“拥有 ”。这正是面向服务架构（SOA）的出发点：多个业务部门“拥有”并“使用”相同的服务系统。这意味着对服务的需求来自多个业务部门，因此，设计、开发和 对特定应用支持的预算需要多个业务部门共同分摊。这种情况下，需要核心IT部门实现服务而不是靠业务部内部的IT部门，而且核心IT部门将与多个业务部门 一起制定服务等级协议（SLA）以提供相似的服务。

    以下是一些在采用SOA的大型企业中常发生的典型场景：

    * 一家大型银行的IT功能已经拥有成熟的SOA架构技术，准备着手进行下一步骤。现在银行面临的问题是：如何让业务部门同意向SOA转型？在SOA进入稳定状态时应该应用怎样的治理机制？

    * 一家医疗保险机构利用SOA进行一个全企业范围的旧资产改造项目，并在IT部门和业务部门之间引入了新的机构来管理服务。

    * 另一家大型银行的SOA转型过程中，由一个业务部门的高级主管负责引领这次转型，这为SOA的启动带来了预算资金。

    现在的SOA治理比传统的共享式IT应用服务更集中化，因此需要对既有治理模式做出细微的调整以满足在SOA环境下的需求。下面是在设计可行的SOA方案时可能遇到的典型问题。

    单独管理问题

    在核心IT部门与业务部门之间引入新的机构单独代理，建立由来自业务部门和核心IT部门的代表组成的SOA治理委员会。

    多业主的管理问题

    建立服务与业务流程/项目/成本和利润中心的对应关系，合理分布投资与操作成本。根据使用分配资金表面看来是个不错的方法，但是它适用于信任度高的环境 下，在企业范围内实施可能很困难。SOA治理委员会可以根据预定的成本分配原则决定投资与操作成本。SOA治理委员会每年或每半年一次议定功能改善或新开 发的优先级。

    使SOA与企业IT架构保持一致的问题

    SOA必须与企业IT架构规则保持一致，这一点由SOA管理机构或SOA治理委员会中的企业架构部门代表决定。该代表团队还要设定IT规则、实现并维持 SOA设施/开发/维护、管理销售商并保证服务质量（QoS）。对于这种一致性，最重要的是合理地部署IT设施，比如策略注册、策略储存库和策略管理设 施。

    难以支付维持治理机制所需昂贵费用的小型企业面临的问题

    业务部门的管理人员定期召开会议决定治理机制的管理方和资金，而IT管理层负责每日操作。

    决定一个企业所要建立的SOA治理模式的指导方针主要有两个：需求与供应（提供企业范围的、共享的标准服务），这是基于INDIGO（IT企业治理信息系统设计）研究项目得出的结论。

    需求中心与供应中心是SOA治理的基石

    INDIGO中的主要内容之一就是由需求中心与供应中心分别负责提供服务的各种责任。把IT部门分为供应中心与需求中心的理由是，这样能够提高服务部门的责任感，可以利用规模与范围经济实现服务，并清晰地划分责任与分工（见图1）。

    

图1

    需求中心的任务是为业务部门提供业务与IT一致性相关的建议。需求中心的分析师能够理解业务语言，进而使SOA与业务用户靠得更近。通常，分析师是来自业 务部门（被业务用户视为“自己人”），他们对IT方面也有很深了解。需求中心主要从业务案例驱动的角度考虑如何提高业务流程的效益与效率。一旦需求中心确 认业务用户所需的服务，就可以把需求信息送达供应中心以实现服务。

    供应中心的目的是花费最少的成本按时提供高质量的一流服务。供应中心有优秀的SOA设施用以为业务用户提供服务。这些SOA设施可以是企业内部的，也可以 是由一流IT服务供应商提供的外部资源。事实上，最近右者的情况渐呈增多的趋势。供应中心不必与需求中心处于同一位置，可以根据情况合理分布以实现最大竞 争力。供应中心对业务用户负责，并受服务等级协议制约。

    供应中心通常即是当前的核心IT部门，由企业CIO领导。供应中心负责实现新的SOA服务、对当前的系统提供支持，并操作SOA基础设施。一般来讲，供应中心需要有三个部门分别完成：

    * 建立企业范围的SOA设施标准，提供相关的基础设施服务

    * 与需求中心协作管理SOA服务的设计与实现团队

    * 进行供应商评估、SLA管理、质量管理，并控制内部活动以保证服务开发的顺利进行。

    INDIGO提出两种实现SOA的治理模式：“嵌入式”需求中心和“浮动式”需求中心，如图2与图3所示。

    

图2

    图3

　 　在“嵌入式”需求中心模式中，需求中心与供应中心的分工、责任和间接责任都有明确的划分。然而，实现这种结构可能需要相当长的时间，因为当今企业大都有 一个强有力的核心IT机构和几个强有力的业务部门，各业务部门又都有自己的IT机构。我认为，对于那些业务部门自身对IT系统有很深的了解和认识，并掌握 相关技术的企业来说，“嵌入式”需求中心可能更为合适。
　　
　　而在“浮动式”需求中心模式下，虽然供应中心有明确的任务和责任，但需求 中心却是一个独立的实体，由业务部门和供应中心同时掌管。这种模式比较容易实现，因为其相对传统的集中式IT企业架构来说并没有太大的转变。虽然这种模式 很容易实现，并且需求中心的任务与职责也容易明白，但由于其中存在着向业务部门和供应中心的双向报告模式，使得报告关系不很明确。因此，这种“浮动式”模 式更适合从传统模式向“嵌入式”模式的过程中作为过渡模式使用。

    不论企业选用哪种模式，都应该清楚地明白供应中心与需求中心在SOA各阶段的任务与责任，这一点是非常重要的。

    SOA实现与操作中的责任

    SOA治理的目标是确定业务用户所需的服务并完美地提供这些服务。需求中心与供应中心在实现SOA中的任务与职责时也在时时提醒SOA治理的双重目标。图4列出SOA实现与操作中的任务与职责。任务与职责的对应关系是以INDIGO为前提的：

    * 业务部门与需求中心负责IT在业务流程中的应用。
    * 业务部门在需求中心里要有信得过的、了解业务部门想法并把业务需求转换为服务的人。
    * 供应中心可以利用由各个业务部门的服务需求汇集的规模经济。
    * 供应中心可以集中精力按时实现高效益、高质量的服务。

    

图4

    实现SOA

    实现SOA的战略决策是由CXO们根据业务与IT的一致性、业务流程管理（BPM）活动和为SOA建立企业标准的供应中心而做出。 INSOAP（Infosys Service Oriented Analysis/ Adoption Process）是一个设计和实现SOA以取得更好的业务与IT一致性的过程。通常，实现SOA的决策应该是阶段性实行的。在实现SOA的过程中，基于 INSOAP的重要阶段有：

    * 当前与目标业务流程建模
    * 流程到应用的对应和评估
    * 服务确认
    * 服务定义与建模
    * 服务实现
    * SOA托管
    * 项目管理
    * 治理

    图5描述了根据INDIGO实现SOA的主要过程。其中一个早期步骤是需求中心对当前业务架构进行描绘，并做出过程/应用到服务的对应。同时，供应中心负 责描绘出当前的技术架构与应用资源元数据。然后，供应与需求中心共同根据服务确认和对应过程为业务部门确定目标架构和SOA方案的蓝图。这个蓝图是供应中 心与需求中心对服务的粒度、分类及组合服务、服务合并与合理化进行定义的依据。在需求中心进行服务契约与服务数据建模工作的同时，供应中心也同时进行服务 实现和托管工作。项目管理、风险的评估与减轻、业务持续性规划、服务治理和管理都由需求中心和供应中心共同进行。

    

图5

    使用INSOAP实现SOA的一个重要方面是服务确认和对应的过程，如图6所示。需求中心提供与业务流程相关的用例。供应中心使用这些用例及与业务流程相 关的应用和数据库确定需要提供的细粒度的组合服务。这是一种自上而下的业务流程到服务的对应方式。如果企业中有旧应用，供应中心还要对这些应用进行自下而 上的服务挖掘。然后，需求与供应中心把从这两种方式中得到的服务组织成业务部门所需的一系列服务。这是服务合并与合理化的基本。供应中心根据合理化作业的 结果开发并实现业务部门所需的服务。供应中心根据业务驱动建模、痛点、和按照需求中心提供的数据做出的效益分析接受服务合理化决定。已实现服务和非功能性 需求问题造成的业务影响由需求和供应中心共同完成。合理化作业的结果也是供应中心决定购买、开发服务或是处理过期应用的依据。一旦服务启动，不管是在企业 内或通过第三方，SOA操作和支持业务用户的治理机制必须及时到位。

    

图6

    操作SOA

    根据INDIGO，操作SOA的主要过程是支持用户使用服务、SLA和QoS管理，如图7所示。关于SOA支持方面，供应中心应该负责建立技术和功能性用 户指南。在传统的IT应用中，通常企业会依照ITIL服务质量标准（IT Infrastructure Library）管理用户指南和相关支持性操作。SOA环境下也可以使用类似的标准。

    

图7

    技术性指南和支持由供应中心负责，而功能性指南和支持则由需求中心负责。通常企业会建立三到四层的支持。第一层主要解决简单问题，第二和第三层由稍专业的 支持团队解决稍复杂的问题，第四层负责SOA设施和改善服务性能相关的问题。进行技术性与功能性指南和支持时应该利用工作流工具和数据库系统以帮助分类、 分析和记录持续恶化的问题。

    SLA和QoS管理是保证业务部门的服务用户对服务满意的关键。需求中心与供应中心共同负责提供新服务的规划过程。他们还要负责建立管理包括金融方面、可 用性/持续性、QoS、偶然事件分析和安全问题等服务等级协议的过程。如果服务由第三方团队提供，供应中心也要建立供应商评估流程，根据服务等级协议保证 服务质量。供应中心还要负责发布能让需求中心满意的配置、变更和版本管理过程。这里要注意的是，可能要结合策略储存库、注册和策略管理设施来管理SOA策 略。传统IT企业则是使用BS1500与ITIL标准进行SLA与QoS管理的。

    确定任务并平衡期望值

    需求与供应中心的重组工作可能会很棘手，因为业务部门与核心IT部门的高级管理人员通常对此有不同的观点。业务部门希望IT部门能给他们带来效益，而IT 部门则在想法减少服务的成本。企业应该为需求与供应中心建立清晰的业务计划书，使其有明确的目标。在尝试重组及SOA转型之前应该准备详细的任务与职责规 划并充分沟通。对大型企业来说，这种转型通常需要12个月以上。

    预期的新职位

    预计需求与供应中心将出现以下重要的管理职位：

    * 总经理，业务服务部门（需求中心），跨越业务流程与IT两个领域在BPM与服务概念化方面的项目上起带头作用，负责业务部门和供应中心的高级管理工作。
    * 经理，业务服务部门（需求中心），负责流程与服务的对应、服务建模、用户评估和功能性指南， 以及供应中心中类似的工作。
    * 总经理，服务架构部门（供应中心），负责建立SOA、服务概念化、服务资源评估和合理化的企业标准，维护服务注册，以及需求中心相似的工作。
    * 服务实现经理（供应中心），负责实现和构建/购买/重用服务相关的决策，实现服务、确定成功实现的关键业务指标（KPI）等项目管理，并处理需求中心中类似的事务。
    * 业务经理（供应中心）负责技术指南操作、SLA管理和QoS，以及需求中心的类似事务。

    平衡点

    对于小型企业来说，在每个业务部门设立需求中心可能是一种过于昂贵的做法，并且有时这种做法还会降低某些业务部门的效率。这种情况下可以使用浮动式需求中心模式。

    在某些情况下，需求中心可能会代业务部门做出一些硬性决定，从而削弱供应中心的作用。这样的需求中心可能会想越过供应中心，直接到供应商处购买服务。因 此，供应中心不但要有能力证明他们才是最佳的服务供应商，还要获得企业高级执行官的支持。供应中心经常会对服务转换所需的费用及需求中心计算转换费用的机 制提出疑问。因此，服务的转换费用计算应该是透明的，并且在不同业务部门之间的费用分配应该公平合理。

    把IT部门划分为供应中心与需求中心能够增强业务部门的责任感，利用规模与范围经济实现服务并清晰地描述出在SOA环境下治理的任务与责任。向需求中心和供应中心的转型是一件需要精心管理的工作，要时刻谨记治理原则，以及任务与职责的分离。