不同的架構方法論，會將架構分為不同視圖，每個視圖側重某一個方面、領域的問題。
　　比如希賽推的ADMEMS架構體系，分為以下幾種視圖：
　　1. 數據架構：描述數據的存儲結構、格式等方面。
　　2. 物理架構：描述機器的物理部署、網絡拓撲方面。
　　3. 運行架構：描述運行期線程、進程間的交互工作機制。
　　4. 邏輯架構：指如何將代碼分成不同模塊、組件，以及之間的職責分配、交互行為。
　　5. 開發架構：主要指開發工具的選擇，程序單元的劃分，開發管理規范流程等方面。
　　例如分為哪些工程、項目，源代碼管理，自動化編譯構建、測試、部署等。
　　目前國際上運用比較廣泛的是TOGAF架構體系，他把架構分為業務架構、數據架構、應用架構、技術架構等幾個方面。
　　想詳細的了解這些架構視圖，可以參考這些架構體系相關的書、資料。
　　另外有很多人無緣無故的抨擊架構概念，不知道是出于調侃還是無知。
　　埃及的金字塔、神廟的建設，不是幾個平常的泥瓦匠聚在一起就能夠造出來的。
　　像SAP、Oracle ERP，國內的金蝶等大規模的系統，以及空間站、火箭的控制系統等，沒有系統性的架構方法、規范、流程，結果只能是悲劇。
　　當規模、復雜度沒有達到一定程度，比如在一些小的團隊、產品中，架構過程可能融入到老板、經理、組長、資歷較深的一些開發者中，融入在大家的日常工作中，以至于感覺不到架構的存在。
　　就算遇到一些問題，因規模不大、復雜度不高，也比較容易調整。
　　當這些前提條件發生變化時，架構的作用和必要性就逐步的體現出來。
　　總的來說，一說到架構，如果懂軟件，那么會了解為一個軟件系統，這個軟件設計的組成結構，如哪些是基礎支持組件，哪些是完成A業務，哪些完成B業務……但說道企業架構的時候，就會問，該企業架構的幾個架構如業務架構、數據架構、業務架構、技術架構，以及如何鏈接在一起。
　　倒覺得，一個企業確實需要這樣的架構，但不要神話它，最主要的是業務如何最終體現到軟件中和流程中。
　　而采取分離式設計時，最容易的錯誤就是各自為政，集成困難。
　　那么以數據為中心的架構設計，會自然提供集成的基礎。
　　提到過，企業最重要的資產是數據，甚至不是信息，是數據。
　　企業的業務流程會變，IT系統會變，所需要的信息與知識會變，唯有數據能夠積淀下來。
　　這有點象自然演進，考古那種，啥都