東方未名

趨向采用 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中的工作。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1406628