企业架构设计方法论-Zachman框架简述(重塑世界观-XX第63期)

一、前言

“Zachman框架由John Zachman于1987年首次提出。之后在1992年，Zachman又与Sowa合作发表了论述更完善的第二篇续作”，基于当时的背景诞生了整套体系化的思想。

1框架示意图

2框架汉化图

二、方法论的优势 VS 劣势

“Zachman使用“5W1H”方法构建分析维度。在1987年的文章中，他介绍了What（数据）、How（流程）、Where（网络），相当于信息、功能、部署；在1992年的文章中，他又进一步完善了对Who（人）、When（时间或者事件）、Why（价值）的探究。这些都表明了实际业务中并不存在一个单独的架构，而是基于各种因素综合裁定出的一整套架构体系。

2.1、方法论的优势

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

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

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

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

2.2、方法论的劣势

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

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

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

3、参考资料

参考 聚合架构 面向数字生态的构件化企业架构 付晓岩

参考Zachman框架PPT解读