引言
雖然 SOA 可以帶來許多好處，但同時也可能受到以下一個或多個問題的困擾：
- 高復雜性和短上市時間，這樣會增加失敗的風險
- 由于高成本和量化投資回報 (ROI) 困難而導致較難容忍出現錯誤
- 需要恰當管理的動態要求和業務需求
如果您使用了軟件方法——軟件開發的系統方法——來在初始 SOA 推出期間提供所需的嚴格控制和過程，并在優化 SOA 的過程中進行調整，就可以避免這些問題。在考慮此處給出的軟件方法之前，請閱讀本系列的第二篇文章，該文指出，在面向服務的體系結構成熟度模型的第 3 級或第 4 級的“面向服務的體系結構成熟度模型”組織應使用 RUP 等正式的軟件方法進行開發工作。只要達到了第 5 級，他們就應該使用 XP 之類的靈活方法了。
您的企業如何在保持開發過程一致的前提下過渡到較高的成熟度級別呢？本文將介紹一種最佳組合的方法，面向服務的統一過程 或 SOUP，用于開展構建工作并隨后進行持續優化。在繼續閱讀本文之前，您應當對 RUP 和 XP 的工作方式有基本的了解。請參閱參考資料，以獲得可幫助您了解相關知識的鏈接。
什么是 SOUP？
SOUP （Service-Oriented Unified Process）是一種使用 RUP 和 XP 中的最佳部分來構建和管理 SOA 項目的軟件方法。它的目標是任何組織中正在進行的 SOA 項目。
典型的軟件開發項目包含應用程序開發過程、項目管理以及所使用的技術。此外，軟件開發項目通常具有四個變量：時間、預算、范圍 和質量。任何一個變量的變化對整個項目都有影響。不斷變化的業務需求使得范圍和質量成為兩個最難管理的因素。技術復雜性可能導致時間和預算管理方面出現問題。
SOA 項目比通常的軟件項目復雜得多，因為它們要求配備更大的跨功能的團隊，并且還有因此而帶來更復雜的團隊間溝通和日常管理工作。
雖然 SOA 可以為組織帶來許多好處，但同時也可能帶來很大的成本支出和時間消耗。如果項目沒有經過良好定義，并且在項目啟動時沒有關于最終結果的遠景，則失敗的可能性就非常大。
可以幫助 SOA 成功完成的關鍵因素有：
- 明確定義的開發過程
- 與業務相關的項目團隊之間增強的溝通渠道
- 明確的支持和控制策略
在初始開發過程中，采用正式軟件方法是盡可能地減少已確定的風險的最好辦法。成功建立了 SOA 項目后，可利用正式的維護和增量開發方法來增加項目的 ROI。然而，XP 之類的靈活方法可能不夠正式，不適合在初始階段使用。SOUP 方法可幫助減少 SOA 推出階段的風險，并能讓您隨后進行持續 SOA 優化工作。
SOUP 是一個由六個階段組成的軟件開發方法。每個階段代表對于 SOA 成功推出非常關鍵的一組特有的活動。當然，和在任何項目中一樣，您將需要根據所在組織的情況對相關過程進行調整。
圖 1 顯示了 SOUP 過程。此方法也沒有非常特別的地方：所有軟件或 SOA 項目都是采用類似的方式定義的。
圖 1. SOUP 過程模型
我將 SOUP 過程分為兩類：
用于初始 SOA 部署的 SOUP
圖 2 顯示了用于初始 SOA 部署的 SOUP 的各個階段。
圖 2. SOUP 與 RUP 模型
每個階段都包含主要交付內容和活動：
初始
在此階段，將確定組織對 SOA 項目的需求。您可以通過應用 SOA 成熟度模型來確定組織的體系結構成熟度水平并確定 SOA 的驅動因素。此時，您將需要向為業務服務的所有項目團隊說明 SOA 的基本概念，并擬訂與反饋和建議流程有關的策略計劃。
此階段的主要交付內容有：
-
SOA 遠景和范圍：給出項目的整體遠景。它還提供了確定項目范圍的邊界，該范圍至少應包含兩個業務線或項目。
-
SOA 策略：說明項目將如何執行的概略計劃。
-
ROI 分析：給出此項目將帶來的成本支出和節省情況。
-
溝通計劃：說明 SOA 團隊將如何與其他項目團隊和業務用戶進行溝通。
客戶（即業務干系人）通常并不能完全了解新軟件產品可以帶來的好處。定義 SOA 策略的企業團隊需要利用項目團隊的專業知識來幫助確定業務問題以及簡化操作的方法。
跨功能分析人員和項目管理人員將對客戶的業務進行分析，以確定基于 SOA 的解決方案的優勢。分析人員將對客戶的內部操作進行研究，此外還要分析其與合作伙伴、供應商以及他們的客戶的交互情況，而且也會研究其總體業務模型。這些因素有助于分析人員制定 SOA 策略并向客戶推薦。
在此階段，您還需要對推薦的 SOA 策略進行全面的 ROI 分析。此分析應當清楚地表明短期、中期和長期的成本優勢。
此階段最重要的交付內容是溝通計劃。項目 IT 團隊和業務干系人比體系結構團隊和分析人員更了解業務。溝通計劃可以確保這些內部干系人能夠理解并參與到開發過程中來。
定義
到目前為止，定義階段是 SOA 項目中最為關鍵的階段。此階段業務和項目團隊的參與將最終決定項目的成功。團隊成員需要積極地參與到作為初始 SOA 推出的一部分開發的需求定義和用例方面的工作中來。
項目生命周期的此階段的活動包括：
- 收集需求
- 分析需求
- 定義非功能需求
- 制定項目計劃，其中包含時間安排和項目估算
- 定義技術基礎設施
- 定義和實現用例
- 定義和記錄總的體系結構
此階段的主要交付內容有：
-
功能需求文檔：詳細描述 SOA 將作為業務服務提供的所有業務流程。
-
非功能需求文檔：包括性能注意事項、服務水平協議 (SLA) 和基礎設施要求。
-
用例和用例實現：詳細說明將構建的所有業務服務的用例。
-
SOA 體系結構文檔：描述項目總的體系結構，包括硬件和軟件組件。
-
SOA 適用性文檔：說明哪些項目將在 SOA 項目的范圍內以及如何在 SOA 的基礎上構建后續項目。
-
基礎設施定義文檔：包括詳細的基礎設施部署圖，其中列出相關服務器以及實現 SOA 所需的服務器的連接和連接位置。
-
項目計劃：整個項目的詳細計劃，包括里程碑和依賴關系。
-
支持和控制模型：描述將如何支持和控制 SOA。其中包括各種注意事項，如 SLA 監視和管理。
研究（請參閱參考資料）表明，與需求相關的問題是軟件項目失敗的首要原因；SOA 項目也不例外。軟件質量 有時定義為軟件對其需求的滿足情況。但是，測定軟件質量的更好辦法可能是通過其滿足的需求的質量 測定，而不是通過其滿足的需求的數量 測定。
在明確說明了交付內容后，SOUP 方法將建議一個用于進行需求收集和管理的正式流程。XP 并不定義用于收集和記錄需求的正式流程；而 XP 開發人員將創建一些用戶案例（請參閱參考資料）并按邏輯順序對這些案例進行排列，以提供一個需求序列。在此開發階段，這樣的流程并不夠用。在 RUP 中，相應的流程更為詳細，并使用更多的正式技術來確保舉行相關的需求收集會議、對需求進行記錄并加以驗證。我建議使用需求存儲庫，該存儲庫將與用例、設計和代碼緊密結合，以在項目進行的整個過程中提供可跟蹤性。該存儲庫可以為 IBM Rational? RequisitePro? 工具或您組織選用的任何其他需求管理工具。更改管理流程也很重要。
此階段最重要的交付內容是支持和控制模型。組織將如何支持 SOA？控制指導方針有哪些？如果推出了一個 SOA，但沒有人使用，則項目就失敗了。支持和控制模型文檔可以防止發生這種情況。
企業應當在制定了真實可行的計劃和目標的情況下啟動項目。其他需求應留待以后解決。如果在預期的時間和預算內，可以完成有關需求的有效業務-IT (B2IT) 協作，則可以幫助確保項目的成功。
請在項目早期定義支持整個 SOA 所需的技術基礎設施。這包括服務器、網絡基礎設施和培訓要求方面的詳細評估。
設計
在設計階段，您將對定義階段確定的設計構件進行細化。用例實現和軟件體系結構文檔將轉化為詳細的設計文檔。
此時，SOA 架構師（通常為企業架構師中的一部分）需要與項目架構師合作，以確保 SOA 團隊給出的設計可以供具體的項目使用。SOA 架構師甚至可能選擇完成一些概念驗證 (proof-of-concept) 項目，以證明 SOA 遠景。此階段的主要交付內容有：
-
詳細設計文檔：描述如何設計和構建服務。
-
應用程序編程模型：提供有關設計開發項目的結構的指南。涉及的主題包括使用的流程和技術、編碼標準以及部署過程。
-
數據庫模型：包括 SOA 使用的數據庫的實體關系圖。
-
測試和 QA 計劃：詳細說明測試和 QA 計劃，并在其中包括測試用例。
構造
在構造階段，將使用您選擇的迭代構建方法來構建 SOA。此階段中包括新的開發和集成活動。您的活動不僅限于軟件方面，還涉及到與基礎設施相關的子項目，如硬件整合項目或服務器承載集中化工作。雖然整個工作是在單個 SOA 項目中進行管理的，但仍然很有可能將由各種小型子團隊進行不同的構造活動。
項目生命周期的此階段將涉及到各種活動，如：
此階段的主要交付內容有：
-
基本代碼：該代碼應存儲在某類源代碼管理存儲庫中。
-
測試結果：執行測試用例和 QA 計劃的結果應可供進行檢查分析。
-
文檔：文檔中應包含關于代碼以及對設計文檔的任何更新的詳細信息。
部署
在部署階段，您將向各個項目團隊推出 SOA，這些項目團隊將開始在其生產環境中的項目上使用此 SOA。此階段最明顯的主要交付內容或許就是投入生產環境中使用的應用程序。然而，SOA 試驗項目的計劃卻是更為重要的交付內容。這將導致進入 SOUP 方法的下一個步驟，該步驟將確定后續項目如何使用新體系結構。此階段的其他主要交付內容有：
-
部署模型：給出總的 SOA 部署結構。
-
用況模型：提供有關如何使用 SOA 的指南。隨著各個項目團隊和業務線開始使用新體系結構，此模型會變得非常重要。
-
后續支持級別模型：將對定義階段開發的支持和控制模型的任何更新進行系統化。
支持
軟件開發周期的這最后一個步驟非常重要。在支持階段，您將確保提供后續 SOA 支持、錯誤修正和進行新功能開發。項目生命周期的此階段將涉及到各種活動，如：
您的 SOA 現在已經投入生產了。但項目團隊如何從該體系結構受益呢？為了構建使用現有服務的應用程序，或設計使用現有 SOA 的新服務，他們是否需要遵循上面詳細列出的所有步驟？正如您將在下面的部分中看到的，實際上，他們可以從一個更為輕量級的方法中獲益。
用于后續 SOA 管理的 SOUP
SOUP 方法可以用于那些使用已經推出的 SOA 的項目。在這種情況下，SOUP 對 XP 進行了大量的參考。圖 3 表明了 SOUP 和 XP 過程彼此重疊。
圖 3. 重疊的 SOUP 和 XP 過程
這種方法主要帶來什么樣的好處呢？SOA 項目的價值在于，它可提供良好定義的體系結構和嚴格的技術指南。您獲得了一個框架，可以在其中以服務的形式構建應用程序。項目團隊的主要任務是構建和使用服務。他們最適合執行這些任務，因為他們具有必要的業務領域知識。但是，他們并不需要考慮技術體系結構或技術的創新，因為這些任務將由 SOA 團隊完成。
此類項目將遵循上一部分中列出的相同 SOUP 指南；不過，您將發現，每個階段的工作量都大幅度地減少了。這一部分的許多交付內容都和前面描述的一樣；必要時，我會說明它們與從頭構建 SOA 時的項目中的對等項之間的差異。
初始
啟動 SOA 并運行后，仍然需要進行一些開發工作。您無疑將希望構建使用現有服務或公開新服務的項目。初始階段的主要交付內容有：
-
項目遠景和范圍：這僅包含單個項目的范圍，而不包含更大的 SOA 計劃的范圍。
-
項目策略：描述此具體項目的策略和流程，并說明其如何利用 SOA。
-
ROI 分析：項目的詳細成本優勢分析，這對于幫助進行與實現有關的決策非常關鍵。
定義
在定義階段，您將構建與 SOA 項目有關的各項內容，并了解如何利用 SOA。您需要標識 SOA 可以提供的服務和仍然需要構建以滿足您的項目目標的服務。
項目生命周期的此階段的活動包括：
- 收集需求
- 標識服務
- 制定項目計劃，其中包括時間安排和項目評估
- 開發測試用例
此階段的主要交付內容有：
-
功能需求文檔：軟件項目的典型需求文檔。
-
用例和用例實現：涵蓋所有正在構建的新業務流程。
-
SOA 適用性文檔：說明現有 SOA 框架如何應用到此項目。
-
項目計劃：詳細說明整個項目，包括里程碑和依賴關系。
-
服務策略：標識已經存在并能夠使用的服務以及可以公開的新服務。
-
測試計劃：其中包括項目的測試用例。
在此階段，您不需要嚴格遵循在 SOA 推出期間遵循的正式需求收集標準。相反，可以通過用戶案例或類-責任-協作者（Class, Responsibilities, Collaborator，CRC）卡（請參閱參考資料）來簡化需求收集。根據 XP 的思想，測試案例是在這種類型的項目的早期構建的。
設計
此階段可以迅速完成，因為大部分服務都在初始 SOA 推出時已經完成。在設計階段，只需要關心如何使用這些服務，需要在現有服務的基礎上構建什么功能，以及需要構建哪些新服務。
此階段的主要交付內容有：
-
詳細設計文檔：說明您的設計如何利用總體 SOA，并建立設計與應用程序編程模型。
-
數據庫模型：封裝供此特定項目使用的邏輯和物理數據設計。
構造
構造階段涉及更多的是裝配，而不是新部署。隨著提供的服務越來越多，每個項目都將有越來越多的可重用服務，而需要構建的新服務也就越來越少。XP 的迭代開發技術是此開發階段的最佳選擇。在 XP 中，理論上的迭代周期設置為兩周，當在 SOA 環境中構建小型服務和使用一組服務時，這一時間對于一個開發 Development-QA 周期來說絕對足夠了。使用此迭代方法，SOA 可以通過快速軟件發布提供有價值的業務靈活性。
項目生命周期的構造階段的活動包括：
此階段的主要交付內容有：
-
新服務：在本階段結束時，任何將要公開的新服務都會準備就緒。
-
測試結果：執行測試用例所得到的結果應提供給所有相關方。
-
文檔：此開發階段應產生詳細的代碼文檔以及對以前創建的其他文檔的所有必要更新。
部署
在此階段，將啟動使用多個服務的應用程序，或啟動新服務。由于基礎設施是由 SOA 團隊進行管理的，因此該流程相對比較簡單。
支持
在此階段，將僅為您的新服務提供支持。在進行此項工作的過程中，請遵循在原始 SOA 項目期間制定的支持指南。單個項目不需要花很多時間制定新的支持指南。
管理 SOA 生命周期
本文向您介紹了 SOUP，這種新的軟件方法可用于構建 SOA 并將此體系結構的好處帶給各個項目。文中說明了可以如何使用類似于 RUP 的正式方法來對 SOA 進行初始構建，然后轉向 XP 樣式的靈活流程，以進行后續服務推出工作。通過實現這兩個過程的最佳組合，您可以依靠一個統一的開發模式來進行相關工作，此模式可提供足夠的靈活性，以便對 SOA 生命周期的不同階段進行管理。