簡述幾種主要的企業架構和企業架構框架理論。

注意：

• 由于企業架構的特性所致，其真實形態在不同的企業之間差異很大，即便是聯邦企業架構也只是提供了五層參考模型而已，所以對于企業架構的總結無法逐一進行，而作為指導企業架構創建的方法論，亦即企業架構框架，由于其具備標準化的特性，將被作為本章內容的重點。
• 當然，即便企業架構框架具有其標準性的一面，也并不意味著每個企業都要削足適履，摒棄自己的真實需求和特色而強行照搬這些框架理論，所以在現實生活中企業應該按照各自的需要對企業架構框架進行適當的裁剪，甚至聯合幾種框架進行定制（例如TOGAF + Zachman），而也只有這樣才能創建出適合于自己的企業架構。

文章目錄

• 一、企業架構框架之異同
• • 1、企業架構框架的共性
  • • （1）概述
    • （2）企業架構演進過程
    • （3）層次劃分
  • 2、主流企業架構框架之對比
  • • （1）Zachman框架（第一個）
    • （2）FEA框架（最早的政府部門的框架）
    • （3）TOGAF
    • （4）Gartner
  • 3、四種框架的比較
• 二、Zachman框架
• • 1、架構簡述
  • 2、使用規則
  • 3、意義
  • 4、其他

一、企業架構框架之異同

先對這些企業架構框架理論進行對比，尋找共性和差別，對企業架構框架有整體性的認識。

1、企業架構框架的共性

（1）概述

目的：指導創建符合自己企業特點的企業架構，以及使用何種方式維護企業架構，使之與企業的發展相同步。

為了達到這一目標，各種企業架構框架基本上都在如下兩個方面闡述創建企業架構的方法論：

• 創建和維護企業架構的過程：如何創建企業架構，以及如何確保企業架構正確的演進。
• 企業架構的內容描述：企業架構的內容如何分類，以及每一類都應該包含哪些內容。

基本上所有的企業架構框架都有關于創建企業架構過程的描述。在這些企業架構框架中，企業架構的生命周期都被描述成一個循環演進的過程，并且在演進過程中還需要施以適當的治理，從而保證每一次的演進都是在一種有序、受控的環境下進行。在企業架構的開發過程中，大多數框架理論還推薦通過使用企業架構成熟度模型來對企業架構的狀態進行評估。

（2）企業架構演進過程

企業架構演進過程：基本上也采用類似的方法來逐漸完善企業架構

• 首先識別并定義此次循環的目標、范圍以及相關干系人。
• 建立用于描述企業在各個領域（業務、數據、應用和技術）當前狀態的基線架構。
• 使用相同的描述方式并依照此次循環的目標與范圍定義出目標架構。
• 采用差距分析的方法，識別并歸納出當前架構與目標架構的區別。
• 按照差距分析的結果，在征得相關干系人同意的情況下開展遷移實施工作。

（3）層次劃分

關于企業架構的內容，雖然不同的企業架構框架理論由于角度不同，但是他們對企業架構內容的層次劃分大體上還是一致的，基本上都是從如下幾個方面（或至少包含如下幾個方面）對企業架構進行描述：

• 業務架構
• 數據架構
• 應用架構
• 技術架構

同時，雖然不同的企業架構框架對這些層次的具體內容有著不一樣的描述，但是基本上所有的框架理論都是采用不同干系人的視角來對各層次具體內容進行歸納分類。

除了架構過程和內容方面的共性，幾乎所有的架構框架理論都強調企業高層對于企業架構成功的重大意義。

• 架構推動方面：由于企業架構包含企業自業務到信息系統的各個方面，因而會涉及到企業中大多數的人員，如果沒有企業高層的決心和驅動，協調這么多的人員本身就是個巨大的難題，從而直接影響到一個企業架構的成功與否。
• 企業發展戰略方面：此外企業高層的思路往往就是企業發展的戰略，亦即企業演進變化的源頭，而將這些戰略在企業各層中加以貫徹，通過信息技術加以實施正是企業架構的意義所在。

2、主流企業架構框架之對比

由于企業架構框架理論出現的歷史背景和研發團體都不相同，因而企業架構框架理論的適用范圍和側重角度都有較大的差異。

注意：本章將根據 《Comparison of the Top Four Enterprise Architecture Methodologies》所述對四種主流的企業架構框架理論（Zachman，FEA，Gartner，TOGAF）進行比較。需要注意的是，由于這篇文章應該完成于2007年，因而TOGAF還沒有發布第9版，因而文章中關于TOGAF重視架構過程而沒有架構內容的描述的論點在當前看是不準確的，在后面的內容中筆者將給予修正。

（1）Zachman框架（第一個）

Zachman框架僅僅提供了關于企業架構內容的分類方法，而對于企業架構的創建過程卻并沒有相應的描述。

• 作為第一個被廣泛承認的企業架構框架理論，Zachman首先提出了一種根據不同的干系人的視角來對信息系統的各個方面進行描述的方法，從而使得站在不同角度的干系人可以針對信息系統的建設使用相同的描述方式進行溝通，而這也對其后的各種企業架構框架理論的發展指明了方向。
• 在Zachman框架中，企業架構的內容被抽象成采用六種視角來觀察的信息系統在六個方面的描述，并且Zachman認為當所有這些角度針對每個方面的描述都完備則一個企業架構的內容是完備的。

（2）FEA框架（最早的政府部門的框架）

FEA不僅在企業架構內容上由其自己的分類方式，而且關于架構過程也有著相當的描述。上述兩者也是FEA的核心內容。

• FEA vs. FEAF：FEAF（聯邦企業架構框架）是一個真正意義的企業架構框架理論，而FEA是以美國聯邦政府為客觀對象的企業架構的具體實例，但FEA中所抽象出來的各種參考模型和治理方法倒比方法論級別的FEAF更加容易讓人接受，所以在很多情況下，FEA也被看作是一種企業架構框架理論。

企業架構內容分類方法：

• 由于FEA的具體內容相對明確，例如：其對服務的分類就包括健康服務、教育服務、自然資源服務以及國土安全服務等有著明顯政府性行為的服務，不過FEA所采用的架構內容分類方法的確是值得借鑒的。
• 架構內容分類方法的實現：
  • 1. 總結業務線：首先采用服務的概念對企業部門的各種服務能力以業務線（Line-of-Business）為單位進行標識、組織和定義，并且將這些服務按照其使用的范圍歸納為企業服務（Enterprise Service）和片段服務（Segment Service）兩大類。通過這樣的方式，聯邦政府各部門的各條業務線得到了總結，而且原先功能上相互重復的服務也被識別了出來，從而有助于服務的重用。
  • 2. 分層描述：同時針對每條業務線或服務能力，FEA從業務、數據、應用和技術這幾個方面進行詳細的描述。所有這些層次的描述在FEA中通過五層參考模型的方式進行規范，從而為各個部門建立起一種統一的用于描述各自服務能力的方法。

企業架構的架構過程：各部門首先需要通過五層參考模型描述企業當前以及目標架構，根據差距分析找到現實和理想的差別，并且細化成各種實施項目。在為這些項目確立了投資和籌資戰略后，對著這些項目進行實施和管理，從而促進企業的發展和企業架構的演進。

此外，聯邦企業架構體系還包括了用以評估一個企業架構完整性、使用狀況和使用效果的企業架構評估框架（EAAF），以及被OMB用來識別和管理各跨部門項目的聯邦過渡框架（FTF）。

小結：由此可見，相對于Zachman，FEA既含有針對架構內容的分類法，又具備架構過程描述，甚至還包括了用于評估架構水平的方法，所以FEA更加具備一個企業架構框架的特性。但是從抽象度和通用性的角度來看，Zachman框架無疑是一種通用的架構建設方法論，而FEA則更傾向于一種基于具體實例的最佳實踐。

（3）TOGAF

目的：為企業架構的創建提供一套標準的方法。TOGAF提出一套經過高度抽象的方法論，并且不依賴于任何一個具體的組織形式（例如，如果使用FEA來創建企業架構，和可能需要像美國政府那樣建立OMB這樣一個統一協調管理企業架構的組織，否則諸如FTF這樣的框架將無從實施和管理），甚至他對自身提出的各個方法和內容分類法都沒有硬性照搬的要求，也沒有排斥其他任何架構框架理論，因而任何企業均可按照自身的情況對TOGAF進行裁剪或與其他框架進行混合，從而創建和維護符合自身情況的企業架構。

核心：架構開發方法（ADM：Architecture Development Method）——用來指導企業如何建立和維護其企業架構的一套流程化的架構開發步驟。

• 具體：ADM將架構過程看成一個循環迭代的過程，并且此迭代過程可以是分層級的，即企業可以使用一個小組負責整個企業架構的迭代開發，也可以由多個架構開發小組針對每一部份進行迭代開發，并最終歸為一體。
• 在TOGAF中，ADM一共定義了十個步驟，除了“需求管理”這一步驟位于各個步驟中心作為其他各步驟的驅動和管理辦法外，其余九個步驟還是有著先后關系的，即前面步驟的輸出作為后面步驟的輸入。

ADM創建和管理企業架構的思想：

• 識別和定義高層的策略、目標以及驅動力等。
• 創建針對架構的高層次的期望，亦即架構愿景。
• 細化架構愿景，在業務、數據、應用和技術這些層面進行詳細描述，并針對采用相同方式描述的當前架構和目標架構進行差距分析。
• 將差距分析結果具體化為解決方案，進而形成一個個項目規劃。
• 實施并管理這些架構項目。
• 在所有過程中監控內外部環境的變化，從而可以將變化快速反映到架構創建過程中。

分析：

• 與FEA相比，前兩步相當于FEA五層參考模型中PRM（Performace Reference Model）的目標，而第三步的細化又于FEA中后面的四層參考模型不謀而合（當然，FEA五層參考模型并不是一個架構過程的概念，但是ADM的使用過程并不排斥對他們的使用，況且其核心思想是一致的）。至于后面的差距分析直到項目的規劃、實施以及管理又與FEA的架構過程在思想上是一致的。而且，通過上述步驟我們可以看出，ADM采用了自上而下的原則通過逐步細化的方式將企業高層的策略過渡到詳細的技術實施，從而構建涵蓋所有干系人角度的企業架構。
• 需要注意的是，雖然ADM中的各大步驟在表面上有著先后依賴的關系，但是這種關系并不是硬性規定的，一個企業可以根據自己的需要調換這些步驟的順序，甚至是跳過某些步驟，而這也是TOGAF所提倡的。此外，ADM除了定義這十大步驟，還詳細定義了每大步驟所包含的各個小步驟、目標以及每大步驟的輸入與輸出。

TOGAF 9（2009）：The Open Group為TOGAF加入了內容框架（CF，Content Framework），從此企業架構不單單是一份僅僅關于企業架構過程的框架理論了。

• 在內容框架中，企業架構內容按照表現形式分為目錄、矩陣和圖形三種，并且根據ADM在各個階段的目標定義了每個階段需要完成的架構制品。
• 除此之外，內容框架還對ADM中各個步驟的輸入、輸出與這些架構制品的關系進行了詳細描述。
• 內容架構中關于架構制品的定義構成了TOGAF下的架構內容元模型，但是這一元模型也只是一種參考性材料，TOGAF并不建議將其強搬至各個企業或組織的架構實踐當中。為了達到這種靈活度，內容框架采用插件方式對內容元模型進行組織，即把一些關鍵并常用的架構制品當作核心內容，并將其推薦到架構實踐過程當中，而把剩下的架構制品分別歸納到治理擴展、服務擴展、流程建模擴展、數據擴展、基礎設施整合擴展以及動機擴展這幾個分組之中。需要注意的是，TOGAF只是對架構內容進行了建議，即便是核心分組中的架構制品在實踐中的具體內容也應按照企業自身的需求而進行定制。

由此可見，TOGAF相對于其他框架理論，具有更加標準、更加通用的特點，而且自從在TOGAF 9種增加了內容框架之后，此企業架構框架理論的完整度也大幅提高，也正因為如此，TOGAF發展至今日已經得到了最廣泛的應用，堪稱業界最流行的企業架構框架理論。

（4）Gartner

Gartner并不提供通常意義上的方法論，而是以其在企業架構建設領域中積累的大量實踐經驗為基礎，對外提供關于企業架構方面的各種最佳實踐（咨詢服務 或 參考實例）。Gartner關于企業架構的建設也有著自己的理念和實際案例。

• Gartner將企業架構看作為一個動態的過程，而不僅僅是一個靜態的名詞。
• 在Gartner的觀念中，企業架構建設的起點應該是對企業發展方向的明確，而不是僅僅對企業當前狀態的描述，并且一個成功的企業架構應該能將業務擁有者、信息專家和技術實現者聯系起來，并為他們提供一個統一的針對企業現狀和發展方向的愿景。

3、四種框架的比較

上述四種企業架構框架各具特點，先將他們放在一起比較如下：

評測方面含義評分評分評分評分

		Zachman	TOGAF	FEA	Gartner
分類法完整度 （Taxonomy completeness）	用以表明當前框架理論對各種架構制品劃分的優劣程度。	4	3	2	1
過程完整度 （Process completeness）	用以表明當前框架理論在指導人們創建企業架構方面是否采用了漸入式的方式，且表現如何。	1	4	2	3
參考模型指南 （Reference model guidance）	用以表明當前框架理論在幫助人們創建一系列相關的參考模型中的作用。	1	3	4	1
實踐指南 （Practice guidance）	用以表明當前框架理論在幫助人們將企業架構的精神融入到組織中，并為其創建一個珍視并使用企業架構的企業文化時的幫助程度。	1	2	2	4
成熟度模型 （Maturity model）	用以表明當前框架理論在評估企業使用企業架構的有效性和成熟度方面的幫助程度。	1	1	3	2
業務關注度 （Business focus）	用以表明當前框架理論是否著眼于使用技術來驅動業務價值。其中，業務價值被定義為減少成本或增加收入。	1	2	1	4
治理指南 （Governance guidance）	用以表明當前框架理論在理解和創建有效的企業架構治理模型方面的幫助程度。	1	2	3	3
劃分指南 （Partitioning guidance）	用以表明當前框架理論在幫助人們對企業進行有效的自治性分區劃分方面的幫助程度。此種分區劃分對于復雜性管理來說是一個重要的方法。	1	2	4	3
視角目錄 （Perspective catalog）	用以表明當前框架理論在指導人們設置架構資產目錄方面的幫助程度。這些架構資產會在未來的活動中被重用。	1	2	4	2
廠商無關度 （Vendor neutrality）	用以表明當前框架理論與某個特定咨詢組織的鎖定程度。此方面評分越高表示與特定廠商的鎖定程度越低。	2	4	3	1
信息易獲取性 （Information availability）	用以表明與當前框架理論相關的免費或廉價信息的數量和質量。	2	4	2	1
價值獲取效率 （Time to value）	用以表明從開始使用當前框架理論到創建具有高度業務價值的解決方案這一過程的效率。	1	3	1	4

在上面表格中評分量級從1至4，其意義分別定義如下：

• 在當前評測方面無所表現。
• 在當前評測方面有所表現，但是并不足夠。
• 在當前評測方面有著可以接受的表現。
• 在當前評測方面有著很好的表現。

二、Zachman框架

1、架構簡述

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框架對于架構的表述更加完備，這一行最終還是被加了進去。這一行的內容代表了最終產品，是架構在客觀現實中的實例體現。例如，對信息系統架構來說，此行的內容就是最終產出的信息系統，同理，對于企業架構來說，這一行所代表的就是運行中的企業本身。簡而言之，前面五行的內容是對于客觀對象的描述，而這最后一行的內容就是客觀對象本身了。

表格中的每一列代表了用于描述信息系統的某一個方面，這幾個基本方面可以清晰的解釋信息系統。這些方面包括：

• 數據（What，即什么內容）：用于表示客觀對象的材料組成，即材料清單。對于企業來說，此部分內容就是組成事物模型（Thing Model，之所以將其稱為組成事物模型而不是數據模型是因為由于不同的行代表了不同的視角，而僅在設計師所處的第三行才會關注真正信息化意義上的“數據模型”，因而在此才使用“組成事物”來對所有視角在此列中的描述對象進行指代）。
• 功能（How，即如何工作）：用于表示功能和轉換行為。對于企業來說，這部分內容就是流程或功能模型等。
• 網絡（Where，即何處）：用于表示各組成部件的坐落位置以及相互之間的聯通關系。對于企業來說，這部分內容就是物流或網絡模型等。
• 人（Who，即何人負責）：用于描述了何人應該做何事，例如用戶手冊和操作說明等。對于企業來說，這部分內容就是人力模型或工作流模型等。
• 時間（When，即什么時間）：用于描述事物發生的時間以及不同事物之間的相對時間關系，例如生命周期和時序圖等。對于企業來說，這部分內容就是時間或動態模型等。
• 原因（Why，即為什么做）：用于表示最終結果和意義。對于企業來說，這部分內容就是動機模型等。

2、使用規則

• 不能為此框架增加新的行或列。在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個交匯點，其中的每一個代表了架構描述的某一具體架構制品。舉例來說，不論是規劃師還是設計師在描述一個系統時，都需要描述系統的數據、功能等方面，但是對于某一個具體方面，例如數據，不同的角色有著不同的理解。對于業務擁有者來說，數據指的是諸如客戶、產品這樣的業務實體以及他們之間的關系，而對于執行系統設計的設計師來說，數據指代的就是完全信息化意義上的數據信息片段了。

3、意義

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

4、其他

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

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

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

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

總結

以上是生活随笔為你收集整理的企业架构笔记（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。