需求中心的任务是为业务部门提供业务与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