确定业务流程

    SOA的一个核心原则是业务和IT保持一致以及建立竞技场(playing field)。通过识别企业通过服务定位提供价值的业务流程，服务工程团队(通常是业务、分析师和IT人员的组合)可能在讨论的出发点方面达成一致。

    许多企业发觉很难理解从何处开始SOA以及哪些是最合适的业务流程。一种好的方法是首先在白板上定义需求目录。将白板划分为3条泳道，分别代表短期需求(3到6个月——通常本质上更有战术性)，中期需求(6到18个月)和长期需求(超过18个月——通常为战略需求，可能随业务需求的变化而变化)。划分泳道之后，开始为每个区域添加需求。尽量避免按应用系统(如，电子商务网站)思考;看得越远，越有可能达到您要求的高度(例如，我需要完善自己的清单系统)。在生命周期的这一阶段，主要着眼于可能成为业务组成部分的业务流程，如电子商务站点。

    完成初步分析之后，服务工程团队可能开始寻找依赖性，试图决定优先级、揭示重用可能性或确定需求之间的依赖性。观察下面的需求目录示例，可以看到对于该企业来说，最初集中在用户注册流程上是再合理不过了，因为许多其他流程依赖于该流程，而且它可以在整个电子商务功能和企业内部网中重用。

    图2：需求目录示例，它向服务工程团队提供了实现公司未来状态的路线图

    根据公司在服务设计和开发方面的成熟度，选择首先开发哪种服务可能很自然地导致构建没有很多依赖性的服务，同时积累经验。尽管这些想法是对的，但是在企业成熟度中，熟悉增强重用的服务建模技术是很重要的，如强大的契约和策略定义。服务工程团队必须意识到重用概念以前曾在业务中提到过多次，但没有多大成效。由于相对于传统应用程序生命周期来说，服务开发周期较短，服务工程团队有能力从短期目录创建一系列可以跨计划快速利用的基础服务，从而实现早期的成功。

    无论如何，对初始服务（特别是依赖服务）的选择应与服务工程团队的能力相一致。这是很重要的。新的团队需要时间才能在SSLC的设计阶段具有更多经验。在服务目录中确定的依赖服务可能由于具有较高的重用水平，看似是一个好的侯选服务，但是不适合于尚未成熟的团队。若一个服务已涉及到跨业务线、提供企业级功能或遵守严格的服务质量规章的依赖性，则它可能不是一个理想的初始侯选服务。

    另一方面，对于一个具有已定义流程和已知端点的服务，如果这些端点是受控的、成熟的并且范围很小，在必要的情况下，服务本身的离散程度足以构建或重构，那么在很短的时间内，这种服务是初始开发的主要侯选服务。这样的初始服务应该可以很快地验证假设、方法学和流程。正确的设计需要经验和实践。反复进行试验并纠正错误，尤其在SOA计划的成型阶段，这种方法是判断在您的企业内哪些SOA实践可以发挥作用的重要机制。早期选择没有依赖性的孤立服务可能会限制服务工程团队在成型阶段获取更多的学习机会。

    服务设计和建模

    服务设计和建模阶段的目标是，基于需求目录中确定的业务流程建立一种定义侯选服务的一致方法。真到开始做的时候，服务工程团队通常用白板描绘业务流程、分解步骤以及讨论当前和未来的需求。为此，一致的设计方法学应该使用业务和IT均可理解的常用语言来建立。

    服务设计方法学为服务工程团队提供了一系列用于分解业务流程的步骤或活动，基于面向服务的设计原则确定服务中开发哪些方面是合理的。对于这种设计方法学，许多企业最初有一些争执，尤其是服务粒度。过细的粒度可能产生不可重用的服务增殖；过粗的粒度，又很难着手。在团队对建模流程满意之前，它应该将其活动集中在定义良好的业务流程中，这些业务流程可能并没有较大企业需求（如高生产量、长期事务）。

    尽管从技术上来说不是建模阶段的一部分（但可能是建模方法学的一部分），但我的经验表明：在定义服务分类原则方面投入时间对企业来说是很重要的。这些指导方针应该定义服务的哪些方面决定了服务是业务线（LOB）或应用程序级服务，还是具有特殊需求的企业服务。这些指导方针可能包括生产量、服务质量（QoS）、正常运行时间、服务关键程度以及多少客户将使用该服务。另外，开始定义与建立和管理服务相关的企业治理控制时，这些指导方针至关重要。开发指导方针可能本身是贯穿始终的工作，但开头很简单，只定义当前需求所要求的部分就可以。而且，服务分类可能有助于将相似功能分组并确认这些功能的业务所有者。记住，后续出现新的需求时可以重新调整指导方针。

    图3：服务分类及其与SOA治理的关系；此分类可能有助于定义SOA资产的企业治理控制。

    根据服务目录示例，企业可能已经建立了企业服务和业务线服务类别。以下进行详细描述。