什么是数据架构?
数据架构解释并支持 企业的数据需求. 它通过 四个要素—数据需求, 主要数据来源, 主要数据类型,以及所需的 数据管理资源.
我们使用四个 企业架构模型 描述您的数据架构 - 主题模型, 主题区域模型, 逻辑数据模型, 和 逻辑文档模型.
数据架构是 信息系统架构. 信息系统架构是一种独特的 架构领域 对齐 功能, 数据, 和 数据管理。实际上,这意味着确保应用程序提供所需的数据流和数据管理,而不仅仅是提供功能。
常见的做法是将数据架构推到幕后。我们痴迷于功能,谈论应用程序——它们能做什么,如何构建,或者如何与其他系统集成。
应用程序的存在是为了处理和管理数据。如果没有对数据架构的深入理解和设计,应用程序就会变成互不相连的孤岛。它们在交付功能的同时,也带来了技术债务。这增加了数据流和数据管理的复杂性。复杂的数据流和数据管理会加速您的技术债务,并增加数据治理的复杂性。
当你以数据为主导,并确保 应用架构 专注于 管理数据资产的应用程序的结构和交互, 您有一个信息系统架构。
没有成功 数字化转型 将基于功能构建。它们始终基于数据构建。
数据需求
一切始于 数据需求 企业的。
数据需求分为三类:
- 数据 需要 创造产品和服务:您的产品和服务所依赖的信息。
- 数据 需要 经营业务:交易、操作和流程数据,确保日常活动顺利进行。
- 数据 需要 保存记录:** 合同和监管规定的合规必需信息。
不要混淆 数据需求 — 你必须无情地分离 很高兴有 从什么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 个业务术语或逻辑数据组件。
逻辑文档属性
文档类型
-
- 记录、商业文件、临时性
数据访问属性
-
- 仅限国家/地区、仅限组织、仅限部门、仅限流程或保管数据
数据保留属性(可选)
-
- 临时、部门、企业、合同、受监管或禁止
数据保护属性(可选)
-
- - 轻松、标准、增强
一切都围绕数据需求
让我们澄清一下 数据需求— 你必须无情地分离 很高兴有 从什么 需要.
所需数据 不需要“绝对需要”或“重要数据”之类的修饰词。“需要”只是“必需”。
明确区分 需要 和 其他一切 是有效应用需求的基础。
一旦你知道某项业务活动需要一些数据,其他一切都会随之而来:
- 来源
- 流动
所需数据定义了流必须到达的位置。 - 质量
所需数据决定质量。 - 安全
安全并不定义数据可以去哪里。需要的数据会去到需要的地方。需要的数据决定了数据 必须 安全送达,并且必须确保安全。 - 数据管理
需求+质量+流量+安全定义所需的数据管理资源
来源是一个挑战——尤其是当供应商和消费者在不同的组织或 权威或治理领域我们常常以为数据消费者定义质量。但事实并非如此。数据生产者定义质量。
消费者可以要求更高的质量,但他们可能面临三种选择:
- 支付更多
- 不用
- 提高自身素质
这与任何其他生产者/消费者关系没有什么不同。
记住:
数据需求在破碎的数据环境中开辟出一条道路。
数据需要打破孤岛。
数据需求驱动真实数据定义
数据需求带来数据治理。