例如，Sisetti的ADMEMS架構系統分為以下視圖:
1.數據架構:描述數據的存儲結構和格式。
2.物理架構:描述機器的物理部署和網絡拓撲。
3.運行架構:描述運行時線程和進程之間的交互工作機制。
4.邏輯架構:是指如何將代碼劃分成不同的模塊和組件，以及它們的職責和交互。
5.開發架構:主要指開發工具的選擇，程序單元的劃分，開發管理的標準化流程。
比如分成哪些項目和項目，源代碼管理，自動編譯構建，測試，部署等。
目前，TOGAF架構系統在國際上得到廣泛應用。他將架構分為業務架構、數據架構、應用架構和技術架構。
如果想詳細了解這些建築視圖，可以參考這些建築體系相關的書籍和資料。
另外，很多人無緣無故攻擊建築這個概念，不知道是出於嘲諷還是無知。
埃及的金字塔和廟宇不是幾個普通的石匠壹起就能建成的。
中國的SAP、OracleERP、金蝶等大型系統，以及空間站、火箭的控制系統等。，沒有系統的架構方法、規範和流程，結果只能是悲劇。
當規模和復雜程度沒有達到壹定程度時，比如在壹些小團隊和產品中，架構過程可能會融入到老板、經理、團隊負責人和壹些資歷很深的開發人員中，融入到每個人的日常工作中，這樣就感覺不到架構的存在了。
即使遇到壹些問題，由於規模小，復雜度低，也比較容易調整。
當這些前提條件發生變化時，架構的功能和必要性就逐漸體現出來了。
壹般來說，說到架構，如果妳懂軟件，就會明白壹個軟件系統的組成結構，比如哪些是基本的支撐組件，哪些是完成A業務的，哪些是完成B業務的。但是說到企業架構，妳會問企業架構的幾個架構，比如業務架構，數據架構，業務架構，技術架構，是怎麽鏈接在壹起的。
相反，壹個企業確實需要這樣的框架，但不要神話它。最重要的是業務最終如何體現在軟件和流程中。
采用分離式設計時，最容易犯的錯誤就是各自為政，難以整合。
那麽以數據為中心的架構設計自然會為集成提供基礎。
如前所述，企業最重要的資產是數據，甚至不是信息，而是數據。
企業的業務流程會變，IT系統會變，需要的信息和知識會變，只能積累數據。