Zachman框架
全稱為企業架構和企業信息系統架構Zachman框架(Zachman Framework for Enterprise Architecture and Information Systems Architecture)。Zachman"框架"實際上是一種組織構架工具（用來設計文檔、需求說明和模型的工具）的一種分類學。包括工具的目標（例如，商業擁有者、創建者）是誰，哪些特殊的問題（例如，數據、功能）需要闡明。
Zachman是這樣描述他的傑作的：
當這個框架應用於企業時，它僅僅是用來分類和組織企業（在這些企業里，企業的管理和企業系統的開發同樣重要）的描述形式的邏輯結構。
許多Zachman框架的支持者認為它是跨學科的，它的影響不僅僅局限於IT行業。例如，一本關於Zachman的書中這樣說：
在適當的時候，你會發現框架不僅僅是存在於IT項目中，它存在於你所做的每一件事情中。當你完全理解了這個框架之后，做任何事情都會變得高效。我指的是任何事情，這個斷言並不武斷。
一、框架簡介
Zachman框架是一種邏輯結構，目的是為IT企業提供一種可以理解的信息表述，它對企業信息按照特定的要求進行分類，從不同角度進行描述。
根據抽象規則，它定義企業信息的一個方面，一個框架采用了一種六行，每行中包含36個子單元的格式。
六行(即縱向維度)反映了IT架構層次，從上到下（Top-Down）。包括了范圍模型、企業模型、系統模型、技術模型、詳細模型、功能模型。
如同建築構架為不同的角色提供不同的材料。每個角色都需要完整的信息，不過對於不同的角色而言，所需的完整信息也是不同的。擁有者感興趣的完整描述是建築物的功能和美感。構造者感興趣的完整描述是建築材料和構建過程。擁有者並不關心牆里面的螺栓釘在哪兒，構造者也不關心卧室的窗戶如何排列，以便在早晨能夠迎來第一縷陽光。
從兩個維度將所有IT構件進行分割，可以划分成小的相對獨立的模塊，便於獨立管理。
六列（即橫向維度）采用5W1H（what、how、where、who、when、why）進行組織。即分別為做什么（數據）、如何做，什么地點，誰來做、什么時間、為什么做。
以列描述中的"數據（What）"為例：
----從商業擁有者的角度，"數據"意味着商業實體。它可能包括實體本身的信息，如客戶和產品，也可能包括實體間關系的信息，如人口群體和庫存。如果你打算和一個商業擁有者討論數據，你應該用到這些語言。
----從數據庫的實現者的角度來看，"數據"就不是商業實體了，而是保存在數據表中的行和列，還有通過連接（join）和映射（projection）生成的表。如果你在和一個數據庫設計者討論"數據"，不要討論客戶的群體，而應該討論關系數據表。
並不是從一個角色的角度看就比從另外一個角色的角度看要好，也不是越詳細越好，也不是某一個的優先級比其他的更高。作為一個整體，無論是從誰的角度都很重要。正如Zachman說過的：
我們在信息系統構架方面與另外的構架溝通時有很多困難，因為存在很多構架表現形式，而不是僅僅只有一個構架。其中一個出錯了，其他的也跟着出錯。構架是不同的。它們是附加的和補充的。選擇為開發每個構架表現形式而支出資源是有原因的。如果不開發任何構架表現形式是有風險的。
正如我前面提到的，Zachman框架由六個功能焦點組成，每個功能焦點都會從一個角色的角度考慮。
zachman framwork 3.0
數據（什么？） |
功能（怎樣？） |
網絡（哪里？） |
角色（誰？） |
時間（何時？） |
動機（為何？） |
|
| 目標范圍 |
列出對業務至關重要的元素（或事件） |
列出業務執行的流程 |
列出與業務運營有關的地域分布要求 |
列出對業務重要的組織部門 |
列出對業務重要的事件及時間周期 |
列出企業目標、戰略 |
| 業務模型 |
實體關系圖（包括M: M關系、N-ary關系、歸因關系） |
業務流程模型（物理數據流程圖） |
物流網絡（節點和鏈接） |
基於角色的組織層次圖 包括相關技能規定、 安全保障問題。 |
業務主進度表 |
業務計划 |
| 信息系統模型 |
數據模型（聚合體、完全規格化） |
關鍵數據流程圖、 應用架構 |
分布系統架構 |
人機界面架構（角色、數據、入口） |
相依關系圖、數據實體生命歷程（流程結構） |
業務標准模型 |
| 技術模型 |
數據架構（數據庫中的表格列表及屬性）、 遺產數據圖 |
系統設計： 結構圖、偽代碼 |
系統架構（硬件、軟件類型） |
用戶界面（系統如何工作）、 安全設計 |
“控制流”圖（控制結構） |
業務標准設計 |
| 詳細展現 |
數據設計（反向規格化）、物理存儲器設計 |
詳細程序設計 |
網絡架構 |
屏顯、安全機構（不同種類數據源的開放設定） |
時間、周期定義 |
程序邏輯的角色說明 |
| 功能系統 |
轉化后的數據 |
可執行程序 |
通信設備 |
受訓的人員 |
企業業務 |
強制標准 |
這36個方格，每個方格就是一個角色（例如商業擁有者）和每個描述焦點（如數據）的交匯。當我們在表格中水平移動（例如從左到右）時，我們會從同一個角色的角度，看到系統的不同描述。當在表格中豎直移動（例如從上到下）時，我們會看到從不同角色的角度，如何觀察同一個焦點。
二、框架釋意：
1、縱向項目
縱向按企業中不同角色的關注點進行划分：
范圍/規划人員（Planner）
包括整個信息系統描述所處的環境上下文、產生於內部與來源於外部的各種約束，以及其他視角下對信息系統的描述所需要考慮的相關構成部分的列表。關注范圍模型，能夠看到企業的發展方向、業務宗旨和系統邊界范圍。
業務模型/擁有者（Owner）
有關最終產品的概念視圖，反映了最終產品的使用特性，即用戶准備如何對最終產品加以使用。具有此視角的干系人包括最終產品的客戶或用戶。關注企業模型，能夠用企業術語定義企業的本質，看到的是企業的結構、處理、組織等。
系統模型/設計師（Designer）
有關最終產品的邏輯視圖，反映了最終產品的本質規律以及邏輯約束。具有此視角的干系人包括工程師、架構師以及能夠將期望所得與現有的物理、技術上的實現聯系起來的各種中間人。關注系統模型，能夠用更嚴格的術語定義企業業務，看到的是每項業務處理所要完成的功能。
技術模型/建造者（Builder）
反映了在產品構建過程中現有技術的物理約束。具有此視角的干系人包括制造工程師、總承包商以及具有生產最終產品所需的技術能力的組織或人員。關注技術模型，使用技術模型來解決企業業務的信息處理需求。
詳細表述/分包者（Sub-Contractor）
關於為了達到生產目的而對復雜對象進行分解的詳細描述，這些內容在從設計媒介到最終產品媒介的轉換中起着非常重要的作用。例如，用於將技術模型中所闡述的技術約束與供應商為所提供的產品聯系在一起的產品規格說明。關注詳細模型，需要去解決關於特定語言、數據庫存儲表格及網絡狀況等具體細節。
產品/運行中的企業（Functioning Enterprise）
在1987年的論文（《A framework for information systems architecture》）中並沒有這一行的內容，實際上此行的內容也並不在架構描述的范疇的之內，不過為了使得架構Zachman框架對於架構的表述更加完備，這一行最終還是被加了進去。這一行的內容代表了最終產品，是架構在客觀現實中的實例體現。例如，對信息系統架構來說，此行的內容就是最終產出的信息系統，同理，對於企業架構來說，這一行所代表的就是運行中的企業本身。簡而言之，前面五行的內容是對於客觀對象的描述，而這最后一行的內容就是客觀對象本身了。
關注功能模型，也是系統的最終用戶，考慮系統能否支持自身的工作。
2、框架中的列
數據（What，即什么內容）
用於表示客觀對象的材料組成，即材料清單。對於企業來說，此部分內容就是組成事物模型（Thing Model，之所以將其稱為組成事物模型而不是數據模型是因為由於不同的行代表了不同的視角，而僅在設計師所處的第三行才會關注真正信息化意義上的“數據模型”，因而在此才使用“組成事物”來對所有視角在此列中的描述對象進行指代）。
功能（How，即如何工作）
用於表示功能和轉換行為。對於企業來說，這部分內容就是流程或功能模型等。
網絡（Where，即何處）
用於表示各組成部件的坐落位置以及相互之間的聯通關系。對於企業來說，這部分內容就是物流或網絡模型等。
人（Who，即何人負責）
用於描述了什么人應該做什么事，例如用戶手冊和操作說明等。對於企業來說，這部分內容就是人力模型或工作流模型等。
時間（When，即什么時間）
用於描述事物發生的時間以及不同事物之間的相對時間關系，例如生命周期和時序圖等。對於企業來說，這部分內容就是時間或動態模型等。
原因（Why，即為什么做）
用於表示最終結果和意義。對於企業來說，這部分內容就是動機模型等。
三、使用規則
1、不增加新的行或列。
在Zachman框架看來，框架中的六行視角以及六列描述方面構成了系統描述的最基本元語，即為了構建系統而對其架構所做的描述只要能夠從六種視角出發，並能為每個視角在六個方面（什么內容（What）、如何工作（How）、何處（Where）、何人負責（Who）、何時（When）和為什么動機（Why））做出解答，那么此架構描述就是完備的，也由此足以成為系統的復雜度管理和變更管理的基礎。
2、不修改行或列的名稱或含義。
在Zachman框架看來，由於本身邏輯框架已經完備，因而修改行或列的標頭名稱或含義會對整個邏輯框架產生不利的影響。這里需要注意的是，Zachman框架列表中，其行標頭和列表頭都含有上下兩個名稱，例如，第一行的標頭就具有“范圍”和“規划者”兩個名稱，而第一列也具有“數據”和“什么（What）”這兩個稱呼。這兩種名稱系列（用加粗大號字體標明的名稱和采用小號斜體字體的名稱）代表着Zachman框架的兩種使用情境：
- 通用情景：此種情景下，Zachman框架具有更高的通用性，例如房屋建築、飛機等。其中各個標頭將采用由小號斜體字體標明的名稱。
- 企業特定情景：此種情景下，Zachman框架的目標放諸“企業”這一特定的概念之上，而其中各個標頭將采用由加粗大號字體標明的名稱。
需要注意的是，不論是上述哪種使用情境，按照Zachman框架的使用規則，這些標頭名稱都不能因為實際情況的不同而進行變更。
3、每一列中的內容都遵從某一通用模型。
由於每一列都代表了所描述架構的某一個方面，因而處於同一列的各個描述在本質上應符合某種經過高度抽象的元模型：
- “數據”列（What）應遵從：事物——關系——事物。
- “功能”列（How）應遵從：流程——輸入/輸出——流程。
- “網絡”列（Where）應遵從：節點——連接——節點。
- “人”列（Who）應遵從：人員——工作——人員。
- “時間”列（When）應遵從：事件——周期——時間。其中，“事件”指代某一時間點，而“周期”代表了一段時間區間。
- “原因”列（Why）應遵從：結果——方式——結果。其中，“結果”代表了目標狀態，而“方式”則用於表示為了達成目標狀態而采用的行為。
4、表格單元中架構描述的詳細度與其所在的行無關。
人們很容易有一種錯覺，那就是在同一列中不同行里面架構描述的詳細度有一個自上而下越來越詳細的趨勢，因為好像越是位於上面的行，其所代表的視角就越不關注於最終產品的實現細節，因而其中的架構描述也無需太高的詳細度，反之越靠下方的行就需要更高的詳細度。從實現的角度來說，這一擔心不無道理，不過就架構描述的目標來說，這種詳細度自上而下漸漸增高的趨勢是有待商榷的。由於框架中的每一行代表了不同的視角，但這並不代表所有的視角都關注於最終產品在實現方面的問題，而正因為每個視角的關注點不同，所以僅從實現細節這個角度來說詳細度的差異是有問題的。例如第一行的規划者關注於最終產品的所處的上下文環境，因而對在這一角度所進行的描述來說，其詳細度應該根據具備這一視角的干系人的要求而定，而其下各行由於關注點不同，所以他們在描述的詳細程度方面不具備可比性。由此我們可以發現，不同行的架構描述是相互獨立但又互相聯系的，他們之間是轉換關系而不是演進關系。
5、不存在可以在不同的表格單元之間共享的元概念元素。
由於表格中的每行或每列都是代表着某一視角或基本元語，因而由他們組成的各個表格單元中的架構描述也應該是獨一無二的，所以不同表格單元之間的架構描述不應該出現共享元概念元素的情況。
6、不要在對角線方向上對不同的單元格進行直接聯系，這樣只會增加溝通障礙。
每一個單元表格只與同行或者同列中位於其上和其下的單元表格之間有着直接關聯，如此才能把溝通障礙和變更管理的難度最小化。
7、Zachman框架邏輯具有通用性和迭代性。
此框架雖然在企業架構領域名聲斐然，不過這並不意味着他只能被應用於這一領域，實際上對於Zachman框架來說，他並不針對於某一具體事物，無論是有形的事物，諸如房屋、飛機等，亦或是抽象的概念實體，例如企業等，都可以是他描述的目標，因而在這一點上其具備普適性，而也正因為這一普適性，其每個單元格中的內容亦可以作為描述目標而被此框架無限迭代描述下去。
總結：
Zachman框架從本質上來說是對企業架構描述的一種分類法，其對於如何解決企業信息化發展所面臨的問題（系統復雜度管理、業務與信息技術的不協調發展）能夠提供如下的幫助：
- 給出了企業架構內容的描述和分類法，從而可以復雜的系統進行分解描述。
- 確保每個干系人的每一個關注點被照顧到。
- 改進每個架構制品使其更加契合目標受眾的關注點。
- 確保業務需求可以被映射到技術實現之上，同時每個技術實現也可以被回溯到業務需求之上。
- 加強業務人員與信息技術人員的溝通和交流，減免以前因缺乏溝通而導致的無謂的內耗。
關於Zachman表格有三條建議，相信它們在企業構架的開發中對我們會有幫助。
第一條建議就是每一個構架材料應該存在於一個方格中，而且只能存在於一個方格中。在一個構架材料放在哪個方格里不應該含糊不清。如果某個構架材料的確不知道應該放在哪個方格中，問題很有可能處在構架材料本身。
當組織在開發企業構架中開始積累材料的時候，它可以使用Zachman表格解釋每個材料的焦點。例如，面向服務構架相關的材料很有可能就放在第三行（從設計着的角度看）。它們一般不會引起商業擁有者的興趣。
第二條建議：僅僅只有當所有的表格都填滿了的時候，一個構架才能被稱為是完整的構架。當所有的方格都填滿了時候，整個表格才有足夠的材料定義系統。
只有當每個方格都填滿了材料的時候，才有足夠的信息描述系統：從每個角色（我們現在可以稱之為"利益相關者"，Stakeholder）的角度觀察系統的每個可能的視角（描述焦點）。所以一個組織可以使用Zachman表格確保企業構架中的所有重要利益相關者之間的討論都是合適的。
第三條建議：表格的每列的方格都是彼此相關的。例如，Zachman表格的數據列（第一列）。從商業擁有者的角度，數據就是關於商業的信息。從數據庫管理人員的角度，數據就是數據庫中的行和列。
盡管商業擁有者對數據的看法和數據庫管理員不同，但它們應該是有關系的。一個人可以遵循商業需求，並且顯示出設計的數據就是被需求驅動的。如果有商業需求並沒有追蹤到數據庫設計，那么就得想想商業需求是否與企業構架相符。另一方面，如果數據庫設計的元素沒有需求與之對應，我們就應該問問自己，在數據庫層面是否存在不必要的設計。
Zachman表格可以從以下五個方面幫助我們開發企業構架：
確保每個利益相關着能夠從描述的焦點考慮。
通過把每個焦點精簡到每個特殊觀眾涉及的焦點來提升構架材料的質量。
確保每個商業需求能夠追蹤到技術實現。
確保商業方面不會規划出多余沒用的功能。
確保技術組包含在商業組的規划中。
但是Zachman本身並不是一個完整的解決方案。有太多的問題它都沒有描述。例如，Zachman沒有給出一步一步構造一個構架的過程。在決定我們將要構建的構架是否是最好的時候，Zachman沒有提供更多的信息幫助我們作出決定。就此而言，Zachman也沒有給出一種途徑展示將來構架的需求。最重要的，從我們的角度，盡管Zachman表格可以幫助組織構架材料，但是它在描述企業復雜性方面幾乎什么都沒做。
采用Zachman框架進行IT規划的一般步驟：
（1）確定組織的願景和原則
- 確定IT架構業務、組織與IT系統范圍，識別業務驅動力；
- 確定IT架構願景和目標；
- 制定IT架構定義的原則；
- 識別IT架構相關需求；
- 業界IT架構最佳實踐研究與學習。
（2）現狀描述分析
- 搜集現有IT系統現狀資料；
- 業務現狀分析，識別現有IT系統對業務支撐上存在的問題。
- 引入最佳實踐，並結合企業實際，定義目標IT架構，包括：數據、應用、基礎設施架構。
- 目標架構與現狀的差距與改進點分析；
- 把具體IT需求納入目標架構框架。
- 對IT架構的改進點，以及具體需求進行優先級排序。
（3）制定IT架構的實施計划
- 確定向目標IT架構遷移的具體實施計划；
- 確定目標IT架構實施的推行組織。優化
（4）持續改進IT架構規划過程中，各個環節不斷優化；
- 制定目標IT架構的持續改進計划；
- 制定IT架構的管理維護機制。