基于现在和将来的需要，您可以为一组不同的抽象层定义需求。至少，您应该分离物理层和逻辑层，并相应地分配规则类型。

　　现在，让我们更具体地看一下每一个步骤。

　　1)盘点现有的数据和系统访问资源

　　第一步是确定数据内容，即您您当前的数据和信息系统访问资源。您您的组织拥有哪些数据和信息资源(本文后面，简称为“资源”)?例如，数据库、信息资源和应用程序(指遗留系统、记录系统)。对于每一个资源，您需要了解支撑元数据，如文档、历史、技术/工具/产品/平台、版本、所有权/管理部门、位置、安全性和访问机制。根据资源及其元数据的数量，您可能想考虑某些元数据目录或者储存库，也可能是一个或一组标准模板，能够以一致的方式获取元信息并允许进行检索。

　　2)确定依赖关系矩阵

　　一旦您已经开始创建资源目录，第二步就是确定依赖关系矩阵。依赖关系矩阵也是资源元信息的一部分，它获取关于资源的使用者、使用时间、使用频率、使用目的(例如，CRUD)和使用地点(即，访问类型——成批的、在线的、实时的或报告式的)的信息。了解用户为何使用某个特殊的资源也是很重要的，这将有助于任务优化，而且为新的数据模型提出要求。

　　一旦您得到了使用某个资源的每个已知用户的情况——“使用者、使用内容、使用地点、使用时间、如何使用以及为什么使用”，您就可以开始分析和形成所有资源用户的概括。这样做的目的是要找到在现有资源向SOA构建块转换的过程中进行简化和重用的可能。它们包括，但不限于，那些面向服务的、自描述的和可发现的资源，这些资源能够便捷地应用于采用开放的、公共的、行业和/或企业标准的SOA生态系统。

　　在这组SOA构建块中包含的一个定义是您的服务定义。要使用什么样的标准、规格和版本呢?例如，可能会要求 WSDL、SOAP、UDDI、WS-Security、WS-I Basic Profile、WS-Addressing、XML和XSD之中的某一个的特定版本，而其它的则可以是可选项/推荐项。数据和信息访问资源很可能会采用与基本SOA构建块定义(即服务)一致的格式。(使用您喜欢的搜索引擎搜索“Service Identification”和“Service Definition”这两个主题可以找到这方面的内容。)

　　建立基线度量/SLA

　　由于每个编目好的资源已经以某种方式存在，所以应该具有预测的或者实际的产品使用统计信息，包括事务规模、模式、并发用户、可靠性、可用性、可伸缩性和性能(RASP)等方面的信息。

　　使用信息也很好地表明了业务和IT的价值和优先权。这个基线信息用来定义一组度量，这组度量将构成服务级别协议(SLA)并允许目标定义和历史跟踪。为了支持 SOA的数据服务层，要规划软硬件的大小和容量，在这一过程中，度量和当前产品信息的价值是无法估量的。确定您的SLA是双向的，即服务提供者针对每个用户定义SLA术语、条件和处罚;用户应该遵守这个协议。

　　例如，一个协议声明用户A每天(这里指一天24小时，从午夜GMT12:00开始计算)可以在DataServiceXYZ(资源/服务的提供者)上执行最多100个get()请求，而每个请求的响应时间将≤2秒。如果用户A发出了超过协议规定的最大数量的get()请求，那么服务提供者能够根据协议规定对其处罚。对服务提供者也有相应的要求。如果用户A的请求数量不大于规定的最大值，则服务提供者必须提供≤2秒的响应时间，否则就要面对协议规定的相应的处罚。

　　度量和SLA定义约定的要求和规则，这些要求和规则影响每个资源的价值、目标和规模的基础。跟踪并重用您的基线度量、SLA，建立一个成本和效益模型。

　　有了上述的一定程度的一组已获取信息，应该可以在所有其它的编目好的资源上下文中开始评价每个资源——即，指定每个资源的优先权。一个好的策略是拥有最少3个、最多10个优先权级别(过多了);小于3个不够，多于10个难于管理。

　　优先权分配的目的是帮助识别在应用上最重要的资源和所支持的业务功能的价值。您应该设计一组度量(包括第三步中的那些)和定义来根据经验比较和评价每个资源，以确定其优先级。分配资源优先级将有助于确定项目的合理起点、潜在的∵业务/IT赞助和相关的业务价值。

　　当这些资源向SOA构建块转换时，使用上述的所有信息能够建立、记录和跟踪每个资源的“当前使用”快照。对于剩下的几个步骤，应该在所有编目好的资源中选择那些被指定为最高优先级的资源。实际数量的选择要根据您的风险评估、优先权评价、业务/IT目标、资源以及其它类似的因素来进行。