這陣子參與編寫一本專為下個月在上海的 beaworld 大會所準備的 soa 專刊，因篇幅關係，部分內容無法納入，在此將其以部落格形式發表。
soa 參考架構 (reference architecture) 是乙個框架，使各個專案都有乙個遵從的依據，藉以促進一致性、最佳實踐典範，和標準化。參考架構並不受限於目前的 it 現況，而應該針對乙個經過深思熟慮的願景目標，可以說是 it 指導未來所有的新開發工作，藉以實現該目標的參考依據。一般來說，2-3 年的規劃，是乙個比較合適的涵蓋範圍，既能提供足夠的時間來達成面向服務的轉型，而又不至於過於長遠而虛幻。因此，參考架構提供了乙個溝通目標願景的方 法，協助部門和角色各異的 it 人員，逐漸朝向該目標會合。
高效的 soa 需要採用新的方法來對待 it 基礎設施，並且根據個別企業的需求來量身定做，並將服務基礎架構、共享的技術服務、安全服務，以及資訊／資料、和遺留系統訪問服務等，全部定義在內。
為了滿足 soa 的要求，所有公司都需要 soa 參考架構和路線圖，來指導部署一套能隨時間演進、而逐漸豐富的工業級服務基礎設施，同時指導對面向服務應用的開發和管理。
此外，企業也需要對參與 soa 架構的各個個別系統的設計，進行監管，並在適當的地方，建立通用服務，透過協作來發揮更高的效率。對於這些舉措，連線端點的標準化（通過建立定義清晰的契約和介面），是達成 it 系統一致性的先決條件。
soa 參考架構指導所有實施 soa 的各個專案，能共同朝向企業級服務，和 soa 基礎架構標準方向的集中發展，盡早使企業從中獲益。換句話說，參考架構規劃的重點，在於開發乙個特定於某個企業需要、切實可行的路線圖，以填補當前和願景 目標之間的鴻溝；評估用於開發、部署和管理、監控的現有系統和技術，定義目標狀態願景，目標參考架構模型。
促進 it 與業務的緊密配合： 參考架構的制定，以業務驅動力和 it 目標為出發點，分析 soa 解決方案能對這些驅動力帶來多大的正面影響，進而為從目前 it 現況演化到願景架構，定出實現架構、相關規範及路線圖。參考架構因此提供了從業務和 it 目標，到實現架構間的可跟蹤性，是業務與 it 之間進行溝通的重要媒介，是企業實現業務靈活性、可管理性和變更規劃的基礎。
協助企業向重用、團隊協作和資源共享的文化遷移：參考架構確立了 soa 架構標準和技術部署的最佳實踐，為日後各個 soa 的實施專案，訂立架構遵從性的度量標準和指標。
參考架構並非一成不變。在乙個新的 soa 策略與規劃迭代中，soa 的參考架構和規範標準，可能需要針對新的業務、it 情況，和已實施的 soa 專案中得到的反饋，進行調整，因此，soa 參考架構不僅是 it 模板，也是也描述 soa 原則和標準的活文件。
對服務建立一套共同的詞彙和做法，包括：
服務的正式定義 – 例如服務必須由契約 (contract)、介面 (inte***ce)，和實現 (implementation) 所組成
服務的分類（核心業務功能服務，資料服務，展現服務等），以及各類服務的設計原則和建議
介面標準 (jms, rmi, http 等)，建議的介面樣式（例如：盡量採用粗粒度、非同步的服務呼叫模式），可靠性要求等
需要遵從的 ws-* 標準
安全策略
服務版本控制策略
服務和資料模型採用規範
服務生命週期定義
與服務基礎設施，例如企業服務匯流排 (esb)、業務流程管理 (bpm)、註冊庫 (registry)、資產庫 (repository) 等相關的規範，包括：
必須支援什麼樣的部署配置
必須具備什麼樣的能力
各個部件的責任
部件之間的耦合關係和原則，應避免的事項，例如，展現服務和業務流程服務不可直接呼叫資料服務，而必須通過核心業務服務；換句話說，資料服務不可直接與展現服務和業務流程服務有耦合關係
各個部件應支援那些科技和標準（例如：sca, sdo…）
有哪些安全顧慮需要考慮，如何管理許可權
要採用哪些產品
由於在規劃服務基礎設施參考架構時，需要涵蓋幾類 soa 參與者和干係人 (stakeholders) 各自不同的顧慮，包括架構師、程式設計師、和負責部署、運營、監控的 it 人員，我們可以採用乙個針對服務基礎設施參考架構調整過的 4+1 檢視（如下），來協助我們分離顧慮，來將不同層面的規範和目標架構一一制定，通過邏輯、實現、部署，和程序等四個檢視，配合最佳實踐典範和模式，來對參考 架構的各個層面，進行描述和規範，如附圖。
圖說: 為 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 投資的正當性，並獲得相關業務部門的經費贊助。以金融行業為例，業務驅動力包括像是：
提公升效率
借貸流程優化
呼叫中心優化
增長銷售額，並顯著超越同業
快速靈活地推出創新的金融商品
擴充套件客戶關係，統合客戶資料
交叉銷售
依據關係定價的策略
降低成本
這一類的價值驅動。分析業務的價值驅動後，接著考慮各種 it 目標，以及它們如何支援這些業務驅動力；例如：
從關注各業務線煙囪／豎井式的應用系統，轉向專注於跨系統／業務線的流程／服務
it 資產重用
提高跨部門協作的業務流程的透明度
並且應訂立評價標準，作為日後考核實現各價值驅動力的指標。接著下來，我們可以根據業務和 it 驅動力，進一步制定恰當的 soa 策略，考慮採用 soa，將對那些業務線，在那些驅動力方面，產生最大的價值，據以訂立實施 soa 專案的優先級別。
圖說: 參考架構規劃過程
圖說: 從業務驅動力和價值鏈分析，來找出應優先考慮採用 soa 來協助提公升的業務和 it 能力。
√√代表 soa 專案能產生很大的正向影響，依此類推。
針對各價值驅動力，我們可以參考附圖中的矩陣分析方式，從價值鏈或業務線中的各個主要的職能（縱向），和各個識別出來的業務和 it 驅動力（橫向），對 soa 所可能產生的正面影響力，一一進行評估，進而挑選出面向服務解決方案最能嘉惠的業務能力，作為首期實施 soa 專案的切入點。圖中的範例只是乙個三萬尺高空的起點，在真實的情況下，往往會針對範例中某個或某幾個得分較高的業務線，往下展開細化，對該業務線中的各個 主要業務能力，進一步進行 soa 價值驅動力分析；換句話說，價值鏈分析中的各個職能域，應該自粗到細，逐步鑽取、drill down 到適當的深度，才能更精準地確定 soa 能對哪些要迫切改善的業務能力，帶來最大價值。
依據業務和 it 驅動力，選定了 soa 策略後。接著應根據企業目前的現況，和未來 2-3 年的目標，進行差距分析，並根據最佳實踐典範 (best practices)，制定 soa 發展的藍圖、路線圖和指導規範，完成參考架構的規劃。接著便可開始根據路線圖中制定的專案，以漸進的方式，通過一致的服務工程方法，乙個接乙個專案去執 行，並在此過程中，逐漸將藍圖中的服務基礎設施搭建起來。
oracle
更多相關
選型成功為企業erp專案種顆優良的種子！
拿什麼給我們的老闆看？
如何在不確定經濟形勢下把握好企業脈搏
乙個jde小菜鳥對新人們的忠告
電子健康檔案在國外的一些實踐
規劃 soa 參考架構
SOA兩大關鍵 架構與規劃
soa的深層次驅動力在於市場競爭要求對企業的管理與流程進行改革優化,這個過程必然是漸進的,而不是突變的。若論當前資訊科技領域中的熱門話題,soa無疑是其中乙個。據gartner 2010年,80 的應用軟體收入增長將來自基於soa的方案。但到底如何實施soa,很多使用者並不十分清楚。unisys中國...
SOA 思想 架構
提出 soa service oriented architecture，面向服務架構 服務提供者 發布自己的服務，並且對使用自身服務的請求進行響應 服務 註冊已經發布的服務提供者，對其進行分類，並提供搜尋服務 服務請求者 利用服務 查詢所需的服務，然後使用該服務。soa體系結構中的元件必須具有上述...
SOA需要認真規劃
transnet公司首席企業設計師nardus breytenbach在midrand舉行的 2008 itweb企業soa會議 上發表講話說，soa是複雜的。它需要規劃和基礎的元件才能取得成功。soa許諾要通過消除業務和it部門的隔閡來提高業務部 門的滿意度。matrix公司高階it經理quint...