軟件架構師的定義乃至所需要的特質歷來眾說紛紜。下面從一些另類的角度來做點分析。

從產生根源來看，程序規模越大，參與人員越多，越需要架構師；

程序越小，參與人員越精英化，架構師存在價值越小。

這不難理解，大軍團作戰，總不好一窩蜂就上去了，總要有些規則，總要有人把我全局。

架構師就是在比較高的層面上把握全局的這個人。

從這個角度來看，對架構師而言選擇最重要，因為站的高，所以選擇具有非常大的價值。

注意不是UML，也不是對業務的理解，不是編碼能力而是做出正確選擇的能力。

當下的開發環境下，考慮解決方案時，所面臨的選擇不是太少，而是太多。

舉個最簡單的例子，我們要開發一個基于Web的項目管理程序，那么你面臨的選擇是：

• 自己從頭造，還是用現成的做二次開發？
• 用現成的，是用開源產品還是微軟的？
• 用微軟的話，是用MS Project還是基于SharePoint?
• 用開源產品，有這么多選項究竟導入那一個?
• 如果自己從頭造，那么是基于微軟的技術，還是基于Linux?
• 使用什么框架么?
• 如果要做，用什么語言?

每一個這類選擇的背后都是赤裸裸的利益---在商業環境下永遠不要忘了這個。

做選擇其實可以很容易，所以是個人就可以干這活，并不具備很高的門檻。

關鍵差異是有無根據和正確程度。

如果說程序員的生產效能可以差10倍的話，架構師的價值可以差無數倍。

想選擇正確，最關鍵的前提是理解待選擇的選項和外部的切實要求。

前一點很難，這往往要求一個人涉獵廣泛，在很多的領域中具有經驗。

不只要知道LAMP，還要知道asp，不只要知道軟件還是知道些硬件，不只要了解Java，可能還要了解C#。

理解程度倒未必一定要很精通，關鍵是要抓住差異以及其適用場景。

但這恰恰與這個時代的特征相反，在這個時代里，技術日趨繁雜，專家越來越多，通才越來越少，諸神隕落啊。

走極端的人可能會說，那么多人，沒懂什么，去做網站也成功了。

這也可能，運氣很好的話，什么也不懂，一樣可以做很對的選擇。

但能力這種事，本來最主要的就是盡可能去除運氣成分。

從編碼的角度看，架構師不懂編碼是不行，但卻不需要是最精通編碼的人。

一者謀的一隅，一者謀的是全局，因此也就導致對技能的要求不同。

原文鏈接：http://www.cnblogs.com/daoshi/archive/2012/08/13/2635664.html