首先我们看一下什么是 Zachman Framework 。
1. Zachman Framework 简介
Zachman Framework 由约翰 扎科曼（ John Zachman ）在 1987 年创立的全球第一个企业架构理论，其论文《信息系统架构框架》仍被业界认为是企业架构设计方面最权威的理论。是其他企业架构框架的源泉。
Zachman 框架（ Zachman framework ）是一种逻辑结构，它的核心理念是同一个事物可以用不同的方式、基于不同的目的、从不同维度进行描述。当一个事物足够复杂时，这种描述框架就有更大的价值。
在 Zachman Framework 之后，又发展出很多企业架构框架，比如由 Open Group 推出的在大型企业中非常流行的 TOGAF 。但 Zachman Framework 仍然是理解企业架构的重要基础。
2. Zachman Framework 的结构
Zachman Framework 是一个综合性分类系统。它相当于通过 6×6 的分类矩阵，把企业架构涉及的基本要素（而不是企业本身）划分成 36 种单元（ Cells ），并清楚地定义了每个单元中的内容（组件、模型等）性质、语义、使用方法等。如下图所示：
Zachman 框架的列
• 数据（ What ，即什么内容） ——用于表示客观对象的材料组成，即材料清单。对于企业来说，此部分内容就是组成事物模型
• 功能（ How ，即如何工作） ——用于表示功能和转换行为。对于企业来说，这部分内容就是流程或功能模型等。
• 网络（ Where ，即何处） - 用于表示各组成部件的坐落位置以及相互之间的联通关系。对于企业来说，这部分内容就是物流或网络模型等。
• 人员（ Who ，即何人负责） ——用于描述了何人应该做何事，例如用户手册和操作说明等。对于企业来说，这部分内容就是人力模型或工作流模型等。
• 时间（ When ，即什么时间） ——用于描述事物发生的时间以及不同事物之间的相对时间关系，例如生命周期和时序图等。对于企业来说，这部分内容就是时间或动态模型等。
• 动机（ Why ，即为什么做） - 用于表示最终结果和意义。对于企业来说，这部分内容就是动机模型等。
Zachman 框架的行
从不同利益相关者的角度来看，每一行都代表组织的不同视图。这些按所需的优先级顺序排列。一行被分配给以下每个利益相关者： :
• 范围 / 规划师（ Planner ） ——包括整个信息系统所处的环境上下文，内外部约束，及其他视角下对信息系统的描述所需要考虑的相关构成部分的列表。
• 业务模型 / 拥有者（ Owner ） ——最终产品的概念视图，反映了最终产品的使用特性，即用户准备如何使用最终产品。具有此视角的干系人包括最终产品的客户或用户。
• 系统模型 / 设计师（ Designer ） ——有关最终产品的逻辑视图，反映了最终产品的本质规律以及逻辑约束。具有此视角的干系人包括工程师、架构师以及能够将期望所得与现有的物理、技术上的实现联系起来的各种中间人。
• 技术模型 / 建造者（ Builder ） 反映了在产品构建过程中现有技术的物理约束。具有此视角的干系人包括制造工程师、总承包商以及具有生产最终产品所需的技术能力的组织或人员。
• 详细表述 / 分包者（ Sub-Contractor ） ——关于为了达到生产目的而对复杂对象进行分解的详细描述，这些内容在从设计媒介到最终产品媒介的转换中起着非常重要的作用。
• 产品 / 运行中的企业（ Functioning Enterprise ） ——代表了最终产品，是架构在客观现实中的实例体现。
Zachman 框架的规则
行和列相交的单元格表示了各个干系人在各自视角上对于信息系统的某个方面的具体描述。在实际应用过程中还应该遵循下列规则：
不能为此框架增加新的行或列。在 Zachman 框架看来，框架中的六行视角以及六列描述方面构成了系统描述的最基本元语，即为了构建系统而对其架构所做的描述只要能够从六种视角出发，并能为每个视角在六个方面（什么内容（ What ）、如何工作（ How ）、何处（ Where ）、何人负责（ Who ）、何时（ When ）和为什么动机（ Why ））做出解答，那么此架构描述就是完备的，也由此足以成为系统的复杂度管理和变更管理的基础。
每一列中的内容都遵从某一通用模型。由于每一列都代表了所描述架构的某一个方面，因而处于同一列的各个描述在本质上应符合某种经过高度抽象的元模型：
- “数据”列（ What ）应遵从：事物——关系——事物。
- “功能”列（ How ）应遵从：流程——输入 / 输出——流程。
- “网络”列（ Where ）应遵从：节点——连接——节点。
- “人”列（ Who ）应遵从：人员——工作——人员。
- “时间”列（ When ）应遵从：事件——周期——时间。其中，“事件”指代某一时间点，而“周期”代表了一段时间区间。
- “原因”列（ Why ）应遵从：结果——方式——结果。其中，“结果”代表了目标状态，而“方式”则用于表示为了达成目标状态而采用的行为。
3. Zachman Framework 模型库
为了让用户能够快速而全面的了解 Zachman Framework 的基础结构， EA 提供了 Zachman Framework 的模型。如下是 Zachman Framework 的模型目录：
各个包简要说明如下：
| 模型包 |
内容 |
| Planner |
这个包代表 Zachman 框架的计划者 / 业务范围行。 |
| Owner |
这个包代表 Zachman 框架的所有者 / 概念行。 |
| Designer |
这个包表示 Zachman 框架的设计器 / 逻辑行。 |
| Builder |
这个包表示 Zachman 框架的 build / Physical 行。 |
| Subcontractor |
这个包代表了 Zachman 框架的分包商 / 组件行。 |
| Functioning Enterprise |
这个包代表 Zachman 框架的 functional Enterprise 行。 |
下面就对每个 Zachman Framework 的模型包进行详细说明：
1.Planner 规划者 下各包
代表框架的计划者视图中包含的业务数据、业务流程、业务场所、业务单元、业务事件及业务动机。具体如下：
Business Data 业务数据
内容包括当前可用的资源以及企业为有效运行业务而需要的资源。包括：资产、业务实体和人力资源
Business Process
高级业务流程图捕获企业执行的业务流程列表。组织单位的主要功能构成了这个单元的潜在内容。
Business Location
捕获了业务操作所在的业务位置列表。
Business Units
组织结构图捕捉了企业的组织结构。
组织单位和涉及业务的外部组织在这里被识别和记录。
链接到供应商联系信息仓库，租赁协议，技术合同等可能在这里提供。
可以将相关的附加信息记录为元素的标记值。
Business Events
在此单元格中记录主要业务事件，并将更多信息记录为标记值。
Business Motivation
右键单击该元素并选择“ Linked Document ”选项以查看链接的文档
目标和策略的细节被记录为标签值。
记录规划项目所需信息的样例模板。
2 、 Owner 所有者 下各包
代表框架的所有者 / 概念行。包括如下内容：
Semantic Data Model
数据地图提供了业务的图像，并使用实体关系图表示。
另一种方法是对概念级类图建模。
Process Analysis Model
下图捕获了业务流程模型，该图是对主要业务活动进行建模。一个流程可能涉及一个较大实体的多个部门或部门。它描述了企业作为其正常活动的一部分所做的事情 ; 主要关注驱动过程的输入、输出、目标和关键事件。
Business Logistics
通信指南和其他相关细节可以在此指定。
企业的业务物流网络表示为一个通信图，详细说明了通信类型，如语音、数据、邮件、互联网以及业务单位之间通信的相关协议和指南。
Work Flow Model
BPMN 图捕获了企业的工作流模型。
Event Schedule
事件进度图为企业的主要业务周期建模。
另一种方法是在没有与事件相关的业务周期时显示事件流。
Business Plan
战略计划有助于制定和管理企业的战略。
包括战略计划和思维导图。
战略计划
思维导图
3 、 Designer 设计师 下各包
表示 Zachman 框架的设计器 / 逻辑行。包括如下内容：
Logical Data Model
逻辑模型捕获平台独立类图。
逻辑数据模型使用类模型表示。这是正在构建的软件系统的逻辑表示。
Application Architecture
应用程序架构捕获每个业务流程的活动和子活动。
它描述业务流程的活动模型。我们用活动图表示
Distribution Sys Design
表示分布式数据系统架构。系统设施，如存储，处理器等可以在这里提到。通常，这是部署图的独立平台表示。
Human I/F Architecture
人机界面架构，可以用 UML 用例来表示。
用例模型是使用 UML 用例描述的系统功能目录。每个用例表示用户或“参与者”在使用系统时所经历的单个、可重复的交互。
一个用例通常包括一个或多个“场景”，描述参与者和系统之间进行的交互，并记录从用户角度发生的结果和异常。
用例可能包括其他用例，作为更大的交互模式的一部分，也可能被其他用例扩展以处理异常情况
Processing Structure
处理结构，我们用状态图，状态转换图对实体状态更改建模，从而捕获完成数据转换的时间。
Business Rule Model
业务规则模型图有助于对从需求模型派生的业务规则进行逻辑表示。
如下业务规则模型是企业中“已执行” / “待执行”业务规则列表。
4 、 Builder 工程师 下各包
表示 Zachman 框架的 build / Physical 行。包括如下内容：
Physical Data Model
物理数据建模在这里完成。 EA 中从类图生成物理模型。
数据库模型描述了作为整个系统设计的一部分必须存储和检索的数据。通常这意味着关系数据库模型，它详细描述了表和数据，并允许生成 DDL 脚本来创建和设置数据库。
这里表示物理数据模型。表、模式和其他存储信息等实体被记录在这里。
System Design
系统设计的技术约束模型描述了程序体系结构。使用平台特定类图。
Technology Architecture
技术架构最好使用详细描述硬件和软件规范的技术特定部署图来表示。
Presentation Architecture
用“用户接口图”来表示。下图表示架构捕获用户界面的屏幕设计和菜单设计。
Control Structure
在控制结构中用“序列图”和“通信图”来表示
控制结构捕获对象之间的交互序列。
这里对具有处理细节的触发器、消息和响应进行了建模。
Rule Design
规则设计捕获将合并到企业操作中的正式规则。
5 、 Subcontractor 分包商下各包
表示 Zachman 框架的 build / Physical 行。包括如下内容：
Data Definition
数据定义可以指向 DDL 脚本、文档、配置文件等的超链接。
Program
链接到代码存储库和配置文件。
Network Architecture
记录网络配置详细信息和协议详细信息。
如下工件可以存储网络规范和配置等细节。
Security Architecture
安全子系统类图和链接到各自的代码。
Timing Definition
调度细节如在线 / 批处理、中断周期和机器周期在这里表示。 UML 时序图用于表示细节。
Rule Specification
规则规范图
6 、 Functioning Enterprise 下各包
代表 Zachman 框架的 functional Enterprise 行。包括如下内容：
Actual Data
代表功能性企业级资源。
Executables
代表功能性企业级功能。实际的可执行程序被记录在这个级别上。
Physical Networks
代表了有效的企业级物理网络。
BusinessUnits
表示功能性企业级业务单元。
Business Schedule
表示功能性企业级业务进度表。
Business Strategy
表示功能性企业级业务策略和规则。
|
17 次
