轉自：http://blog.csdn.net/qq_32246443/article/details/49407207
對於系統架構師角色，有些公司是不設立的。這個讓本人非常驚訝，也就時常會對比回想華爲的系統架構師崗位是怎麼一回事、有哪些作用？
此處聊以筆記。
一、先說一下華爲大致的軟件開發階段。作爲背景介紹。
研發部門拿到需求之後，研發部門的設計主要分爲如下三個級別。
（1）軟件部門編寫系統架構設計文檔，主要是本系統劃分爲多少個模塊、模塊間如何協作等。該文檔在review成熟沒有問題之後存檔，並指導下一級開發。
（2）軟件部門接下來編寫模塊設計文檔，主要是本模塊的內部設計、對外接口設計等。同上要進行review，OK之後存檔，用於指導下一級開發。
（3）軟件部門接下來編寫獨立單元設計文檔（由於華爲採用敏捷開發，所以內部就叫做story設計），主要是一個story中的各個邏輯關係設計、接口設計等。（review要求一樣，不再贅述）
二、好，接下來可以開始談談系統架構師（SE， System Engineer，下文簡稱SE）了。
（一）先說下範圍，哪些部門有SE？只有軟件部門有SE嗎？
錯，不但軟件部門有SE，測試部門也有SE的。我就來說說測試SE。在上文說的系統架構設計階段，測試SE就會參與review， 從測試角度去進行分析。
其好處是：由於軟件同事做系統架構設計，不是從測試角度去做，所以測試SE往往會發現一些SW確實疏於考慮的問題。
這種設計上的bug，不用等到軟件設計、開發完成之後，再通過測試出bug來彌補，否則太低效，也太貴了。
這裏想貼一張bug發現階段和成本的關係圖：
確實，bug發現的越晚，就越貴啊！
（所以有時候，這個SE崗位的缺失，似乎表面上減少了一個崗位的工資支出。但實質上看，是節約了成本、還是增加了成本呢？）
二、軟件SE的主要職責。
軟件SE主要獨立負責（掌管）某一系統架構設計的完成。通過文檔來承載。要在組內review 後無問題然後纔可以存檔和指導下一步開發（當然後期仍然可能會有些小的調整。對於無法預估的變化，這個神仙也做不到）。
第二步，組內各模塊骨幹做模塊設計，這時一般SE也比較關鍵和忙碌。因爲模塊骨幹會經常騷擾SE，有很多問題要詢問SE，然後才能成功寫完文檔。
第三步，組內各成員對於story進行開發。需要完成story文檔設計和review。然後進行開發。開發階段會有很多編程具體問題，也要和SE頻繁交流、代碼review等。這裏暫不贅述了。
三、SE還有一個職責，就是要負責“外部接口變更”的評審。
因爲各個模塊之間、各個組之間要分工和配合，這種分工一般是通過外部接口作爲通道，來承載兩邊。所以軟件上的外部接口是很重要的通道，也是不能隨意改動的。
對於不得不進行“外部接口變更”的情況下，需要一個專業、有能力的團隊和流程來進行審查，確保這種變更的質量。
研發內部有一個團隊叫做“CCB” 即變更控制委員會 Change Control Board。一般是由各個領域的SE組成，在每週二（或者每週四，記不清了）專門進行CCB評審。評審前，提出接口變更的人，要先按照模板將自己的CCB描述寫好，提前幾天發給CCB的各位。
然後會上（一般是遠程、多方的電話會議。因爲各SE都各安天涯，往往不在一個城市）自己介紹一下變更內容，CCB大神們繼續分析、交流。有的變更，會評審通過，那麼就可以執行了（被影響的各組要被知會）；有的變更未通過，那麼是不能執行的。
當前先寫到這裏。