最近看了幾本關於架構的書籍，看來架構做爲一個概念和體系還很年輕，還不是很清晰。
首先架構的概念太寬泛，各領域都有架構的概念，僅就軟件領域而言，也包括：
業務架構、應用架構、技術架構、數據架構等。
本文僅就技術架構而言，有認爲架構只是過程而非結果的，有認爲架構只是圖表的，有認爲架構是路線和思想的。我認爲這只是概念層的架構，實在的、落地的、具體的、科學的架構纔是美麗的架構，否則只是“浮雲”啊。
因此我認爲：架構是支持某種類型軟件運行的虛擬機和構建器。參考：“應用架構的特徵”、“平臺之美”
架構不是面向具體功能的，而是面向全部需求的需求(元需求)，關注設計的設計（元設計），解決開發之共性，簡化開發之過程，提供應用之舞臺，可謂應用之母也。
架構是體系化的，完備的，能夠滿足一類軟件全部元需求的運行平臺和構建平臺，具體功能運行於其上，可以做到一通百通。
我預言：未來二十年將是各類架構平臺軟件誕生並逐步成熟的年代。它將逐步超過數據庫、中間件的軟件市場份額。
下面給出一個富客戶端企業技術架構的簡圖供參考：
一般架構爲三層，即表示層，領域層和數據層，但真實的企業級軟件架構要求更細緻，領域層會進一步分解爲中颱和後臺，中臺會實現諸多企業級應用系統的元需求，如：文件傳輸、消息發佈、錄入複覈、工作流轉、運行監控等非業務性需求。
虛擬AE層實現架構與具體技術的隔離，這是保障應用不受具體技術環境影響的重要設計。
參閱：軟件領域十大命題
有朋友希望推薦架構方面的書，我在這裏回答一下，首先如果你搞開發不滿3年，建議你先不要研究架構，認真學習一下“代碼整潔之道”或“編程規則”（該文就借鑑了許多該書的觀點），這對你成長爲架構師會有幫助，能夠寫出結構優美的代碼是成爲架構是的第一步。
另外，架構師需要很綜合的能力，要了解軟件、硬件、網絡、數據庫、中間件、工作流等的基本原理，欣賞繪畫、閱讀歷史、研究哲學，這樣你才能夠逐步具備進行企業級應用架構設計的能力，學習一下“系統架構設計師教程”也是不錯的選擇。
事實上，在許多國際水準的軟件企業，有10年開發經驗的，纔有資格進入產品開發部，有15年經驗才允許做架構層面的設計，但在我國10年還在搞開發的人幾乎不存在了，10年如果還在搞開發會被很多人認爲是沒出息的！這幾乎形成了一種文化，這應該給我們深刻的啓發和反省。
目前“架構”還很年輕，概念還比較亂，確切地說還沒有很好的書籍（有些書籍甚至會誤導你，書不是看的越多越好，一定要選擇，要看經典，“人月神話”、“人件”一定要看，不過“人件”讀起來比較澀，你可以參考我爲此書寫的精簡版，你最好把它推薦給你的老闆，讓他明白軟件開發人員是智力工作者，不是“碼工”）。“架構之美”並沒有名字那麼美，尤其不要被前面幾位寫推薦序的忽悠了，該書1~30頁是值得認真閱讀的。