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