成功規畫SOA(3)：完整的規劃藍圖
在成功規畫SOA系列第一篇文章中我談到什麼是服務導向架構（Service-Oriented Architecture, SOA）以及該如何確保它為貴公司帶來價值。在「Domain Model」中我特別著重「業務策略與流程」、「架構」、「成本與效益」。第二篇文章則討論了如何制定有效的SOA藍圖。在最後一篇文章裏，我將探討說明Domain Model剩下的三部份：「構成元素」、「專案與應用」以及「組織與管理」，說明該如何它們融入到你的長期專案規畫中。
長期SOA規畫
圖一所示的BEA SOA Domain Model可在你做SOA規畫的策略提供有效指導。以下圖表中標出的六個主要領域都必須均衡發展才能確保導入成功。
圖一 BEA Domain Model
本系列第一篇文章檢視的是前三大領域--「業務模型與流程」、「架構」及「成本與效益」。但開始導入後，你必須要走完SOA每一階段才能算是完整的SOA規畫。
「Domain Model」後三部份在你以重覆而漸進的步伐前進時，特別有助於持續評估與確保專案的彈性。有效評估你的前進步伐可以讓你在實踐商業價值的道路上一旦偏離正軌能即時發現、及時矯正。接下來我們就要深入探討這幾個部份，說明他們如何協助你進行長期SOA規畫。
構成元素(Building Blocks)：重覆使用你的資產
SOA的成功有賴於實踐重覆使用的文化。SOA的構成元素是一些分自分散而能重新使用的服務與架構元素，可相互組合成複合式應用與服務基礎架構。每一個構成元素實作出來後就會成為你整個SOA的功能目錄中的一員。而隨著目錄愈來愈健全，未來的專案需要開發的新程式碼與服務基礎架構就會愈來愈少，維護成本逐漸降低，而ROI也將穩定大幅成長。
清楚定義出服務，並經常把它送進一個生產性IT佈署計畫中乃是SOA專案的成功關鍵。服務一般可用三項元素定義之：
•服務實作：服務的實作包含實際程式碼、應用介面及其他可透過服務展現出來的功能。
•服務介面：服務介面具備一些標準化服務工具，可供使用者依據合約取用功能。
•服務合約：服務合約明訂服務的用途、功能、限制及使用方式。安全條件、回應速度、傳輸量及可用性等合約細節也有舉例說明。
你的服務可以從現有應用中取得，也可以全新打造，不過無論哪一種方式你都面臨同樣的問題：該從哪一種服務實作起呢？以貴公司最基礎的簡單服務為佳，最好先從各業務單位通用的服務做起，再慢慢延伸到特定單位適用的功能。這種作法有助於你的同事逐漸適應組合、重覆使用服務的作業方式，而不會一開始就被一堆複雜工作所困。同樣地你也應該從技術難度較低的服務做起，然後漸次挑戰更高難度的類別。最先建立的基礎架構服務像是登入、稽核、錯誤處理（error handling）等類似功能。
專案與應用(Projects and Applications)：實作你的SOA藍圖
服務藍圖可從找出貴公司目前可用的IT專案與功能著手。接著，企業再把能完備此一架構與具有業務價值的個別專案開發出來並排定優先順序。
第一步是檢視既有應用與專案的狀況，決定哪些功能可以重覆利用。完全無法運用到其他應用，或是還在開發中的專案則先放在一旁。
以下資訊請務必要蒐集到：
•現有應用功能、服務與依存關係
•既有服務的細緻度與能力
•現有應用與預定或開發中的專案的依存關係，以及相關開發與維護挑戰
•目前通用服務的使用狀況
•與應用開發相關的成本及其他測量值／測量標準
•應用所存取與傳遞的資訊
•應用程式中所有到的資料模型、轉換（transformation）及轉譯（translation）
•應用所牽涉到的工作流（workflow）及流程流
•服務的使用，像是單一簽入（single sign-on）、登入、錯誤與例外處理、監控與通知
•服務層級協定（service-level agreement）、服務品質與非功能性的相關業務資訊
•目前正在執行的里程碑（milestone）與較急迫的專案時程的細節
蒐集到這些資料可以幫助你清楚掌握現有專案及應用狀況，進而找出共通功能。
組織與管理(Organization and Governance)：設定預期目標
建置SOA需要對貴公司員工作業文化做些改變。IT功能／部門間必須建立起更密切的協同以便大家都能一同參與實現業務價值的工作，而不只是由一個單位部門一肩挑。
本領域有兩大主題。第一是必須提供充份教育，讓成員們不只清楚SOA的技術面相，也能了解文化變革的必要。這些關鍵訊息若沒能確實傳達，將來也必然無法確實實踐。
第二，「組織與管理」的宗旨是把導入SOA視為一項企業變革計畫，而非只是帶入最新潮的技術而已。爭取高層主管的同意與長期支持有助於公司內跨部門合作，讓你有確保大家遵循及宣揚理念的「尚方寶劍」。
不同公司基於企業成熟度與經營方針的差異，建立「組織與管理」的方法也有所不同。中央化、由上而下管理的組織最有利於初期導入SOA，接著依次是聯邦或半聯邦的治理方式，最後是地方自治式的階層組織。中央化組織對結構、資金籌措、營過程及工具、標準、技能變革管理以及指導方針有全面而深入的掌握。它也有助於決定、執行與強化以下SOA FAQ（這裏只是列舉）的相關流程：
•系統的定義與修改由誰負責？
•誰有權存取服務？
•我們該提供怎樣的服務品質？
•誰要負擔服務的建置費用？
•由誰負擔服務基礎架構的費用？
•服務的相互依存性應如何管理？
•如何把服務對外公開？
•SOA成不成功應如何測量？
最後，「組織與管理」的功能可確保你SOA計畫的進程，以及它所實現的業務價值可以被測量出來。如果沒有達到該有的水準，則貴公司就可採取成本效益的修正措施了。
總結
本文目的是提供一套清楚指導準則以協助公司利用BEA的「Domain Model」作為規畫、實作與檢視的框架，來導入SOA。本文著重探討長期規畫，說明SOA要成功，必須將「軟體重覆使用」的觀念落實到制度層面加以管理，也必須了解分析現有IT專案對蒐集通用功能的重要性，以及「組織與管理」模型該如何建立。
David Groves為BEA全球諮詢事業群美洲SOA Practices Lead，擁有含括IT策略、企業解決方案諮詢、專業管理及專案實作方法論等11年產業經驗。
本文為投稿作者意見，不代表CNET立場。--
|
|
|
|
| 
對本則報導有任何意見或看法嗎?歡迎留言
