全称为企业架构和企业信息系统架构Zachman框架(Zachman Framework for Enterprise Architecture and Information Systems Architecture)。Zachman"框架"实际上是一种组织构架工具（用来设计文档、需求说明和模型的工具）的一种分类学。包括工具的目标（例如，商业拥有者、创建者）是谁，哪些特殊的问题（例如，数据、功能）需要阐明。
Zachman是这样描述他的杰作的： 当这个框架应用于企业时，它仅仅是用来分类和组织企业（在这些企业里，企业的管理和企业系统的开发同样重要）的描述形式的逻辑结构。 许多Zachman框架的支持者认为它是跨学科的，它的影响不仅仅局限于IT行业。例如，一本关于Zachman的书中这样说： 在适当的时候，你会发现框架不仅仅是存在于IT项目中，它存在于你所做的每一件事情中。当你完全理解了这个框架之后，做任何事情都会变得高效。我指的是任何事情，这个断言并不武断。
Zachman框架是一种逻辑结构，目的是为IT企业提供一种可以理解的信息表述，它对企业信息按照特定的要求进行分类，从不同角度进行描述。
根据抽象规则，它定义企业信息的一个方面，一个框架采用了一种六行，每行中包含36个子单元的格式。
六行(即纵向维度)反映了IT架构层次，从上到下（Top-Down）。包括了范围模型、企业模型、系统模型、技术模型、详细模型、功能模型。
如同建筑构架为不同的角色提供不同的材料。每个角色都需要完整的信息，不过对于不同的角色而言，所需的完整信息也是不同的。拥有者感兴趣的完整描述是建筑物的功能和美感。构造者感兴趣的完整描述是建筑材料和构建过程。拥有者并不关心墙里面的螺栓钉在哪儿，构造者也不关心卧室的窗户如何排列，以便在早晨能够迎来第一缕阳光。
纵向按企业中不同角色的关注点进行划分：
规划人员关注范围模型，能够看到企业的发展方向、业务宗旨和系统边界范围。
系统所有者关注企业模型，能够用企业术语定义企业的本质，看到的是企业的结构、处理、组织等。
体系结构师设计人员关注系统模型，能够用更严格的术语定义企业业务，看到的是每项业务处理所要完成的功能。
构建人员关注技术模型，使用技术模型来解决企业业务的信息处理需求。
集成人员关注详细模型，需要去解决关于特定语言、数据库存储表格及网络状况等具体细节。
用户关注功能模型，也是系统的最终用户，考虑系统能否支持自身的工作。
从两个维度将所有IT构件进行分割，可以划分成小的相对独立的模块，便于独立管理。
六列（即横向维度）采用6W（what、how、where、who、when、why）进行组织。即分别为做什么（数据）、如何做，什么地点，谁来做、什么时间、为什么做。
以列描述中的"数据（What）"为例：
----从商业拥有者的角度，"数据"意味着商业实体。它可能包括实体本身的信息，如客户和产品，也可能包括实体间关系的信息，如人口群体和库存。如果你打算和一个商业拥有者讨论数据，你应该用到这些语言。 ----从数据库的实现者的角度来看，"数据"就不是商业实体了，而是保存在数据表中的行和列，还有通过连接（join）和映射（projection）生成的表。如果你在和一个数据库设计者讨论"数据"，不要讨论客户的群体，而应该讨论关系数据表。 并不是从一个角色的角度看就比从另外一个角色的角度看要好，也不是越详细越好，也不是某一个的优先级比其他的更高。作为一个整体，无论是从谁的角度都很重要。正如Zachman说过的： 我们在信息系统构架方面与另外的构架沟通时有很多困难，因为存在很多构架表现形式，而不是仅仅只有一个构架。其中一个出错了，其他的也跟着出错。构架是不同的。它们是附加的和补充的。选择为开发每个构架表现形式而支出资源是有原因的。如果不开发任何构架表现形式是有风险的。 正如我前面提到的，Zachman框架由六个功能焦点组成，每个功能焦点都会从一个角色的角度考虑。
zachman framwork 3.0
数据（什么？） |
功能（怎样？） |
网络（哪里？） |
角色（谁？） |
时间（何时？） |
动机（为何？） |
|
|
目标范围 |
列出对业务至关重要的元素（或事件） |
列出业务执行的流程 |
列出与业务运营有关的地域分布要求 |
列出对业务重要的组织部门 |
列出对业务重要的事件及时间周期 |
列出企业目标、战略 |
|
业务模型 |
实体关系图（包括M: M关系、N-ary关系、归因关系） |
业务流程模型（物理数据流程图） |
物流网络（节点和链接） |
基于角色的组织层次图 包括相关技能规定、 安全保障问题。 |
业务主进度表 |
业务计划 |
|
信息系统模型 |
数据模型（聚合体、完全规格化） |
关键数据流程图、 应用架构 |
分布系统架构 |
人机界面架构（角色、数据、入口） |
相依关系图、数据实体生命历程（流程结构） |
业务标准模型 |
|
技术模型 |
数据架构（数据库中的表格列表及属性）、 遗产数据图 |
系统设计： 结构图、伪代码 |
系统架构（硬件、软件类型） |
用户界面（系统如何工作）、 安全设计 |
“控制流”图（控制结构） |
业务标准设计 |
|
详细展现 |
数据设计（反向规格化）、物理存储器设计 |
详细程序设计 |
网络架构 |
屏显、安全机构（不同种类数据源的开放设定） |
时间、周期定义 |
程序逻辑的角色说明 |
|
功能系统 |
转化后的数据 |
可执行程序 |
通信设备 |
受训的人员 |
企业业务 |
强制标准 |
这36个方格，每个方格就是一个角色（例如商业拥有者）和每个描述焦点（如数据）的交汇。当我们在表格中水平移动（例如从左到右）时，我们会从同一个角色的角度，看到系统的不同描述。当在表格中竖直移动（例如从上到下）时，我们会看到从不同角色的角度，如何观察同一个焦点。
关于Zachman表格有三条建议，相信它们在企业构架的开发中对我们会有帮助。 第一条建议就是每一个构架材料应该存在于一个方格中，而且只能存在于一个方格中。在一个构架材料放在哪个方格里不应该含糊不清。如果某个构架材料的确不知道应该放在哪个方格中，问题很有可能处在构架材料本身。 当组织在开发企业构架中开始积累材料的时候，它可以使用Zachman表格解释每个材料的焦点。例如，面向服务构架相关的材料很有可能就放在第三行（从设计着的角度看）。它们一般不会引起商业拥有者的兴趣。 第二条建议：仅仅只有当所有的表格都填满了的时候，一个构架才能被称为是完整的构架。当所有的方格都填满了时候，整个表格才有足够的材料定义系统。 只有当每个方格都填满了材料的时候，才有足够的信息描述系统：从每个角色（我们现在可以称之为"利益相关者"，Stakeholder）的角度观察系统的每个可能的视角（描述焦点）。所以一个组织可以使用Zachman表格确保企业构架中的所有重要利益相关者之间的讨论都是合适的。 第三条建议：表格的每列的方格都是彼此相关的。例如，Zachman表格的数据列（第一列）。从商业拥有者的角度，数据就是关于商业的信息。从数据库管理人员的角度，数据就是数据库中的行和列。 尽管商业拥有者对数据的看法和数据库管理员不同，但它们应该是有关系的。一个人可以遵循商业需求，并且显示出设计的数据就是被需求驱动的。如果有商业需求并没有追踪到数据库设计，那么就得想想商业需求是否与企业构架相符。另一方面，如果数据库设计的元素没有需求与之对应，我们就应该问问自己，在数据库层面是否存在不必要的设计。 Zachman表格可以从以下五个方面帮助我们开发企业构架： 确保每个利益相关着能够从描述的焦点考虑。 通过把每个焦点精简到每个特殊观众涉及的焦点来提升构架材料的质量。 确保每个商业需求能够追踪到技术实现。 确保商业方面不会规划出多余没用的功能。 确保技术组包含在商业组的规划中。 但是Zachman本身并不是一个完整的解决方案。有太多的问题它都没有描述。例如，Zachman没有给出一步一步构造一个构架的过程。在决定我们将要构建的构架是否是最好的时候，Zachman没有提供更多的信息帮助我们作出决定。就此而言，Zachman也没有给出一种途径展示将来构架的需求。最重要的，从我们的角度，尽管Zachman表格可以帮助组织构架材料，但是它在描述企业复杂性方面几乎什么都没做。
采用Zachman框架进行IT规划的一般步骤：
（1）确定组织的愿景和原则
- 确定IT架构业务、组织与IT系统范围，识别业务驱动力；
- 确定IT架构愿景和目标；
- 制定IT架构定义的原则；
- 识别IT架构相关需求；
- 业界IT架构最佳实践研究与学习。
（2）现状描述分析
- 搜集现有IT系统现状资料；
- 业务现状分析，识别现有IT系统对业务支撑上存在的问题。
- 引入最佳实践，并结合企业实际，定义目标IT架构，包括：数据、应用、基础设施架构。
- 目标架构与现状的差距与改进点分析；
- 把具体IT需求纳入目标架构框架。
- 对IT架构的改进点，以及具体需求进行优先级排序。
（3）制定IT架构的实施计划
- 确定向目标IT架构迁移的具体实施计划；
- 确定目标IT架构实施的推行组织。优化
（4）持续改进IT架构规划过程中，各个环节不断优化；
- 制定目标IT架构的持续改进计划；
- 制定IT架构的管理维护机制。
