成功规划SOA实作篇

1、成功規劃SOA：實作篇 David Groves2006/06/05在發展IT架構時你會逐漸發現到，若要獲致真正的業務效益，你必須徹底改變系統架構的思維。本文是關於服務導向架構(SOA)的系列三篇文章中的第一篇，將提供你實用祕訣、深刻剖析和領域模型（Domain Model）以規劃和開發一個成功的SOA。 SOA：一種新的思維方式 愛因斯坦說：當我們面臨重大問題，如果我們沒有從引發問題的層次往上提升，從更高的層次觀察問題，這些問題將不可能被解決。這個概念應用到當今的企業運算領域時，如果我們不改變對IT的思維習慣，IT也就無法成功支援商業方面的需求。對於開發人員和企業架構師來說，SOA為這種改變

2、提供一個基礎的架構。 這裏我們要思考的問題是：我們該如何自我提升到新的層次？該如何為這種徹底變革做準備？如何確保以最具成本效益、對組織最沒有損害的方式來進行這種變革？所有答案之首在於適當的規劃。 與其說SOA是一種技術，不如說它是一種思維方式。它是一項大膽的基礎架構變革，代表我們在使用技術和相互協同方式上的變革。它的爆紅不是業界一時熱潮的結果，而是因為IT業已認知到SOA乃是促進業務和IT系統更密切結合的重大革命。這場革命驚天動地，對企業具有深遠影響。 究竟什麼是SOA？ 服務導向架構是一種IT策略，它把包含在各種企業應用中的功能組織成相互可操作的標準化服務，而這些服務又可以迅速組合和重覆使用

3、以滿足業務需求。 一個服務是一個由服務層次協定（SLA）管理的原始碼模組，可經由標準化介面加以存取。每個服務都表示一部分的功能，明確對應到業務流程中的某一步驟。服務可以重新打造或是把現有把各自孤立的應用程式中的系統功能模組公開（expose）出來。 慢慢地你就可以建立起服務目錄，使業務功能如液體般可以讓許多不同系統存取與重複使用。這樣，SOA就能同時支援策略變革並在技巧層次上減少重複資料，避免資訊重覆輸入和人為錯誤。例如，使用SOA能建立一個消費者的單一視圖，在此流程中，開啟更多交叉銷售和向上銷售的可能性，進而提供更多服務提升使用者體驗。 基礎架構新典範 SOA的典範轉移有一部份是從應用基礎架

4、構（Application Infrastructure）轉換到服務基礎架構（Service Infrastructure）。在SOA之前，各種應用程式乃是以點對點的方式連結成相互分離(silos)的系統。SOA也用同樣的後端應用引擎和中介軟體，但更使用一個聚合的服務基礎架構層（Service Infrastructure Layer），如圖一所示。 圖一 服務基礎架構層SOA實作 SOA實作依照以下步驟開始： 思維需具備策略性，執行需具有戰術性：應從簡單的、中立的服務來實作，從單一核心流程開始，而不要想橫跨多個業務部門。 從上到下考量：找出支援這個單一核心流程所需的服務。 從下到上考量：找出

5、現有系統中可當成一個服務公開、支援這個流程的功能。 考慮基礎架構服務：找出共通的支援功能需求。 逐步擴充：最初的專案成功之後，再邁入技術上較具難度挑戰性的專案。 建立應用目錄(application catalog)：一個又一個專案下來，逐步累積與重覆使用服務模組，長期下來可減少你的成本。 關注受益：按投資回報率(ROI)切分專案階段，也要為整合預留一段時間。 利用好的模型有效規劃 SOA若想成功，仰賴IT和業務單位之間新的合作方式。在你開始SOA規劃時，你需要在技術性和非技術性要素之間取得有效的平衡。為此BEA發展了Domain Model（如圖二所示），可協助指導你規劃須等量齊觀的六大領域

6、以確保導入的成功。 方法論 : BEA SOA Domain Model 圖二 BEA Domain Model 最好先從業務策略與流程、架構以及成本與效益三個領域著手規劃。業務策略與流程：把SOA對應到業務 SOA把IT功能對應到業務流程，使業務隨著時間而改善。對應流程如下： 分析：研究業務流程，找出所需的支援功能。 開發：從現有的IT資產中蒐集功能，開發新功能，確保所有服務都有明確的服務層級協定。 利用：將服務編排進流程，確保未來措施與策略一致，找出最佳化時機。 架構：定義長期需求 為IT組織建立參考架構很重要。這種參考架構描述的不是現有狀態，而是依據貴公司長遠目標的二、三種架構融合而成的

7、長期遠景圖。你應該花些時間來定義架構的指導原則和策略，但要避免使這些指導原則走入死胡同。SOA系統的彈性和模組化特性是第一考量。 成本和效益：展現立即的業務價值 SOA宗旨在於佈署底層架構，因此重要的是依據成本效益排定服務開發的優先順序，這樣SOA從一開始就能有好的ROI。若能仔細規劃，你的啟動成本多半可以為現有預算所吸收。經過一段時間後，服務模組的重覆使用可確保以後每個新業務應用程式的啟動成本很低。在實作一開始設定好基線(baseline)，確保進度可被測量，同時要避免在過程中臨時要回頭填補坑洞。 使用SOA成熟度模型 這牽涉到方法論的問題。BEA的SOA成熟度矩陣（如本圖所示）可協助監視S

8、OA佈署，以便協助企業依據不同開發階段檢查進度。這個矩陣被劃分成三個階段：探索（Exploring）、延伸（Expanding）和使用（Exploiting）。你可以使用像BEA Online Self-Assessment Tool的工具來評估架構的成熟度。 SOA通常不是一種零與一的兩極化選擇，一般是採取分階段漸進的模式，我們未來還有其他主題（如定義長期的架構和發現立即的業務價值）來探討之。 成功規劃SOA：打造你的SOA藍圖 Steve Bennett2006/06/06摘要 服務導向架構（Service-Oriented Architecture, SOA）系列文章的第二篇將提供一套具

9、體的計劃連同訣竅與深入見解以協助您建構有效的SOA藍圖，並確保您SOA專案能大功告成。 任何偉大的旅程都必須先決定目的地，貴單位導入SOA的決策也不能例外。但和西部拓荒的早期美國人一樣，你一開始對前方有什麼，或是該如何前往目的地可能都只隱約有個概念而已。要成功抵達目的地，你得評估自己的優劣勢、確立清楚的方向、選擇路線，然後在前進時不斷重新評估路線。簡而言之，你必須為旅程創出屬於你自己的地圖。 什麼是SOA藍圖，為什麼非它不可？ 服務導向架構是一種將企業內分散的軟體功能整合成一個可相互溝通的標準化服務，以便依照企業需求快速組合和重新使用。只有在企業長期目標與短期需求達到平衡後，SOA的效益才可能

10、實現。要達成這種平衡，企業可在SOA專案一開始的時候就制定出組織、財務、營運、設計與施行作法。然而相較於全面式革新，其實以漸進、反覆的方式執行文化變革，反而更能給組織較充足的時間去學習。基本上，SOA藍圖正提供了一套反覆而漸進式的作法，在你不斷前進的同時可以捕捉（或重新塑造）貴公司特有計畫的精神。 SOA藍圖應該包括以下三大特點： 1.成熟度：請把你的SOA藍圖看成會持續蒐集經驗與學習的活的文件。隨著SOA藍圖愈趨成熟，你的SOA專案將能井井有條的愈變愈繁複。要製作一張SOA藍圖，一開始得先評估貴單位可用於SOA的能力與行事法則。（某些廠商，如BEA有線上自我評估工具可以協助自我評估）。 2.

11、範疇（scope）：一個完整的SOA藍圖應該包含六大領域（見圖一）。這些領域各自分離卻又相互關連。每個領域確實執行乃是確保全企業（enterprise-wide）SOA專案成功的基礎。SOA藍圖應該要能清楚勾勒出你SOA專案的輪廓，並且為達成SOA目標而建立透明而彈性的時間表。這些目標應該可以細分成可被管理的數個階段，然後以反覆而漸進方式實現之。 3.品質：每個里程碑（milestone）皆套用學習、調整的流程，而你的藍圖在整個專案過程反覆而漸進地前進著的同時，可不能愈離愈遠。為確保你SOA藍圖的品質，你最好要與所有相關成員溝通、確定過、並且取得所有部門的意見與同意。 圖一 BEADomain

12、 Model如何建立SOA模型 發展SOA藍圖有四大領域：SOA規劃、SOA成熟度評估、SOA未來願景以及SOA藍圖定義 SOA規劃 SOA專案要在本階段中經過整理與定義。所有相關成員在經過溝通與簡報後開始了解情況，並且在工作優先順序及範圍取得共識。由於本階段攸關貴單位所有員工，因此清楚而充足的溝通相當必要。在本階段你要做的事包括： 定義SOA的範疇建立與其他IT專案間的界限與配合狀況適度展現SOA對業務的價值展現目前與未來業務計畫間的配合程度。 SOA成熟度評估 在SOA成熟度評估階段，你得建立衡量進度的機制。你必須定義出目前有哪些服務和能力可用以當成SOA起點，並找出哪些專案可作為發展基礎

13、。透過一系列面談與問卷，你的團隊應該可以檢查多個領域-針對每個作分析、定出基線(base-line)、並確認現有模式（as-is）情境。你可以利用BEA的Domain Model規劃以下檢視作業： 業務策略與流程：由上而下檢視業務策略與流程架構：檢查現有架構、政策與標準成本與效益：全面檢視目前的成本架構與效益benefits cases建構元素：分析既有的服務、流程、工具及技術專案與應用：檢查現有的系統、以及正在進行與規劃中的專案組織與管理：分析目前的管理架構與政策 SOA未來願景 在本階段中，你的團隊可在小組討論中決定與定義出理想的狀態，並確保各單位都同意。業務策略與流程：做出SOA未來願景

14、與業務策略與流程之間的關聯架構：指導性原則、要求、政策、標準與參考架構成本與效益：測量機制與測量標準建構元素：共享的服務架構要求及標準化工具專案與應用：將SOA對應到專案及應用程式組織與管理：管理與遵循架構與政策 SOA藍圖定義 你的SOA是在此一階段開始定義。你應該依據前面三階段所蒐集到的資訊針對貴公司SOA目標與相應的時程作全面的差異分析。近期事件會比較詳細，而未來的事則變通性較大，以便可以融合你在過程中學到的心得。 1.業務策略與流程：依據機會而定義業務價值 2.架構：短期、中期、長期參考架構藍圖3.成本與效益：未來測量標準、成本架構與效益benefits cases藍圖。4.構成元素：

15、排定共通服務策略與標準化流程的優先順序。5.專案與應用：專案與應用的影響6.組織與管理：計畫的管理架構與政策 你應該將SOA藍圖視為會不斷蒐集經驗與心得的活的文件。隨著藍圖逐漸成熟，你的SOA計畫也會在井井有條的方式下日趨繁複。（見圖二） 圖二SOA學習、調整藍圖成功規畫SOA(3)：長程規畫 David Groves2006/06/07摘要 在成功規畫SOA系列第一篇文章中我談到什麼是服務導向架構（Service-Oriented Architecture, SOA）以及該如何確保它為貴公司帶來價值。在Domain Model中我特別著重業務策略與流程、架構、成本與效益。第二篇文章則討論了如

16、何制定有效的SOA藍圖。在最後一篇文章裏，我將探討說明Domain Model剩下的三部份：構成元素、專案與應用以及組織與管理，說明該如何它們融入到你的長期專案規畫中。 長期SOA規畫 圖一所示的BEA SOA Domain Model可在你做SOA規畫的策略提供有效指導。以下圖表中標出的六個主要領域都必須均衡發展才能確保導入成功。 圖一BEA Domain Model本系列第一篇文章檢視的是前三大領域-業務模型與流程、架構及成本與效益。但開始導入後，你必須要走完SOA每一階段才能算是完整的SOA規畫。 Domain Model後三部份在你以重覆而漸進的步伐前進時，特別有助於持續評估與確保專案

17、的彈性。有效評估你的前進步伐可以讓你在實踐商業價值的道路上一旦偏離正軌能即時發現、及時矯正。接下來我們就要深入探討這幾個部份，說明他們如何協助你進行長期SOA規畫。 構成元素(Building Blocks)：重覆使用你的資產 SOA的成功有賴於實踐重覆使用的文化。SOA的構成元素是一些分自分散而能重新使用的服務與架構元素，可相互組合成複合式應用與服務基礎架構。每一個構成元素實作出來後就會成為你整個SOA的功能目錄中的一員。而隨著目錄愈來愈健全，未來的專案需要開發的新程式碼與服務基礎架構就會愈來愈少，維護成本逐漸降低，而ROI也將穩定大幅成長。 清楚定義出服務，並經常把它送進一個生產性IT佈署

18、計畫中乃是SOA專案的成功關鍵。服務一般可用三項元素定義之： 服務實作：服務的實作包含實際程式碼、應用介面及其他可透過服務展現出來的功能。 服務介面：服務介面具備一些標準化服務工具，可供使用者依據合約取用功能。 服務合約：服務合約明訂服務的用途、功能、限制及使用方式。安全條件、回應速度、傳輸量及可用性等合約細節也有舉例說明。 你的服務可以從現有應用中取得，也可以全新打造，不過無論哪一種方式你都面臨同樣的問題：該從哪一種服務實作起呢？以貴公司最基礎的簡單服務為佳，最好先從各業務單位通用的服務做起，再慢慢延伸到特定單位適用的功能。這種作法有助於你的同事逐漸適應組合、重覆使用服務的作業方式，而不會一

19、開始就被一堆複雜工作所困。同樣地你也應該從技術難度較低的服務做起，然後漸次挑戰更高難度的類別。最先建立的基礎架構服務像是登入、稽核、錯誤處理（error handling）等類似功能。 專案與應用(Projects and Applications)：實作你的SOA藍圖 服務藍圖可從找出貴公司目前可用的IT專案與功能著手。接著，企業再把能完備此一架構與具有業務價值的個別專案開發出來並排定優先順序。 第一步是檢視既有應用與專案的狀況，決定哪些功能可以重覆利用。完全無法運用到其他應用，或是還在開發中的專案則先放在一旁。 以下資訊請務必要蒐集到： 現有應用功能、服務與依存關係既有服務的細緻度與能力現有應用與預定或開發中的專案的依存關係，以及相關開發與維護挑戰目前通用服務的使用狀況與應用開發相關的成本及其他測量值測量標準應用所存取與傳遞的資訊應用程式中所有到的資料模型、轉換（transformation）及轉譯（translation）應用所牽涉到的工作流（workflow）及流程流服務的使用，像是單一簽入（single sign-on）、登入、錯誤與例外處理、監控與通知服務層級協定（service-level agreement）、服務品質與非功能性的相關業務資訊目前正在執行的里程碑（milestone）與較急迫的專案時程的細節 蒐集到這些資料可以幫助你清楚掌握現有專案