軟體架構師之職責範圍

　　上一篇<軟體架構師之基本素質>講述了做為一名合格的架構師應該具備哪些基本條件。當我們具備了這些條件的時候就可以選擇成為架構師了。這時候我們就應該知道軟體架構師應該做些什麼，不應該做些什麼，也就是軟體架構師的職責範圍。

　　由於國內外軟體土壤差別巨大，適合國外的一些理論在國內不一定行的通，而國內的一些資料往往都是根據國外的資料直接搬過來用的，這也直接導致國外的軟體架構師在國內變得水土不服。今天本篇隨筆的內容則是在一些培訓資料的基礎上，加上自己的思考，總結出來的適合國情的軟體架構師職責範圍。

　　1，需求整理分析
　　有人認為架構師是在需求規格說明書完成後介入的，但我認為架構師要從項目最開始的階段就參與進來。理由有很多：首先，第一手的資訊損失最少，架構師能夠更好的把握需求；其次，分析人員在與客戶交流時，往往不會深入挖掘需求，因為有很多隱藏的需求客戶自己都不見得意識的到，而架構師則可以依靠敏感的軟體嗅覺發現這些需求，減少以後的變數；第三，分析人員往往脫離Team Dev，盲目接受客戶需求，而架構師能夠清楚把握現有的研發團隊能做什麼，不能做什麼，提前預知風險，降低項目失敗的機率。

　　2，系統分解
　　在收集完資訊後，架構師需要將使用者需求轉化為軟體需求，同時要補充非業務需求，如健壯性，擴充性等等。如何區分和化解使用者需求與軟體需求，如何有效把握使用者需求與軟體需求的區別，是系統分解的核心。這是最考驗架構師的地方，也是只有架構師參與的工作。

　　3，技術選型
　　這一步要根據對軟體需求決定項目該使用何種架構，開發模型，及依賴選項。如使用多層架構還是分布式架構，是瀑布模型還是RUP，是使用MySQL還是SQLServer，是否需要使用企業庫，是否需要使用ORM。但是，架構師對項目的技術選型要提供多種不同的方案，並為每種不同方案提供詳細說明文檔，用來闡述每種方案的優勢，劣勢，可行性等內容。這些文檔供專案經理或領導決策最終的技術選型。

　　4，系統設計
　　依據軟體需求和技術選型，架構師需要和軟體工程師一起將軟體需求落實到軟體詳細設計說明書中。架構師負責將軟體需求分解，重組織為子項目，子系統，組件和模組，以及它們之間的邏輯關係，從而形成不同的邏輯組成部分，最後還需要確定各個子系統及組件間的介面。這些都是作為進一步的團隊分工的依據。同系統分解一樣，系統設計是考驗架構師能力的重要職責。

　　5，培訓與指導
　　在軟體詳細設計說明書完成後，為保證項目的順利進行，架構師需要對整個團隊進行技術培訓，讓團隊中的每個人明白自己的職責範圍，該做什麼，不該做什麼。在項目實施過程中，架構師需要參與到具體開發過程中，給與每個開發人員有效指導，以避免團隊成員對系統設計的誤解而造成項目的延誤。在我看來，這點對於新手比較多的團隊尤為重要。因為國內新手的一個通病是眼高手低，剛學會了一點點就認為自己什麼都會；當他們拿到真正的設計時又往往不知所措，畏首畏尾。

　　6，保持溝通
　　溝通是保證項目順利開展的有效保障。架構師要從多方面跟蹤項目進度，及時與專案經理或直屬領導彙報項目進展，與技術開發人員溝通遇到的問題，如果是反覆式開發法，還需要與使用者溝通需求變更。

　　以上是一個項目開發過程中架構師需要承擔的主要職責，相比一些培訓指導，我認為，架構師需要更深入地參與到項目中。