zachman架構

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》 的做者），而僅僅把其當成企業架構描述的一個內容分類法。這種見解是有其根據的，就其緣由仍是由於此框架在以下方面沒法給予解答：

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