架構(gòu)師首先必須具有豐富的開發(fā)經(jīng)驗，是個技術(shù)主管。需要對面向過程、面向?qū)ο蟆⒚嫦蚍?wù)等設(shè)計理念有深刻的理解，可以快速的察覺出實現(xiàn)中的問題并提出相應的改進（重構(gòu)）方案（也就是通常說的反模式）。這些都需要長期的開發(fā)實踐才能真正的體會到，單從書本上很難領(lǐng)會到，就算當時理解了也不一定能融會到實踐中去。

在技術(shù)能力上，軟件架構(gòu)師最重要也是最需要掌握的知識是構(gòu)件通信機制方面的知識，括進程內(nèi)通信（對象訪問、函數(shù)調(diào)用、數(shù)據(jù)交換、線程同步等）以及進程外（括跨計算機）的通信（如RMI、DCOM、Web Service）。在WEB應用大行其道的今天，開發(fā)者往往對服務(wù)器間的通信關(guān)注的比較多，而對進程內(nèi)的通信較少關(guān)注。進程外跨機器通信是構(gòu)建分布式應用的基石，它是架構(gòu)設(shè)計中的鳥瞰視圖；而進程內(nèi)的通信是模塊實現(xiàn)的骨架，它是基石的基石。如果具體到一個基于.Net企業(yè)級架構(gòu)設(shè)計，首先需要的是語言級別的認識，括.NET的CLR、繼承特性、委托和事件處理等。然后是常用解決方案的認識，括ASP.NET Web Service、.NET Remoting、企業(yè)服務(wù)組件等?？傊S富的開發(fā)實踐經(jīng)驗有助于避免架構(gòu)師紙上談兵式的高來高去，給代碼編寫人員帶來實實在在的可行性。

其次，具有足夠的行業(yè)業(yè)務(wù)知識和商業(yè)頭腦也是很重要的。行業(yè)業(yè)務(wù)知識的足夠把握可以給架構(gòu)師更多的擁抱變化的能力，可以在系統(tǒng)設(shè)計的時候留出一些擴展的余地來適應可能來臨的需求變化。有經(jīng)驗的設(shè)計人員可能都碰到過這樣的事，一廂情愿的保留接口在需求變化中的命中率非常低。也就是說，在系統(tǒng)設(shè)計之初為擴展性留下來的系統(tǒng)接口沒能在需求變化的洪流中發(fā)揮真正的作用，因為需求的變化并沒有按照預想的方向進行，到最后還是不得不為變化的業(yè)務(wù)重新設(shè)計系統(tǒng)。這就是因為對業(yè)務(wù)知識的理解和對市場或者商業(yè)的判斷沒有達到一個實用的、可以為架構(gòu)擴展性服務(wù)的水平。

再次，架構(gòu)設(shè)計師對人的關(guān)注必須提升到架構(gòu)設(shè)計之初來納入考慮的范圍，括溝通以及對人員素質(zhì)的判斷。軟件過程是團隊協(xié)作共同構(gòu)建系統(tǒng)的過程，溝通能力是將整個過程中多條開發(fā)線粘合在一起的膠水。大家都應該碰到過事后說“原來是這樣啊，我不知道啊”或者某個開發(fā)人員突然高聲呼喊“為什么這里的數(shù)據(jù)沒有了”之類的。溝通的目的就是盡量避免多條開發(fā)線的混亂，讓系統(tǒng)構(gòu)建過程可以有條理的高效進行。另外，對人的關(guān)注還表現(xiàn)在對團隊成員的素質(zhì)判斷上，比如哪些開發(fā)人員對哪些技術(shù)更熟悉，或者哪些開發(fā)人員容易拖進度等。只有合理的使用人力資源，讓合適的人做合適的事情才能讓整個軟件過程更加高效。

架構(gòu)師應時刻注意新軟件設(shè)計和開發(fā)方面的發(fā)展情況，并不斷探索更有效的新方法、開發(fā)語言、設(shè)計模式和開發(fā)平臺不斷很快地升級，軟件架構(gòu)師需要吸收這些新技術(shù)新知識，并將它們用于軟件系統(tǒng)開發(fā)中。但對新技術(shù)的探索應該在一個理性的范圍內(nèi)進行，不能盲目的跟風。解決方案提供商永遠都希望你能使用它提供的最新技術(shù)，而且它們在推廣自己的解決方案的時候往往是以自己的產(chǎn)品為中心，容易給人錯覺。比如數(shù)據(jù)庫，往往讓人覺得它什么都能做，只要有了它其它什么都不重要了。但事實上并不是如此，對于小型應用可以將許多業(yè)務(wù)邏輯用script的方式放入數(shù)據(jù)庫中，但很少看到大型應用采用這樣的做法。對于新東西需要以一種比較的觀點來判斷，括橫向的比較和縱向的比較，最后得出一些性能、可移植性以及可升級等指標。另外，新入行的開發(fā)人員往往關(guān)心新技術(shù)動向而忽略了技術(shù)的歷史，而從DOS時代一路殺過來的開發(fā)者就對現(xiàn)在的技術(shù)體系有較全面的把握。