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项目性质、变更频率和变更大小影响。本文指出了在实现之前识别、验证和核实服务清单内容的关键非常好的实践。