構建成功的 SOA 項目

領測軟件測試網

從架構師的角度了解面向服務的體系結構 (SOA) 開發過程的主要階段。了解實現成功的 SOA 項目方面的經驗教訓和最佳實踐，包括組織準備情況、用戶的角色、對流程進行轉換、基于資產的支持和工具要求。

引言

Saugatuck Technology、Gartner 及其他公司所做的行業調查表明，無論各自的基礎技術如何，很多大型企業都采用了或要將面向服務的體系結構（Service-Oriented Architecture，SOA）作為其戰略方向加以采用。

在最近的一項調查中，Saugatuck Technology 發現“SOA 正逐漸在大中型企業中緩慢但穩定地推廣開”。¹（請參見soa/index.html?ca=drs-cn#resources">參考資料。）在此項調查中，他們與在大中型企業工作的高級 IT 管理人員（用戶）和應用程序架構師進行了 40 次深入的訪談，注意到“所采訪的 37% 的高級 IT 管理人員都表示其公司目前正處于 SOA 部署的有限或完全生產階段”¹。

雖然注意到 Gartner 預測在接下來兩年中所有新應用程序中將有 80% 將基于 SOA，但 Saugatuck 的調查表明用戶的期望非常樂觀，指出“到 2008 年，將有接近 67% 的用戶將使用有限或完全的 SOA 生產環境”。¹其他 Saugatuck 研究數據表明，到 2008 年，會有不到 45% 的大中型企業會采用有限或完全的 SOA 生產環境。在任何情況下，下一年大中型企業中有 45% 到 80% 采用 SOA 都是非常顯著的變化了。

隨著將 SOA 應用于更為復雜的任務，將會出現更多復雜情況。復雜任務涉及到各種類型的集成模板，用于處理不同的業務挑戰和需求，如遺留集成與轉換、應用程序、打包應用程序集成、組合業務服務和自定義開發。

作為架構師，您經常在將業務需求和 IT 需求應用到 SOA 項目中扮演著領頭雁的角色。本文討論在從傳統開發向 SOA 的過渡中的一些主要成功因素和經驗教訓。

回頁首

評估組織準備情況

架構師必須處理 SOA 項目中的很多錯誤和挑戰。一個主要的挑戰就是組織準備情況。但是在處理此挑戰前，務必確定 SOA 能夠給組織帶來什么樣的價值，并指定恰當的轉換計劃。

很多 SOA 項目的啟動都是僅僅因為客戶在長期戰略中需要 SOA，不過并沒有實際確定 SOA 可能帶來的好處有多少，或者確定哪些業務區域可以得到改進。這樣將得到定義槽糕的交付計劃和范圍，而隨后會因為沒有達到客戶的預期而導致客戶滿意度下降。如果在早期銷售周期中參與者沒有足夠的 SOA 知識來確定工作范圍或在簽署合同前向客戶傳遞相關知識，則可能會導致預期不當。顯然，同樣重要的是，交付團隊和客戶都要全面了解 SOA。

有關 SOA 的觀點通�？蓺w為兩類：SOA 是最好，或者 SOA 一錢不值。這是兩個極端，而 SOA 實際上位于兩者之間的位置。不幸的是，作為架構師，您可能需要面對支持這兩種觀點中的一種的客戶和開發團隊成員，因此要么過度積極，要么過度消極�？朔�這些極端思想，需要在 SOA 開發過程中進行大量的理念傳遞和培訓。

“SOA 并不是什么新東西——全是假想，沒有實質�！�

要克服有負面影響的謬論和駁斥不相信 SOA 的人，您可以指出 SOA 在 20 世紀 90 年代早期就出現了，已經取得了長足的發展。還要務必記住，與其他技術（如 CORBA）相比，今天的 Web 服務標準已經得到了更廣泛的行業和用戶的接受，而這也對 SOA 的推廣起到了促進作用。

“SOA 是革命性的范式變遷，是萬能藥�！�

對于過分樂觀的觀點，您需要指出，SOA 更多是發展的結果，而不是革命性劇變的結果。在進行類似的事情方面比以前有所改進，只是更好了。這不是范式變遷，不過這是一個重要的轉變。SOA 對企業處理分布式計算的方法進行了發展，對其實現進行了改進，但 SOA 并不代表著可以視為革命性的突破性變更。

SOA 在經常受到業務環境的頻繁更改影響的異類環境中尤為有用。您需要首先向客戶確認其 IT 環境是否是同類環境。如果是，則 SOA 可能并不適合該客戶的情況。高性能是否比松散耦合更為重要？客戶是否希望對 IT 功能進行嚴密的控制，以盡可能提高性能？如果是，則 SOA 也不適合他們使用。即使是能夠從 SOA 獲益的公司，也不要假定他們所需要的唯一體系結構就是 SOA。畢竟，SOA 能很好地與其他體系結構并存，而 SOA 本身并不能解決信息和語義集成挑戰。公司需要其他技術方法來解決這些更具挑戰性的問題。

在啟動 SOA 項目前，應回答以下問題：

• SOA 帶來了對業務什么樣的實際承諾？
• 為什么要在 SOA 投入資金來提高組織的收益？
• SOA 將為業務帶來什么樣的好處，組織應該如何做來確保投資在將來有回報？

可以用于幫助派生出長期和短期戰略、熱圖和 KPI 值的一項技術是組件業務建模（Component Business Modeling，CBM）。我們知道 SOA 的承諾是構建足夠靈活的 IT 基礎設施，以響應業務的需求。由于具有這么廣泛和戰略意義的價值主張，因此很容易看到 SOA 是無法回避的趨勢。但是，每個組織都需要做到以下幾點，仔細地計劃從傳統開發組織過渡到服務組織的工作：

• 始終保持開放態度
• 不受制于內部或外部派系利益
• 注重“全局”

通常這些都是項目所面臨的最嚴峻的挑戰。

將組織向服務過渡的過程需要時間、人力、流程、方法和工具支持。這是一項長期的體系結構戰略，目的是為了滿足業務目標，需要采取漸進的方式才能獲得其承諾的好處。在開始項目前，務必了解組織所處的位置和準備情況。要確定項目的范圍和所需的工作，應該在做出任何建議前確定組織的準備情況。SOA 路線圖能夠幫助保持增量計劃的戰略性。不幸的是，并非所有 SOA 項目都考慮了全局。

回頁首

獲得涉眾支持

組織中的不同人員各有自己不同的考慮，而這在 SOA 轉換過程中有著非常大的影響�！皹I務優勢”對不同的人員有不同的含義。無論是 SOA 還是非 SOA 項目，架構師在整個開發過程中都經常必須面對各種類型的人。

我們都知道涉眾的支持對任何項目的成功都非常重要，但對 SOA 項目尤為重要。SOA 活動應該由業務人員在考慮業務目標的情況推動開展，因此與傳統開發項目相比，此類項目需要更多的業務涉眾參與。不幸的是，技術人員所支持的 SOA 項目的有些業務優勢根本與業務不相關，而是只有 IT 部門能夠感受到其影響的技術優勢。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: soa