iweroulsdjf

面向服務體系結構（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 原則為導向開始，接著描述了體系結構管理流程作為一項關鍵流程確保了面向服務體系結構的相容性和一致性。還描述了如何為適合的決策制定和開發建立組織結構，以提供所需的角色和職責。最后，本文還講述了如何將治理模型投入使用，并為您提供了我們在該領域所獲得的提示和技巧。