經常會聽到這樣的抱怨，我做出的架構設計，下面的人能力不夠，無法實現。這個架構是XX推薦的，為啥做下來問題會這么多？ 我們的架構師只會說，其實水平不行，做出來的東西很難用等等。

其實認同我說的1的人應該已經明白，架構既然是漸進驗證的，那么架構的可行性就是一個必須考慮的問題。架構師需要熟悉自己的團隊成員的構成和技術特點，在此基礎上對設計做權衡，再好再優秀的架構也要取決于團隊成員的理解能力和執行能力，這點對很多人來說居然完全不理解。

和現在的各路有志青年一樣，我也曾經努力奮斗要做一個架構師，我在01年參加了sun的架構師認證考試。那時候的SCEA考試并沒有什么參考資料和販賣答案。各路精英只能在一個國外論壇上泡著交流經驗，經常看到某某高分過了的消息，又看到某某平常表現不錯，又差了多少分沒過云云。

我看了很多書，也頗有些項目經驗，通過成績卻一般，80分左右，所以很想知道別人的設計是如何做的，什么樣的設計可以得到更高的分。 經過協商，我和一個挪威人，一個德國人（有20年的開發經驗）交換了通過考試的作業。讓我震驚的是德國人設計的粒度，他的架構設計幾乎想日本人做的詳細設計一樣，只要簡單的翻譯工作就已經可以run，即便是對德國人的嚴謹細致早有所聞，我還是難以想象這是一個小項目的架構設計。 和德國人做了交流，他說他必須做得這么細，否則他的團隊成員理解會產生偏差， face to face的交流也不能彌補這個問題，因為他的小伙子不是都足夠聰明。
 
這讓我第一次意識到，架構師的工作的一個中心，并不是直接面對客戶，面對老板而是面對技術團隊成員。其后的工作中我又多次碰到類似的問題， 同樣的需求，一個架構師面對不同的團隊成員的時候，很可能作出截然相反的設計。架構師必須針對團隊成員的特點，認真考慮團隊成員的技術能力和學習能力，有針對性的選擇和平衡，甚至是犧牲，才能保證架構的可行性。

在一個理想的技術團隊，架構師固然可以只關心技術，但是這樣的團隊現實中存在的概率有多少？ 就如death to march 2nd中所說，現實的軟件開發團隊，大部分都要面對一個資源短缺問題，

不能說服老板給你足夠的資源，那么只能選擇充分使用現有的資源，菜刀也是刀，對不對。

我不知道有多少項目架構師脫離開發團隊能獲得真正的成功，一般來說，強調架構設計的項目都是中等以上規模的項目，人數一般都會超過10個以上，對項目管理，對技術人員有著更高的要求。不少公司都樂意高薪聘請外援進行架構設計來解決問題，但是結果都不理想，原因即如此。

我非正式的咨詢過2個項目，架構設計都由大堆錢的工程師完成，pm哭喪著臉跟我抱怨，我們的架構沒問題，都是大堆錢做的, 國外啥啥都這么用，但是我們的程序員不行，無法很好的將架構實現。

姑且不談大堆錢為了推銷自己的產品加塞的東西，單就這種絲毫不考慮團隊成員構成，千人一面的拷貝設計，都已經注定成功只能是偶然了。這樣的架構，又如何說沒問題？一個架構師最低限度的責任，既是將這種大眾face裁剪調整到適合自己團隊的面孔，交鑰匙的做法是沒戲的。我只能很無奈的告訴他們，這樣復雜的過度設計，如果不做裁剪，即便我給你找到合適的程序員，你也無法承擔時間上的成本，何況性能始終都會是個大問題。

不少中小公司的同胞們敬仰著大堆錢公司，指望他們能解決根本的問題，殊不知，某種意義上，架構設計的工作，是沒法外包的，你可以咨詢，可以顧問，但是干活是另外一回事。這點和互聯網應用什么的，還是挺大差別的。