基于現在和將來的需要，您可以為一組不同的抽象層定義需求。至少，您應該分離物理層和邏輯層，并相應地分配規則類型。
現在，讓我們更具體地看一下每一個步驟。
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個難于管理。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
