以業務為中心設計 SOA–要錯過 SOA 的最大的優勢

基於項目的 SOA 解決方案通常採用自底向上以技術為中心的方式開發。通過這些解決方案，可實現 SOA 入門，並提供 SOA 設計和開發工具方面的實踐經驗，但從企業體繫結構的角度而言，這樣帶來的好處通常很少。缺乏企業級 SOA 方法的組織仍然可以成功實現 SOA，不過卻會和 SOA 的好處失之交臂。

來自 IBM WebSphere Developer Technical Journal.

企業體繫結構與 SOA

回顧進行過的很多 SOA 客戶合作項目，我發現幾乎所有的客戶都會想到在其服務導向架構（Service-Oriented Architecture，SOA）解決方案的設計和部署中採用自底向上方法。總的說來，他們在分析現有資產、支援（或僅僅“封裝”）相關項目（或他們認為相關的項）以及開發服務類別目錄來處理需求方面都做得相當不錯。總的說來，通常是業務部門要求使用 SOA 作為體繫結構模型來進行以 IT 為中心的整合。其積極的一面在於，此方法提供了靈活性和基本的重用，但 SOA 的最大的回報並非在於此。

在企業級實現 SOA 成功需要將 SOA 概念與企業體繫結構的業務（及技術）戰略及治理整合，並要支援自頂向下（及自底向上）SOA 解決方案分析和設計。通過關注業務方面，將其作為 SOA 設計和開發不可或缺的一部分，組織就能更好地從其 SOA 解決方案獲得實際的價值。

之所以有這篇文章，我的目的是希望能夠增強將 SOA 設計與以業務為中心相結合的概念。本文並不是要作為企業體繫結構或 SOA 設計方法方面的教程，如果您希望瞭解更進一步的資訊，請參考參考資料部分提供的有關 IBM 的 SOA 方法的資訊。

回頁首

從項目級到企業級

開始之前，讓我們澄清一點：在項目層級進行 SOA 採用工作並沒有什麼錯，事實上，大多數企業 SOA 活動通常都是從恰當劃定了範圍的項目開始的。此外，採用企業體繫結構的組織會希望通過實驗實現來驗證 SOA 解決方案。關鍵是要通過項目/實驗級獲得的經驗，並將其推廣到企業體繫結構層級。

我在數周前與一家大型企業的首席企業架構師進行了一次有意思的交談。儘管最初討論的是 SOA 的技術方面和 SOA 設計模式，但我們花了大量時間討論 SOA 和企業體繫結構。在客戶的 IT 戰略中，SOA 是按逐個項目的方式實現的。這個以項目為中心的開發方法是目前實現 SOA 的大部分企業的特徵——是由於傳統企業文化和基於項目的資金投入模型促成的。儘管以項目為中心的 SOA 活動提供了一定的好處，但企業層級的 SOA 支援能夠提供更大的靈活性和服務重用，並能促使在業務和 IT 之間進行更好的相關。除非 SOA 成為企業體繫結構的一部分，並徹底進入組織的開發、設計、部署和治理方法，否則就不能完全實現 SOA 的最高回報。

在企業層級成功實現 SOA（及後續的其他成功）能帶來更多的好處，包括快速適應市場動向、縮短新解決方案的上市時間、提供與業務需求的聯絡以及減少長期 IT 成本。2006 年進行的 IBM Institute of Business Value 調查可為這些結論提供支援。

另一方面，項目驅動的 SOA 實現面臨的一個挑戰是，對解決方案提升，使其不僅在一個服務調用集合上工作。通過在企業體繫結構層級整合 SOA，可使其成為業務/IT 生態系統的一部分。通過此方法，可將服務作為建立新解決方案的基礎，並能夠提供業務需求與 IT 解決方案間的內聚。

在圖 1 中，業務和 IT 戰略對企業體繫結構的定義和規範起到促進作用。從下遊的角度而言，企業體繫結構支援在組織層級以資訊、應用程式和組織方面為中心進行規劃。此架構實現企業級治理，並為 IT 解決方案設計和交付提供指導和支援。企業層級的 SOA 設計通常要求 SOA 成為企業體繫結構的戰略、規劃和執行層的主要支援架構。

圖 1. 關注項目與關注企業的情況對比

圖 1 供稿人：Gil Long ，IBM 傑出工程師來源：IBM Global Services – EA Method Class.

回頁首

對業務進行分解

為了在企業體繫結構中將 SOA 作為戰略和規範不可擷取的一部分啟用，通常需要瞭解組織的核心競爭力，以確保在營運目標和體繫結構需求之間建立緊密的聯絡。分析企業中的核心功能的流程可以通過各種技術來完成。例如，IBM Global Business Services 使用組件業務建模（Component Business Modeling，CBM）來評估組織競爭力。ibm.com 提供了有關 CBM 流程的文獻供參考。

從較高的抽象層級而言，CBM 是相對較為直觀的概念。CBM 解決方案的基礎是組織核心心業務組件的定義。業務組件是提供特定業務價值的人員、技術和資源的分組，能獨立進行操作。銷售管理和產品管理/營銷以及人員、流程和技術方面（進行呈現或執行功能）都是業務組件。業務組件支援從分析和記錄所使用的商務服務以及組件提供的服務的角度對業務功能和服務進行標識和設計。例如，“銷售管理”業務組件可能會使用來自帳戶管理的服務，並可能向其他組件（如“收貨”）提供銷售訂單處理之類的服務。

派生出業務組件後，CBM 允許我們根據其相對於業務的總體成本對其進行分類，並評估業務部門是否會認為這些功能具有足夠的競爭力。通過對競爭力進行分組，可標識有待改進和最佳化的地區。圖 2 顯示了一個樣本 CBM 工作產品，其中反白了標識為需要進行持續分析和設計的地區的組件。

圖 2. 樣本組件業務模型

所標識的這些“重點地區”可能成為流程建模之類的 SOA 設計活動的輸入。例如，如果我們決定帳戶開立 (Account Opening) 是有待改進的地區，我們可以通過清楚說明與帳戶開立相關的業務遠景、營運目標和使用者規範來確定初始需求。

作為此流程的樣本，我們在進行與大型零售銀行的合作項目時在內部使用了 CBM。在分析期間，我們認識到帳戶管理 (Account Management) 是該銀行的一項核心競爭力，同時也是客戶滿意度和減少客戶大量流失方面的一項重要決定因素。CBM 活動認為，帳戶開立流程可通過轉換為跨銀行的多個業務部門支援更為簡單和標準的流程集（如服務）獲益。通過交付這個增強功能可以減少成本並增加客戶滿意度。通過將 CBM 分析與 Information Warehouse 資訊及流程建模結合使用，此銀行目前正在積極地開發企業級解決方案來跨各個業務部門對帳戶開立流程進行轉換。

CBM 技術提供了一個架構，用於確定組織中的主要競爭力和從後續步驟方面提供有關組織最佳化的指南。此外，幾乎每個主要垂直行業都可以通過 IBM Global Business Services 合作項目獲得的 CBM 模版。業務組件設計流程會在業務層級定義需要改進的戰略地區、將這些目標與商務服務視圖進行協調並將此服務視圖與 IT 規劃結合使用，從而為企業體繫結構提供輸入。

回頁首

面向服務的建模與體繫結構

服務建模方法對獲得經過最佳化的服務模型來實現解決方案設計非常重要。面向服務的建模和體繫結構（Service-Oriented Modeling and Architecture，SOMA）技術提供了嚴格的有相關記錄的分析和設計方法，用於確定 SOA 解決方案。SOMA 是 IBM 的端到端 SOA 解決方案開發方法。我在此將不會對 SOMA 進行詳細討論，而將重點討論以業務為中心進行 SOA 設計的概念。不過，Ali Arsanjani 所撰寫的出色文章中對 SOMA 進行了詳細討論。（請參見參考資料。）

SOA 模型中三個基礎構造是服務、服務元件（實現這些服務的實現實體）和編排服務的流（或流程）。之所以提出 SOMA，主要是用於處理所有這三個構造的分析和設計工作。正如 Rational Unified Process (RUP) 中所述，SOMA 實際上由三個主要步驟組成， 3 中所示。

• 服務識別：派生和定義候選服務。
• 服務規範工作：建立並驗證服務公開決策和進階服務模型的派生物。
• 服務實現：從整體組件設計的角度確定屬性並擴充進階服務模型。

圖 3. SOMA 的三個步驟

儘管 SOMA 通過多種方式在 SOA 與業務之間建立聯絡，但服務識別和 Service Litmus Test（服務規範的第一個關鍵步驟）是我們將重點關注的領域。

服務識別

正如前面提到的，服務識別步驟的主要輸出是一組候選商務服務。可通過三種技術在服務識別過程中產生候選服務列表：

• 自頂向下方法，稱為域分解。
• 自底向上以 IT 中心的方法，以對現有 IT 資產進行發現和描述其特徵為重點。
• 中間相遇方法，稱為目標-服務建模。

域分解提供自頂向下業務驅動的技術，旨在捕獲關於組織的重要業務域、功能與概念子系統和商務程序的資訊。域分解是通過源自業務組件設計的業務需求規範實現的。此外，還可以通過使用 WebSphere Business Modeler 之類的工具對流程模型進行建立和驗證來啟用域分解。

商務程序建模通常在業務組件的設計中的主要商務活動標識工作之後進行。流程建模通常首先由業務分析人員使用工具來建模商務程序的現有（當前）狀態。在流程模型中，分析人員給出作為流程中的步驟的工作活動或任務。隨著流程模型的發展並由其他業務涉眾進行複查後，“任務”將成為類似於候選服務的項目。在有些建模工具實現（如 WebSphere Business Modeler）中，業務分析人員可以設計現有模型和將來模型，並能夠對流程進行類比，以確定運行時特徵，包括成本、資源需求和流程瓶頸。有些工具還支援對業務關鍵業績指標（Key Performance Indicator，KPI）進行定義和規範。帳戶開立的業務 KPI 之一可以為，要求開立帳戶的平均時間不應超過 18 個小時。通過持續的設計和類比工作，流程建模可在業務需求和商務服務之間建立聯絡，從而協助標識候選服務。

現有資產分析技術可通過工具加以利用，也可以通過回顧現有 IT 資產的現有文檔和知識來進行利用。此活動檢查可能考慮用於實現將來流程所需的功能的現有 IT 資產。現有資產的來源可能包括以下方面：

• 基於大型主機（例如 CICS/IMS/Batch）的事務。
• 通過 API、訊息傳遞或服務介面串連的商務應用程式（如 SAP、Siebel）。
• 自訂內部應用程式，如 J2EE、.Net 和客戶機/伺服器應用程式。
• 通過夥伴獲得的外部服務和組件的服務與介面。

可以用於支援此功能的工具之一就是 WebSphere Asset Transformation Workbench。此工具可協助 IT 人員對現有應用程式進行擴充、重用和轉換，並支援對大型主機和/或分布式環境中的應用程式進行依賴關係分析。

對於域分解，資產分析活動所得到的結果是潛在候選服務列表。其中應該清楚地指出，所發現的資產（以及潛在候選服務的第一次迭代）並不等於服務。事實上，大部分操作都是細粒度的，即使是組合後的服務（如通過 SAP 的 IDOC 或 BAPI 互動）也是如此。這些候選服務通常在遵循 SOA 設計原則方面並非極為理想，將可能使用更抽象的服務對其進行封裝。

最後，目標-服務建模從自頂向下和自底向上方法派生，使用業務和 IT 需求促進其他候選服務的標識。此活動可協助標識與業務一致的服務，確保發現在域分解或現有資產分析期間未能標識的服務。目標-服務建模從營運目標標識開始，將其細分為子目標，然後確定需要哪些服務來完成這些子目標。

服務規範

SOMA 中的第二個主要階段是服務規範。此技術包含一系列步驟，但對於文本，我們將主要討論兩個活動：

1. 應用 Service Litmus Test，以確定候選服務是否適合公開。
2. 從依賴關係、組合、非功能需求、訊息定義和狀態管理需求的角度確定服務模型規範。

Service Litmus Test 是所定義的一組標準，用於確定是否應該公開候選服務。這些標準主要歸為四個大的領域：

1. 業務一致性：關注服務的業務相關性、是否存在用於支援開發和維護的資金投入模型以及在整個組織內共用服務的能力。

2. 可組合性：關注與組合層級的非功能需求的一致性、狀態管理方面的注意事項、服務依賴關係的標識以及對技術/平台獨立性的支援。

3. 外部化服務描述：關注是否存在外部服務描述（如 WSDL）、支援通過服務描述進行服務發現和綁定的能力以及將中繼資料作為服務描述的一部分提供。

4. 冗餘消除：關注跨所需特定功能的多個組合情境重用候選服務的能力。

通過這組問題，設計團隊可以就哪些服務應該作為服務實現開發、公開和管理做出恰當的體繫結構決策。

作為 Service Litmus Test 的樣本，我們與一家大型運輸與物流公司舉行的研討會確定了超過 400 個最初被視為候選服務的業務相關 SAP 互動（BAPI 和 IDOC）。除了這組服務，還有其他近 400 個自訂應用程式中公開的服務。總共有超過 800 個候選服務。儘管此分析工作仍然在繼續，但我們預計公開的服務的數量將不會超過 200 個。

服務模型的定義由多個步驟組成，通常會由此建立 UML 成果。可通過使用體繫結構工具（如 Rational Software Architect 和 UML Profile for Software Services）協助進行此步驟。在此步驟期間，將通過記錄服務依賴關係、定義服務組合、記錄服務非功能方面、定義進階服務訊息模型和指定狀態管理需求來設計服務模型。

服務實現

作為 SOMA 中的最後一項主要活動，服務實現將定義組件的服務分配以及這些組件到實現解決方案的分配。例如，某個服務可能通過使用我們作為 Web 服務公開的 EJB 實現，而另一個服務可能通過封裝一個或多個 CICS 事務實現，另外的服務還可能通過提供 J2C 互動模式的適配器實現。

回頁首

實際運用

我們在討論的過程中已涉及了三個核心地區：企業體繫結構、業務組件設計及通過 SOMA 的 SOA 分析與設計。這三個領域如下面的關係圖中所示：

圖 4. SOMA 的三個核心領域

企業體繫結構內的戰略及評估與核心組織競爭力分析間的聯絡將導致一組進階業務與 IT 需求的出現。這些需求反過來形成了 SOA 設計業務需求的初始步驟基礎。

4 中所示，此流程實際上具有迭代性質。隨著新市場動向開始促使企業體繫結構成形或隨著組織的核心競爭力發生更改，這些更改要求對其對整體服務設計的影響進行分析。此外 SOMA 服務建模流程中的步驟也具有迭代性質。由於開發服務模型或開始考慮服務實現的各個方面的因素，我們可能最終會回到之前的設計工作中所做出的決策。

在 Grady Booch 的 developerWorks Blog中，他給出了非常精闢的評述：

我認為，SOA 的價值主張源自其縮寫中的 A：體繫結構 (Architecture)。其在治理和發展系統的體繫結構方面具有可靠的、經過驗證的價值；另外還必須堅進行一些艱難的抉擇，其中的很多決策都不能視為前瞻性的（正是由於這個原因，其流程以有規律的增量式迭代發布可執行版本才如此重要）。

結束語

基於項目的 SOA 解決方案通常會採用自底向上以技術為中心的方法，可協助實現 SOA 設計與開發入門，但從企業體繫結構的角度而言，其提供的好處非常有限。

通過採用以業務為中心的方法設計 SOA 解決方案，可在企業層級將業務需求與 IT 開發流程聯絡起來。通過將 SOA 定義為主要支援體繫結構，可為企業解決方案開發提供可靠的基礎平台。將 SOA 作為核心企業解決方案方法的這種實現方式可允許基於組織的核心競爭力定義需求及確定其範圍。將這些業務和 IT 需求作為輸入，可以通過 SOMA 之類的服務開發方法以最佳的方式設計 SOA 解決方案。設計 SOA 解決方案的這種方法可提供服務的企業級視圖，而且能縮短新應用程式上市的時間，並同時減少通過服務重用公開的 IT 資源。更為重要的是，以業務為中心的 SOA 解決方案設計可確保 SOA 與組織的相關性及其對組織的價值。