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)等。
