架構師首先必須具有豐富的開發經驗，是個技術主管。因為他必須清楚什麼是可以實現的，實現的方式有哪些，相應的難度怎麼樣，實現出來的系統面對需求變化的適應性等一系列指標。另外，需要對面向過程、物件導向、面向服務等設計理念有深刻的理解，可以快速的察覺出實現中的問題並提出相應的改進（重構）方案（也就是通常說的反模式）。這些都需要長期的開發實踐才能真正的體會到，單從書本上很難領會到，就算當時理解了也不一定能融會到實踐中去。
在技術能力上，軟體架構師最重要也是最需要掌握的知識是構件通訊機制方面的知識，包括程序內通訊（物件訪問、函式呼叫、資料交換、執行緒同步等）以及程序外（包括跨計算機）的通訊（如rmi、dcom、web service）。在web應用大行其道的今天，開發者往往對伺服器間的通訊關注的比較多，而對程序內的通訊較少關注。程序外跨機器通訊是構建分布式應用的基石，它是架構設計中的鳥瞰檢視；而程序內的通訊是模組實現的骨架，它是基石的基石。如果具體到乙個基於.net企業級架構設計，首先需要的是語言級別的認識，包括.net的clr、繼承特性、委託和事件處理等。然後是常用解決方案的認識，包括asp.net web service、.net remoting、企業服務元件等。總之，豐富的開發實踐經驗有助於避免架構師紙上談兵式的高來高去，給**編寫人員帶來實實在在的可行性。
其次，具有足夠的行業業務知識和商業頭腦也是很重要的。行業業務知識的足夠把握可以給架構師更多的擁抱變化的能力，可以在系統設計的時候留出一些擴充套件的餘地來適應可能來臨的需求變化。有經驗的設計人員可能都碰到過這樣的事，一廂情願的保留介面在需求變化中的命中率非常低。也就是說，在系統設計之初為擴充套件性留下來的系統介面沒能在需求變化的洪流中發揮真正的作用，因為需求的變化並沒有按照預想的方向進行，到最後還是不得不為變化的業務重新設計系統。這就是因為對業務知識的理解和對市場或者商業的判斷沒有達到乙個實用的、可以為架構擴充套件性服務的水平。
再次，架構設計師對人的關注必須提公升到架構設計之初來納入考慮的範圍，包括溝通以及對人員素質的判斷。軟體過程是團隊協作共同構建系統的過程，溝通能力是將整個過程中多條開發線粘合在一起的膠水。大家都應該碰到過事後說「原來是這樣啊，我不知道啊」或者某個開發人員突然高聲呼喊「為什麼這裡的資料沒有了」之類的。溝通的目的就是盡量避免多條開發線的混亂，讓系統構建過程可以有條理的高效進行。另外，對人的關注還表現在對團隊成員的素質判斷上，比如哪些開發人員對哪些技術更熟悉，或者哪些開發人員容易拖進度等。只有合理的使用人力資源，讓合適的人做合適的事情才能讓整個軟體過程更加高效。
架構師應時刻注意新軟體設計和開發方面的發展情況，並不斷探索更有效的新方法、開發語言、設計模式和開發平台不斷很快地公升級，軟體架構師需要吸收這些新技術新知識，並將它們用於軟體系統開發工作中。但對新技術的探索應該在乙個理性的範圍內進行，不能盲目的跟風。解決方案提供商永遠都希望你能使用它提供的最新技術，而且它們在推廣自己的解決方案的時候往往是以自己的產品為中心，容易給人錯覺。比如資料庫，往往讓人覺得它什麼都能做，只要有了它其它什麼都不重要了。但事實上並不是如此，對於小型應用可以將許多業務邏輯用script的方式放入資料庫中，但很少看到大型應用採用這樣的做法。對於新東西需要以一種比較的觀點來判斷，包括橫向的比較和縱向的比較，最後得出一些效能、可移植性以及可公升級等指標。另外，新入行的開發人員往往關心新技術動向而忽略了技術的歷史，而從dos時代一路殺過來的開發者就對現在的技術體系有較全面的把握。
**
架構師應該掌握哪些設計模式
今天去參加了北京博文視點出版社在上海辦的乙個open party http www.douban.com event 11051981 其中有兩個topic給我很大的啟發，乙個是溫昱的 架構 設計的事實與謬誤 另乙個是老趙 jeffz cn 的 web應用中的快取 當然，我的收穫未必是他們兩位想要傳...
架構師知識目錄
架構師知識目錄 架構師是大多數程式設計師發展的終極目標，乙個好的架構師在公司有著舉足輕重的作用，不管是在薪水還是職位方面都會受到boss的足夠重視。萬丈高樓平地起，沒有兩把刷子高樓是蓋不起來的，所以架構師要對得起自己的職位，兢兢業業，嚴謹，客觀，尊重所學的所有知識。以下是我的知識結構清單，共勉！ro...
架構師知識體系 2 什麼是架構師
軟體行業架構師兩個定義 系統架構師是乙個既需要掌控整體又需要洞悉區域性瓶頸並依據具體的業務場景給出解決方案的人。具體來說是乙個確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節 掃清主要難點的技術人員。主要著眼於系統的 技術實現 因此他 她應該是特定的開發平台 語言 工具的大師...