Zachman框架起源於John Zachman先生在1987年完成的那篇著名的資訊系統架構論文（《A framework for information systems architecture》 ），並一直髮展至今。在這篇論文中Zachman先生以修建房屋為例從兩個維度將與資訊系統架構設計相關的各種元素歸納到如下表格之中：

• 表格中的每一行代表了在資訊系統構造過程中所涉及到的某干係人在描述資訊系統時所採用的視角，包括：
  • 範圍/規劃師（Planner）：包括整個資訊系統描述所處的環境上下文、產生於內部與來源於外部的各種約束，以及其他視角下對資訊系統的描述所需要考慮的相關構成部分的列表。
  • 業務模型/擁有者（Owner）：有關最終產品的概念檢視，反映了最終產品的使用特性，即使用者準備如何對最終產品加以使用。具有此視角的干係人包括最終產品的客戶或使用者。
  • 系統模型/設計師（Designer）：有關最終產品的邏輯檢視，反映了最終產品的本質規律以及邏輯約束。具有此視角的干係人包括工程師、架構師以及能夠將期望所得與現有的物理、技術上的實現聯絡起來的各種中間人。
  • 技術模型/建造者（Builder）：反映了在產品構建過程中現有技術的物理約束。具有此視角的干係人包括製造工程師、總承包商以及具有生產最終產品所需的技術能力的組織或人員。
  • 詳細表述/分包者（Sub-Contractor）：關於為了達到生產目的而對複雜物件進行分解的詳細描述，這些內容在從設計媒介到最終產品媒介的轉換中起著非常重要的作用。例如，用於將技術模型中所闡述的技術約束與供應商為所提供的產品聯絡在一起的產品規格說明。
  • 產品/執行中的企業（Functioning Enterprise）：在1987年的論文（《A framework for information systems architecture》）中並沒有這一行的內容，實際上此行的內容也並不在架構描述的範疇的之內，不過為了使得架構Zachman框架對於架構的表述更加完備，這一行最終還是被加了進去。這一行的內容代表了最終產品，是架構在客觀現實中的例項體現。例如，對資訊系統架構來說，此行的內容就是最終產出的資訊系統，同理，對於企業架構來說，這一行所代表的就是執行中的企業本身。簡而言之，前面五行的內容是對於客觀物件的描述，而這最後一行的內容就是客觀物件本身了。
• 表格中的每一列代表了用於描述資訊系統的某一個方面。在Zachman先生看來，對於任何一個事物只要在幾個基本方面對其進行清晰的解釋就足將其描述清楚，而且幾千年來人類自然語言的特性也證明了這一結論。這些方面包括：
  • 資料（What，即什麼內容）：用於表示客觀物件的材料組成，即材料清單。對於企業來說，此部分內容就是組成事物模型（Thing Model，之所以將其稱為組成事物模型而不是資料模型是因為由於不同的行代表了不同的視角，而僅在設計師所處的第三行才會關注真正資訊化意義上的“資料模型”，因而在此才使用“組成事物”來對所有視角在此列中的描述物件進行指代）。
  • 功能（How，即如何工作）：用於表示功能和轉換行為。對於企業來說，這部分內容就是流程或功能模型等。
  • 網路（Where，即何處）：用於表示各組成部件的坐落位置以及相互之間的聯通關係。對於企業來說，這部分內容就是物流或網路模型等。
  • 人（Who，即何人負責）：用於描述了何人應該做何事，例如使用者手冊和操作說明等。對於企業來說，這部分內容就是人力模型或工作流模型等。
  • 時間（When，即什麼時間）：用於描述事物發生的時間以及不同事物之間的相對時間關係，例如生命週期和時序圖等。對於企業來說，這部分內容就是時間或動態模型等。
  • 原因（Why，即為什麼做）：用於表示最終結果和意義。對於企業來說，這部分內容就是動機模型等。
• 每行和列相交的單元格表示了各個干係人在各自視角上對於資訊系統的某個方面的具體描述。

    通過上述關於Zachman框架內容的表述我們可以發現此框架本身並不複雜，不過在實際應用過程中我們還應該遵循下列的使用規則：

• 不能為此框架增加新的行或列。在Zachman框架看來，框架中的六行視角以及六列描述方面構成了系統描述的最基本元語，即為了構建系統而對其架構所做的描述只要能夠從六種視角出發，並能為每個視角在六個方面（什麼內容（What）、如何工作（How）、何處（Where）、何人負責（Who）、何時（When）和為什麼動機（Why））做出解答，那麼此架構描述就是完備的，也由此足以成為系統的複雜度管理和變更管理的基礎。
• 每一列中的內容都遵從某一通用模型。由於每一列都代表了所描述架構的某一個方面，因而處於同一列的各個描述在本質上應符合某種經過高度抽象的元模型：
  • “資料”列（What）應遵從：事物——關係——事物。
  • “功能”列（How）應遵從：流程——輸入/輸出——流程。
  • “網路”列（Where）應遵從：節點——連線——節點。
  • “人”列（Who）應遵從：人員——工作——人員。
  • “時間”列（When）應遵從：事件——週期——時間。其中，“事件”指代某一時間點，而“週期”代表了一段時間區間。
  • “原因”列（Why）應遵從：結果——方式——結果。其中，“結果”代表了目標狀態，而“方式”則用於表示為了達成目標狀態而採用的行為。
• 每個表格單元中的模型應該是其所在列採用的通用模型的具體特化。雖然在前面規則中提到過，每一列中的架構描述都遵循相同的模型，但是由於每一行所代表的視角對於描述所採用的術語、語法以及所受的約束各有不同，因而對於每個具體的單元格來說，其中的架構描述也應該是以該列所採用的通用元模型為基礎並受其所在行視角約束的特化。
• 表格單元中架構描述的詳細度與其所在的行無關。人們很容易有一種錯覺，那就是在同一列中不同行裡面架構描述的詳細度有一個自上而下越來越詳細的趨勢，因為好像越是位於上面的行，其所代表的視角就越不關注於最終產品的實現細節，因而其中的架構描述也無需太高的詳細度，反之越靠下方的行就需要更高的詳細度。從實現的角度來說，這一擔心不無道理，不過就架構描述的目標來說，這種詳細度自上而下漸漸增高的趨勢是有待商榷的。由於框架中的每一行代表了不同的視角，但這並不代表所有的視角都關注於最終產品在實現方面的問題，而正因為每個視角的關注點不同，所以僅從實現細節這個角度來說詳細度的差異是有問題的。例如第一行的規劃者關注於最終產品的所處的上下文環境，因而對在這一角度所進行的描述來說，其詳細度應該根據具備這一視角的干係人的要求而定，而其下各行由於關注點不同，所以他們在描述的詳細程度方面不具備可比性。由此我們可以發現，不同行的架構描述是相互獨立但又互相聯絡的，他們之間是轉換關係而不是演進關係，
• 不存在可以在不同的表格單元之間共享的元概念元素。由於表格中的每行或每列都是代表著某一視角或基本元語，因而由他們組成的各個表格單元中的架構描述也應該是獨一無二的，所以不同表格單元之間的架構描述不應該出現共享元概念元素的情況。
• 不要在對角線方向上對不同的單元格進行直接聯絡，這樣只會增加溝通障礙。每一個單元表格只與同行或者同列中位於其上和其下的單元表格之間有著直接關聯，如此才能把溝通障礙和變更管理的難度最小化。
• 不要改變行或列的標頭名稱。在Zachman框架看來，由於本身邏輯框架已經完備，因而修改行或列的標頭名稱或含義會對整個邏輯框架產生不利的影響。這裡需要注意的是，在圖3所示的Zachman框架列表中，其行標頭和列表頭都含有上下兩個名稱，例如，第一行的標頭就具有“範圍”和“規劃者”兩個名稱，而第一列也具有“資料”和“什麼（What）”這兩個稱呼。這兩種名稱系列（用加粗大號字型標明的名稱和採用小號斜體字型的名稱）代表著Zachman框架的兩種使用情境：
  • 通用情景：此種情景下，Zachman框架具有更高的通用性，例如房屋建築、飛機等。其中各個標頭將採用由小號斜體字型標明的名稱。
  • 企業特定情景：此種情景下，Zachman框架的目標放諸“企業”這一特定的概念之上，而其中各個標頭將採用由加粗大號字型標明的名稱。

        需要注意的是，不論是上述哪種使用情境，按照Zachman框架的使用規則，這些標頭名稱都不能因為實際情況的不同而進行變    更。

• Zachman框架邏輯具有通用性和迭代性。此框架雖然在企業架構領域名聲斐然，不過這並不意味著他只能被應用於這一領域，實際上對於Zachman框架來說，他並不針對於某一具體事物，無論是有形的事物，諸如房屋、飛機等，亦或是抽象的概念實體，例如企業等，都可以是他描述的目標，因而在這一點上其具備普適性，而也正因為這一普適性，其每個單元格中的內容亦可以作為描述目標而被此框架無限迭代描述下去。

      綜上所述，Zachman框架認為一個關於客觀事物（可以是房子或飛機這種有形實體，也可以是諸如企業這樣的無形概念物件）的架構描述應包括兩個維度，其中，一個維度表示了對架構進行描述所應採用的六種視角，而另一個維度則代表了架構描述所需要回答的六個方面的問題。這兩個維度正交交叉，從而形成了36個交匯點，其中的每一個代表了架構描述的某一具體架構製品。舉例來說，不論是規劃師還是設計師在描述一個系統時，都需要描述系統的資料、功能等方面，但是對於某一個具體方面，例如資料，不同的角色有著不同的理解。對於業務擁有者來說，資料指的是諸如客戶、產品這樣的業務實體以及他們之間的關係，而對於執行系統設計的設計師來說，資料指代的就是完全資訊化意義上的資料資訊片段了。除了這些明顯的特性之外，Zachman框架還暗含了以下三點意義：

• 每個架構製品僅能存在於一個表格單元中。也就是說，每個架構製品的定義都必須是清晰的，如果某個架構製品可能出現於兩個或兩個以上的表單元中則表示此架構製品的內容是有問題的。
• 僅當某一個角色針對系統某一方面提供了足夠的架構製品才表示與之對應的表單元是完整的，而表中所有的表單元都被填充才表示一個架構是完整的。
• 針對表中每一列的內容必須是相互關聯的。例如，在業務擁有者定義的資料必須在設計師的資料庫設計中得到對映，並且每個資料庫中的資料的定義都可以回溯到某個業務中的資料定義。

      Zachman框架從本質上來說是對企業架構描述的一種分類法，其對於如何解決企業資訊化發展所面臨的問題（系統複雜度管理、業務與資訊科技的不協調發展）能夠提供如下的幫助：

• 給出了企業架構內容的描述和分類法，從而可以複雜的系統進行分解描述。
• 確保每個干係人的每一個關注點被照顧到。
• 改進每個架構製品使其更加契合目標受眾的關注點。
• 確保業務需求可以被對映到技術實現之上，同時每個技術實現也可以被回溯到業務需求之上。
• 加強業務人員與資訊科技人員的溝通和交流，減免以前因缺乏溝通而導致的無謂的內耗。

      儘管如此，有些學者並不將Zachman看作為一個框架（例如，《Comparison of the Top Four Enterprise Architecture Methodologies》 的作者），而僅僅把其當成企業架構描述的一個內容分類法。這種看法是有其根據的，就其原因還是因為此框架在如下方面無法給予解答：

• 雖然此框架描述了企業架構應該包含哪些內容，但是並沒有給出如何建立這些內容，亦即缺乏一種關於架構開發過程的描述。
• 在此框架之下企業架構內容就像一張靜態畫面一樣，而企業架構是應該隨著企業的發展而變化的，因而如何在不斷地演進過程中對企業架構進行治理也是他缺乏的內容之一。
• 此框架並沒有提供一個判別標準，因而無法瞭解按照此種方式組織的企業架構是否是一個好的架構，也就是說該框架缺乏成熟度框架。