提到企业架构，就不能不提到Zachman框架（Zachman Framework™）。Zachman框架起源于John Zachman先生在1987年完成的那篇著名的信息系统架构论文（《A framework for information systems architecture》）。Zachman于1964-1990年在IBM工作，是IBM业务系统规划（BSP）的创始人之一。
01 Zachman框架的历史地位
Zachman框架是全球第一个企业架构理论，是其他企业架构框架的源泉。它全称为企业架构和企业信息系统架构(Zachman Framework for Enterprise Architecture and Information Systems Architecture)。Zachman指出：“为了避免企业分崩离析，信息系统架构已经不再是一个可有可无的选择，而是企业的必需。”
John Zachman最早是从建筑、飞机等复杂业务中形成对这一框架的认识。Zachman框架的核心理念是同一个事物可以用不同的方式、基于不同的目的、从不同维度进行描述。当一个事物足够复杂时，这种描述框架就有更大的价值。
在Zachman Framework之后，又发展出很多企业架构框架，比如由Open Group推出的在大型企业中非常流行的TOGAF。但Zachman Framework仍然是理解企业架构的重要基础。
02 Zachman框架的基本思路
Zachman框架（Zachman Framework™）是一种模式，或者说描述企业的元模型，是两种有几千年历史的分类法的交集。
第一种是建立在原始疑问词上的沟通基础要素，即我们熟悉的5W1H方法：什么（What）、如何（How）、何时（When）、何人（Who）、何地（Where）以及为何（Why）。这些问题答案的集成，能够对复杂的想法形成全面、综合的描述。第二种来自具体化（reification），即古希腊哲学中假定的抽象观念到实例的转换过程，在Zachman框架中记为：辨别（Identification）、定义（Definition）、表达（Representation）、规定（Specification）、配置（Configuration）和实例化（Instantiation）。Zachman Framework对企业架构的上述两个维度做正交，形成了一个6x6的矩阵，非常容易理解，又直观明白。这种方法也成为后续其他EA框架的重要参考。
03 Zachman框架基于角色的视点和视图
尽管Zachman框架最直观的表述是两个维度，但同时也与其他的维度重合。这种维度的合并也体现了Zachman的智慧，使得复杂的企业架构能够更容易被人理解。比如，由于各角色的工作内容处于不同的抽象程度，所以抽象程度的六个层面实际上与企业架构的利益相关者这一维度相重合，即规划者、业务管理者、系统分析者（架构师）、系统设计者、系统建设者和用户。
该框架的每一行都代表了某一类利益相关者对企业的完整理解，是一组独特的视图，但不同角色之间的完整理解又是不一样的。Zachman在文中使用了建筑行业作为类比。在建筑行业里，架构材料通过使用二维表格表示出来。表格其中的一维是变量"游戏中的角色"。对于一个建筑物来说，这些选手就是拥有者（谁为这个项目付款）、构造者（负责构建的人）、城市规划委员会（负责确保建筑遵循当地建筑标准的人）。
建筑架构为不同的角色提供不同的材料。每个角色都需要完整的信息，不过对于不同的角色而言，所需的完整信息也是不同的。拥有者感兴趣的完整描述是建筑物的功能和美感。建造者感兴趣的完整描述是建筑材料和构建过程。拥有者并不关心墙里面的螺栓钉在哪儿，建造者也不关心卧室的窗户如何排列，以便在早晨能够迎来第一缕阳光。
正如Zachman在他的一篇文章中提到的：每个架构表现形式和其他的架构不同，其本质不仅仅是细节层面。
04 Zachman架构模型的层次
从利益相关者看到的内容来看，Zachman框架从上到下代表了架构模型的层层演进：范围上下文，业务概念，系统逻辑，技术物理，组件组装和操作类。其中：
规划者视图（范围上下文）是规划人员关注的业务语境层面的高阶概念级视角的企业模型内容。
管理者视图（业务概念模型）是业务管理者关注的业务语义方面的概念级视角模型。
架构师视图（系统逻辑模型）是架构师（包括业务架构师和IT架构师）关注的业务层面的逻辑模型，不受具体解决方案的约束。
设计者视图（技术物理模型）是具体系统实施人员关注的物理实现模型，包括了特定的解决方案和技术。
建设者视图（组件组装）是系统开发者关注的组件级别的实现细节。
用户视图（操作类）是用户在其操作环境中的视图。
用户视图已经到了具体系统功能层面，从前面五行来看，前面两行半可以归属为业务架构，后面可以归属为IT架构（信息系统架构）。
Zachman框架很好的定义了架构的详细层次，从视角的角度可以将架构分为高级概念层（A）、概念层（B）、业务逻辑层（C）、设计逻辑层（C’）以及设计物理层（D）。其中，范围上下文对应于高级概念层（A），业务概念对应于概念层（B），系统逻辑对应了业务逻辑层（C）和设计逻辑层（C’），技术物理模型和组件组装对应于设计物理层（D）。
05 Zachman框架的价值和不足
Zachman框架从本质上来说是对企业架构描述的一种分类法，可以从以下六个方面帮助我们开发企业架构，帮助解决企业信息化发展所面临的问题（系统复杂度管理、业务与信息技术的不协调发展）：
1. 确保每个利益相关者的每一个关注点被照顾到。
2. 通过把每个焦点精简到每个特定利益相关者涉及的焦点来提升架构材料的质量。
3. 确保业务需求可以被映射到技术实现之上，同时每个技术实现也可以被回溯到业务需求之上。
4. 确保商业方面不会规划出多余没用的功能。
5. 确保技术组包含在商业组的规划中。
6. 加强业务人员与信息技术人员的沟通和交流，减免以前因缺乏沟通而导致的无谓的内耗。
尽管Zachman框架给出了帮助组织架构内容的分类方法，但是Zachman本身并不是一个完整的解决方案。比如，Zachman框架没有给出架构开发的流程步骤，偏于静态描述而无法对持续演进的企业架构进行动态描述，也没有给出评价架构成熟度的方法。
06 Zachman框架的实际应用
在具体实践中，Zachman框架可以与具体领域的方法工具相结合，开展企业架构设计。下图显示了Zachman框架的本体结构以及UML，BPMN，ERD和其他图的组合使用。
Zachman论文《A frameworkfor information systems architecture》下载方式：
