「企业架构」Zachman框架简介

Zachman框架是John Zachman在1987年提出的，成为工程企业架构中广泛使用的方法。它以信息系统架构框架（frameworkforinformationsystemarchitecture）的名义发表在IBM的系统期刊上。Zachman于1964-1990年在IBM工作，是IBM业务系统规划（BSP）的创始人之一。

Zachman框架背后的基本思想是，可以使用不同类型的描述，以不同的方式为不同的目的描述相同的复杂项。这个框架提供了36个必要的类别来完全描述任何东西，特别是复杂的东西，如制成品。这36个类别由6行6列组成，采用二维矩阵的形式。

框架的六行是：

1. 计划者视图（范围上下文）-此视图描述业务目的和策略，为其他视图定义竞争环境。

2. 所有者视图（业务概念）–此视图显示企业的哪些部分可以自动化。

3. 设计器视图（系统逻辑）–此视图概述了系统将如何满足组织的信息需求。

4. 实现者的观点（技术物理）–这是一个系统在解决生产约束时如何实现的表示。

5. 子构造函数视图（组件组装）-这些表示说明了特定系统元素的实现细节。

6. 用户视图（操作类）-这是操作环境中运行系统的视图。

这些列表示向企业提出的疑问或问题。

1. 什么（数据）–什么是业务数据、信息或对象？

2. 如何（功能）–通过定义流程，业务是如何工作的？

3. 哪里（网络）-业务运营在哪里？

4. 何时（时间）-何时执行业务流程？

5. 为什么（动机）–为什么选择解决方案，它是如何产生的，以及是什么激励了某些活动的执行？

Zachman定义了7条使用框架的规则。

规则1：不要向框架添加行或列。

几千年的语言经验将确定这六种原始疑问句是谁、什么、何时、何地、为什么以及如何。如果你能回答所有这六个问题，那么你就可以得到关于主题或对象的任何其他问题的答案。向框架中添加行或列将使分类方案非规范化。

规则2：每一列都有一个简单的泛型模型。

在我们的案例中，框架的每一列都描述了分析目标企业中的一个独立变量。因此，任何一列的基本泛型模型都非常简单：它表示的变量（抽象）与自身相关。

规则3：每个单元模型专门处理其列的泛型模型。

任何给定单元格的特定模型都必须根据行透视图的约束、语义、词汇表、术语和事实进行自定义。此外，考虑到单元描述构成了管理变更的基线，因此（元）模型将必须表达由变更到该单元模型所影响的所有概念。因此，给定单元格的特定（元）模型将从通用的列模型开始，根据行的语义约束进行调整，然后可能进行扩展，以容纳所有相关概念，用于表示单元格行透视图的约束以及管理对单元格模型本身的更改。

规则4：任何元概念都不能分为多个单元。

该框架构成了一个干净的规范化分类系统，每一列都是唯一的。没有一个元概念可以分为多个单元。没有冗余。这是使框架成为良好分析工具的一个基本因素。

规则5：不要在单元格之间创建对角线关系。

首先，业主、设计师、建筑商和分包商都在用同一个词来表示完全不同的东西，这就造成了一个非常混乱的沟通问题。企业中的人可能会说同一种语言，使用同一种语言，但可能无法有效地相互沟通。禁止对角线的结构原因是因为细胞关系是传递的。在逻辑上更改单元格可能会影响同一列中的上下单元格以及同一行中的每个其他单元格。

规则6：不要更改行或列的名称。

不要在通用框架或企业特定框架中更改行或列的名称。如果更改行和列的名称，也会更改受影响行或列的含义。您可以对框架进行反规范化，使其不再全面。

规则7：逻辑是通用的和递归的。

框架的逻辑是通用的。它可以用于对任何事物的描述进行分类，并分析与其架构组成相关的任何事物。它是递归的。它可以用来分析建筑结构本身。框架是惰性的。它不知道用来分析什么。只有分析人员知道分析对象并确定分析的边界，所选择的分析边界具有深远的影响。

Zachman框架是如何使用的，在哪里使用的？

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

Zachman框架提供了一种对组织架构进行分类的方法。它是一个主动的业务工具，可用于为组织的现有功能、元素和流程建模，同时帮助管理业务更改。该框架借鉴了Zachman在复杂产品中如何管理变更的经验。John Zackman强调框架可以扩展到整个企业架构，而不仅仅限于信息架构。

John Zachman认为框架被用作：

1. 一个计划工具-帮助你定位问题并做出明智的选择。

2. 一个解决问题的工具——控制业务抽象的复杂性，实现单个业务变量的隔离。

3. 通过将工具和方法映射到框架来评估它们，从而证明一种中立的方式来对它们所做和不支持的事情进行编目。

4. 用于构建灵活的组件架构和系统的上下文，这些架构和系统能够支持高比率的企业更改，并替换由于“上下文外”而“未集成”的“现有系统的库存”

在Zachman框架中开始的逻辑点应该在二维矩阵的左上角，然后沿着表格向下。用于表示特定业务领域的相关业务信息或模型可能已经存在于业务计划、项目计划、系统规范、程序指南或其他文档中。

当你浏览这个矩阵时，会有一些空白需要填补，其中只有一个人或少数专家知道的隐含信息需要明确，并提供给更广泛的受众。可能存在重叠或冗余的情况。目标是管理变更，减少冗余和重叠。

本文 :https://architect.pub/introduction-zachman-framework 讨论：知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】 公众号

【jiagoushipro】
【超级架构师】
精彩图文详解架构方法论，架构实践，技术原理，技术趋势。
我们在等你，赶快扫描关注吧。

【ca_cea】
50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化.

QQ群

【792862318】深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。
加QQ群，有珍贵的报告和干货资料分享。

视频号 【超级架构师】
1分钟快速了解架构相关的基本概念，模型，方法，经验。
每天1分钟，架构心中熟。

知识星球 【首席架构师圈】向大咖提问，近距离接触，或者获得私密资料分享。

喜马拉雅 【超级架构师】路上或者车上了解最新黑科技资讯，架构心得。 知识星球 认识更多朋友，职场和技术闲聊。 微博 【超级架构师】 哔哩哔哩 【超级架构师】

抖音 【cea_cio】超级架构师

快手 【cea_cio_cto】超级架构师

小红书 【cea_csa_cto】超级架构师

网站 CIO(首席信息官) https://cio.ceo 网站 CIO,CTO和CDO https://cioctocdo.com 网站 应用开发和开发平台 https://apaas.dev 网站 开发信息网 https://xinxi.dev 网站 首席架构师社区 https://jiagoushi.pro 网站 超级架构师 https://jiagou.dev 网站 企业技术培训 https://peixun.dev 网站 程序员宝典 https://pgmr.pub 网站 程序员云开发分享 https://pgmr.cloud 网站 CPO宝典 https://cpo.work 网站 架构师实战分享 https://architect.pub ‍ 网站 首席安全官 https://cso.pub ‍ 网站 CIO酷 https://cio.cool 网站 CDO信息 https://cdo.fyi 网站 CXO信息 https://cxo.pub

谢谢大家关注，转发，点赞和点在看。