1.1　Zachman框架

Zachman框架是企业架构理论的鼻祖。这么说显得有些老气横秋，实际上这个框架才30多岁，按人的年龄来看还不算老。但计算机行业发展太快，而且大家对电子行业一向“喜新不恋旧”，因此，Zachman框架对很多软件设计人员而言像是只闻其名、未见其面的“上古神器”。

Zachman框架由John Zachman于1987年首次提出。之后在1992年，Zachman又与Sowa合作发表了论述更完善的第二篇续作，常见的Zachman框架示意图就诞生于此，如图1-1所示。

Zachman框架发表的时候，软件行业自由发展了近40年，以“瀑布模型”为代表的工程理论也提出了近20年。这数十年间，软件越来越复杂，其中既有业务发展的原因，也有计算机行业“自作自受”的原因。1964年，IBM System360系列的成功使得企业有能力进行更大范围的信息化改造，因此企业端软件开发大胆地走上了深入“业务迷宫”的“不归路”。

图1-1　Zachman框架示意图

这条“不归路”既不平坦也不清晰，充满了对定制化的追求和对业务本质的误解，这些追求和误解往往同时来自于业务和技术两个方面，混杂着各种似是而非的观点，堪称“灾难”。面对这种情况，当时就职于IBM的Zachman写了一篇名为《信息系统架构框架》的论文，表达了对连什么是“架构”都给不出一致答案的现状的感慨，并试图阐述“架构”应该包含什么。

这篇文章对企业架构理论而言意义重大，被视为开山之作，尽管Zachman在文章中并没有明确提出“企业架构”这个概念，但是，他创造性、包容性地提出了企业架构应当是一系列架构的总和这个观点，强调了对复杂系统的认知是多角度、分层次的，不同的角度、项目的不同时间阶段对应的架构视图和架构描述都应是不同的，而架构框架就是要建立不同架构描述之间的关系。不同视角的架构可以有差异，其实也就相当于认为没有一个单一的架构描述可以包含架构的所有信息，由此，他批判了一个至今依然存在的现象——我们总是试图在一个混乱的视角下描述架构的所有内容。事实上，并不存在一个单独的架构（single architecture），只存在一整套架构（a set of architecture）。

Zachman将需求方、架构师、实施团队等角色类比成建筑行业中的业主、建筑师、承包商等。尽管大家都围着房子转，但业主、建筑师、承包商对房屋的认知是不同的，对各自心目中的方案的预期及其详细程度的要求也不同。同一座房屋，业主看到的是房屋的外观，建筑师看到的是结构和成本，承包商看到的是每一部分详细的施工方案，承包商下还可以有更细节的专业材料商，而材料商关注的则可能只是地板。

不同视角的观点构成了对同一对象不同角度和不同详细程度的综合性描述。尽管根据每一层级视角的细化，在理想情况下可以反推出上一级的模型，但是框架并不能严格保证这种反推的一致性，因为各层级的关注点是不同的。如果没接触过Zachman框架，那么上述观点看起来是有些反直觉的。在1992年的文章中，Zachman将层次最终定义为Planner、Owner、Designer、Builder、Contractor五层。

除了角色的视角之外，还需要在每种视角中建立不同的观察维度，以满足描述软件设计最基本的要求。Zachman使用“5W1H”方法构建分析维度。在1987年的文章中，他介绍了What（数据）、How（流程）、Where（网络），相当于信息、功能、部署；在1992年的文章中，他又进一步完善了对Who（人）、When（时间或者事件）、Why（价值）的探究。

从当时已有的设计观念来看，在这六个维度中，What、How、Where是比较容易清晰描述的，在实际操作中也经常采用；对Who、When的描述并没有很明确的要求，但从现在的视角来看，对这两个因素的描述已经很普遍和规范了；唯独对于Why这个因素，由于其中存在相当程度的主观因素，因此一直很难量化。战略可以被视为Why的最高级别的表述，但是任何一个战略都很难在提出时被准确评价，并且战略的风险往往影响又最大。Zachman框架聚焦于信息系统架构，因此两篇文章都没有在战略规划上用太多笔墨，1987年的文章中还特意和战略规划划清了界限。

框架最大的价值在于让软件设计人员明白，没有必要为架构视角的不同而争执，而是要把这些视角统一到一个框架中，以构成对同一个对象的完整描述。1992年的Zachman框架中包含了30个架构单元（5个层次×6个维度），每个单元既是独立的，也是相互关联的，每个单元都需要单独的架构描述和架构决策，而框架的意义就在于揭示架构决策的影响，让设计人员基于更完整的视角去做架构决策的判断。

但是，为了真正实现这一目标，框架给了我们一个延续至今的任务：为每个单元分配适当的设计形式，也就是找到对于每个单元而言合理的架构构建和描述方法。一些单元已经有了很好的表示方法，一些至今仍在寻找。框架也隐含了这样一个观点：企业端软件设计要关注的是企业而不只是软件，要从多个视角去完整地关注企业，不能一接到项目就直接开发。

尽管Zachman框架的想法很好，但是它主要还是以理论为主，缺少详细的实现过程。在实操中，构建这样一个框架绝非易事，Zachman自己也在文中多次提到因信息不足而无法进行框架描述。但是，难做不等于做不成，更不等于不该做，越是复杂的工程越是需要清晰的思路，我们还要做更多的研究。

无论存在何种缺陷，就像瀑布模型一样，Zachman框架的开创性价值毋庸置疑，而其描述的框架开发思想也很适合当时最为常见的瀑布模型。它为架构理论的发展做出了巨大贡献。