1.2 Zachman框架

Zachman框架（Zachman Framework）是最著名的企业架构框架之一，由John A. Zachman于1987年在IBM首次提出，如今已发展到3.0版本。Zachman框架其实并不是我们通常理解的“框架”，因为它并没有定义具体的落地实施方法，而更像一种方法论（原文称作Ontology）。所以当这个框架应用于企业时，它仅仅用来作为分类和组织企业的描述形式的逻辑结构，通过利益相关方以及沟通的基础要素这两个维度的解构，完成整个企业架构的理论基础。

1.2.1 Zachman框架的维度

在创建建筑、飞机以及其他复杂的项目或者系统时，Zachman意识到对于复杂的对象可以通过拆分利益相关方以及不同维度，使其变得更有条理。为此，Zachman将企业架构涉及的基本要素拆分成一个6×6的二维矩阵，并在这个矩阵中清楚地定义了每个单元格的内容性质、语义及使用方法等。

这个矩阵由两个维度构成：利益相关方和问题的基本要素。其中，利益相关方（包括管理层、业务管理者、架构师、工程师、技术人员以及操作人员等6个角色）对应回答What、How、Where、Who、When以及Why这6个问题，进而构成整个框架的完整内容，如图1-2所示。

图1-2 简化的Zachman框架

1.2.2 Zachman框架的特点

在当今复杂的业务环境中，许多大型组织很难应对变化。困难的部分原因是组织缺乏对不同领域中复杂结构和组件的内部理解，在这些领域中，有关业务的遗留信息被锁定在特定员工或业务部门的范围内。

Zachman框架控制业务抽象的复杂性，实现单个业务变量的隔离。当组织着手进行企业架构的设计与开发时，Zachman框架可以确保不同的角色关注不同的重点，明确不同角色的边界。例如，面向服务架构相关的材料很有可能就放在第三行（从架构师的角度看），它们一般不会引起业务管理者的兴趣。

Zachman框架通过从不同的角度（5W1H）进行拆分，来帮助架构师聚焦某个具体的问题，确保不会产生冗余的功能或者规划，保证整个模块的相对独立性。这一点非常重要，因为它从设计之初就减少了后续的整体维护及沟通成本等。例如电商产品模块中存在两张类似的商品维度表以及部分相同的字段，那么基于这两张表中的任何一张都可以完成功能开发，这时就会产生沟通成本，并且人员的更替或者沟通的问题都可能导致不同的功能采用不同的数据表，进而产生较高的维护成本。因为任何涉及相同字段数据的更新都会涉及多次开发流程，随着时间的流逝，这种设计带来的成本将会成倍增加。这只是两张表导致的成本增加。对于Zachman框架这种高度抽象的框架来说，它需要帮助架构师尽量避免冗余带来的实施或服务过程中的潜在风险。

1.2.3 Zachman框架的使用

在具体的工作中，如何利用Zachman框架指导利益相关方进行思考或者工作呢？下面以Zachman框架中的架构师这一角色为例简单讲解一下。

架构师这个角色的业务观点主要是满足系统逻辑设计。按照框架内容来看，框架主要分为6个方面：组成对象及关系（What）、系统功能及输入输出（How）、业务节点及连接（Where）、系统角色及工作产品（Who）、时间及频率（When）、业务目标或者方式（Why）。根据我的理解，其中Why应该是业务的起点，即这件事背后的战略目标或者意义。

这样说其实还是太抽象，我们以搭建数据平台的架构师为例进行详细讲解。为解决数据孤岛问题，提高企业整体效率（Why），需要进行数据平台的构建；数据架构师拿到任务之后开始调研，然后梳理清楚企业的不同业务场景及其背后的数据实体；经过一段时间的调研及梳理之后，确定数据平台的核心实体以及实体之间的关系（What）；由于数据平台的实体分布在不同的应用系统中，所以需要对接不同的系统进行数据抽取以及其他工作（How）；由于不同的数据有着不同的生命周期且不同应用对于数据的时效不一样，所以需要设置不同的数据批处理或者同步周期（When）；随着数据平台的功能逐步完善，开始支持不同的业务系统及创新业务，需要在不同的业务环节接入数据平台的服务（Where）；同时，数据平台包含企业的绝大部分数据，需要拆分不同的权限分给不同的用户进行管理（Who）。这样不断循环迭代，整个数据平台初具规模。

但是在上述描述的过程中，你会发现Zachman框架存在一些问题：首先，在How阶段我们需要进行数据抽取，但是Zachman框架并不能告诉我们如何抽取以及采用什么工具抽取；其次，Zachman框架只告诉我们应该拆分，但是没有告诉我们如何拆分，即它只提供了结果却没有提供对过程的描述。

实际上，虽然Zachman框架没有告诉我们构建过程的细节、架构设计的终点或者衡量标准是什么，但它在企业架构理论层面的权威性不容忽视。