如何組建理想SOA團隊

趨向採用 SOA

軟件開發領域的主要發展趨勢是從傳統軟件體系結構過渡到面向服務的體系結構 (SOA)。在傳統軟件體系結構中，將項目視爲單個新應用程序的交付。在SOA中，將項目視爲集成服務的交付——一些是新建的，一些是現有的。不管其規模和預算如何，幾乎全部信息技術(Information Technology，IT)部門當前都在進行過渡到SOA的工做。您可能已經讀過多篇關於SOA採用、成熟度模型和實現的文章了。本文將描述在組織採用SOA或過渡到更高的SOA成熟度水平的過程當中，您的IT團隊成員中所需的一組新角色及其各自的職責。

在造成SOA團隊時，最大的範式轉換是從組合應用程序交付過渡到服務交付。傳統軟件開發人員一般構建應用程序中的 一個模塊，或典型的三層體系結構中的單個層的一部分。開發人員的一個例子就是在模型-視圖-控制器(Model-View- Controller，MVC)體系結構中負責控制器或模型層的人員。在SOA環境中，這些開發人員如今負責服務實現。他們並不須要知道什麼時候、如何或爲什 麼調用服務以及誰調用服務。他們所關心的就是，服務進行什麼工做以及須要符合什麼樣的服務水平協議(Service Level Agreement，SLA)。

爲了進行此範式轉換，您須要造成完整的SOA團隊，其中的每一個角色的職責與傳統軟件開發團隊中的相同角色略有不一樣。本文將說明SOA團隊中如下角色的狀況:

　·架構師
　　·開發人員
　　·業務分析人員
　　·項目經理

在典型的IT組織中還包括多個其餘角色，包括基礎設施支持、數據庫支持、安全性等等。不過，瞭解了這些主要角色如何改變後，您就可以對其餘角色進行調整，以與其匹配。

理解架構師的角色

在較大的組織中，一般有兩個體系結構小組。企業體系結構小組定義組織內的每一個應用程序小組都必須遵循的控制策略、最佳實踐和過程。應用程序體系結構小組負責其特定應用程序的體系結構，確保體系結構可以支持當前和未來的業務需求。

企業架構師

在SOA組織中，企業架構師的角色是推進和促進SOA的採用。他們須要幫助應用程序架構師和各個開發小組理解SOA的基礎知識並將業務需求轉換爲有意義的服務，以便這些小組進行實現和公開。

僅由您本身的應用程序或業務流程使用的服務幾乎沒有價值。企業架構師須要確保全部應用程序架構師按期討論其項目， 以肯定他們能夠公開或使用的服務。在不能重用現有服務的狀況下，企業架構師還須要確保充分利用構建新服務的每一個機會。促進對現有服務的重用確定比編寫新服 務具備更高的優先級。最後，他們必須確認服務是在可靠的技術之上構建的，且可以知足所確立的 SLA。

企業架構師負責定義測定和跟蹤 SLA 的機制。他們定義有關控制、安全性、災難恢復等等的策略和過程。他們一般是涉及到 Web 服務管理、編排和企業服務總線的解決方案的主要決策者。

應用程序架構師

應用程序架構師的角色是確保所編寫的代碼是面向服務的，且遵循可用於面向服務的開發的最佳實踐和流程。他們須要在不會對解決方案進行過分設計的前提下將業務需求轉換爲有意義的服務。典型的服務建立和使用比代碼的直接調用開銷更大。所以，肯定做爲服務公開的粒度級別以及如何進行公開是此角色的主要工做職能。

應用程序架構師還要與組織中的企業架構師及其餘應用程序架構師緊密合做，以確保充分利用每一個服務重用機會，且恰當地對服務進行構建、發現、安全保護、使用和測定。

應用程序架構師最終負責服務交付和使用(非功能要求)的全部技術方面的工做，包括 SLA 遵循狀況的可測定性、符合控制策略、執行和確保安全策略等等。

閱讀不一樣SOA文獻中關於架構師的信息時，您可能會遇到術語業務架構師，即應該理解業務狀況並設計服務的人員。在 個人SOA團隊定義中，此角色的工做由應用程序架構師完成，而不是由企業架構師完成。應用程序架構師或業務架構師是業務小組和技術小組間負責技術設計方面 的協調人，而業務分析人員則是負責業務方面的協調人。

開發人員的角色

在傳統IT小組中，開發人員一般負責應用程序的一個片斷。這些片斷能夠由功能(如註冊中心或報告模塊)或技術(如 JavaServer Pages? [JSP]、Enterprise JavaBeans [EJB]、數據庫層等等)肯定。

因爲SOA團隊一般採用較短的開發週期，因此按技術對開發人員進行劃分並不實際。所以，將按功能劃分的開發團隊轉變到新的SOA開發人員角色更爲容易一些。

成功的SOA開發人員將能同時理解業務流程和功能。他們會恰當構建所需的服務來知足業務流程的需求。愈來愈重要的 是，要執行用於錯誤處理、跟蹤/審覈、數據轉換和安全性的良好設計原則，並確保將其加入到任何服務代碼中。因爲SOA的核心原則之一是重用，因此開發人員 必須放棄傳統開發人員但願構建一切的想法。若是某個方面的服務已經存在，請使用這個服務——而不要本身從頭構建。

因爲 Web 服務的技術發展並有大量有關該技術的參考材料可供使用，所以能夠說開發人員已經「全副武裝」，能充分勝任其在新SOA環境中的工做了。

業務分析人員的角色

業務分析人員多是最可貴到正確認識的一個角色。做爲技術人員兼架構師，我傾向於將架構師視爲最關鍵的SOA團隊 成員。不過，基於經驗和最慎重的考慮，我必須指出，做爲SOA團隊中的一員，實際上業務分析人員的工做變化最大。不管開發環境如何，業務分析人員都執行兩 個主要職能:

與執行人員和策略級的用戶溝通，以瞭解其對系統的要求。

與技術團隊成員溝通，以將肯定的要求轉換爲能進行編碼和測試的技術規範。

在SOA環境中，業務分析人員還有兩項新職能:

與整個開發團隊合做，讓他們開始以服務 的方式思考問題。(他們須要何種服務來進行其工做?已經存在哪些服務可供使用或在調整後進行使用？如此等等。)

與技術團隊合做，以設計和構建必要的服務，可能會利用已經存在的現有服務。

不管喜歡與否，在不少企業中，因爲組織使用的技術的侷限性，業務分析人員一般會不斷更改相關要求。這個問題可能並不能獲得消除，但在SOA環境中，業務分析人員進行服務設計的空間確定更大，而不用過多地擔憂技術。

項目經理的角色

SOA 環境中的項目經理的角色與傳統IT環境中的項目經理之間的主要差別在於項目生命週期。不管SOA團隊採用何種方法(IBM Rational? Unified Process (RUP)、瀑布式、敏捷方法)，項目經理一般都須要爲每一個服務計劃較短的交付週期。他們與業務用戶和不一樣服務使用者一塊兒定義服務水平協議 (SLA)。此外，他們必須與多個IT小組(如基礎設施支持小組)共同確保這些 SLA 是能夠實現的。

項目經理在服務運行時進行協調和跟蹤方面的角色比跟蹤平常服務交付更爲重要。不過，因爲週期較短，這個工做相對較爲容易一些。

總結：SOA角色及其對您的團隊的意義

本文討論的關鍵詞是培訓。當您決定進行SOA項目時，須要仔細考慮團隊人員的當前角色，並確保經過培訓、指導和調整試驗及錯誤週期來幫助他們準備好進行其在SOA中的工做。