系統架構師的職、責、權
胡育兵2012/6/6
一、 名稱與定位
1 職業名稱
系統架構師（System Architecture）
2 職業定位
系統構架，是對已確定的需求的技術實現構架、作好規劃，運用成套、完整的工具，在規劃的步驟下去完成任務。
系統架構師是一個最終確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節、掃清主要難點的技術人員。他主要着眼於系統的“技術實現”。
系統架構師負責設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個項目，使設計的項目儘量效率高，開發容易，維護方便，升級簡單，等等。
二、 架構師的主要任務？
架構師的主要任務不是從事具體的軟件程序的編寫，而是從事更高層次的開發構架工作。他必須對開發技術非常瞭解，並且需要有良好的組織管理能力。可以這樣說，一個架構師工作的好壞決定了整個軟件開發項目的成敗。
ü 領導與協調整個項目中的技術活動（分析、設計和實施等）
ü 推動主要的技術決策，並最終表達爲軟件構架
ü 確定和文檔化系統的相對構架而言意義重大的方面，包括系統的需求、設計、實施和部署等“視圖”
ü 確定設計元素的分組以及這些主要分組之間的接口
ü 爲技術決策提供規則，平衡各類涉衆的不同關注點，化解技術風險，並保證相關決定被有效的傳達和貫徹
ü 理解、評價並接收系統需求
ü 評價和確認軟件架構實現的專業技能
三、 架構師是如何參與到項目/產品研發中的？
1 需求整理分析
有人認爲架構師是在需求規格說明書完成後介入的，但我認爲架構師應該儘可能的從項目最開始的階段參與進來。理由有很多：
首先，第一手的信息損失最少，架構師能夠更好的把握需求；
其次，分析人員在與客戶交流時，往往不會深入挖掘需求，因爲有很多隱藏的需求客戶自己都不見得意識的到，而架構師則可以依靠敏感的軟件嗅覺發現這些需求，減少以後的變數；
第三，分析人員往往脫離開發團隊，盲目接受客戶需求，而架構師能夠清楚把握現有的研發團隊能做什麼，不能做什麼，提前預知風險，降低項目失敗的機率。
2 系統分解
在收集完需求信息後，架構師需要將用戶需求轉化爲軟件需求，同時要補充非業務需求，如健壯性，擴展性等等。如何區分和化解用戶需求與軟件需求，如何有效把握用戶需求與軟件需求的區別，是系統分解的核心。這是最考驗架構師的地方，也是隻有架構師參與的工作。
3 技術選型
這一步要根據軟件需求決定項目該使用何種架構，開發模型，及依賴選項。如使用多層架構還是分佈式架構，是瀑布模型還是RUP，是使用MySQL還是SQL Server，是否需要使用企業庫，是否需要使用ORM。架構師對項目的技術選型提供多種不同的方案，併爲每種不同方案提供詳細說明文檔，用來闡述每種方案的優勢，劣勢，可行性等內容。這些文檔供領導決策最終的技術選型。
4 系統設計
依據軟件需求和技術選型，架構師需要和軟件工程師一起將軟件需求落實到軟件詳細設計說明書中。架構師負責將軟件需求分解，重組織爲子項目，子系統，組件和模塊，以及它們之間的邏輯關係，從而形成不同的邏輯組成部分，最後還需要確定各個子系統及組件間的接口。這些都是作爲進一步的團隊分工的依據。同系統分解一樣，系統設計是考驗架構師能力的重要職責。
5 培訓與指導
在軟件詳細設計說明書完成後，爲保證項目的順利進行，架構師需要對整個團隊進行技術培訓，讓團隊中的每個人明白自己的職責範圍，該做什麼，不該做什麼。在項目實施過程中，架構師需要參與到具體開發過程中，給與每個開發人員有效指導，以避免團隊成員對系統設計的誤解而造成項目的延誤。在我看來，這點對於新手比較多的團隊尤爲重要。因爲國內新手的一個通病是眼高手低，剛學會了一點點就認爲自己什麼都會；當他們拿到真正的設計時又往往不知所措，畏首畏尾。
6 保持溝通
溝通是保證項目順利開展的有效保障。架構師要從多方面跟蹤項目進度，及時與項目經理或直屬領導彙報項目進展，與技術開發人員溝通遇到的問題，如果是迭代開發，還需要與用戶溝通需求變更。
四、 公司項目實戰
以上是一個項目開發過程中架構師的職、責、權。以下就我在擔保集團二期中做的一些事，做一下描述：
n 背景
首先說明一下，我當時在技術部，不是該項目的專職架構師，只是以架構師的身份參與到該項目中。因此，在該項目中我無法履行一個架構師的全部職、責、權。與上文中的描述略有不同。
n 參與的工作
1、 項目售前支持
Ø 與售前項目經理一起去客戶現場溝通需求，主要是獲取用戶的需求，以及關注的核心功能與識別未來可能的變化。擔保集團二期項目與一期類似，主要的需求是：業務數據的錄入、修改、刪除、多級審批、數據分析與統計等需求，以及與第三方平臺（一期平臺、單點登錄平臺、電子簽章）等實現無縫對接。
Ø 與第三方平臺廠商面對面溝通，對涉及到的接口和技術詳細討論，提前預估出存在的風險。
Ø 由於需要與第三方平臺實現無縫集成。最核心的關鍵點是與一期項目平臺實現完整對接。而一期開發商與我們是競爭關係，無法獲取到任何支持。建議項目經理和市場人員想辦法獲取一期項目源代碼及數據庫結構等技術資源，分析技術細節。
2、 項目規劃與前景框架
通過以上售前相關的支持，識別出存在的風險、客戶的系統運行環境、系統的非功能性需求、業務特性、以及可能存在的需求變更風險，制定前景框架：
Ø 與第三方平臺的整合，需要獨立開發一套基於JDBC的單點登錄平臺，實現一期、二期項目人員、角色、權限的統一讀取和主體界面的展現。簡單點說，就是獨立開發一個登錄、主界面展現的平臺，同時訪問和操作一期、二期兩個數據庫。
Ø 由於客戶業務的不確定性，主要表現在：業務單據不確定、業務流程不確定，業務流轉條件不確定、業務數據異常、流程步驟回滾等不確定性等因素，需要一套擴展性好、配置簡單、能夠與業務實現無縫集成的業務工作流引擎。
Ø 基於業務數據分析與統計的需求，需要一款報表工具支撐客戶業務的變化，同時考慮報表工具的易用性、成本等，最終選型ireport。
Ø 數據整合：二期項目中的很多初始數據來源於一期項目，需要一款ETL數據抽取工具。爲了使用方便，以及我所掌握的技術，推薦使用SQL Server中的SSIS工具，併爲項目組員提供技術使用培訓。
3、 開發過程
項目進入研發階段，組織項目組，分析、討論客戶需求的特點，將需求轉化爲軟件開發思想。
Ø 爲項目組提供業務工作流引擎的設計思路、功能實現、數據庫結構設計、技術（編碼）實現方式和思路。對項目核心組員進行架構實現思路的培訓(澄清技術細節)，幫助組員理解架構設計的思想，爲組員解惑。
Ø 爲項目組提供簡單的數據庫設計規範培訓
Ø 爲項目組提供簡單的編碼規範培訓
Ø 項目組在研發過程中的疑難支持
n 小結
通過架構師的架構設計，提前預估並規避項目存在的風險。通過技術手段降低系統開發難度，並將業務置於技術架構應用之上，使技術架構能夠支撐業務的不確定性。
在系統研發階段，技術人員幾乎不用關注用戶的業務，也不需要懂得用戶的業務，基礎平臺研發出來之後，只需要將用戶的業務在平臺上面進行配置（業務實施），技術與業務相對獨立，又相輔相成。