EA方法論

1 EA的定義

Enterprise Architecture，企業架構，簡稱EA。根據開放羣組的業務領導層IT架構指引：「有效的企業架構（Enterprise Architecture，EA）對企業的生存和成功具備決定性的做用，是企業經過IT得到競爭優點的不可缺乏的手段。」

企業架構是關於業務流程和IT 基礎設施的一整套邏輯和結構，它反映了企業經營對集成和標準化的需求。從另外一個角度說，企業架構也表明一種去理解、識別和表達上述邏輯和結構的方法和過程。

在上述定義中要明確的是，企業（Enterprise）是指由一整套可識別的、互爲做用的業務功能構成的(商業)組織，它有能力做爲獨立實體經營運做。它既能夠是存在企業內的企業：只要企業內部的事業部門可以獨立運做，它或許就能夠被看成一個企業。也能夠存在於擴展企業：它意味着企業框架中也包括了與企業有各類關係的外部實體（如： 供應商、商業夥伴和客戶等）。

 

2 EA的內容和做用

最先提出企業架構概念的META Group認爲，企業架構包括BAIT四大部分，也就是業務架構（Business）、應用架構（Application）、信息架構（Information）、和技術架構（Technology），這已經被你們所公認。可是，還應該有治理架構（Governance），這就造成"4+1"的企業架構框架（EAF），主要緣由IT治理近年來獲得普遍承認，隨着ITIL和COBIT的推廣，信息化管控愈來愈成爲企業內的一個專業職能。

現有各類企業架構方法的合集，企業架構可看做包含如下內容的綜合體：

l  企業業務架構（Enterprise Business Architecture）

l  企業信息系統架構（Enterprise Information System Architecture）

• 數據架構（Data Architecture）
• 應用架構（Application Architecture）

l  企業技術架構（Enterprise Technology Architecture）

• 網絡架構（Network Architecture）
• 硬件架構（Hardware Architecture）
• 軟件架構（Software Architecture）
• 集成架構（Integration Architecture）
• 安全架構（Security Architecture）

l  IT 管理架構（IT Management Architecture）

固然，上述內容根據採用的不一樣架構方法有所不一樣。另外，根據企業的狀況和架構工做的具體要求，所關注的側面或具體架構也會產生差別。可是共同的是，企業架構從總體、宏觀的角度描述了企業業務、信息系統、技術、治理各方面IT 工做所需的信息，並能夠有效地協調企業中的信息資產、利益相關者的協調運做，以使其與企業的戰略目標相吻合並有效地支持企業（業務）願景的達成。企業架構對企業具備重要的意義。具體來講，能夠實現如下目標：

l  覆蓋了企業信息化中全部利益相關者的各類不一樣視角；

l  提供了將分散的各類信息「串」起來的結構；

l  支持從需求到實現的「可追蹤」性；

l  爲優化和重用提供了基礎；

l  實現了業務、信息、應用與技術之間的協同；

l  與 SOA 有效結合，提供企業所需的敏捷性；

3基於EA的系統架構設計過程

3.1基本概念

EA是一個思想，在這個思想的指導下，咱們能夠完成系統架構的設計。在這個設計的過程當中，包含兩個關鍵的步驟：系統需求分析和系統概要設計。完成這兩個步驟之後，將會產出兩個輸出物，分別是：系統需求分析說明書和系統概要設計說明書。

如下，將對這個設計過程進行詳細地介紹，首先，是一些關鍵的概念描述，詳細信息以下表：

概念	描述
需求調研	經過調研，獲取用戶（客戶與最終用戶）的需求信息。
需求分析	根據需求調研結果，對用戶需求進行分析概括，肯定系統須要實現的功能和非功能需求。經過系統用例模型描述系統的功能需求，使之成爲在開發全過程當中研討系統需求和進行設計的依據，在軟件測試階段做爲系統測試的基礎。
用戶體驗設計	根據《軟件需求規格說明書》文檔內容構造系統界面原型，驗證需求文檔內容的完整性和正確性，發現可能存在的質量問題，併爲後續系統開發提供輸入。
系統整體框架設計	設計系統整體框架，爲後續組件視圖、數據視圖、集成視圖、部署視圖、環境視圖和安全視圖的設計提供指導。設計內容包括：系統設計原則、整體技術路線和架構概覽。
系統組件視圖設計	把業務需求落實到具體的系統實現。設計內容包括：定義系統的邏輯分層、肯定每一分層包含組件、以及組件的包含依賴關係。
系統數據視圖設計	根據業務需求，肯定支持系統實現的數據實體。設計內容包括：數據模型、數據分類、數據流轉和數據存儲與分佈。
系統集成視圖設計	明確本系統與周邊系統的集成關係。設計內容包括：明確集成場景、選擇集成方式，設計集成接口組件。
系統部署視圖設計	系統部署視圖設計定義系統全部的邏輯部署單元及其依賴關係，說明每一個部署單元所包含的組件，並定義系統全部的部署節點、節點承載的部署單元。
系統環境視圖設計	定義執行環境軟硬件配置。
系統安全視圖設計	進行系統安全防禦設計以有效防範對應用和數據的非法訪問，保證主機、網絡、應用、數據和終端的安全。

 

3.2系統架構設計全過程

系統架構設計的所有流程過程以下圖所示：

上圖描述了系統架構設計流程中所涉及到的關鍵角色，角色的職責，流程的步驟，各個流程步驟之間的關係，以及該設計過程的輸入物和產出物。

關鍵角色包括：

l  總部架構管理辦公司，負責制定《軟件需求規格說明書模板》和《系統概要設計模板》；

l  客戶與最終用戶，負責提出需求；

l  需求分析人員，負責與客戶交流，並根據《軟件需求規格說明書模板》以及相關的指導思想編寫《軟件需求規則說明書》；

l  研發單位，系統分析人員，負責編寫《系統概要設計書》；

l  第三方測試機構，架構管理辦公室，負責評審。

   設計過程的輸入物包括：

l  《軟件需求規格說明書模板》；

l  《系統概要設計模板》；

l  《系統架構設計方法論》。、

   設計過程的產出物包括：

l  《軟件需求規格說明書》

l  《系統概要設計》

3.3系統架構設計內容總覽

系統架構設計的內容，以及關鍵要點描述以下圖所示：

在上圖中，列出了系統架構設計的兩個關鍵產出物《需求規格說明書》和《系統概要設計說明書》。其中，《需求規格說明書》又是進行系統概要設計的前提，以此爲輸入，通過系統概要設計，將會產出《系統概要設計說明書》

圖中也列出了這兩個說明書的重要組成部分。《需求規格說明書》包含三部分組成內容，它們分別是：業務描述，系統功能規格，系統技術規格；《系統概要設計說明書》七部份內容，它們分別是：系統整體框架，系統組件視圖，系統數據視圖，系統集成視圖，系統部署視圖，系統安全視圖，系統環境視圖。

如下，將從需求分析的角度和系統概要設計的角度對EA方法論進行描述。

3.4需求分析

3.4.1需求分析的關鍵點和方法

在需求分析階段，包含三個關鍵點，它們分別是：需求調研，需求分析，用戶體驗設計。這三個步驟是分前後順序的。首先，進行需求調研，而後對需求調研的結果進行分析，也就是需求分析，而後根據需求分析的結果進行用戶體驗設計。如下，將對這三個關鍵點進行論述。

3.4.1.1需求調研

需求分析人員與用戶接觸，進行一系列的交流。最終，將用戶反饋過來的信息進行整理，得到需求分析的結果。

需求調研的要點描述以下：

l  梳理涉及到的業務流程；

l  描述每一個流程包含哪些業務活動；

l  描述業務活動的具體業務步驟、輸入\輸出業務信息、業務規則及涉及到的非功能性需求。

   需求調研的流程步驟描述以下：

3.4.1.2需求分析

根據需求調研結果，相關分析人員要對用戶需求進行分析概括，肯定系統須要實現的功能和非功能需求。經過系統用例模型描述系統的功能需求，使之成爲在開發全過程當中研討系統需求和進行設計的依據，在軟件測試階段做爲系統測試的基礎。

需求分析的要點描述以下：

l  肯定系統邊界；

l  肯定涉及的系統用例清單，明確系統用例的子用例；

l  描述每一個用例；

l  收集全部系統功能點，描述系統功能點；

l  肯定系統在技術層面如何實現系統的非功能性需求。

     需求分析的流程步驟描述以下：

3.4.1.3用戶體驗設計

根據《軟件需求規格說明書》文檔內容構造系統界面原型，驗證需求文檔內容的完整性和正確性，發現可能存在的質量問題，併爲後續系統開發提供輸入。

用戶體驗設計的要點描述以下：

l  收集用戶信息；

l  評估當前用戶體驗要求/標準；

l  定義可用性需求；

l  制定用戶界面原型；

l  用戶界面原型驗證。

   用戶體驗設計的流程步驟描述以下：

3.4.2需求分析說明書的主要組成

需求分析說明書有三部分組成，它們分別是：業務描述，系統功能規格，系統技術規格。如下，將對這三個方面進行論述。

3.4.2.1業務描述

業務描述的關鍵要點包括以下內容：

l  業務目標：定義本項目的業務目標是什麼，以及本項目的業務範圍；

l  梳理業務流程：梳理本項目涉及到的業務流程，描述每一個流程包含哪些業務活動、流程屬於什麼業務職能；

l  肯定業務活動：描述每一個業務活動的具體業務步驟、輸入\輸出業務信息、業務規則及涉及到的非功能性需求；

l  肯定執行角色：收集本項目涉及到的全部角色，描述角色的職責；

l  組織單元：收集本項目涉及到的全部組織單元，描述各部門的職責；

l  業務信息：收集本項目涉及到的全部業務信息。業務信息包括表單、報表、文檔等業務信息，及這些業務信息的內容。

 

3.4.2.2系統功能規格

系統功能規則的關鍵要點包含以下內容：

l  系統功能規格：描述系統須要哪些功能來支撐需求調研中得出的業務需求，及這些業務功能需求轉變爲系統功能後，系統參與者和系統功能之間是怎麼相互聯繫的；

l  系統用例：針對系統用例進行說明，包括：用例名稱、編號、描述、參與者、前置條件、基本流程、備選流程、後置條件、業務規則、主要界面、非功能性需求；

l  系統功能點：功能點（包括包含系統功能、系統接口、報表）應包含： 功能點編號、名稱、類型、優先級、對應用例編號、依賴功能點編號、功能點內容描述、所屬應用；

 

3.4.2.3系統技術規格

系統技術規格的關鍵要點包含以下內容：

l  性能：描述系統在性能方面的規格。應至少從響應時間、吞吐量及容量三個方面描述；

l  可靠性：描述產品、系統在規定的條件下，規定的時間內，完成規定功能的能力；

l  可用性：描述在外部資源獲得保證的前提下, 系統在規定條件下和規定時間內, 處於能執行規定功能狀態的能力；

l  可擴展性：描述設計良好的系統容許更多的功能，在必要時能夠進行相應的擴展；

l  易用性：描述系統對於用戶學習和使用的難易程度、使用的滿意程度等；

l  安全：描述系統在安全方面的需求，包括應用安全和數據安全；

l  容量規劃：描述系統在必要時可以提供的負載容量。

 

3.5系統設計

3.5.1整體框架設計

3.5.1.1設計要點

整體框架設計的內容包含以下：

l  肯定設計原則：設計原則是指爲達到目標系統設計所應遵循的原則；

l  肯定整體技術路線：整體技術路線是指系統採用的應用類型、技術路線和架構風格；

l  肯定架構概覽：描述系統的上下文關係，包括：本系統與周邊系統的關係、各系統所屬分區。

 

3.5.1.2設計方法

系統框架設計的設計要點描述以下：

l  肯定本項目在系統設計時應遵循的相關原則；

l  肯定整體技術路線包括肯定系統採用的應用類型、技術路線和架構決策；

l  描述系統的上下文關係。

系統框架設計的流程步驟描述以下：

3.5.2組件視圖設計

3.5.2.1設計要點

組件視圖設計的內容包括：

l  系統邏輯分層：說明系統共有多少邏輯分層，並描述每一個層級的職責、實現技術、依賴層級及與該層級的層間通訊方式；

l  應用組件：肯定系統有哪些應用組件，並描述應用組件包含哪些功能點、能夠拆分爲哪些組件，這些組件分佈在哪些邏輯層級及每一個組件開放了哪些方法；

l  公共組件：肯定系統使用的公共組件，並描述每一個公共組件的職責、來源、開放的方法及分佈在哪些邏輯層級；

l  組件依賴：描述組件間的依賴關係；

 

3.5.2.2設計方法

組件視圖設計的要點描述以下：

l  說明系統共有多少邏輯分層，並描述每一個層級的職責、實現技術、依賴層級及與該層級的層間通訊方式；

l  肯定系統有哪些應用組件，並描述應用組件包含哪些功能點、能夠拆分爲哪些組件，這些組件分佈在哪些邏輯層級及每一個組件開放了哪些方法；

l  肯定系統使用的公共組件，並描述每一個公共組件的職責、來源、開放的方法及分佈在哪些邏輯層級；

l  描述組件方法間的依賴關係。

組件視圖設計的流程步驟描述以下：

3.5.3數據視圖設計

3.5.3.1設計要點

數據視圖設計的內容包括以下：

l  定義數據模型：識別數據實體，肯定數據實體的屬性，肯定數據實體所屬的主題域，分析數據實體間的關係；

l  定義數據分類：對數據實體進行分類，肯定數據實體屬於結構化或非結構化，肯定結構化數據實體屬於主數據或業務數據；

l  定義數據流轉：分析出全部存在交互關係的系統，獲取全部數據實體清單，肯定數據實體是不是數據交換實體，肯定每一個數據交換實體的源系統和目標系統；

l  定義數據存儲與分佈：定義出數據在應用系統之間的分佈狀況，同時明確出數據在不一樣應用系統的存在狀態（o/c）。

 

3.5.3.2設計方法

數據視圖的設計要點描述以下：

l  設計數據邏輯模型，梳理出數據實體的具體屬性，及描述屬性的各參數；

l  肯定每一個數據實體的分類；

l  肯定數據交換實體的數據流轉，包括：系統之間的流轉、系統和數據中心之間的流轉；

l  肯定數據實體的存儲與分佈。明確數據在不一樣應用系統的存在狀態，是全部者或複製者。

  數據視圖設計的流程步驟描述以下：

3.5.4集成視圖設計

3.5.4.1設計要點

集成視圖設計的內容包括：

l  定義集成場景：針對數據流轉分析出集成接口及其屬性，選擇合適的集成方式，歸集全部的集成接口造成集成場景清單， 描述每一個集成場景（包括源系統、目標系統、頻率、實時性、數據量）。

l  界面集成設計：描述每一個界面集成接口組件，包括所屬的集成場景、發起方/提供方、接口信息（接口名稱、描述、實現技術）。

l  應用集成設計：描述每一個應用集成接口組件，包括所屬的集成場景、發起方/提供方、集成方式、發起方的接口信息、提供方的接口信息。

l  數據集成設計：描述每一個應用集成接口組件，包括所屬的集成場景、發起方、發起方的數據格式、接收方、接收方的數據格式、集成方式、數據類型、發起方式、時間窗口、交換數據信息。

3.5.4.2設計方法

集成視圖設計的要點描述以下：

l  肯定集成場景並描述源系統、目標系統、頻率、實時性、數據量、集成方式；

l  界面集成、應用集成以及數據集成經過各自的集成接口組件來實現，進行各類集成方式的集成接口組件設計。

集成視圖設計的流程步驟描述以下：

3.5.5部署視圖設計

3.5.5.1設計要點

部署視圖設計的內容包括：

l  定義部署單元：基於組件清單，分析設計部署單元，整理造成本項目的部署單元清單；肯定每一個部署單元所包含的組件清單；肯定各部署單元的依賴關係；

l  定義部署節點：基於部署單元清單，分析設計邏輯部署節點，整理造成本項目的邏輯部署節點清單；描述每一個邏輯部署節點的做用；明確每一個邏輯部署節點對應的物理部署節點；肯定每一個邏輯部署節點上承載的部署單元。

3.5.5.2設計方法

部署視圖設計的要點描述以下：

l  說明部署單元包含的組件清單、說明部署單元間的依賴關係；

l  說明系統的邏輯部署節點和物理部署節點及節點的類型和節點承載的部署單元。

部署視圖設計的流程步驟描述以下：

3.5.6環境視圖設計

3.5.6.1設計要點

環境水土設計的內容包括：

l  定義容量規劃：肯定每一個物理部署節點須要的硬件類型；估算應用服務器、數據庫服務器CPU內存容量需求；估算存儲容量需求和增加趨勢；估算網絡帶寬要求；

l  定義硬件環境：肯定硬件資源，整理造成硬件配置清單；肯定每一個硬件所屬的物理部署節點；

l  定義軟件環境：肯定每一個邏輯部署節點所需的基礎軟件（包括操做系統、中間件、數據庫軟件等）。

3.5.6.2設計方法

環境視圖設計的要點描述以下：

l  根據部署節點的性質和業務量來定義容量規劃，以肯定所需硬件可以知足將來工做負載的需求；

l  根據容量規劃肯定硬件資源，整理造成硬件配置清單；

l  根據邏輯部署節點的性質，肯定每一個邏輯部署節點所需的基礎軟件類型（包括操做系統、中間件、數據庫軟件等）。

環境視圖設計的流程步驟描述以下：

3.5.7安全視圖設計

3.5.7.1設計要點

安全視圖設計的內容包括：

l  應用安全：進行應用安全防禦設計，有效防範對應用的非法訪問，保證應用的安全；

l  數據安全：結合業務系統數據分類所定義的數據安全級別，制定數據安全防禦的措施要求，對業務系統數據保護進行約束；

l  主機安全：採用信息保障技術確保業務數據在進入、離開或駐留服務器時保持可用性、完整性和保密性；

l  網絡安全：防範惡意人員經過網絡對業務系統進行攻擊，同時阻止惡意人員對網絡設備發動的攻擊；

l  終端安全：對信息內網和信息外網的桌面辦公計算機終端以及接入信息內、外網的各類業務終端進行安全防禦。

3.5.7.2設計方法

安全視圖設計的要點描述以下：

l  進行應用安全防禦設計，有效防範對應用的非法訪問，保證應用的安全；

l  結合數據分類所定義的數據安全級別，制定數據安全防禦的措施要求，對系統數據保護進行約束；

l  採用信息保障技術確保業務數據在進入、離開或駐留服務器時保持可用性、完整性和保密性；

l  防範惡意人員經過網絡對業務系統進行攻擊，同時阻止惡意人員對網絡設備發動的攻擊；

l  對信息內網和信息外網的桌面辦公計算機終端以及接入信息內、外網的各類業務終端進行安全防禦。

安全視圖設計的流程步驟描述以下：

4目前主要企業架構介紹

通過十幾年的發展，企業架構已經成了企業（組織）總體信息規劃和信息化建設的重要環節。根據Infosys 在2007 年進行的企業架構調研，圖3 中列出了在本領域佔據領先地位的企業架構及其普及程度。下面咱們對主要的幾種企業架構進行逐一介紹。

各類企業架構的普及情況

1）Zachman

第一個最有影響力的框架方法論就是Zachman框架，它是John Zachman首次在1987年提出的。
　　在理解Zachman框架以前，須要瞭解的是，它並非一個框架，至少從框架的定義上嚴格地來看，它不是。從《美國傳統詞典》上，咱們能夠找到框架的定義以下：
　　支持或封裝其餘事情的一種結構，尤爲是做爲其餘的一些已經建立的東西的基礎給予其骨架支持；一種外部的工做平臺；腳手架；一種基本結構；組成觀察顯示的一系列的假想、內容、價值和實踐。
　　而在分類學中，它是這樣定義的：
　　在顯示天然關係的有序系統中的有機分類；科學、法律或者理論的分類；系統化；劃分紅有序的組或類別。
　　Zachman"框架"其實是一種組織構架工具（用來設計文檔、需求說明和模型的工具）的一種分類學。包括工具的目標（例如，商業擁有者、建立者）是誰，哪些特殊的問題（例如，數據、功能）須要闡明。
　　而Zachman是這樣描述他的傑做的：
　　當這個框架應用於企業時，它僅僅是用來分類和組織企業（在這些企業裏，企業的管理和企業系統的開發一樣重要）的描述形式的邏輯結構。
　　許多Zachman框架的支持者認爲它是跨學科的，它的影響不只僅侷限於IT行業。例如，一本關於Zachman的書中這樣說：
　　在適當的時候，你會發現框架不只僅是存在於IT項目中，它存在於你所作的每一件事情中。當你徹底理解了這個框架以後，作任何事情都會變得高效。我指的是任何事情，這個斷言並不武斷。
　　在和Zachman討論問題的時候，他本人也曾說：
　　這個框架已經存在了幾千年，並且我敢確定它在之後的幾千年將繼續存在。稍微有些改變的是咱們對它的理解和怎樣使用它。
　　Zachman在解釋他的IT分類學時，最初試用了建築行業做爲類比。在建築行業裏，構架材料經過使用二維表格表示出來。表格其中的一維是變量"遊戲中的角色"。對於一個建築物來講，這些選手就是擁有者（誰爲這個項目付款）、構造者（負責構建的人）、城市規劃委員會（負責確保建築遵循當地建築標準的人）。
　　建築構架爲不一樣的角色提供不一樣的材料。每一個角色都須要完整的信息，不過對於不一樣的角色而言，所需的完整信息也是不一樣的。擁有者感興趣的完整描述是建築物的功能和美感。構造者感興趣的完整描述是建築材料和構建過程。擁有者並不關心牆裏面的螺栓釘在哪兒，構造者也不關心臥室的窗戶如何排列，以便在早晨可以迎來第一縷陽光。
　　正如Zachman在他的一篇文章中提到的：
　　每一個構架表現形式和其餘的構架不一樣，其本質不只僅是細節的層面。
　　構架材料組織的第二維是材料的描述中心--和項目相關的什麼（what）、怎樣（how）、誰（who）、什麼時候（when）、爲何（why）。這一維和第一維之間是相互獨立的。構造者和擁有着都須要知道"什麼"，可是"什麼"是什麼還得取決於問這個話的人是誰。
　　在Zachman的第一篇論文和隨後的詳細解說中，Zachman建議有六個描述的焦點（數據、功能、網絡、人員、動機）和六個角色的角度（規劃者、擁有者、設計者、構造者、轉包商、運營企業）。如圖1-3所示
　　以列描述中的"數據"爲例。從商業擁有者的角度，"數據"意味着商業實體。它可能包括實體自己的信息，如客戶和產品，也可能包括實體間關係的信息，如人口羣體和庫存。若是你打算和一個商業擁有者討論數據，你應該用到這些語言。
　　從數據庫的實現者的角度來看，"數據"就不是商業實體了，而是保存在數據表中的行和列，還有經過鏈接（join）和映射（projection）生成的表。若是你在和一個數據庫設計者討論"數據"，不要討論客戶的羣體，而應該討論關係數據表。
　　並非從一個角色的角度看就比從另一個角色的角度看要好，也不是越詳細越好，也不是某一個的優先級比其餘的更高。做爲一個總體，不管是從誰的角度都很重要。正如Zachman說過的：
　　咱們在信息系統構架方面與另外的構架溝通時有不少困難，由於存在不少構架表現形式，而不是僅僅只有一個構架。其中一個出錯了，其餘的也跟着出錯。構架是不一樣的。它們是附加的和補充的。選擇爲開發每一個構架表現形式而支出資源是有緣由的。若是不開發任何構架表現形式是有風險的。
　　正如我前面提到的，Zachman框架由六個功能焦點組成，每一個功能焦點都會從一個角色的角度考慮。Zachman框架的描述可參見圖（Zachman框架），它描述得很清楚。

從圖中，能夠看到，在一個Zachman表格中，有36個方格，每一個方格就是一個角色（例如商業擁有者）和每一個描述焦點（如數據）的交匯。當咱們在表格中水平移動（例如從左到右）時，咱們會從同一個角色的角度，看到系統的不一樣描述。當在表格中豎直移動（例如從上到下）時，咱們會看到從不一樣角色的角度，觀察同一個焦點。
　　關於Zachman表格有三條建議，相信它們在企業構架的開發中對咱們會有幫助。
　　第一條建議就是每個構架材料應該存在於一個方格中，並且只能存在於一個方格中。在一個構架材料放在哪一個方格里不該該含糊不清。若是某個構架材料的確不知道應該放在哪一個方格中，問題頗有可能處在構架材料自己。
　　當組織在開發企業構架中開始積累材料的時候，它可使用Zachman表格解釋每一個材料的焦點。例如，面向服務構架相關的材料頗有可能就放在第三行（從設計着的角度看）。它們通常不會引發商業擁有者的興趣。
　　第二條建議：僅僅只有當全部的表格都填滿了的時候，一個構架才能被稱爲是完整的構架。當全部的方格都填滿了時候，整個表格纔有足夠的材料定義系統。
　　只有當每一個方格都填滿了材料的時候，纔有足夠的信息描述系統：從每一個角色（咱們如今能夠稱之爲"利益相關者"，Stakeholder）的角度觀察系統的每一個可能的視角（描述焦點）。因此一個組織可使用Zachman表格確保企業構架中的全部重要利益相關者之間的討論都是合適的。
　　第三條建議：表格的每列的方格都是彼此相關的。例如，Zachman表格的數據列（第一列）。從商業擁有者的角度，數據就是關於商業的信息。從數據庫管理人員的角度，數據就是數據庫中的行和列。
　　儘管商業擁有者對數據的見解和數據庫管理員不一樣，但它們應該是有關係的。一我的能夠遵循商業需求，而且顯示出設計的數據就是被需求驅動的。若是有商業需求並無追蹤到數據庫設計，那麼就得想一想商業需求是否與企業構架相符。另外一方面，若是數據庫設計的元素沒有需求與之對應，咱們就應該問問本身，在數據庫層面是否存在沒必要要的設計。
　　Zachman表格能夠從如下五個方面幫助咱們開發企業構架：
　　確保每一個利益相關着可以從描述的焦點考慮。
　　經過把每一個焦點精簡到每一個特殊觀衆涉及的焦點來提高構架材料的質量。
　　確保每一個商業需求可以追蹤到技術實現。
　　確保商業方面不會規劃出多餘沒用的功能。
　　確保技術組包含在商業組的規劃中。
　　可是Zachman自己並非一個完整的解決方案。有太多的問題它都沒有描述。例如，Zachman沒有給出一步一步構造一個構架的過程。在決定咱們將要構建的構架是不是最好的時候，Zachman沒有提供更多的信息幫助咱們做出決定。就此而言，Zachman也沒有給出一種途徑展現未來構架的需求。最重要的，從咱們的角度，儘管Zachman表格能夠幫助組織構架材料，可是它在描述企業複雜性方面幾乎什麼都沒作。

2）Open Group TOGAF

TOGAF 是一個開放的標準化的架構框架（The Open Group Architecture Framework 的縮寫），是爲組織設計、評價和創建正確的架構服務的，它包含架構開發方法（ADM）、基礎架構和資源庫。

TOGAF 的關鍵是TOGAF 架構開發方法（Architecture Development Method：ADM），這是一個開放的、行業公認的、可靠的、用於開發知足業務需求的企業架構的方法。ADM是一個循環的流程，須要不斷根據業務需求進行驗證。主要步驟包括：（1）初始化，創建框架；（2）基準描述（3）目標架構（4）機會和解決方案（5）遷移規劃（6）實施（7）架構維護。

3）美國政府的聯邦企業架構（FEA）和聯邦企業架構框架（FEAF）

美國政府創建FEA 旨在改進聯邦政府內部的互操做性，促進聯邦政府的電子政務轉型。FEA 是由美國管理和預算辦公室（OMB）創建，也獲得了聯邦CIO 委員會的支持，主要包括聯邦企業架構參考模型和聯邦政府企業架構管理系統。

每一個聯邦政府機構要創建他們本身的企業架構，但要與FEA 參考模型保持一致。FEA參考模型包括績效參考模型（PRM）、業務參考模型（BRM）、服務組件參考模型（SRM）、數據和信息參考模型(DRM)、技術參考模型(TRM)等。