摘要
在“成功规划SOA”系列文章的第一篇文章：SUCcessfully Planning for SOA（中文版，dev2dev，2005年12月）中，我讨论了什么是面向服务的架构（Service-Oriented Architecture，SOA），以及如何确保它为您的业务交付价值。我非凡关注了域模型的业务策略与流程、架构以及成本和收益等方面。第二篇文章讨论了如何创建有效的SOA路线图。在这最后一篇文章中，我将介绍域模型的其余3个方面：构件块(Building Blocks)、项目和应用程序(PRojects and applications)，以及组织和治理(Organization and Governance)，并将重点放在如何把它们集成到长期项目规划中去。
进行长期SOA规划
如图1所示，BEA SOA域模型是一个强大的工具，有助于指导客户实施SOA规划战略。图中重点显示的6个主要部分应给予同等重视，以确保实现成功。
图1. BEA域模型
本系列前面的文章考察了开始3个部分——业务策略与流程(Business Strategy and Process)、架构(Architecture)以及成本和收益(Cost and Benefits)。然而，实现开始后，对SOA的规划并没有终止，而是继续贯穿于SOA项目的每个阶段。
当进入迭代和增量阶段后，域模型的最后3个部分对于确保动态评估以及项目的灵活性都相当有用。对正在进行的项目进行有效评估可以使您在发现没有成功地交付业务价值时马上进行纠正。本文的其余部分将更具体地分析其中每个部分，并说明它们对于SOA长期规划的作用。
构件块：利用(并重用)资产
SOA依靠于成功地将重用制度化。SOA的构建块是分散、可重用的服务和架构元素，可以用于构成复合的应用程序和服务基础架构。每个构建块在实现之后就会被添加到SOA功能的总体目录中。随着该目录的增长，对于未来要开发的项目来说，需要开发的新代码和服务基础架构就将减少，维护成本降低，而且ROI也肯定会稳步增加。
明确地定义一个服务，并能够以一种一致和可重复的方式将其交付到实际部署中，这就是SOA项目成功的要害所在。服务最好通过3个元素来定义：
服务实现：服务的实现由实际代码、应用程序接口或包含（将通过此服务公开的）功能的其他技术资产组成。
服务接口：服务接口为服务的用户提供一种基于标准的方法，用于根据它所提供的契约来访问其功能。
服务契约：服务契约指定服务的目的、功能、约束和使用。契约细节的例子包括安全性需求、响应速度、吞吐量和可用性。
服务可以从现有应用程序公开，也可以从新开始构建，但是应该首先实现哪个服务呢？处于企业核心的简单服务是最佳选择，可以从对业务单元最不可知的服务开始，然后逐渐转向更加特定于业务单元的服务。这种方法答应团队习惯于在不过分关注复杂性的情况下构建和重用服务。类似地，应该从技术上较轻易的服务开始，然后一步一步转向技术上的难点。最早构建的服务中有一些是基础架构服务，比如日志记录、审计、错误处理以及类似功能。
项目和应用程序：实现SOA路线图
服务路线图是从识别企业中已有的IT项目和功能开始的。接下来，企业需要开发使架构完整的项目以及交付业务价值的单个项目，并按照重要性对这些项目进行排序。
一开始，需要了解现有应用程序和项目的情况，以便确定可以在哪里重用现有功能。对于那些完全特定于其所在的应用程序或为其开发的项目的功能，此时就完全可以不用考虑。
一定要知道以下内容：
当前应用程序的功能、服务和依靠性
现有服务的粒度和功能
当前应用程序与已列入规划或正在进行的项目之间的相互依靠性，以及相关的开发和维护问题。
当前公共服务的使用情况
与应用程序开发相关的成本和其他指标
应用程序访问和提供的信息
应用程序中使用的数据模型、转换和变换
应用程序中涉及到的工作流和流程流
对如下服务的使用情况：单点登录、日志记录、错误和异常处理、监控以及通知。
服务水平协议、服务质量，以及相关的非功能性业务信息
当前交付的里程碑和即时项目时间帧的细节
这些数据将帮助您了解当前的项目和应用程序，并帮助识别通用功能。
组织和治理：设置异常
SOA要求在人员的协作方式方面有所变化。有必要在IT部门之间建立更紧密的协作，因为这样能够推动全体人员都重视交付业务价值，而不是只在单个功能性部门中。
要想在此领域中获得成功，有两个方面是必不可少的。首先，必须提供足够的培训，以便让团队不仅能够了解SOA的技术方面，还能了解它所需要的文化变化。没有提供这些要害消息的企业将很难继续进行下去。
其次是组织和治理，要将SOA的采用当作是一个企业改变的计划，而不仅仅是最新的技术方向。从高级治理人员获取并保持支持将有助于企业的各个部门进行无缝协作，并确保您具有足够的权限来获得服从。
不同企业进行组织和治理的方式各不相同，这取决于企业的成熟度和发展方向。对于最初的SOA实现来说，自顶向下的集中式治理是最有效的，接下来是联邦或部分联邦的治理，最后是一个自治程度更高的层次系统。这种结构便于整体而有效地查看结构、资金、操作流程和工具、标准、技能变化治理以及指导原则。它还有助于根据以下（以及其他）SOA常见问题来决定、制定和改进流程：
谁定义和修改系统？
谁可以访问服务？
必须提供什么样的服务质量？
谁将为服务的构建买单？
谁将为服务基础架构买单？
所治理服务的相互依靠性？
如何向外部公开服务？
如何衡量SOA是否成功？
