如何組建理想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中的工作。