「企业架构」Zachman框架简介

简介: 「企业架构」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框架的规则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zachman框架是如何使用的,在哪里使用的?

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

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

John Zachman认为框架被用作:

  1. 一个计划工具-帮助你定位问题并做出明智的选择。
  2. 一个解决问题的工具——控制业务抽象的复杂性,实现单个业务变量的隔离。
  3. 通过将工具和方法映射到框架来评估它们,从而证明一种中立的方式来对它们所做和不支持的事情进行编目。
  4. 用于构建灵活的组件架构和系统的上下文,这些架构和系统能够支持高比率的企业更改,并替换由于“上下文外”而“未集成”的“现有系统的库存”

将Zachman框架付诸实践。

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

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

相关文章
|
28天前
|
数据采集 监控 前端开发
二级公立医院绩效考核系统源码,B/S架构,前后端分别基于Spring Boot和Avue框架
医院绩效管理系统通过与HIS系统的无缝对接,实现数据网络化采集、评价结果透明化管理及奖金分配自动化生成。系统涵盖科室和个人绩效考核、医疗质量考核、数据采集、绩效工资核算、收支核算、工作量统计、单项奖惩等功能,提升绩效评估的全面性、准确性和公正性。技术栈采用B/S架构,前后端分别基于Spring Boot和Avue框架。
|
11天前
|
存储 分布式计算 关系型数据库
架构/技术框架调研
本文介绍了微服务间事务处理、调用、大数据处理、分库分表、大文本存储及数据缓存的最优解决方案。重点讨论了Seata、Dubbo、Hadoop生态系统、MyCat、ShardingSphere、对象存储服务和Redis等技术,提供了详细的原理、应用场景和优缺点分析。
|
17天前
|
监控
SMoA: 基于稀疏混合架构的大语言模型协同优化框架
通过引入稀疏化和角色多样性,SMoA为大语言模型多代理系统的发展开辟了新的方向。
29 6
SMoA: 基于稀疏混合架构的大语言模型协同优化框架
|
1月前
|
运维 供应链 安全
SD-WAN分布式组网:构建高效、灵活的企业网络架构
本文介绍了SD-WAN(软件定义广域网)在企业分布式组网中的应用,强调其智能化流量管理、简化的网络部署、弹性扩展能力和增强的安全性等核心优势,以及在跨国企业、多云环境、零售连锁和制造业中的典型应用场景。通过合理设计网络架构、选择合适的网络连接类型、优化应用流量优先级和定期评估网络性能等最佳实践,SD-WAN助力企业实现高效、稳定的业务连接,加速数字化转型。
SD-WAN分布式组网:构建高效、灵活的企业网络架构
|
17天前
|
Kubernetes Cloud Native 云计算
云原生技术深度解析:重塑企业IT架构的未来####
本文深入探讨了云原生技术的核心理念、关键技术组件及其对企业IT架构转型的深远影响。通过剖析Kubernetes、微服务、容器化等核心技术,本文揭示了云原生如何提升应用的灵活性、可扩展性和可维护性,助力企业在数字化转型中保持领先地位。 ####
|
17天前
|
运维 Cloud Native Devops
云原生架构:重塑企业IT的未来####
随着数字化转型浪潮的汹涌,云原生架构凭借其高度灵活、可扩展和高效的特性,正逐步成为企业IT系统的核心。本文将深入探讨云原生架构的核心要素、技术优势以及如何引领企业实现业务创新与敏捷交付。 ####
|
1月前
|
Cloud Native Devops 持续交付
云原生架构:重塑企业IT的无形之手####
本文旨在探讨云原生架构如何成为推动企业数字化转型的核心动力,它不仅是一种技术升级,更是业务与开发模式的深刻变革。通过剖析云原生的核心要素——微服务、容器化、持续集成/持续部署(CI/CD)、以及DevOps文化,本文揭示了这一架构如何提升系统的弹性、可扩展性和敏捷性,为企业在竞争激烈的市场环境中赋予快速响应和创新的能力。不同于传统综述,本文将以一个虚构案例贯穿始终,直观展示云原生架构从理论到实践的转化过程,为读者提供一幅生动的技术蓝图。 --- ###
|
14天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
12天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
12天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
30 1
服务架构的演进:从单体到微服务的探索之旅
下一篇
无影云桌面