由約翰 扎科曼（John Zachman ）在1987年創立的全球第一個企業架構理論，其論文《信息系統架構框架》至今仍被業界認為是企業架構設計方面最權威的理論。是其他企業架構框架的源泉。
基本介紹
- 中文名：Zachman框架
- 定義：企業架構理論
- 創立者：約翰 扎科曼
- 創立時間：1987年
簡介,發展,
簡介
Zachman框架（Zachman framework）是一種邏輯結構，它旨為信息技術企業提供一種可以理解的信息表述。它可以對企業信息按照要求分類和從不同角度進行表示。Zachman框架的創始人John Zachman早在1987年就提出了這種思想，它全稱為企業架構和企業信息系統結構架構(Zachman Framework for Enterprise Architecture and Information Systems Architecture)。
Zachman框架提煉和吸收了傳統方法中的一些精髓，它是一款獨立於信息企業所使用的工具的平台。它可以根據抽象規則定義企業信息的一個方面.一個框架採用了一種六行,每行中包含36個子單元的格式，這六行包括了範圍，商業模式,系統模式，技術模式,組件和工作系統)其中有六列分別為誰，什麼，什麼時間，什麼地點，為什麼和如何做。
Zachman框架被很多企業管理者認為是一種發展IT企業和進行複雜管理的規則集合。
發展
第一個最有影響力的框架方法論就是Zachman框架，它是John Zachman首次在1987年提出的。
在理解Zachman框架之前，我們需要了解的是，它並不是一個框架，至少從框架的定義上嚴格地來看，它不是。從《美國傳統詞典》上，我們可以找到框架的定義如下：
支持或封裝其他東西的一種結構，尤其是作為其他的一些已經創建的東西的基礎給予其骨架支持；一種外部的工作平台；腳手架；一種基本結構；組成觀察顯示的一系列的假想、內容、價值和實踐。
而在分類學中，它是這樣定義的：
在顯示自然關係的有序系統中的有機分類；科學、法律或者理論的分類；系統化；劃分成有序的組或類別。
Zachman"框架"實際上是一種組織構架工具（用來設計文檔、需求說明和模型的工具）的一種分類學。包括工具的目標（例如，商業擁有者、創建者）是誰，哪些特殊的問題（例如，數據、功能）需要闡明。
而Zachman是這樣描述他的傑作的：
當這個框架套用於企業時，它僅僅是用來分類和組織企業（在這些企業里，企業的管理和企業系統的開發同樣重要）的描述形式的邏輯結構。
許多Zachman框架的支持者認為它是跨學科的，它的影響不僅僅局限於IT行業。例如，一本關於Zachman的書中這樣說：
在適當的時候，你會發現框架不僅僅是存在於IT項目中，它存在於你所做的每一件事情中。當你完全理解了這個框架之後，做任何事情都會變得高效。我指的是任何事情，這個斷言並不武斷。
在和Zachman討論問題的時候，他本人也曾說：
這個框架已經存在了幾千年，而且我敢肯定它在以後的幾千年將繼續存在。稍微有些改變的是我們對它的理解和怎樣使用它。
Zachman在解釋他的IT分類學時，最初試用了建築行業作為類比。在建築行業里，構架材料通過使用二維表格表示出來。表格其中的一維是變數"遊戲中的角色"。對於一個建築物來說，這些選手就是擁有者（誰為這個項目付款）、構造者（負責構建的人）、城市規劃委員會（負責確保建築遵循當地建築標準的人）。
建築構架為不同的角色提供不同的材料。每個角色都需要完整的信息，不過對於不同的角色而言，所需的完整信息也是不同的。擁有者感興趣的完整描述是建築物的功能和美感。構造者感興趣的完整描述是建築材料和構建過程。擁有者並不關心牆裡面的螺栓釘在哪兒，構造者也不關心臥室的窗戶如何排列，以便在早晨能夠迎來第一縷陽光。
正如Zachman在他的一篇文章中提到的：
每個構架表現形式和其他的構架不同，其本質不僅僅是細節的層面。
構架材料組織的第二維是材料的描述中心--和項目相關的什麼（what）、怎樣（how）、誰（who）、何時（when）、為什麼（why）。這一維和第一維之間是相互獨立的。構造者和擁有者都需要知道"什麼"，但是"什麼"是什麼還得取決於問這個話的人是誰。
在Zachman的第一篇論文和隨後的詳細解說中，Zachman建議有六個描述的焦點（數據、功能、網路、人員、時間、動機）和六個角色的角度（規劃者、擁有者、設計者、構造者、轉包商、運營企業）。如圖1-3所示
支持或封裝其他東西的一種結構，尤其是作為其他的一些已經創建的東西的基礎給予其骨架支持；一種外部的工作平台；腳手架；一種基本結構；組成觀察顯示的一系列的假想、內容、價值和實踐。
而在分類學中，它是這樣定義的：
在顯示自然關係的有序系統中的有機分類；科學、法律或者理論的分類；系統化；劃分成有序的組或類別。
Zachman"框架"實際上是一種組織構架工具（用來設計文檔、需求說明和模型的工具）的一種分類學。包括工具的目標（例如，商業擁有者、創建者）是誰，哪些特殊的問題（例如，數據、功能）需要闡明。
而Zachman是這樣描述他的傑作的：
當這個框架套用於企業時，它僅僅是用來分類和組織企業（在這些企業里，企業的管理和企業系統的開發同樣重要）的描述形式的邏輯結構。
許多Zachman框架的支持者認為它是跨學科的，它的影響不僅僅局限於IT行業。例如，一本關於Zachman的書中這樣說：
在適當的時候，你會發現框架不僅僅是存在於IT項目中，它存在於你所做的每一件事情中。當你完全理解了這個框架之後，做任何事情都會變得高效。我指的是任何事情，這個斷言並不武斷。
在和Zachman討論問題的時候，他本人也曾說：
這個框架已經存在了幾千年，而且我敢肯定它在以後的幾千年將繼續存在。稍微有些改變的是我們對它的理解和怎樣使用它。
Zachman在解釋他的IT分類學時，最初試用了建築行業作為類比。在建築行業里，構架材料通過使用二維表格表示出來。表格其中的一維是變數"遊戲中的角色"。對於一個建築物來說，這些選手就是擁有者（誰為這個項目付款）、構造者（負責構建的人）、城市規劃委員會（負責確保建築遵循當地建築標準的人）。
建築構架為不同的角色提供不同的材料。每個角色都需要完整的信息，不過對於不同的角色而言，所需的完整信息也是不同的。擁有者感興趣的完整描述是建築物的功能和美感。構造者感興趣的完整描述是建築材料和構建過程。擁有者並不關心牆裡面的螺栓釘在哪兒，構造者也不關心臥室的窗戶如何排列，以便在早晨能夠迎來第一縷陽光。
正如Zachman在他的一篇文章中提到的：
每個構架表現形式和其他的構架不同，其本質不僅僅是細節的層面。
構架材料組織的第二維是材料的描述中心--和項目相關的什麼（what）、怎樣（how）、誰（who）、何時（when）、為什麼（why）。這一維和第一維之間是相互獨立的。構造者和擁有者都需要知道"什麼"，但是"什麼"是什麼還得取決於問這個話的人是誰。
在Zachman的第一篇論文和隨後的詳細解說中，Zachman建議有六個描述的焦點（數據、功能、網路、人員、時間、動機）和六個角色的角度（規劃者、擁有者、設計者、構造者、轉包商、運營企業）。如圖1-3所示
以列描述中的"數據"為例。從商業擁有者的角度，"數據"意味著商業實體。它可能包括實體本身的信息，如客戶和產品，也可能包括實體間關係的信息，如人口群體和庫存。如果你打算和一個商業擁有者討論數據，你應該用到這些語言。
從資料庫的實現者的角度來看，"數據"就不是商業實體了，而是保存在數據表中的行和列，還有通過連線（join）和映射（projection）生成的表。如果你在和一個資料庫設計者討論"數據"，不要討論客戶的群體，而應該討論關係數據表。
並不是從一個角色的角度看就比從另外一個角色的角度看要好，也不是越詳細越好，也不是某一個的優先權比其他的更高。作為一個整體，無論是從誰的角度都很重要。正如Zachman說過的：
我們在信息系統構架方面與另外的構架溝通時有很多困難，因為存在很多構架表現形式，而不是僅僅只有一個構架。其中一個出錯了，其他的也跟著出錯。構架是不同的。它們是附加的和補充的。選擇為開發每個構架表現形式而支出資源是有原因的。如果不開發任何構架表現形式是有風險的。
正如我前面提到的，Zachman框架由六個功能焦點組成，每個功能焦點都會從一個角色的角度考慮。Zachman框架的描述可參見圖1，它描述得很清楚。
從資料庫的實現者的角度來看，"數據"就不是商業實體了，而是保存在數據表中的行和列，還有通過連線（join）和映射（projection）生成的表。如果你在和一個資料庫設計者討論"數據"，不要討論客戶的群體，而應該討論關係數據表。
並不是從一個角色的角度看就比從另外一個角色的角度看要好，也不是越詳細越好，也不是某一個的優先權比其他的更高。作為一個整體，無論是從誰的角度都很重要。正如Zachman說過的：
我們在信息系統構架方面與另外的構架溝通時有很多困難，因為存在很多構架表現形式，而不是僅僅只有一個構架。其中一個出錯了，其他的也跟著出錯。構架是不同的。它們是附加的和補充的。選擇為開發每個構架表現形式而支出資源是有原因的。如果不開發任何構架表現形式是有風險的。
正如我前面提到的，Zachman框架由六個功能焦點組成，每個功能焦點都會從一個角色的角度考慮。Zachman框架的描述可參見圖1，它描述得很清楚。
從圖中，你可以看到，在一個Zachman表格中，有36個方格，每個方格就是一個角色（例如商業擁有者）和每個描述焦點（如數據）的交匯。當我們在表格中水平移動（例如從左到右）時，我們會從同一個角色的角度，看到系統的不同描述。當在表格中豎直移動（例如從上到下）時，我們會看到從不同角色的角度，觀察同一個焦點。
關於Zachman表格有三條建議，相信它們在企業構架的開發中對我們會有幫助。
第一條建議就是每一個構架材料應該存在於一個方格中，而且只能存在於一個方格中。在一個構架材料放在哪個方格里不應該含糊不清。如果某個構架材料的確不知道應該放在哪個方格中，問題很有可能處在構架材料本身。
當組織在開發企業構架中開始積累材料的時候，它可以使用Zachman表格解釋每個材料的焦點。例如，面向服務構架相關的材料很有可能就放在第三行（從設計著的角度看）。它們一般不會引起商業擁有者的興趣。
第二條建議：僅僅只有當所有的表格都填滿了的時候，一個構架才能被稱為是完整的構架。當所有的方格都填滿了時候，整個表格才有足夠的材料定義系統。
只有當每個方格都填滿了材料的時候，才有足夠的信息描述系統：從每個角色（我們現在可以稱之為"利益相關者"，Stakeholder）的角度觀察系統的每個可能的視角（描述焦點）。所以一個組織可以使用Zachman表格確保企業構架中的所有重要利益相關者之間的討論都是合適的。
第三條建議：表格的每列的方格都是彼此相關的。例如，Zachman表格的數據列（第一列）。從商業擁有者的角度，數據就是關於商業的信息。從資料庫管理人員的角度，數據就是資料庫中的行和列。
儘管商業擁有者對數據的看法和資料庫管理員不同，但它們應該是有關係的。一個人可以遵循商業需求，並且顯示出設計的數據就是被需求驅動的。如果有商業需求並沒有追蹤到資料庫設計，那么就得想想商業需求是否與企業構架相符。另一方面，如果資料庫設計的元素沒有需求與之對應，我們就應該問問自己，在資料庫層面是否存在不必要的設計。
Zachman表格可以從以下五個方面幫助我們開發企業構架：
確保每個利益相關著能夠從描述的焦點考慮。
通過把每個焦點精簡到每個特殊觀眾涉及的焦點來提升構架材料的質量。
確保每個商業需求能夠追蹤到技術實現。
確保商業方面不會規劃出多餘沒用的功能。
確保技術組包含在商業組的規劃中。
但是Zachman本身並不是一個完整的解決方案。有太多的問題它都沒有描述。例如，Zachman沒有給出一步一步構造一個構架的過程。在決定我們將要構建的構架是否是最好的時候，Zachman沒有提供更多的信息幫助我們作出決定。就此而言，Zachman也沒有給出一種途徑展示將來構架的需求。最重要的，從我們的角度，儘管Zachman表格可以幫助組織構架材料，但是它在描述企業複雜性方面幾乎什麼都沒做。
