技術技能是架構師的必備條件。你需要有技術技能來獲取這個職位，但是情商和理解組織業務的能力才定義了你有多優秀。
程序員的理想？如果是選擇技術這塊，他們的理想都是架構師。這個問題在我們這個行業來說是很突出的，有的人理想做管理，有的人理想做技術。那麼想做技術的這些開發人員來說，他們都很嚮往這種架構師的角色，應該說架構師也確實是站在技術這塊是最高的級別。但是他們怎麼成爲架構師，在這個過程當中，他們應該做什麼事情，應該怎麼去往這個方向努力，其實他們都很茫然。事實上我們也知道，現在我們這個行業很多架構師，尤其是做技術的這些架構師，他們很多都是從開發人員這樣一步一步走上來的。
但是在這個過程當中，有的人就倒下了，有的人就一直就是成爲一名普通的開發人員，或者軟件工程師，沒有走上這樣一個層面。原因就在於，架構師需要的能力和開發人員需要的能力還是有區別的，我們要求架構師要有實現方面能力，這跟做建築這塊不一樣，建築方面可以直接培養一個架構師，但是就我們這個行業來說，從學院裏面培養出來一個架構師是不大可能的，是需要有很多經驗的積累，也是要有編碼的這樣一些技巧，這是必須的。就是架構師必須要了解實現，但是如果停留在實現這個層面，就不可能成爲一名合格的架構師，是因爲架構師把握的更多的是大局的東西，是一個更高層面的、抽象方面的知識。
怎麼才能成爲一名架構師呢，需要在這方面有意識的培養自己，第一個培養，就是從行業這塊，因爲做我們這個軟件行業，根據不同的領域，領域模型可能不一樣，業務流程不一樣，業務規則不一樣。那麼如果你對這個行業的業務規則、業務流程不清楚，你也很難得到一個好的理論模型，也就很難得到一個好的架構，所以從行業這方面，要有意識的培養這方面的能力。就是你可以集中在你公司所從事的一些行業，比如金融行業，或者製造行業，或者保險行業，電信、通訊這方面的行業，要有這方面的能力，你要有意識去積累。而不是要埋頭光顧着寫代碼，而是有意識的去參與一些需求這塊的理解和分析，這是我認爲第一個。
第二個，就是要去掌握一些提高自己的抽象能力，提高自己的建模能力。因爲架構師所需要具備的最大的、最強的一個能力，就是能夠從很紛繁複雜的需求當中，從很多細節實現當中，能夠去抽象出一個共同的東西出來，能夠從不同的地方，能夠找到共同的地方，也就是所謂的共性和可變性這樣一種分析，他們在這一方面的能力把握的非常好。然後這一方面的能力，把握抽象出來以後，還要把它形成爲一個模型，形成出領域模型、分析模型、設計模型，通過這個模型的方式來把它表達出來，就是我認爲要有意識的要積累這方面的能力。
第三個，我認爲應該有意識的、有前瞻性的去了解這方面的知識，不管是從網絡上，包括像咱們InfoQ也有一個架構的專區，架構專區有很多很優秀的文章，都是國內外一流的架構師寫的一些文章，可以有意識的去看這些方面的文章，或者是讀一些優秀的書籍。那麼從這方面來培養你在架構這一塊的能力。
第四個我覺得還有一個交流，有意識的提高交流，很多開發人員爲什麼沒有在最後成爲架構師，就是因爲他們很多技術人員可能
比較內向，偏向於研究，偏向於和機器打交道，而忽略了和人打交道。而架構師，我剛纔也說了，架構師是在業務和實現的技術人員兩者之間搭建一個橋樑，這橋樑一方面是從書面的角度、文檔的角度來進行協作、交流，另外一方面就是口頭方面來交流，而我們開發人員在這一方面還有所欠缺。所以我認爲，開發人員要最後成長爲一個架構師，第一個你要把目標定好，定好之後，就要有意識的往這個方向去發展，要培養架構師具備的這些能力。再根據多做一些項目，有效的、及時的去總結這些項目的經驗，或者說及時的去學習一些，因爲你可能是開發人員，但是在你的項目組裏邊，肯定有架構師類似這樣的角色存在，那麼你可以有意識的向這個架構師去學習，或者說從他那個地方得到的一些東西、方案，你學會去思索，去思考，這樣我覺得慢慢的從經驗上去積累，從技術上去積累，從能力上去提高，慢慢的我想，給你一個好的機會，一定能會成爲一名合格的，乃至於優秀的架構師。
困難應該還是抽象的能力和大局觀的能力。因爲我們要求開發人員的能力，就是要求他具體的實現能力，把握細節，某一個算法的一個實現，然後某一個業務流程，他怎麼去實現，或者某一個技術，不管是什麼語言，或者什麼平臺，某一個技術，比如說安全，或者是寫一個Web Service，或者是寫一個權限管理。在這一塊來說，他們的能力是很強的，但是怎麼把它提取到更高的抽象能力和大局觀這塊，我覺得很多開發人員都比較欠缺。
首先從技術角度先說一下，對於架構師我的看法是首先要專，然後是博。就是第一個，必須得深入去了解你所擅長的某一個框架，某一個平臺，一定要專。我說所謂的專，不是說把它每個細節都掌握得很清楚，而是要把它內在的原理搞得很清楚，這樣即使碰到一個新的問題，你也可以能夠很快的解決。因爲架構師在基礎這塊，要樹立起技術的權威，如果你設計出來的模型你自己都不清楚，我打個比方來說，你對通訊的協議都不清楚，你怎麼去做架構設計，你怎麼去把握它，所以必須得專。
但是，還有一個很重要的就是要博，因爲我們做架構、做軟件，不一定是，一直做項目都會只用一個平臺，只用一門技術，而且現在的項目，其實有一個發展，是多語言、多平臺共存的這樣一種發展，很多項目我們看到都有這種趨勢。那麼如果說你只懂一門技術，只鑽一門框架，只鑽一門平臺，那麼當需要你去集成多個系統的時候，你可能就束手無策了，所以一定要博。那麼博的意思是說，由於軟件，不管是什麼平臺，不管是什麼框架，不管是什麼語言，其實它的原理是相通的。由於你專了，所以你對它的語言、原理、平臺的機制都很清楚，你要再去快速的掌握其他的技術，是非常容易的。但是又有區別，你需要去把握它不同的地方，同時你還可以取長補短，你可以用另外一個技術的優勢來彌足你現在所用的技術的缺陷，所以這是我對技術方面的認爲。
而從業務來說，你要成爲一位行業的專家，當然是最好，但是人的精力是有限的。一般來說我們有兩種情況，一種情況就是如果這個架構師，他一直只做一個方向，就是他一直做汽車製造這塊，那他可能隨着經驗的積累，慢慢慢慢的，他可能會成爲一個汽車行業專家。但是事實上這種情況是很少的，很多架構師可能會面對另外一個新的項目，比如說你原來做汽車製造，現在讓你做金融的，那你該怎麼辦？所以我們一般的做法是，如果一個大的公司、大的團隊，我們會有專門的領域專家，由領域專家來負責業務這塊，或者由客戶來負責業務這塊。但是我們的架構師也必須要對業務要有一定的瞭解，至少你要把一些行業的術語要搞清楚，這樣你才能夠和你的客戶和領域專家在溝通上沒有任何的問題，所以我不認爲說，每個架構師都必須得成爲一個業務專家，但是至少你在做這個架構之前，你必須要了解這個業務，瞭解這個行業。
如何評價系統架構的好壞？
從功能需求方面來說，如何去衡量架構師是成功的、是好的，其實很簡單，就是要滿足功能、滿足客戶需求。那我們可以利用一些方法，比如說需求矩陣、用需求跟蹤這些方面，或者通過原形這些角度來和客戶進行溝通，通過客戶這邊來了解我們這個架構方案在功能需求方面是否滿足需求。然後我們可以利用一些方法，比如驅動設計，或者通過用力這些方式去驅動，把領域模式，也就是所謂的業務模型，把它建好。
從非功能性需求來說，其實是架構的一個難題，提到有安全方面、性能方面、可擴展性、可伸縮性，要求都很多。比如我們現在，都知道像Twitter、FaceBook，他們的業務都很簡單，像Twitter就很簡單，我follow你，然後你去follow我，那業務很簡單。
但是作爲一個Twitter的架構師要求很高，要求最高的可能在性能、安全穩定性這塊，因爲訪問的人很多，所以性能這塊如何去衡量，就需要有一些衡量的指標，比如響應時間之類的。在業界有很多解決這種非功能性需求方面的通用的一些方法，比如從性能角度來說，一般是利用緩存，在硬件方面不能再高的改善的情況之下，最重要的可能就是利用緩存，不管是用普通的緩存，還是用分佈式緩衝。另外就是考慮可伸縮性，通過集羣的方式，增加服務器的方式來提高這種性能。這些東西呢，我們就是在做架構的時候，我覺得在前期就要考慮好。
而且我覺得還有一個方法，就是把每一個功能、非功能性的因素，在權衡或者評價這個架構是否合適的時候，可以把它的因素擴大化，比如原來客戶只要求能夠承擔十萬人同時上線，你可以把它放大，你放大到一百萬人，當同時上線的人數達到一百萬人的時候，這個架構會不會出問題，通過這樣一種方式，就是把某一個因素擴大化，來衡量你的架構。另外一個預先做調研，預先做架構，架構這塊我可以先做，先做出一個原形出來，架構的原形，我們通過一些測試手段，通過壓力測試，這方面的一些測試手段，來權衡這個架構是否有問題。
如何來保持架構師技術的敏銳度？
編碼也是能夠提高他的技術敏銳度。寫整個解決方案的大體上的一些編碼，而不是摳具體的算法，一些細節的實現，比如說我甚至可以寫一個框架性的東西出來，然後具體的實現由開發人員去填，另外比較困難的東西，可以由你來編碼去解決。還有從面向對象的角度來說，你可以寫一些基類或者抽象類，把一些共同的東西提取出來。如何保持敏銳度呢，首先編碼這個角度來說，我們要隨時磨鍊，我知道像我們很多世界一流的，象Kent Beck、Martin Fowler這些人，他們每天都還在寫代碼，就是要提高這方面能力，如果長期不寫，就有可能到真正去做項目的時候，碰到一個問題需要你來寫的時候，你寫不出來。
程序員如何走向架構師？前者指導建議：
第一個就是，要認清自己，就說你的特長是什麼，你的性格，你自己要有充分的瞭解，如果你確實在協調能力方面、組織能力方面、口頭表達能力方面、交流能力方面、抽象能力方面你達不到，你可以選擇另外路子。而不是覺得架構師好，你就一定要去做，其實在這個行業有很多角色都是非常好的，走到最後成爲專家照樣是能夠得到很好的事業；
第二個要認清目標，你的目標是什麼。而且你這個目標有一個近期的短期和長期目標，你在近一年要做什麼事情，過三年、五年你要達到一個什麼樣的高度；如果沒有目標，那就意味着你不會去關注你周圍的跟這個目標相關的事情。在心理學上有一個重要的法則叫吸引力法則，就說只有當你心裏有所想，這些信息它纔會來找你。
第三，要找到適合自己的方法，因爲每個人的能力不一樣，特長不一樣，學習方法可能都不一樣，那麼你的方法是什麼，你要找到。比如說你可以通過多去閱讀源代碼，閱讀一些開源的項目，或者說你可以多看書，多做項目之後，你可以在網上多找一些相關的文檔，這些都是一些好的學習方法，像我現在每天保持閱讀網絡上的一些文章，或者是閱讀書籍，特別有的書籍，是一些很一流的，戰鬥在一線的架構師，寫的一些心得體會的總結。有的東西，可能在我們做的項目根本就沒辦法碰得到，但是在將來的項目中有可能會碰到，如果你還寄希望於在將來的時候碰到問題的時候你再去找，那就會出現很大的問題。
第四，未雨綢繆，你要事先做好準備，打下堅實的基礎；最後一個，我認爲最重要的是，基礎很關鍵，不要好高騖遠，不要一下子我要成爲架構師了，好，我現在就去面向對象思想我都不太瞭解，設計模式我都不太瞭解，好，我現在就去搞架構模式，我去做架構的研究，我去分析這些架構的整個實現的原理，你根本就沒有辦法去掌握，所以你先要腳踏實地的先把最關鍵、最基礎的東西先掌握好，就像我剛纔說的要先專後博。先把這個東西研究的很透，而且不要抱着一個思想，就說我知道了就行了，要知其然，而不知其所以然，這樣就會有很大的問題，我們要去把它研究透。包括像現在，就拿C#這種語言來說，你可能覺得這門語言你很清楚了，但事實上這個C#裏面，涉及到框架的，比如說PC垃圾回收怎麼運行機制，內存的管理是怎麼去管理的，多線程是怎麼處理的，併發是怎麼去解決的，有很多很多東西需要深入的去分析，而不是盲目的知道C#的語法就夠了，這五點對於開發者來說是一個比較重要的，應該說是比較重要的一個能力。
學習是很重要的一個層面，我們說形成知識技能是不夠的，一定要讓它應用並且形成自己的智慧，這纔是有價值的。培根說了知識就是力量，那發展到今天，我們越來越發現實際上，就像彼得?德魯克說的，知識本身這個它不產生價值，哪怕它在我們腦海裏裝的太多太多，只是知識而已，只是裝在腦袋裏的知識，東西而已，讓它產生價值最佳的方式是什麼？應用和分享知識。
即使你有好用的錘子，也不要把身邊所有東西都當成釘子。在快速變更的現代科技社會，經驗法則不會一直適用。傳統智慧說永遠不要在數庫裏面實現業務邏輯。爲何這個說法傳播如此廣泛？大多數架構師都有類似經驗，這會導致原始數據庫在硬件方面如巨獸般增長，無法運行，也非常難維護。
這個假冒克蘇魯恐怖神出現的原因是主要數據庫平臺常常缺乏兩個重要而且立等可用的特性：橫向劃分數據庫的能力（比如根據數據實體劃分數據）和縱向劃分數據庫的能力（不同的數據庫實體放入不同數據庫中）。當然，我們可以自己建立這兩種特性，但是數據庫管理團隊以外的人常常也想處理類似問題。對於DBA來說這是賴以生存的手段而不是用於解決問題的能力。也就是說，對數據庫做劃分或者隊列的技術常常要存在於數據庫之外，使得開發者需要自己處理協議轉換、多種接口、數據集成等問題。
簡單的事情有效果
簡單說，任何需要超過三句話來解釋給其他人的事情，都不會實際有效的工作。
簡單解決方案的另一個效果是促使你思考，而多思多想總是好的。總之，朝着讓系統應用更爲簡單的目標去迎接所有需求、定律以及標準，毫不留情的去掉所有導致系統緩慢的多餘脂肪。
創新一定會有風險，因爲有投入，而且產出是不可預知的，但是不創新的風險更大，因爲如果你不創新，但不能保證我們的競爭對手也不創新，在競爭領域裏，不能單單把眼光放到團隊內，而是要放在整個市場，放在我們的競爭對手。就一句，創新有風險，不創新風險更大。
