改進您的SOA 專案規劃

轉自IBM DW中國

作者：Yvonne Balzer (yvonne.balzer@de.ibm.com), 高階 IT 管理顧問, IBM Global Services ITMC

面向服務體系結構（Service-Oriented Architecture，SOA）具有顯著提高 IT 效率的潛力。但是要在組織中實現它，僅僅瞭解技術是不夠的，還必須精通管理。在本文中，Yvonne Balzer 會描述能幫助您成功實現任何 SOA 專案的治理原則。

如今，業務和 IT 價值鏈開始在行業中融合。我們現在所說的 企業體系結構和 面向服務體系結構(SOA) 都與 IT 的實現無關。因此，我們也需要建立業務和 IT 之間的橫向聯絡，定義和開發諸如 SOA 這樣的體系結構，並執行專門針對企業的客戶端專案。

出於這些原因， 治理在如今的 IT 行業中的角色變得比以前更為重要。在本文中，我將介紹在 IBM IT Management Consulting (ITMC) 開發組的最佳實踐治理方法，這些方法都已在幾個客戶端專案得以開發和實現。我們將從已經過檢驗的 IT 治理結構和實踐開始，增強治理模式以滿足 SOA 的需求。

動機和問題

由於行業中出現的問題和挑戰， IT 在現代組織中的角色發生了根本上的變化。現在，IT 必須以接近實時的速度非常迅速的反應並靈活的啟用業務。IT 必須設計和管理一部分高度整合的複雜企業體系結構，並且業務和 IT 元件之間的界線也越來越模糊。本文將介紹關鍵的治理功能，它能夠幫助您達到這些目標併成功實現 SOA 專案。

治理提供了一種拱形（overarching）的結構，其目的是為了從戰略性、功能性和操作性層次上支援使用者的業務目標。它為有效的規劃、決策制定、操縱以及 SOA 專案控制而定義了規則、流程、度量和組織結構，以達到使用者的業務需求和目標。最後，治理模型定義了以下內容：

• 需要做 什麼。
• 如何去做。
• 應該由 誰來做。
• 應該 如何進行度量。

該模型同樣也為有效的規劃、決策制定、操縱以及 SOA 專案控制而定義了規則、流程、度量和組織結構，以達到使用者的業務需求和挑戰性的目標。

以下是在 SOA 專案內定義適合的治理結構所涉及的一些關鍵性問題：

• 客戶端從該專案中能獲得哪些好處？客戶端的目標和期望是什麼？
• 在進行 IT 規劃、操縱和決策制定時，有哪些角色、職責、結構和流程是已經存在於客戶端站點的？
• 如何提高技能和領導能力？
• 需要哪些原則和指導方針來優化業務和 IT 之間的關聯？
• 為了企業和 IT 能夠進行互動，以維持一致性並保持足夠的靈活性來快速適應新的變化，什麼樣的構造方式才是適合的？
• 什麼樣的服務規範、服務定義和描述才是適合的？
• 如何控制和度量服務及服務提供者？由誰來對現有服務所進行的修改進行監控、定義並授權？
• 如何決定服務的原始策略？
• 存在哪些問題？專案如何支援客戶端來解決這些問題？

基於我們的經驗，我們相信公認的、正式的治理模型是成功實現業務目標的關鍵。因此，我們建議在 SOA 專案中建立治理功能。該治理模型應該也處理 漸進式改造的基本需求，即集中使用每個步驟中學習到的內容來定義和執行下一步。建立用於 SOA 的改造和實現的治理程式體，是治理模型的核心需求。為快速可靠的完成該項工作，我們提倡使用客戶端現有的結構並共同工作，以改造該結構並使其適應 SOA 專案。

治理模型：SOA 專案的正確形式

IT 治理有一些不同的定義。IT Governance Institute（請參閱 參考資料以獲得相關連結） 給出了一個對 IT 治理的較好的一般概述：

IT 治理是指導部門及執行機構的職責。它是企業治理的主要組成部分，由領導階層和組織結構組成，它確保組織的 IT 能夠維持並可以擴充套件組織 IT 的策略和目標。

IT 治理的目的是指導 IT 以確保它的效能可以滿足業務目標，因此：

*IT 和企業的聯合會使預期的利益變為現實。
*IT 使企業的機遇得到開拓，並使企業的利益最大化。
*IT 資源能夠可靠的使用。
*IT 相關的風險被合理的控制。

圖 1 的治理模型是組織結構、連線流程和相關聯絡的結合。它基於戰略方向和被稱為 治理原則的公認的基本原則。在大量複雜的專案中，該方法通過我們的經驗得到了不斷的改進。由此，我們認識到這些要素是任何型別專案的基礎。

圖 1. 核心治理要素

戰略方向及指導原則

客戶端戰略方向的定義是成功發展適合的 SOA 及持續專注於業務需求的關鍵。對業務策略和目標的普遍理解是業務單位和 IT 的基礎。

治理的原則和指導方針是任何決策的基礎。這些原則和指導方針將規定解決方案的範圍並定義協作的方式。因此，執行部門應該很好的理解接受它們。其中一條主要的指導方針就是 治理方式。兩種主要方式的區別是：

• 中央式治理：這對企業而言是最好的方式。治理委員會擁有來自每個服務域（以後對此將有更多介紹）和專家的表述，這些專家可以與實現解決方案關鍵技術元件的人進行對話。中央治理委員會將在對實現修改授權之前，評審任何對服務的新增、刪除以及對現有服務的變更。
  
  
• 分散式治理：這對分散式團隊而言是最好的方式。每個業務單元都能夠控制在自己的組織內部如何提供服務。這需要功能性的服務域方法。中央委員會可以為不同的團隊提供指導方針和規範。

每個原則都應該依照基礎理論來定義，這些理論用於說明該原則的目的和含義。指導原則定義了 SOA 的開發、維護和使用的一些基礎規則。特定原則用於體系結構設計或是服務定義，也就是說，這些指導原則專注於特定的主題。這些原則具有以下特性，它們能為設計樣式提供固有特徵，並應該包括專案的以下幾個方面：

• 指導原則：
  • 重用（Reuse）、粒度（granularity）、模組性（composability）、 可組合性（composability）和元件化（componentization）
  • 與標準（一般的或是特定於行業的）一致
  • 服務的識別和歸類、提供和傳遞、監控和跟蹤
• 特定體系結構原則：
  • 封裝
  • 業務邏輯和基礎技術的分離
  • 單一實現和元件的企業觀點（enterprise-view）
  • 機遇存在時利用現有資產
  • 生命週期管理
  • 系統資源的有效使用
  • 服務的成熟度和效能

通過理解體系結構和設計的 SOA 樣式的原則，以及這些原則對業務和 IT 的聯合所帶來的好處，您就能在設計解決方案時確定 SOA 的適用性。這些原則驅動服務設計明確的基本特性。您可以將每一個特性對應到一個或多個提供給原則和特性以完整性的 SOA 原則。

治理流程

治理流程是戰略性的 IT 規劃和操縱所需的流程，比如：

• 策略的發展
• IT 規劃
• 業務量管理
• 資源
• 創新管理
• 體系結構管理。

在 SOA 專案中，需要在專案的一開始就建立 體系結構管理流程(AMP)。 AMP 主要的目標是確保已定義的 SOA 的一致性、有效開發以及永續性。

基於我們在許多專案方面積累的經驗，我們開發了一個標準 AMP，您可以在客戶端專案內快速簡單的使用它。該流程由四個子流程組成，如 圖 2所示，這些子流程使用 IBM LOVEM 表示法，定義完善且可用。（ LOVEM即 line of visibility engineering methodology，請參閱 參考資料以獲得更多資訊）。

圖 2. 體系結構管理流程

下面更詳細地介紹圖中的一些要素：

• 體系結構的評審及批准流程：
  • 定義構造好的方法來評審和批准現有 SOA 的變化，做出與 SOA 的路線相一致的決策。
  • 設計和服務的正式評估稽核是關鍵的控制點。
• 體系結構的例外以及漸進發展流程：
  • 提供請求體系結構決策的方法。
  • 允許 SOA 體系結構的例外以滿足獨特的企業需求。
• 體系結構維護流程：
  • 當新的服務新增到體系結構中時，確保 SOA 已被維護且修改已經傳達到風險承擔者。
  • 體系結構的變化都有備有文件說明且被傳達。
• 體系結構通訊流程：
  • 確保 SOA 對每個需要訪問的人都是可用的。
  • 加深對 SOA 重要性的理解

組織結構

為提供體系結構治理，必須在組織內部確立一些結構，定義所有需要的角色和職責，以及定義適當的制定決策的組織結構。經驗顯示，建立 體系結構辦公室很有用，特別是在複雜且龐大的專案中。體系結構辦公室職責是保持 SOA 在戰略、戰術、操作層次上符合業務需求。該辦公室應該包括體系結構設計權威人士，他是體系結構管理流程的所有者。此外，每個層次都定義了角色和職責。

根據我們在客戶端所做的工作，有兩個有效辦法可以用於建立和執行這樣的體系結構辦公室：

• 如果客戶端組織已經有了和體系結構辦公室類似的制度，那麼您應該結合這個現有的組織結構。應該確保所有的功能和職責都能夠明確的用於制定體系結構決策。對於 SOA 專案，這些功能和職責應該涉及到 SOA 決策，並隨時保持聯絡。
• 如果客戶端站點沒有治理委員會，我們推薦您在 SOA 專案的上下文中建立體系結構辦公室，並通過它來決定關鍵的可交付專案。用 SOA 專案中的客戶端和專案人員暫時充當該體系結構辦公室的工作人員。這些人員應該是決策制定者，並且應該包含 CIO。在專案的最後，體系結構辦公室可以被整合到客戶端組織。

圖 3說明了體系結構辦公室以及每個層次上的角色和職責。在戰略層有體系結構部門，它是一個決策部門，負責提交標準和原則，並通過業務和 IT 策略來進行服務的優先順序排序。在戰術層，體系結構組作為體系結構設計權威來運作，負責定義體系結構管理流程，以及定義修改、刪除或新增服務和管理域的決策準則。在操作層，專案組開發和實現服務。

圖 3. 體系結構辦公室

每個專案組都需要角色描述來定義其任務和職責以及操作的模式。

SOA 治理引入 域所有權的概念， 域管理一系列共享常用內聚業務的可重用服務。在很多情況下，這些是業務服務的子集，比如使用者資訊、案例資訊、商業競爭統計資訊等等，以及競爭參考，比如商業風險等級、產品分析和規劃服務。每個域負責維護自己的業務物件，也負責對其他的域釋出服務介面。域為業務物件提供服務檢索和維護、封裝業務邏輯、定位以及與物件和服務相關聯的格式。當主管某個產品或產品領域的人希望從域獲得服務時，他們生成一個請求並且兩個組確定相互聯絡，建立服務層次協定。這些聯絡和協定也存在於域之間。

根據域所有權的概念，一些新的角色和職責應被提供給在 SOA 專案中的開發生命週期，如下面的 表格 1所描述。

表格 1. SOA 專案中的角色和職責

角色	描述
域所有者	管理域的方向，域包含了一個或多個服務的聚集，也包含了業務聯絡以幫助多個業務單元中的所有者理解業務透視。資料和流程的所有者使用業務分析員來闡明業務目標和需求。跟蹤 ROI 計算服務的使用。
域的物件導向業務分析人員	開發人員使用沒有假定使用者介面的服務功能性案例。確保完全提取的規格化業務服務都被識別並指定。必須堅持嚴格且靈活的服務定義和開發生存週期。
業務代表	為域識別和分析業務服務。
域開發人員和維護人員	與面向服務開發生命週期一致的建立和維護服務。建立並實現符合開發規則的服務（例如，服務設計注意事項或 Web 實現指南）、 SOA 以及參考體系結構。
服務測試人員	確保服務經過嚴格的測試，以獲得合適的業務價值。為功能性介面以及它的獨立實現建立測試案例。

在給定服務域中工作的人員負責開發業務和技術的整合，以提供可以跨業務界線共享的業務服務，使成員和區域受益。當他們將應用程式中開發的功能轉換成服務域中開發的功能時，便會在組織結構（角色和職責）中為應用程式的開發引入變化。

將治理模型投入使用

開發治理模型的流程基於一個具有三個步驟的方法。該方法基於時間約束（time-constrained）客戶端專案而開發。成功的關鍵是治理功能的建立。

• 步驟 1：實施
  • 在適當的位置設定核心治理功能，並支援客戶端業務操作。
  • 邊做邊學，才能迅速成功。
  • 使用經驗豐富的專業人員擔當高層管理角色。
• 步驟 2：專業化
  • 建立必要的結構、流程、方法和工具。
  • 吸取步驟 1 中的經驗。
  • 使用有經驗的架構師和專業人員。
• 步驟 3：穩固
  • 傳授並培訓客戶端人員執行操作。
  • 將操作模式變為指導模式。
  • 使用有指導經驗的顧問和專家。

圖 4對這些步驟進行了更詳細的描述

圖 4. 將治理模式投入使用
 

提示和技巧

以下是我們從實際專案中獲得一些實踐經驗：

• 有規律的通知每一個需要訪問的人（通過專案通訊稿，或者也許是開會）。SOA 創立了組織文化也改變了技術，這可能會產生溝通障礙，因此互相通訊非常重要。
• 將每個決策、約束和設想記入文件，以確保決策制定的說服力和透明度。
• 定義關鍵的交付以及必需的工具集和模板。
• 為生存週期的管理和方案設定實踐工具。
• 用基本原理定義決策，並文件化和傳達這些決策。
• 必須保持所有風險承擔者的有力支援和決策制定者的說服力。

  結束語

  本文說明了治理為什麼重要以及 SOA 專案中需要什麼。並對我們 SOA 治理模型的一些關鍵要素進行了概述。從以 SOA 原則為導向開始，接著描述了體系結構管理流程作為一項關鍵流程確保了面向服務體系結構的相容性和一致性。還描述瞭如何為適合的決策制定和開發建立組織結構，以提供所需的角色和職責。最後，本文還講述瞭如何將治理模型投入使用，併為您提供了我們在該領域所獲得的提示和技巧。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-600841/，如需轉載，請註明出處，否則將追究法律責任。