前幾天看到一篇架構師已死的文章，頗為有趣，仔細想想，架構師之所以興盛和之所以必死，多半是因為太多的人對軟件架構師的工作存在諸多誤解的緣故。而諸多媒體和原廠商出于自身利益在國內行業進行的過度吹捧，給予了架構和軟件架構師太多的光芒，程序員們自然而讓的就把個人的職業規劃扔到了聚焦點上。
寫一些自己對架構設計和架構師的一些不是很成熟的看法，寫到哪算那，全當口水了。
架構的概念非常廣泛，解決的問題域空間也各有差距， 不能從一而論， 此處單指企業應用的范圍而已，和互聯網應用等其他范疇有較大差距。
1. 架構是設計出來。
這是很多人對軟件架構的一個最大誤解。
傳統的瀑布模型里，人為的劃分設計和編碼實現過程，也劃出了設計和驗證過程的鴻溝，整體設計（概要設計）的可驗證性，要在項目的中后期才能得到體現，這時候為時已晚。而為了保證設計的質量，回避中后期風險，又往往會強調加強設計粒度和評審粒度，這樣一來，無形中又繼續加大了設計和驗證的鴻溝，拖長了問題反饋周期，規模越大的項目，問題越為突出。
據我的印象，業界中最早的最有影響的關于架構和架構師的界定其實來源于RUP.有別于傳統的瀑布模型的中的概要設計，軟件架構很難再說是按流水線方式設計出來。架構設計和概要設計的最大差別在于架構設計更看重反饋和驗證過程，更看重架構師在整個軟件開發過程中的由始而終的參與。在rup中，項目早期的關鍵迭代都和架構設計有直接關系。
架構設計應該強調通過更好的反饋-溝通-驗證機制， 能在項目的較早期就得到技術和業務上的驗證，為整個項目打下穩定的基礎。 在某些敏捷開發過程中，架構設計并不會作為一個顯著的KPI提出，更多是作為一種隱喻。通過使用迭代和其他更好的反饋交流機制，讓項目的架構設計在在項目的前期以驗證和演進的方式完成。可以說一個真正的架構設計，必須是可以有效驗證的。
而現在很多公司和組織流行的先讓大拿組織做設計，設計做完再評審，然后丟給小兵去干活的架構設計流程，實際是對瀑布模型的繼續，我個人認為是完全背道而馳的。我多次參加過這樣的架構設計評審，基本上可以說沒有什么有真正營養的東西，只是一些流行概念的堆砌，昨天EJB,今天SSH，明天又是OSGI，這樣的架構設計作出來也有可能會大幅度修改，或者堅決不修改讓下面的人痛苦不堪，所謂的評審和存檔過程只是自欺欺人而已。再考慮現在各大公司流行的CMM/CMMI，過程改進管理，這些paper的工作還可能會因為引入復雜的審批修改流程把人拖入泥潭。
這種做法，在java圈子里面，因為早期sun和一些大公司對架構和模式概念的極力鼓吹，大為盛行。某些人甚至只是看完了blueprint，做了幾個tutorial，就搖身一變架構師，開始了架構設計生涯。
這樣的架構師也往往很少編寫代碼（我們可以理解，一個人寫完300頁的設計文檔以后，還有多少意愿再去寫實現代碼？），很少參與項目的開發工作，只滿足做一些試驗性質的代碼工作（對呀，現在開源東西這么多，流行的東西組裝一下架構設計就算over了么，還實現什么設計）和指導工作，甚至有些paper的架構師，完全就是靠粗讀各種pattern和x寶典來做設計，設計的可行性和高風險性，可想而知，早期大量EJB的濫用導致的項目失敗，其實根本原因在于甚少有架構師以驗證演進的手段來決定是否應該使用EJB，怎樣合理的使用EJB，將架構設計草率的外包給各大原廠商鼓吹的概念或者各種blueprint。而小兵們在面對架構+模式兩頂大帽的時候也只會怯懦的懷疑自己的個人能力，然后堅持不懈的向架構師這一偉大位置繼續奮斗。
而另一方面項目管理者也往往會誤以為有了正規的架構設計就可以更好的保證軟件項目質量，可以將項目的重心放置在需求和非技術工作之外，可以不用再考慮一般程序員的技術能力問題， 可以大幅度的xxx，xxx， 最后一堆苦水，然后再把責任歸咎于架構師不成熟。
我早年經歷過的幾個項目就有此方面沉痛的教訓，事后我個人復審設計，發現基本上整個方向都是錯誤的，個別項目設計者甚至連EJB的一些基本概念都沒有了解，自己重頭實現了一遍。過長的驗證周期導致后期已經無法再做任何修改，只能咬牙吞下。
真正實用的架構是以逐步嚴謹的方式驗證出來的，即便是自稱中國java NO.1的袁紅崗告訴你EJB非常好，沒有EJB的架構就不是真正的J2EE架構，你也要驗證以后再說，在此順便bs一下csdn。
在那篇架構師之死的小品里，boss問小兵，你如何說服大家要使用hibernate？ 其實答案很簡單，架構又不是設計出來的， 為什么要說服？