系統架構師在軟件開發的活動中起到了綱領性的作用，就像建筑設計師一樣，從大的方向來給軟件定一個基調。軟件開發中碰到的很多問題，歸咎起來都可能和當初的架構設計有關，所以架構師要想不成為眾矢之的，也不是容易的事情。

    各個行業甚至同一行業不同主攻方向的team都需要不同的架構師，比如做SOA的很多架構師實際上的職責是向用戶推銷自己的產品，即使有時采用其他方案更適合企業的情況，出于宣傳本公司產品的需要，也要貶低一番。當然利益對架構的影響不可避免，其他行業也存在類似的情況。但是SOA的架構師更多做的是把自己公司的產品套用在客戶身上。當架構師是在設計自己公司的產品時，相對來說會客觀一些，從功能，性能，穩定性，擴展性，市場接受程度和成本等幾方面來權衡。

    如果一個架構師負責的僅僅是一個小的模塊，或者是一個小的應用程序，那么他所能施展的空間不太多，包括操作系統，硬件，驅動，其他模塊的接口等都是已經確定的了，甚至自己的模塊需要哪些接口暴露給別人也都是定義好的了，那么這個架構師該做些什么呢？從別的程序或者系統來看，這個應用程序至少要具備以下幾個條件才能算是合格的：

    1、完成此應用程序的基本功能。如果這是一個通信程序客戶端，那么它至少應該完成客戶端所具有的功能，通過所有的測試用例。不同的功能是需要不同的組成架構的，從降低復雜度和提高可維護性的角度來考慮對系統進行解構，往往是最直觀的做法。

    2、健壯性。這個程序不應該輕易的crash，如果是界面程序，在面對異常情況的時候采取柔和的方式來通知用戶。如果是被別的程序所使用的庫，保持健壯性更是非常重要。作為架構師，應該采取一定的措施來保證模塊的正確工作，至少應該保證在出錯的情況下能夠比較容易的區分是否是本模塊造成的。也許有人說這是design和program的事情，但是架構師如果不在綱領上制定策略和要求，實現上也是很難操作的。

    3、低的資源消耗。我碰到很多軟件架構，在架構文檔里看時非常華麗，用了很多模式，一個普通的應用要拆分成多個進程，再用MVC分離各個模塊，加上一大堆監聽器適配器過濾器等，可以說模式是能帶來一些好處的，但是往往代價是更多的資源消耗，內存占的多了，性能下降了，邏輯變得更復雜了。作為架構師一定要權衡，而不是為了表達自己的知識能力。最好的情況是，能夠給出在各種usecase下模塊或應用對資源的消耗程度，比如會占用多少內存，某個接口需要多長時間等。因為現在的接口定義一般都只是定義使用方式，包括函數名和參數列表，至于使用時的代價由于沒有說明，往往成為模塊使用者和提供者之間爭論的焦點。

    從程序員的角度來講，可維護性往往更為重要，因為維護的階段比開發的階段更長，面對的壓力也更大，而且由于各種各樣的原因，經常要一個新手來維護這個程序，如何讓新手很容易的理解它并且馬上具備解決問題的能力，對架構師來說也不是一件可以推卸的責任，采用常見的設計模式，制定或采用通用的代碼風格，完善相關的文檔等等，都是好的practice。

    對于那些高層次的架構師來說，因為面對的是由很多模塊應用組成的系統，他所要處理的實際上如何協調各模塊關系，保證整個系統的功能性能和穩定性，至少他應該了解各個應用所具備的功能，基于此來制定各個模塊之間的接口。在必要的時候，要去掉那些作用不大但影響整個系統性能和穩定性的模塊，對各個模塊的可選功能也要做一定的限制，不能允許其無限制的膨脹。架構師也往往面臨著選擇既有實現的困境，采用第三方或者開源實現時，一定要和已有的實現進行全方位的比較，在很難做出決定時寧可保持不變，或者采用小的實驗步驟來獲取真實的數據。

    本文由希賽軟考網整理。

    相關推薦：

  我們為什么要報考系統架構師考試？

  系統架構師與產品經理、項目經理有什么區別？

  2015年軟考系統架構設計師精選復習筆記