什么是数据架构?
数据架构解释并实现了 企业的数据需求. 它通过 四个要素—数据需求, 主要数据来源, 主要数据类型, ,以及所需的 数据管理资源.
我们使用四个 企业架构模型 描述您的数据架构 - 主题模型, 主题领域模型, 逻辑数据模型, 和 逻辑文档模型.
数据架构是 信息系统架构. 信息系统架构是一种独特的 架构领域 对齐 功能, 数据, 和 数据管理. 。实际上,这意味着确保应用程序提供所需的数据流和数据管理,而不仅仅是提供功能。.
常见的做法是将数据架构推到幕后。我们痴迷于功能,并讨论应用程序——它们的作用是什么,如何构建,或者如何与其他系统集成。.
应用程序的存在是为了处理和管理数据。如果没有对数据架构的深入理解和设计,应用程序就会变成互不相连的孤岛。它们在交付功能的同时,也带来了技术债务。这增加了数据流和数据管理的复杂性。复杂的数据流和数据管理会加速您的技术债务,并增加数据治理的复杂性。.
当你以数据为主导,并确保 应用程序架构 专注于 管理数据资产的应用程序的结构和交互,, 您有一个信息系统架构。.
没有成功 数字化转型 将基于功能构建。它们始终基于数据构建。.
数据需求
一切始于 数据需求 企业的。.
数据需求分为三类:
- 数据 需要 创造产品和服务:您的产品和服务所依赖的信息。.
- 数据 需要 经营业务:交易、操作和流程数据,确保日常活动顺利进行。.
- 数据 需要 保存记录:合同和法规定义的合规所需信息。.
不要混淆 数据需求 — 你必须无情地分离 很高兴有 从什么 n需要.
需要 不需要“绝对”或“重要”之类的修饰语。“需要”只是“必要”。.
主要数据来源
数据在哪里创建、收集,以及在哪里进行转换。数据来自手动流程、应用程序、设备和外部合作伙伴。了解源系统对于数据质量、沿袭和治理至关重要。.
数据管理资源
能够以适当的质量、可信度和安全性,在适当的地点、时间、以适当的方式交付所需数据的工具和系统。实际上,这些是针对应用程序和基础设施架构的一系列广泛要求。.
浏览数据架构模型种类
导航 提供端到端的企业架构全景。这是我们致力于构建端到端模型架构的具体方式。.
我们按照最佳实践来开发 EA Landscape,即每次逐步扩展一个架构项目。.
我们通过离散管理企业模式 模型种类. 模型类型可以支持特定的分析,也可以专注于端到端模型的某个方面。简单来说,模型类型是指特定建模类型的约定。.
每种模型都经过优化,可以告诉我们一些有关架构的信息。.
不同类型的模型将探索:
- 动机和策略
- 架构领域的部分
使用模型种类可以提高一致性和可重用性,从而提高整个 EA 团队的生产力和一致性。.
导航模型种类描述
每种模型类型定义如下:
- 目的:为什么存在这种模型以及它旨在回答什么问题。.
- 范围:概述模型类型中包含和排除的内容的界限。.
- 内容与结构:创建模型类型的实例时应使用的组件、关系和属性。.
- 建模方法:指导如何包含或排除哪些内容,以关注与目标相关的具体方面。.
- (可选)与其他模型类型的关系:描述链接的目的以及使用什么关系来连接两个模型。.
企业数据模型说明
我们从 DAMA 的企业数据模型中汲取了 Navigate 的数据模型类型。企业数据模型由以下部分组成: 主题模型, 主题领域模型(SAM), 和 逻辑数据模型(LDM). 。SAM 和 LDM 均基于主题构建。它们服务于不同但又相互关联的目的。.
这 主题模型 描述组织的数据格局。每个主题对数据格局都有意义。.
这 主题区域模型 是 以业务为中心 视图。它旨在详细理解一个特定的业务领域——"主题"。SAM 以一种业务利益相关者易于理解的方式定义“主题”。它是对数据的叙述,重点关注它所 方法。.
这 逻辑数据模型, ,是一个 技术导向. 。它以 SAM 为基础,从 SAM 的业务概念转变为足够的细节来指导实施。.
SAM 和 LDM 面向两个不同的受众。SAM 反映了业务部门对数据含义的理解。LDM 则为实施提供指导和约束。该框架通常记录在主数据蓝图中。.
SAM 和 LDM 反映同一主题,但面向不同的受众。.
主题模型
主题模型范围
主题模型识别 商业相关 信息区
每个主题都标识了某个活动领域或某个特定操作方面所需的信息
提供一个 共同理解 数据格局
曾经
- 关于数据格局的框架讨论
- 突出显示数据复杂区域
- 直接进一步建模
主题模型指导
企业范围
- 12-20个科目
全部门建筑项目
- 预计 3-5 个科目
转型计划
- 预计 5-10 个主题
主题区域模型
主题区域模型类型 (SAM) 表示单个主题内的信息。SAM 用于确保对数据格局的理解达成共识。.
目的很明确——了解数据格局。.
DAMA 告诉我们要思考定义主题中信息的实体。实体与其他实体之间存在关系。主题内部存在关系,主题与其他主题中的实体也存在关系。.
实体只是表达信息主题的一种数据方式,是一个名词。我们使用“业务术语”组件。.
学科领域模型指导
主题领域模型使用 8-15 个业务术语(实体)来定义主题。此外,还需要 1-2 个来自其他主题的业务术语,以完整理解主题。.
尽量将业务术语控制在 13 个左右。必须确保模型易于管理。.
当你接近 12 个商业术语时,考虑一下是否有多个主题
少于 8 个商业术语表明这可能不是一个深奥或重要的主题。.
逻辑数据模型
逻辑数据模型类型 (LDM) 表示单个主题内的信息,旨在指导和约束实现。LDM 用于确保数据环境的技术处理一致性。.
目的很明确——指导实施,确保数据环境能够支持业务' 数据需求.
逻辑数据模型指南
逻辑数据模型使用 12-20 个逻辑数据组件(实体)。预计其他主题将包含 3-5 个逻辑数据组件。.
LDM 必须 包括基本关系、属性以及数据访问和数据管理架构规范
逻辑数据属性
数据访问
-
- 此实体是否有特定的访问限制
数据分类
-
- 它属于哪一类数据?(主数据、参考数据、交易数据)
数据保留
-
- 它有特殊的保留要求吗?这些要求从何而来?
数据类型
-
- 它是什么类型的数据?(数字、文本、布尔值、计算)
数据保护属性(可选)
-
- 数据是否有意外的保护需求?
逻辑文档模型
逻辑文档模型类型的存在是为了表示与特定业务活动(例如,报价单、销售订单、发票、提单、工作申请)相关的工件,例如表格、信函或报告。.
它提供数据上下文,有助于理解数据安全、保留、流动和治理。例如,以下数据实体 价格 不传达保留或安全要求,而像 引述, 销售订单, 和 发票 提供该背景。.
逻辑文档涵盖三种文档类型:
- 记录:法律或合同规定的文件,具有外部定义的内容和保留要求。.
- 商业文件:内部定义的支持业务流程的文档,由组织政策管理以确保一致性和可审计性。.
- 临时文件:由个人或团队创建和使用的非正式文档,其保留由内部政策管理并与创建者的需求保持一致。.
逻辑文档模型指南
当考虑端到端业务流程时,逻辑文档模型最为简单。端到端流程通常使用 3-10 个逻辑文档。.
目标是达到 6 个左右的逻辑文档。您正在寻找完整的 记录, 以及一份有用的清单 商业文件 和 临时文件 以获得保留、安全性和质量。.
每个逻辑文档将包含 5-10 个业务术语或逻辑数据组件。.
逻辑文档属性
文档类型
-
- 记录、商业文件、临时性
数据访问属性
-
- 仅限国家/地区、仅限组织、仅限部门、仅限流程或保管数据
数据保留属性(可选)
-
- 临时、部门、企业、合同、受监管或禁止
数据保护属性(可选)
-
- - 轻松、标准、增强
一切都围绕数据需求
让我们澄清一下 数据需求— 你必须无情地分离 很高兴有 从什么 需要.
所需数据 不需要“绝对需要”或“重要数据”之类的修饰词。“需要”只是“必需”。.
明确区分 需要 和 其他一切 是有效应用需求的基础。.
一旦你知道某项业务活动需要一些数据,其他一切都会随之出现:
- 来源
- 流动
所需数据定义了流必须到达的位置。. - 质量
所需数据决定质量。. - 安全
安全并不定义数据可以去哪里。需要的数据会去到需要的地方。需要的数据决定了数据在哪里 必须 安全送达,并且必须确保安全。. - 数据管理
需求+质量+流量+安全定义所需的数据管理资源
来源是一个挑战——尤其是当提供者和消费者在不同的组织或 权威或治理领域. 我们常常以为数据消费者定义质量。但事实并非如此。数据生产者定义质量。.
消费者可以要求更高的质量,但他们可能面临三种选择:
- 支付更多
- 不用
- 提高自身素质
这与任何其他生产者/消费者关系没有什么不同。.
记住:
数据需求推动着一条穿越破碎数据格局的道路。.
数据需要打破孤岛。.
数据需求驱动真实数据定义
数据需求带来数据治理。.
什么是数据架构?的结论
数据架构引领 信息系统架构. 信息系统架构是 架构领域 对齐 数据, 数据管理, 和 功能.
数据架构解释并实现了 企业的数据需求 通过 四个要素—数据需求, 主要数据来源, 主要数据类型, ,以及所需的 数据管理资源.
四 企业架构模型 描述您的数据架构: 主题模型, 主题领域模型, 逻辑数据模型, 和 逻辑文档模型.
常见的做法是将数据架构推到后台,并将焦点放在应用程序上——它们的作用、如何构建或如何与其他系统集成。.
最佳实践以数据为主导,并确保 应用程序架构 专注于 管理数据资产的应用程序的结构和交互.
没有成功 数字化转型 将基于功能构建。它们始终基于数据构建。.