註：這陣子參與編寫一本專為下個月在上海的 BEAWorld 大會所準備的 SOA 專刊，因篇幅關係，部分內容無法納入，在此將其以blog形式發表，並將詞彙調整成台灣IT界比較慣用的說法。
SOA 參考架構 (Reference Architecture) 是一個框架，使各個專案都有一個遵循的依據，藉以促進一致性、最佳典範，和標準化。參考架構並不該受限於目前的 IT 現況，而應針對一個經過深思熟慮的願景目標；它可說是 IT 用來指導未來所有的新開發工作，藉以實現該目標的參考依據。一般來說，2-3 年的規劃，是一個比較合適的涵蓋範圍，既能提供足夠的時間來達成服務導向的轉型，又不至於過於長遠而虛幻。因此，參考架構提供了一個溝通目標願景的方法，協助部門和角色各異的 IT 人員，逐漸朝向該目標會合。
高效的 SOA 需要採用新的方法來對待 IT 基礎設施，並且根據個別企業的需求來量身定做，並將服務基礎架構、共享的技術服務、安控服務，以及資訊／資料、和Legacy系統擷取服務等，全部定義在內。
為了滿足 SOA 的要求，所有公司都需要 SOA 參考架構和roadmap，來指導部署一套能隨時間演進、而逐漸豐富的企業級服務基礎設施，同時指導對服務導向應用的開發和管理。 此外，企業也需要對參與 SOA 架構的各個個別系統的設計，進行監管，並在適當的地方，建立通用服務，透過協同合作來發揮更高的效率。對於這些措施，連結端點的標準化（透過建立清晰定義的契約和介面），是達成 IT 系統一致性的先決條件。
SOA 參考架構指導所有實作 SOA 的各個專案，能共同朝向企業級服務，和 SOA 基礎架構標準的方向來發展，盡早使企業從中獲益。換句話說，參考架構規劃的重點，在於 1) 開發一個針對某個企業需要、切實可行的roadmap，以填補當前狀況和願景目標之間的鴻溝；2) 評估在開發、部署和管理、監控方面的既有系統和技術，進而定義目標狀態願景，和目標參考架構模型。
SOA 參考架構可說是指導 SOA 成功的藍圖，其作用包括：
- 促進 IT 與業務的緊密配合： 參考架構的制定，以業務驅動力 (business drivers) 和 IT 目標為出發點，分析 SOA 解決方案能對這些驅動力帶來多大的正面影響，進而為從目前 IT 現況演進到願景架構，定出實作架構、相關規範及roadmap。參考架構因此提供了從業務和 IT 目標，到實作架構間的可追蹤性，是業務與 IT 之間進行溝通的重要媒介，是企業實作業務靈活性、可管理性和變更規劃的基礎。
- 協助企業向重用、團隊協作和資源共享的文化遷移：參考架構確立了 SOA 架構標準和技術部署的最佳典范，為日後各個 SOA 的專案，訂立度量標準和指標，來評估架構遵循的程度。
參考架構並非一成不變。在一個新的 SOA 策略與規劃周期中，SOA 的參考架構和規範標準，可能需要針對新的業務、IT 狀況，和已導入的 SOA 專案中所得到的反饋，進行調整，因此，SOA 參考架構不僅是 IT 模板，也是也描述 SOA 原則和標準的活檔案。
我們可以將參考架構的內容，粗分為兩大部分：
- 對服務建立一套共同的詞彙和做法，包括：
- 服務的正式定義 – 例如服務必須由契約 (contract)、介面 (interface)，和實作 (implementation) 所組成
- 服務的分類（核心業務功能服務，資料服務，展現服務等），以及各類服務的設計原則和建議
- 介面標準 (JMS, RMI, HTTP 等)，建議的介面style（例如：盡量採用粗顆粒、非同步的服務呼叫模式），可靠性要求等
- 需要遵循的 WS-* 標準
- 安控策略
- 服務版本控制策略
- 服務和資料模型採用規範
- 服務生命週期定義
- 與服務基礎設施，例如企業服務匯流排 (ESB)、業務流程管理 (BPM)、註冊庫 (Registry)、資產庫 (Repository) 等相關的規範，包括：
- 必須支援什麼樣的部署設定
- 必須具備什麼樣的能力
- 各個基礎設施元件的責任
- 基礎設施元件之間的耦合關係和原則，應避免的事項，例如，展現服務和業務流程服務不可直接呼叫資料服務，而必須透過核心業務服務；換句話說，資料服務不可直接與展現服務和業務流程服務有耦合關係
- 各個基礎設施元件應支援那些科技和標準（例如：BPEL, SCA, SDO…）
- 有哪些安控concerns需要考慮，如何管理權限
- 要採用哪些產品
由於在規劃服務基礎設施參考架構時，需要cover幾類 SOA 參與者和 stakeholders 各自不同的concerns，包括架構師、程式設計師、和負責部署、維運、監控的 IT 人員，我們可以採用一個針對服務基礎設施參考架構調整過的 4+1 視圖（如下），來協助我們分離concerns，來將不同層面的規範和目標架構一一制定，透過邏輯、實作、部署，和行程等四個視圖，配合最佳實踐典範和模式，來對參考架構的各個層面，進行描述和規範，如附圖。
圖說: 為 SOA 參考架構調整過的 4+1 視圖，源於 Kruchten 在 1997 年發表的《Architectural Blueprints – the 4+1 view model of software architecture》
圖說: 服務基礎設施參考架構的邏輯視圖 (Logical View)
圖說: 服務基礎設施邏輯視圖下的功能視圖 (Functional View)
圖說: 服務基礎設施參考架構的實作視圖實例（情節為某電信客戶的 provisioning service），描繪所計劃採用的產品，以及如何透過這些產品間的互動，來實作解決方案
參考架構的規劃過程（如下圖），應先起於業務驅動力 (business drivers) 分析，有助於確保目標架構能支援業務的發展策略和方向，展現 SOA 建設對業務的價值，彰顯 SOA 投資的正當性，並獲得相關業務部門的經費贊助。以金融業為例，業務驅動力包括像是：
- 提升效率
- 貸款流程最佳化
- Call center最佳化
- 提升營業額，並明顯超越同業
- 快速靈活地推出創新的金融商品
- 延伸客戶關係，統合客戶資料
- 交叉行銷
- 根據關係來定價的策略
- 降低成本
這一類的價值驅動力。分析業務的價值驅動後，接著考慮各種 IT 目標，以及它們如何支援這些業務驅動力；例如：
- 從focus在各業務部門 silo 式的應用系統，轉向專注於跨系統／業務部門的流程／服務
- IT 資產重用
- 提高跨部門協作的業務流程的透明度
並且應訂立評價標準，作為日後考核實作各價值驅動力的準繩。接著下來，我們可以根據業務和 IT 驅動力，進一步制定適當的 SOA 策略，考慮採用 SOA，將對哪些業務部門，在哪些驅動力方面，產生最大的價值，據以訂立實作 SOA 專案的優先順序。
圖說: 參考架構規劃過程
圖說: 從業務驅動力和價值鏈分析，來找出應優先考慮採用 SOA 來協助提升的業務和 IT 能力。
√√ 代表 SOA 專案能產生很大的正向影響，依此類推。
針對各價值驅動力，我們可以參考附圖中的矩陣分析方式，從價值鏈或業務部門中的各個主要的職能（縱向），和各個識別出來的業務和 IT 驅動力（橫向），對 SOA 所可能產生的正面影響力，一一進行評估，進而挑選出服務導向解決方案最能嘉惠的業務能力，作為首期實作 SOA 專案的切入點。圖中的範例只是一個三萬英呎高空的起點，在真實的情況下，往往會針對範例中某個或某幾個得分較高的業務線 (line of business)，往下展開，對該業務部門中的各個主要業務能力，進一步進行 SOA 價值驅動力分析；換句話說，價值鏈分析中的各個職能域，應該從粗到細，逐步 drill down 到適當的深度，才能更精準地確定 SOA 能對哪些要迫切改善的業務能力，帶來最大價值。
依據業務和 IT 驅動力，選定了 SOA 策略後。接著應根據企業目前的現況，和未來 2-3 年的目標，進行差距分析，並根據最佳實踐典範 (best practices)，制定 SOA 發展的藍圖、roadmap和指導規範，完成參考架構的規劃。接著便可開始根據roadmap中制定的專案，以漸進的方式，透過一致的服務工程方法，一個接一個專案去執行，並在此過程中，逐漸將藍圖中的服務基礎設施搭建起來。