在“成功規劃SOA”系列文章的第一篇文章：SUCcessfully Planning for SOA（中文版，dev2dev，2005年12月）中，我討論了什么是面向服務的架構（Service-Oriented Architecture，SOA），以及如何確保它為您的業務交付價值。我非凡關注了域模型的業務策略與流程、架構以及成本和收益等方面。第二篇文章討論了如何創建有效的SOA路線圖。在這最后一篇文章中，我將介紹域模型的其余3個方面：構件塊(Building Blocks)、項目和應用程序(PRojects and applications)，以及組織和治理(Organization and Governance)，并將重點放在如何把它們集成到長期項目規劃中去。
如圖1所示，BEA SOA域模型是一個強大的工具，有助于指導客戶實施SOA規劃戰略。圖中重點顯示的6個主要部分應給予同等重視，以確保實現成功。
圖1. BEA域模型
本系列前面的文章考察了開始3個部分——業務策略與流程(Business Strategy and Process)、架構(Architecture)以及成本和收益(Cost and Benefits)。然而，實現開始后，對SOA的規劃并沒有終止，而是繼續貫穿于SOA項目的每個階段。
當進入迭代和增量階段后，域模型的最后3個部分對于確保動態評估以及項目的靈活性都相當有用。對正在進行的項目進行有效評估可以使您在發現沒有成功地交付業務價值時馬上進行糾正。本文的其余部分將更具體地分析其中每個部分，并說明它們對于SOA長期規劃的作用。
SOA依靠于成功地將重用制度化。SOA的構建塊是分散、可重用的服務和架構元素，可以用于構成復合的應用程序和服務基礎架構。每個構建塊在實現之后就會被添加到SOA功能的總體目錄中。隨著該目錄的增長，對于未來要開發的項目來說，需要開發的新代碼和服務基礎架構就將減少，維護成本降低，而且ROI也肯定會穩步增加。
明確地定義一個服務，并能夠以一種一致和可重復的方式將其交付到實際部署中，這就是SOA項目成功的要害所在。服務最好通過3個元素來定義：
服務可以從現有應用程序公開，也可以從新開始構建，但是應該首先實現哪個服務呢？處于企業核心的簡單服務是最佳選擇，可以從對業務單元最不可知的服務開始，然后逐漸轉向更加特定于業務單元的服務。這種方法答應團隊習慣于在不過分關注復雜性的情況下構建和重用服務。類似地，應該從技術上較輕易的服務開始，然后一步一步轉向技術上的難點。最早構建的服務中有一些是基礎架構服務，比如日志記錄、審計、錯誤處理以及類似功能。
服務路線圖是從識別企業中已有的IT項目和功能開始的。接下來，企業需要開發使架構完整的項目以及交付業務價值的單個項目，并按照重要性對這些項目進行排序。
一開始，需要了解現有應用程序和項目的情況，以便確定可以在哪里重用現有功能。對于那些完全特定于其所在的應用程序或為其開發的項目的功能，此時就完全可以不用考慮。
一定要知道以下內容：
這些數據將幫助您了解當前的項目和應用程序，并幫助識別通用功能。
SOA要求在人員的協作方式方面有所變化。有必要在IT部門之間建立更緊密的協作，因為這樣能夠推動全體人員都重視交付業務價值，而不是只在單個功能性部門中。
要想在此領域中獲得成功，有兩個方面是必不可少的。首先，必須提供足夠的培訓，以便讓團隊不僅能夠了解SOA的技術方面，還能了解它所需要的文化變化。沒有提供這些要害消息的企業將很難繼續進行下去。
其次是組織和治理，要將SOA的采用當作是一個企業改變的計劃，而不僅僅是最新的技術方向。從高級治理人員獲取并保持支持將有助于企業的各個部門進行無縫協作，并確保您具有足夠的權限來獲得服從。
不同企業進行組織和治理的方式各不相同，這取決于企業的成熟度和發展方向。對于最初的SOA實現來說，自頂向下的集中式治理是最有效的，接下來是聯邦或部分聯邦的治理，最后是一個自治程度更高的層次系統。這種結構便于整體而有效地查看結構、資金、操作流程和工具、標準、技能變化治理以及指導原則。它還有助于根據以下（以及其他）SOA常見問題來決定、制定和改進流程：
新聞熱點
疑難解答
