系統架構設計師是一個最終確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節、掃清主要難點的技術人員。那麼作爲一個優秀的系統架構設計師需要具備哪些條件呢?yjbys小編和大家分享相關的資料，歡迎大家閱讀學習哦!
系統架構師在軟件開發的活動中起到了綱領性的作用，就像建築設計師一樣，從大的方向來給軟件定一個基調。軟件開發中碰到的很多問題，歸咎起來都可能和當初的架構設計有關，所以架構師要想不成爲衆矢之的，也不是容易的事情。
各個行業甚至同一行業不同主攻方向的team都需要不同的架構師，比如做SOA的很多架構師實際上的職責是向用戶推銷自己的產品，即使有時採用其他方案更適合企業的情況，出於宣傳本公司產品的需要，也要貶低一番。當然利益對架構的影響不可避免，其他行業也存在類似的情況。但是SOA的架構師更多做的是把自己公司的產品套用在客戶身上。當架構師是在設計自己公司的產品時，相對來說會客觀一些，從功能，性能，穩定性，擴展性，市場接受程度和成本等幾方面來權衡。
如果一個架構師負責的僅僅是一個小的模塊，或者是一個小的應用程序，那麼他所能施展的空間不太多，包括操作系統，硬件，驅動，其他模塊的接口等都是已經確定的了，甚至自己的模塊需要哪些接口暴露給別人也都是定義好的了，那麼這個架構師該做些什麼呢?從別的程序或者系統來看，這個應用程序至少要具備以下幾個條件才能算是合格的：
1、完成此應用程序的基本功能。如果這是一個通信程序客戶端，那麼它至少應該完成客戶端所具有的功能，通過所有的測試用例。不同的功能是需要不同的組成架構的，從降低複雜度和提高可維護性的角度來考慮對系統進行解構，往往是最直觀的做法。
2、健壯性。這個程序不應該輕易的crash，如果是界面程序，在面對異常情況的時候採取柔和的方式來通知用戶。如果是被別的程序所使用的庫，保持健壯性更是非常重要。作爲架構師，應該採取一定的`措施來保證模塊的正確工作，至少應該保證在出錯的情況下能夠比較容易的區分是否是本模塊造成的。也許有人說這是design和program的事情，但是架構師如果不在綱領上制定策略和要求，實現上也是很難操作的。
3、低的資源消耗。我碰到很多軟件架構，在架構文檔裏看時非常華麗，用了很多模式，一個普通的應用要拆分成多個進程，再用MVC分離各個模塊，加上一大堆監測器適配器過濾器等，可以說模式是能帶來一些好處的，但是往往代價是更多的資源消耗，內存佔的多了，性能下降了，邏輯變得更復雜了。作爲架構師一定要權衡，而不是爲了表達自己的知識能力。最好的情況是，能夠給出在各種usecase下模塊或應用對資源的消耗程度，比如會佔用多少內存，某個接口需要多長時間等。因爲現在的接口定義一般都只是定義使用方式，包括函數名和參數列表，至於使用時的代價由於沒有說明，往往成爲模塊使用者和提供者之間爭論的焦點。
從程序員的角度來講，可維護性往往更爲重要，因爲維護的階段比開發的階段更長，面對的壓力也更大，而且由於各種各樣的原因，經常要一個新手來維護這個程序，如何讓新手很容易的理解它並且馬上具備解決問題的能力，對架構師來說也不是一件可以推卸的責任，採用常見的設計模式，制定或採用通用的代碼風格，完善相關的文檔等等，都是好的practice。
對於那些高層次的架構師來說，因爲面對的是由很多模塊應用組成的系統，他所要處理的實際上如何協調各模塊關係，保證整個系統的功能性能和穩定性，至少他應該瞭解各個應用所具備的功能，基於此來制定各個模塊之間的接口。在必要的時候，要去掉那些作用不大但影響整個系統性能和穩定性的模塊，對各個模塊的可選功能也要做一定的限制，不能允許其無限制的膨脹。架構師也往往面臨着選擇既有實現的困境，採用第三方或者開源實現時，一定要和已有的實現進行全方位的比較，在很難做出決定時寧可保持不變，或者採用小的實驗步驟來獲取真實的數據。
