一般來說是不需要的，但是肯定是要懂的。

理想情況下，架構師需要創建一個技術愿景，通過該愿景我們可以獲得可維護又可靠的產品。架構師需要協調不同的團隊，共同構建一個相互依存的軟件生態系統。此外，他們還需要分享高層的集成決策，傳達應用程序和組件之間協同工作的方式。除此之外，他們還需要根據常見的軟件問題審查并規定工具和框架，并通過向利益相關者和領導層傳達最終產品的目標和愿景，將所有這些聯系在一起。

所以架構師的工作聽起來很偉大。你可能想知道為什么我把如此之多的工作都推給了忙忙碌碌的架構師。為了理解這一點，讓我們來看看我剛描述的情況與現實生活的對比。

現實情況看起來因公司而異。事實上，有些公司確實讓他們的架構師在履行其他所有職責的同時也擔負了編程的任務。但是這些公司不是這篇文章的討論對象。我想重點討論曾經與我合作過的不參與編程工作的架構師在公司里究竟做了哪些工作。

系統架構設計師的能力有什么？

1、負責公司系統架構的設計、研發工作

必須在某一特定領域有自己深刻的理解和實踐經驗，比如在java領域，就應該熟悉各種開源框架，并能在開源框架上開發各種系統功能，比如系統安全，與異構系統通信協議、高并發下各種緩存、集群、分布式。架構師應該是在微觀上能解決各種系統異常的人，宏觀上能為公司的發展提供可匹配的架構支持（架構水平可擴展）。

2、能夠制定技術規范，能夠對開發人員在技術上提供指導

所以架構師必須在技術上有一定權威的人，必須是團隊的技術核心人物，能夠根據最佳實踐制定技術規范，并要求技術人員按照規范實施。如果開發人員，尤其是新員工不能理解如何使用架構進行開發的時候，架構師應該組織對大家培訓，開發相應的demo，交付大家使用，必要時，必須闡明架構為什么這么設計的緣由。試想，如果在關鍵的技術決策的時候，沒人care你的想法，那么你真的具備架構師的能力嗎。

3、組織大家完成技術攻關，對核心的技術選型有自己見解，能識別系統風險點，也能識別系統的優化點

在關鍵的技術難點需要攻關的時候，架構師應該沖在前頭。有經驗的架構師，應該在系統設計之初就應該預想到可能的技術難題，并提前做技術研究。

所以架構師必須知識面比較廣，能夠對不同的技術選型有自己的判斷，并能對不同的技術組合做出權衡，識別各種技術選型與組合的風險，對已經運行的系統，應該持續優化，既能夠憑借自己的經驗識別系統的優化點，也善于運用各種工具，定量化分析系統的性能瓶頸，并組織技術小伙伴一塊解決。

4、業務理解能力與一定的項目管理能力

上面說的三點，想必立志成為架構師的小伙伴都能明白。但是在技術上有追求的架構師對業務、對項目管理天生有一定的排斥感，因為這兩樣都必須和人打交道，跟人打交道對架構師來說效率低下（其實，很多架構師都偏內向，不喜歡也不善于和人打交道），不如敲代碼那么酣暢淋漓。

所以，直覺上認為，執著于做一個架構師是不需要以上兩方面的能力，把架構做到極致、把技術做到極致就夠了。其實，技術是服務于業務的，你的用戶只有兩千人，你做個能應對兩千萬的人架構那只能是浪費資源。對業務的理解會有助于架構師在更高層面上去理解架構，做出的架構就比較適用，后期也能夠對業務做到隨需應變。

5、另外，架構師在工作中，往往會主動或者被動參與些開發管理工作，比如工作任務分配和預估項目進度，因為往往理解技術人員專長的人是架構師（或是技術經理）、架構師能把合適的技術任務分給合適的人。或者即使不是架構師來分配任務，一般項目經理也會征求架構師的意見。

比如開發了新的架構，需要給大家培訓。比如系統要和其他部門系統通信、集成，需要跨部門的協作。各種各樣的場景會將架構師卷入一些項目管理中，從一定職業生涯規范考慮，學習或者參與一定的項目管理，能從更宏觀的層面去看一個項目的發展，而不單單將自己局限在技術上去看問題。

當然，架構師還要求有很強的自學能力、分析能力、發現問題、解決問題的能力。在互聯網時代，還需要寫作、溝通、培訓的能力。

以上就是小編的分享，希望可以幫助到大家。