面向服务架构（SOA）已被作为一种通过对齐IT和业务来促进业务机动性的方法被广泛接受。这种方法的主要不同之处在于，用相对较低的成本就能轻易 地获得某种机动性。在较高的层次，该方法试图将第n次业务变更所产生的增量成本降低到零或接近于零。组织推行SOA项目目的就是为了在他们的SOA之旅当 中尽早达到这个难以捉摸的第n个迭代。在实践中，要达到这种最佳状态的时间可能得花数年，甚至更长时间。本文正是为那些参与SOA项目的业务分析师、企业/系统架构师而写的。

　　服务识别是迈向SOA终点漫长旅程的关键第一步。它是一个迭代步骤，需要在分析和规划阶段就要尽早地组织和发起。该步骤决定了整体的服务蓝图，蓝图 中包含了被识别的服务，它们的名字、分类、优先级，甚至还对相关的实现过程进行了恰当的路线图阶段划分。服务识别阶段奠定了基于服务的生态环境的基础，本文则指出了业务服务识别相关的最佳实践。

　　1）了解项目的性质

　　根据所处环境，SOA项目可以分为以下类别：

　　SOA转型：这是指企业所开展的那些将现有项目向SOA转型的项目。几乎所有应用是功能成熟的，虽然不适于快速变更。在这种状态下的企业通常面临的是对于变更的刚性阻抗。此处的重点在于，在解决服务空白的同时从遗留应用和商业成品软件（COTS）中暴露和（或）重新设计服务。

　　SOA采纳：这是指那些已经拥有服务于关键业务流程的应用的企业所实施的项目，尽管新应用的范围是支持某个其他已经存在的核心业务功能。这里的重点是，开发新的应用和服务，同时逐步重新调整现有应用。

　　SOA启程：这适用于基于服务的产品开发，以及那些拥有需要再造的分离系统的企业。这里的重点是从零开始审视功能和开发服务。通常会采用契约优先的方式。这种企业处于一个相对不错的位置，可以实现长期的回报。

　　图2：本图显示了四种假想但关联的变更随时间推移的关联ROI。在SOA转型（i）分类下的企业利用功能成熟度可以快速、极早的获 益，但随着时间的推移回报相对平缓。相反，在SOA启程（iii）分类下的企业，从长期来看，借助可预期而且更快推向市场的时间的潜力和更低的集成成本， 可以获得快速上升的回报。

　　确定分类将有助于确定重点和期望值，同时也有助于明确服务识别方法。

　　2）业务牵头

　　在全球经济低迷的背景下，展示切实、快速的投资回报率（ROI）的需求在升高。在竞争日益激烈的环境中，业务团队和IT团队应当紧密合作，借助彼此能力迅速支持激烈、非常规的业务举措。需要一再强调服务的识别，这在很大程度上是一个业务引导、IT跟进的步骤。

　　3）跟企业远景和相关驱动力一致

　　来自战略、远景和长期业务目标/目的的投入对于建立一个强大、可适应变化的基础至关重要。这些投入在SOA线路图及相关阶段中得到了体现。它通过注 入面向未来的服务蓝图抽象层，以及延长服务契约的使用寿命来影响服务的识别(如，专门从事信贷产品的金融企业可能有意尝试保险和经纪业务，这可能会要在蓝 图中加入一些产品无关的服务)。

　　4）关注端到端的业务流程

　　这些是形成流程蓝图主体的主要流程，包含了核心和非核心功能。这些流程通常可以在不同的抽象层次来描述，这种层次在流程模型中被称为流程层次。这 时，可以采用自顶向下的方法，将服务从多重这样的层次中抽取出来。高抽象层产生组合服务，低层次产生细粒度的服务候选。如此关注流程和服务候选将有助于识 别整个企业的功能冗余。不管是否考虑SOA项目的性质(上文已经指出)，这个实践很重要。

　　5）利用工具加速识别

　　SOA规划和治理工具可以简化和加速服务识别和沟通的过程。它们甚至能把服务之间的关系可视地描述出来。服务仓库相关的工具还有助于识别服务变更的提议所带来的影响。

　　6）重用行业制品

　　多年来，在垂直行业中，诸如电信、公共事业等，拜相关组织（IFX，SWIFT，OAGi，Accord，ETIS，ISO等）所赐，SOA领域有 了长足的发展。少量的跨行业制品也可以找到。可以看看并利用这些标准化的服务契约（接口和操作）、数据模型和第三方服务的列表。这会让你大力推进迈向 SOA的行动，因为大部分这些制品（基于XML）很可能是可扩展和向后兼容的。

　　然而，这些制品在使用前必须经过周密的调查研究。例如，当采用这些标准的时候，企业可能需要询问这样几个问题：该数据模型是部分采用还是全部采用? 是否有必要对规范模型提供本地支持，或者是只要限制它与外部集成的接触点就够了?是否还有什么潜在成本?它有没有得到厂商广泛的支持?

　　7）建立契约基线

　　服务契约应该同时强调功能和非功能的能力。基线需要被建立起来，可以通过识别作为契约一部分的相关属性来完成。功能属性可能包括诸如服务描述、消息 结构和数据模型这样的细节。非功能属性可能包括诸如服务质量(如响应时间，可用性)，成本构成（数量或周期）和安全性这样的细节。这样的基线标准化了WSDL文件、XML模式和WS-Policy定义（加强行为约束的元数据）的内容，保证了整个企业中契约的一致性。

　　8）完善服务属性等级矩阵（ARMS）

　　只扩展流程和业务目标等来识别巨大的候选服务列表及相应契约相当自然。这些服务在帮助机动性方面可以做得跟它的来源一样好，而且可能会导致服务扩 增。包含服务属性(如重用性、组合性、抽象性、竞争力差异等)的矩阵和它们的相对加权平均可以用于显示、评级和完善候选清单。要想获得成功，这个等级不应 该比根据分类、线路图阶段等预先确定的目标等级低。可以修改粒度，以及反复修改契约以满足需求矩阵。

　　9）使用业务机动性场景仿真（BASS）进行测试

　　在实现之前，这是评估系统灵活性的非常轻松的一步。来自路线图后续阶段的业务场景和用例或是不符合当前阶段的典型业务场景需要被编撰出来。接着，通过仿真，使用包含契约的服务目录来说明这些场景，同时评估对系统的影响。评估的关键指标包括：

　　i）服务重用率（重用的服务数/场景中的服务总数）

　　ii）服务使用率（重用的服务数/目录中的服务总数）

　　iii）服务修订率（修订的服务数/重用的服务数）

　　iv）服务创建率（新建的服务数/场景中的服务总数）

　　v）服务利用率（针对某服务，已识别的服务消费者数/场景中的服务总数）

　　这些IT指标规范了复杂度，同时具有联合评估对推向市场时间的影响的特性。这会进一步调整和影响服务列表。已经经过路线图初始阶段的企业可以在BASS中包含历史数据，以产生更好的业务和财务指标。

　　10）拥抱变更

　　以服务为基础的系统，其特点是可以同时接受计划中的和计划外的变更。服务清单是一个关键的驱动力，同时提供一个跟SOA治理流程配合良好的、迭代的 SOA识别过程也很关键。这个迭代会与路线图的各个阶段、持续改进项目或来自内外部触发条件（如降低服务开销的的技术进步可能会允许添加新的细粒度服务）的结果对齐。这些变更可能会导致服务创建、服务修订和服务退役。

　　总结：

　　组合应用由服务清单中的服务装配而来，促进了业务机动性。服务识别产生了这个业务和技术服务的列表。识别服务集合相对容易，但是，ROI则受SOA项目性质、变更频率和变更大小影响。本文指出了在实现之前识别、验证和核实服务清单内容的关键最佳实践。