基于现在和将来的需要，您可以为一组不同的抽象层定义需求。至少，您应该分离物理层和逻辑层，并相应地分配规则类型。
现在，让我们更具体地看一下每一个步骤。
1）盘点现有的数据和系统访问资源
第一步是确定数据内容，即您您当前的数据和信息系统访问资源。您您的组织拥有哪些数据和信息资源（本文后面，简称为“资源”）？例如，数据库、信息资源和应用程序（指遗留系统、记录系统）。对于每一个资源，您需要了解支撑元数据，如文档、历史、技术／工具／产品／平台、版本、所有权／管理部门、位置、安全性和访问机制。根据资源及其元数据的数量，您可能想考虑某些元数据目录或者储存库，也可能是一个或一组标准模板，能够以一致的方式获取元信息并允许进行检索。
2）确定依赖关系矩阵
一旦您已经开始创建资源目录，第二步就是确定依赖关系矩阵。依赖关系矩阵也是资源元信息的一部分，它获取关于资源的使用者、使用时间、使用频率、使用目的（例如，CRUD）和使用地点（即，访问类型——成批的、在线的、实时的或报告式的）的信息。了解用户为何使用某个特殊的资源也是很重要的，这将有助于任务优化，而且为新的数据模型提出要求。
一旦您得到了使用某个资源的每个已知用户的情况——“使用者、使用内容、使用地点、使用时间、如何使用以及为什么使用”，您就可以开始分析和形成所有资源用户的概括。这样做的目的是要找到在现有资源向SOA构建块转换的过程中进行简化和重用的可能。它们包括，但不限于，那些面向服务的、自描述的和可发现的资源，这些资源能够便捷地应用于采用开放的、公共的、行业和／或企业标准的SOA生态系统。
在这组SOA构建块中包含的一个定义是您的服务定义。要使用什么样的标准、规格和版本呢？例如，可能会要求 WSDL、SOAP、UDDI、WS-Security、WS-I Basic Profile、WS-Addressing、XML和XSD之中的某一个的特定版本，而其它的则可以是可选项／推荐项。数据和信息访问资源很可能会采用与基本SOA构建块定义（即服务）一致的格式。（使用您喜欢的搜索引擎搜索“Service Identification”和“Service Definition”这两个主题可以找到这方面的内容。）
3）建立基线度量／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个难于管理。
文章来源于领测软件测试网 https://www.ltesting.net/
