本篇重點說明下SOA服務架構規劃中服務目錄規劃集的形成。SOA服務架構規劃不僅僅是基于SOA參考架構的思想，更多的是需要基于TOGAF和企業架構的思想來分析和構建完整的服務架構和服務目錄庫。

服務架構規劃的重點有一項是形成完整的服務目錄庫，除了服務本身的多維度分層外，更加重點重要的還是識別出粗粒度和可重用的各類服務。SOA的核心思想就是要將企業的業務或信息系統劃分為多個松耦合的組件，然后根據端到端流程的協同關系來識別和發現服務，即業務能力組件化和組件能力服務化；其次則是要基于云平臺能力向云端集中化遷移的核心思路，來考慮整個IT應用架構中需要平臺化的能力，同時將平臺層能力以服務化的方式暴露出來。

在整個服務架構規劃中也可以看到，對于主數據和共享數據的平臺化建設，PaaS技術平臺的建設，最終將識別和產生共享數據服務和平臺技術服務。而對于從流程協同和業務架構分析入手，更多的產生業務服務；而對于從數據架構中的CRUD矩陣分析入手則產生數據服務。

下面再重點闡述下整個服務架構規劃的核心邏輯和過程：

首先最重要的仍然是當前業務和IT現狀調研，一開始不要陷入細節，而是應該從端到端業務流程分析入手，對于工程項目建設，供應鏈，研發生命周期管理，財務概預核決算，從客戶提出產品或服務的需求到最終的能力交付，都可以看到有不少的端到端流程，這些端到端流程是入手的基礎。通過端到端流程的梳理可以看到流程在多個業務部門和單位之間的協同，最終再將業務流程協同映射到跨多個業務系統或業務組件間的業務和數據協同。跨系統交互核心流程分析和梳理是識別組件或服務的關鍵一個步驟。

由于企業整個服務目錄規劃前期只會做到系統間協同和能力開放，因此分析到跨系統的端到端流程已經足夠來分析和識別有價值的服務。基于由頂向下的思路我們不會馬上落入到某一個業務活動，或者某一個業務系統中功能細節，而是分而治之，先將業務系統內部處理流程和邏輯看為黑盒，先分析清楚哪些能力是業務系統必須開放出去以實現跨系統流程交互的。

在跨系統流程交互中分析中，自然會分析到業務協同和交互過程中傳遞的業務對象，我們會進一步去分析這些業務對象映射的數據對象，通過單獨數據對象的分析以方便我進行單純的數據架構建模和數據CRUD分析，這個對于后續分析和識別數據分析是相當重要的。

其次，基于業務和IT調研的內容，我們會初步分析和構建當前企業的流程和業務架構，數據架構和應用架構，同時在業務架構中識別和分析相關的業務組件。如果僅僅是分析到系統間的話，那么最終的業務系統就是相關的業務組件，這跟我們識別和分析的粒度密切相關。

在這些都分析完成后，接著可以構建完整的企業業務系統間的集成架構視圖，也可以理解為當前的系統間詳細接口和集成情況。這個圖梳理清楚后，基本系統間交互的接口全部梳理清楚，也清楚了系統間集成和交互關系。對于集成架構圖的形成，一方面是采用第一步談到跨系統流程分析和梳理中的接口交互，數據架構CRUD分析中的數據共享和交互；一方面是由底向上的分析當前系統間已有的歷史接口情況，并對接口的業務場景和對應流程進行補充梳理，以形成完整的集成架構視圖。

集成架構視圖做好后，可以將前期分析的端到端流程執行情況，進一步在集成架構視圖上進行交互模擬，以確保核心的接口交互和服務沒有遺漏。特別要注意的是在前面我們重點分析的是端到端流程，但是很多不是端到端流程場景，例如只跨了兩個業務系統的簡單業務流程或協同，業務需要進一步考慮清楚，否則會出現較多的集成接口遺漏。

最后，我們需要基于集成架構視圖情況，規劃和梳理服務目錄集，即按照服務的分層和分類來重新審視當前的系統間集成和能力共享。下面來看下幾類典型服務的進一步服務識別和規劃。

流程服務：注意端到端流程也是流程服務，但是該流程更加長，也很多對應到最終的流程編排和組合。因此需要從端到端流程中進一步找尋流程協作片段。這種流程片斷最好是完全的自動化業務流，或者有較強的一致性和事務要求，這些都可以識別為流程服務。

業務服務：業務服務更多強調的是業務規則類服務，或者強調基于業務功能操作觸發的單條數據操作類服務。業務服務將更加體現服務調用的實時性，和業務操作場景的綁定以及業務邏輯的體現。或者可以理解為對于業務流程中橫向實時協同的服務都可以看做為業務服務。

數據服務：更多的是從數據CRUD分析中識別出來的服務，其中既包括了主數據，也包括了共享動態數據。一個服務如果更多是事后非實時的共享數據傳遞或數據查詢，則更多的是數據服務。從這個層面來說業務服務和數據服務本身存在一些較難界定清楚的地方。也有一些方法是單獨僅僅將主數據和共享數據中心提供出來的分析規劃為數據服務，其它全部為業務服務。

服務全部識別清楚后，還需要進一步對服務進行歸并去重，服務組合或拆分，服務關鍵屬性的定義，以方便根據服務類型，服務技術分層，服務提供系統多層面來規劃完整的服務目錄庫和服務視圖。