Zachman框架（Zachman Framework™）是一个纲目（schema）——两种有几千年历史的分类法的交集。第一种是建立在原始疑问词上的沟通基础要素：什么、如何、何时、何人、何地以及为何。这些问题答案的集成，能够对复杂的想法形成全面、综合的描述。第二种来自具体化，即古希腊哲学中假定的抽象观念到实例的转换，在Zachman框架中记为：辨别、定义、表达、规定、配置和实例化。
Zachman说，框架分类的最初启发是来自对建筑、飞机和其它复杂的工业产品的观察经验。对于上述定义，他还强调，Zachman框架是一种描述企业的本体，是元模型，而不是关于创建对象的最终实现（实例）的方法学。它是关于结构的，而不是过程。它是企业架构（EA）的基础。
基本结构
Zachman框架是一个综合性分类系统。它相当于通过6×6的分类矩阵，把企业架构涉及的基本要素（而不是企业本身）划分成36种单元（Cells），并清楚地定义了每个单元中的内容（组件、模型等）性质、语义、使用方法等。从相关介绍可以知道，在找到现在这种二维矩阵的划分方式之后，对每个单元的内容也在逐步认识、实践和总结。考察现在的标准叙述，仍可以感觉到，单元的内容和单元间的关系，远不像架构的整体方案所暗示的那样明确、直观。标准中对多单元上用法说明，有些也并非显而易见。这一方面体现在这个表面简单的结构中，还蕴藏着不少“道理”，同时可能也说明，这里还有不少可以探讨的空间和不同的可能性。
详细的分类矩阵，可以由其网站上看到。5W1H的描述展开，看来“非常基本”，似乎只有用或不用的选择，但并非没有讨论余地，特别是，如果站在企业规划、建模、模型工作机制这样一些角度上，会更有多的讨论空间——不仅是关于5W1H这一方案的选择，而是在更深的层面上（参见后续的分析文章）。相对于行的展开，按照“具体化”层次展开的列，则更需要仔细考察。下表将Zachman提示的具体化标志与实际矩阵上的标签对应起来，以便于观察。同时，对照列出了“Who”这一列单元格里的基本提示。单元格里放的东西，前五层都表现为模型（或文档），而最底层是实例。
| 具体化层次 | 矩阵左侧标签 | 矩阵右侧标签 | 单元举例（“Who”列） |
| Identification 辨别 |
Scope Contexts 范围语境 |
Strategists as Theorists 战略家，相当于理论家 |
名称：组织识别/边界列表 组件：组织类型/类型定义 说明：列出业务上重要的组织 |
| Definition 定义 |
Business conceptes 业务概念 |
Executive Leaders as Owners 执行领导，相当于所有者 |
名称：组织定义/语义模型 组件：组织角色、组织工作 说明：工作流模型 |
| Representation 表达 |
System Logic 系统逻辑 |
Architects as Designers 架构师，相当于设计者 |
名称：组织表达/图解（Schematic）模型 组件：系统角色、系统工作 说明：人类界面架构 |
| Specification 规定 |
Technology Physics 技术物理学 |
Engineers as Builders 工程师，相当于建造者 |
名称：组织规范/蓝图（Blueprint）模型 组件：技术角色、技术工作 说明：呈现（presentation）架构 |
| Configuration 配置 |
Component Assemblies 部件组装 |
Technicians as Implementers 技师，相当于实施者 |
名称：组织配置/清单 组件：组件角色、组件工作 说明：安全架构 |
| Instantiation 实例化 |
Operations Classes 操作类 |
Workers as Participants 工作者，相当于参与者 |
名称：企业组织实例 组件：组织角色、组织工作 说明：实际的人和它们的工作 |
从现有的单元格内容和关联的解释看，这个表面简单的“正交”二维分类矩阵，每一个交点（单元）上对应的到底应该是什么，并非显而易见，或许有许多值得探讨的可能性。而从现在所给出的方案看，这两个维度也许并非如矩阵图所暗示的那样，完全是简单正交的。纵向的具体化层次划分，表面上看似乎经验性的色彩较为浓厚，但结合其所给的各列内容方案，能够体会到，其中的蕴含还是相当深的，正如它十几年发展已经体现的，一方面有很多经验性的、实践的支持，一方面也是得来不易，很有参考价值。这个分类矩阵的行、列选择，的确相当基本，显示出某种“本质划分”的特点，但也并非没有争议。以后我们将对此进行讨论。
如果我们按照这个框架本来的定位——作为一种企业架构/工程的描述性逻辑结构、分析框架去使用，它无疑是非常有启发性的一种基础性工具，一旦超出这个范围——例如，用来指导实际企业的企业“架构”开发，甚至企业建模，就可能会遇到很多具体的问题。