引言

数据架构师最怕什么？ 可能是面对空白画板时的无从下手。

在TOGAF架构方法中，数据架构（C阶段）是连接业务与技术的重要桥梁，但TOGAF本身并没有给出标准画法，只是描述了应该包含哪些制品。

本文将系统拆解TOGAF数据架构的16种核心图表，教你如何从一张白纸到专业图表，让你的数据架构文档既专业又直观，帮你在数据架构师的道路上少走5年弯路。

近1年AI突飞猛进，在各种AI特别是Claude的助力下，我终于可以把TOGAF提到的16种数据架构图全部重新演绎了一遍，这次效果超出意外的好。

TOGAF数据架构制品概览

在TOGAF中，架构制品主要分为三种类型：

✅ 目录（Catalogs）：特定类型构建块的列表，用于治理或参考目的

✅ 矩阵（Matrices）：显示两个或多个模型实体之间关系的网格

✅ 图表（Diagrams）：以图形格式呈现架构内容，使利益相关者能够检索所需信息

为了更实用，我们不按类型，而是按用途将16种图表分为四大类：

一、数据基础描述类图表 📊

这类图表解决的核心问题是"我们有什么数据"和"数据之间是什么关系"，是其他所有图表的基础。

1️⃣ 数据实体/数据组件目录

核心价值： 相当于企业的"数据资产清单"，展示企业拥有哪些核心数据以及它们的组成部分。

关键元素：

• 数据实体列表（如客户、产品、账户）
• 数据组件列表（每个实体的子分类）
• 描述（每个实体和组件的简要说明）
• 业务所有者（负责管理该数据的部门）

画法步骤：

1. 识别企业的核心数据实体（通常不超过10个）
2. 为每个实体确定2-5个关键数据组件
3. 创建表格格式，实体作为主行，组件作为子行
4. 添加描述和所有者信息

应用案例：

下面是一个金融企业的数据实体/数据组件目录示例：

我们可以看到金融企业的7个核心数据实体：客户、账户、交易、产品、风险、财务和合规。这些实体代表了金融业务中最基本的业务概念。

每个数据实体下都有多个数据组件。例如，"产品"实体细分为存款产品、贷款产品、投资产品和保险产品。这种分解帮助我们理解数据的逻辑结构。

业务所有者列标明了哪个部门负责这些数据的维护和管理。例如，"客户"实体由客户关系部负责，"风险"实体由风险管理部负责。这反映了数据治理的责任分配。

上手技巧： 不要一开始就尝试穷尽所有数据，先找出企业最关键的5-7个数据实体。想象你在向非技术高管解释"我们公司核心关注哪些数据"，这些就是你的核心数据实体。

2️⃣ 数据实体目录

核心价值： 数据实体的"身份证"，详细说明每个数据实体的属性、特性和管理要求。

关键概念：

• 数据实体：表示企业中具有业务意义的信息对象，是业务概念的数据表达
• 数据分类：将数据实体按照不同标准（如敏感性、重要性、来源等）进行分类
• 数据所有者与数据管理员：分别是对数据质量和使用负最终责任的业务部门高管，和负责日常数据管理的人员

画法步骤：

1. 从数据实体/数据组件目录中选取核心实体
2. 为每个实体创建详细属性表，包括：详细描述、业务重要性、数据分类、数据所有者、数据管理员和保留要求
3. 与业务所有者确认每个属性的正确性
4. 形成标准化的实体目录文档

应用案例：

下面是一个金融企业的数据实体目录示例：

示例展示了一家金融企业的四个核心数据实体：客户、账户、交易和产品。让我们深入分析这些实体的特点和管理要求：

客户实体

客户实体被分类为"主数据"，这意味着它是企业最基础、最重要的数据资产之一。它的业务重要性为"关键"，表明它直接影响企业的核心业务能力。客户数据需要在客户关系终止后保留7年，这是典型的金融监管要求。

所有者和管理员的明确分工反映了数据治理的层次结构：客户关系部主管承担总体责任，而专门的客户数据管理团队负责日常管理。

账户实体

账户实体被分类为"交易数据"，与客户的各种金融活动直接相关。它的保留期限比客户数据更长（10年），这反映了金融交易记录的监管要求更为严格。

交易实体

交易实体同样被分类为"交易数据"，它记录了所有金融活动的历史。交易数据的保留要求为7年，但注明可能根据监管要求延长，这体现了数据管理对法规的响应性。

产品实体

产品实体也被分类为"主数据"，它定义了金融机构提供的所有产品和服务。有趣的是，产品数据的保留要求包括"历史版本永久保存"，这反映了对产品变更历史的追溯需求，对于合规审计和客户纠纷解决非常重要。

上手技巧： 先做一个实体的完整目录作为模板，然后复制这个结构来处理其他实体，保持格式一致。与业务部门访谈时，重点确认"业务重要性"和"保留要求"这两项。

3️⃣ 业务数据目录

核心价值： 从业务视角描述数据资产，关注数据如何支持业务流程和业务功能，而不是数据的技术特性。

关键概念：

• 业务数据：从业务视角定义的数据，重点关注其在业务中的应用和价值，而非技术结构
• 信息类别：数据根据其使用目的和性质的分类，例如"客户分析信息"、"产品开发信息"等
• 数据价值：数据对业务的重要程度和贡献，可能是货币价值、战略价值或操作价值

画法步骤：

1. 与业务部门一起确定关键业务数据类别
2. 映射每个类别支持的主要业务流程
3. 定义如何衡量每类数据的业务价值
4. 确定数据的使用者和质量要求

应用案例：

下面是一个金融企业的业务数据目录示例：

上面的示例展示了一家金融企业的业务数据目录，它从业务视角对数据进行分类。让我们深入分析这个案例：

客户洞察数据

这类业务数据主要用于客户细分和个性化营销等活动。它被多个业务部门（市场部、销售部、客户关系管理部）共同使用，这反映了数据在组织中的横向流动。其价值通过客户获取成本降低、客户终身价值提升等具体业务指标来衡量。

与数据实体目录不同，这里不关注数据的技术结构，而是聚焦于数据如何支持业务活动和创造价值。

风险评估数据

这类业务数据服务于贷款审批、信用评分等风险管理流程。它的价值直接体现在风险指标改善上，如坏账率降低和欺诈损失减少。风险管理部、合规部和信贷部共同负责这些数据，反映了数据责任的分布式特性。

财务绩效数据与产品绩效数据

这两类业务数据分别支持财务管理和产品管理的核心流程，它们的价值衡量也聚焦于相应的业务领域。例如，财务绩效数据通过财务报告准确性等指标衡量价值，而产品绩效数据则关注产品盈利能力和市场份额等。

上手技巧： 与业务用户交流时，不要使用"数据实体"这样的技术术语，而是问"你们团队依赖哪些关键信息来做决策"。这样能获得更真实的业务数据视角。

4️⃣ 数据实体/关系图

核心价值： 展示企业核心数据之间的关联关系，是理解数据内在结构的基础。

关键概念：

• 数据实体：企业中被识别为离散概念的数据封装，代表企业关心的业务对象
• 属性：描述数据实体特征的数据元素，如客户实体可能包含姓名、地址、电话等
• 关系：数据实体之间的关联，可以是一对一、一对多或多对多关系
• 基数：描述关系中实体间联系的数量约束

画法步骤：

1. 绘制核心数据实体的矩形框
2. 确定实体间的关系类型
3. 用适当的连线表示关系（带箭头方向和标记）
4. 在每个实体中列出3-5个最重要的属性
5. 为每个关系添加业务含义描述（如"下单"、"包含"）

应用案例：

下面是一个零售企业数据实体/关系图示例：

上图展示的零售企业数据实体/关系模型包含了零售业务的核心实体及其关系：

• 客户实体：存储客户的基本信息，包括唯一标识符、姓名和联系方式
• 产品实体：记录商品信息，包括产品ID、名称、价格和库存量
• 订单实体：记录销售交易，关联客户ID作为外键，包含订单日期和总金额
• 订单明细实体：作为订单和产品间的关联实体，记录每个订单中的具体商品项目
• 门店实体：记录实体店铺信息，包括门店ID、名称和地址
• 员工实体：存储员工信息，包括员工ID、姓名，并关联所属门店

这些实体通过以下关系连接：

• 客户-订单：一对多"下单"关系，一个客户可以下多个订单
• 订单-订单明细：一对多"包含"关系，一个订单包含多个订单项
• 产品-订单明细：一对多"订购"关系，一种产品可以出现在多个订单项中
• 门店-订单：一对多"处理"关系，一个门店可以处理多个订单
• 门店-员工：一对多"雇佣"关系，一个门店可以雇佣多名员工
• 员工-订单：一对多"负责"关系，一名员工可以负责多个订单

上手技巧： 先画出核心实体和最明显的关系，再逐步添加细节。避免一个图中放太多实体（最好不超过10个），否则会难以阅读。对于复杂系统，考虑按业务领域创建多个ER图。

5️⃣ 类层次结构图

核心价值： 从面向对象的视角展示数据结构的技术实现，为技术团队提供数据模型的详细结构视图。

关键概念：

• 类（Class）：代表一组具有相同属性、方法和关系的对象
• 继承（Inheritance）：表示子类继承父类特性的关系
• 关联（Association）：表示类之间的一般关系，可以是单向或双向的
• 聚合（Aggregation）与组合（Composition）：表示"整体-部分"关系，区别在于部分对整体的依赖程度

画法步骤：

1. 确定数据模型中的主要类
2. 识别类之间的继承层次结构
3. 添加每个类的关键属性和方法
4. 绘制类之间的关系线（继承、关联、聚合或组合）
5. 添加关系的方向和多重性标记

应用案例：

下面是一个金融企业的类层次结构图示例：

以上展示的金融企业数据类层次结构图是从面向对象的视角展示数据模型的典型案例。让我们深入分析这个图表：

类的继承层次结构

图表展示了一个清晰的账户类层次结构：

• Account 作为抽象基类，定义了所有账户类型共有的属性（账户ID、余额、开户日期）和方法（获取余额、更新余额）
• 三个具体子类 SavingsAccount（储蓄账户）、 CheckingAccount（支票账户）和 LoanAccount（贷款账户）继承了基类，并添加了特定的属性和方法

这种继承结构体现了面向对象设计中的"是一种"关系，并通过代码重用实现了系统的高效设计。

类之间的关系

图表展示了几种不同类型的关系：

• 聚合关系： Customer（客户）和 Account（账户）之间的聚合关系表明客户拥有多个账户（1..），而一个账户可以属于零个或多个客户（0..）
• 关联关系： Transaction（交易）和 Account（账户）之间的关联表明交易操作账户，一个账户可以有多个交易记录，而每个交易记录对应一个账户
• 关联关系： Product（产品）和 Account（账户）之间的关联表明产品定义账户，一个产品可以定义多个账户，而每个账户由一个产品定义

这些关系反映了数据实体之间的业务规则和依赖。

类的结构和职责

每个类都清晰地展示了其属性和方法：

• 属性：使用 - 前缀表示私有属性，描述了类的数据内容
• 方法：使用 + 前缀表示公开方法，描述了类可执行的操作
• 可见性：通过 + 和 - 符号区分了公开和私有成员

例如， Transaction 类包含了交易ID、时间戳和金额等属性，以及处理交易和撤销交易等方法，明确定义了交易数据的结构和行为。

上手技巧： 这个图主要面向技术团队，确保使用标准UML符号。对于初学者，先关注类之间的关系，随后再丰富属性和方法的细节。对于继承关系，确保遵循"是一种"的原则（如储蓄账户"是一种"账户）。

二、数据映射与关联类图表 🔄

这类图表解决的核心问题是"数据与业务/系统之间是什么关系"，帮助理解数据的使用和管理责任。

6️⃣ 数据实体/业务功能矩阵

核心价值： 映射数据实体与业务功能之间的关系，清晰展示"哪些业务功能使用哪些数据"以及"如何使用这些数据"。

关键概念：

• 业务功能：企业为实现其目标而执行的活动集合，描述的是"企业做什么"
• CRUD操作：创建(Create)、读取(Read)、更新(Update)和删除(Delete)数据的操作方式
• 数据所有权：指示哪个业务功能对特定数据实体的创建和维护负主要责任

画法步骤：

1. 从数据实体目录获取实体列表作为行
2. 从业务架构获取业务功能列表作为列
3. 与业务人员一起确定每个交叉点的CRUD操作
4. 标识每个数据实体的主要所有者（负责创建和维护的业务功能）
5. 使用颜色编码突出显示重要关系

应用案例：

下面是一个金融企业的数据实体/业务功能矩阵示例：

以上展示的金融企业数据实体/业务功能矩阵清晰地映射了数据实体与业务功能之间的关系。让我们分析这个矩阵的关键见解：

数据所有权模式

矩阵明确标示了每个数据实体的主要所有者（蓝色底色的单元格）。例如：

• 客户管理功能拥有客户数据
• 产品管理功能拥有产品数据和市场数据
• 风险管理功能拥有风险数据和合规数据
• 财务管理功能拥有账户数据、交易数据、财务数据和员工数据
• 渠道管理功能拥有渠道数据

这种所有权模式清晰地划分了数据责任边界，避免了"数据无主"或"多头管理"的问题。

跨功能数据使用

矩阵也显示了数据如何被多个业务功能共享和使用：

• 客户数据被所有业务功能读取，反映了其在整个企业中的核心地位
• 产品数据同样被大多数功能使用，但主要由产品管理创建和维护
• 财务数据主要由财务管理创建和管理，产品管理和风险管理只读取这些数据

这种视图有助于识别数据共享和集成的需求，优化数据流动。

访问权限差异

不同业务功能对同一数据实体的访问权限不同：

• 对于交易数据，财务管理有完整的CRUD权限，渠道管理可以创建和读取，风险管理可以读取和更新，而其他功能只能读取
• 对于风险数据，风险管理拥有完整权限，客户管理、产品管理和财务管理只能读取，渠道管理则完全不访问

这种权限差异反映了数据安全和访问控制的要求，为系统实现提供了指导。

上手技巧： 矩阵可能会很大，先关注最核心的业务功能和数据实体，创建一个小型矩阵，然后再扩展。使用颜色编码（如CRUD操作用不同颜色）可以大大提高可读性。

7️⃣ 应用程序/数据矩阵

核心价值： 映射企业应用程序与数据实体之间的关系，展示"哪些应用系统访问哪些数据"以及"如何访问这些数据"。

关键概念：

• 应用程序：企业内部署的软件系统，用于支持特定业务功能或流程
• 主系统：对特定数据实体有创建和主要维护责任的应用系统，通常被视为该数据的"系统记录"
• 接口需求：应用之间需要建立接口或集成的地方，特别是当一个应用需要访问由另一个应用创建和维护的数据时

画法步骤：

1. 从系统目录获取应用系统列表作为列
2. 从数据实体目录获取实体列表作为行
3. 确定每个交叉点的CRUD操作
4. 标识每个数据实体的系统记录（负责创建和主要维护的系统）
5. 使用颜色或特殊符号突出显示关键关系

应用案例：

下面是一个金融企业的应用程序/数据矩阵示例：

以上展示的金融企业应用程序/数据矩阵清晰地展示了系统与数据之间的关系。让我们深入分析这个矩阵的关键洞察：

系统责任分配

矩阵明确标示了每个数据实体的系统记录（蓝色底色的单元格）：

• CRM系统是客户数据的主要所有者
• 核心银行系统负责账户和产品数据
• 支付系统是交易数据的系统记录
• 风险管理系统管理风险数据和市场数据
• 财务系统负责财务数据和员工数据
• 网银平台管理渠道数据
• 合规监控系统负责合规数据

这种明确的责任分配有助于确保数据质量和数据治理的有效实施。

数据访问模式

矩阵揭示了不同应用系统的数据访问模式：

• 客户数据被几乎所有系统读取，显示它的广泛使用性
• 核心银行系统和支付系统访问大量数据实体，反映它们的核心地位
• 风险管理系统访问各类风险相关数据，但不参与操作性交易
• 移动银行和网银平台主要访问与客户交互相关的数据

这种访问模式有助于系统间接口设计和数据权限规划。

系统集成需求

通过分析矩阵中的"R"和"U"标记，可以识别出系统间需要建立接口的地方：

• 所有系统都需要与CRM系统集成以获取客户数据
• 财务系统需要与核心银行系统和支付系统集成以获取账户和交易数据
• 风险管理系统需要与多个系统集成以获取全面风险视图
• 合规监控系统需要广泛访问各系统数据以执行监控职能

这些集成需求是应用架构设计的重要输入。

数据流向分析

通过观察谁创建、谁读取、谁更新数据，可以看出企业内部数据的主要流向：

• 客户数据主要由CRM系统创建，流向其他系统
• 交易数据由多个渠道（核心银行、网银、移动银行）创建，最终由支付系统处理和管理
• 财务数据由财务系统创建和管理，少数系统只需要读取
• 合规数据由合规监控系统创建，风险管理系统可以更新

了解这些数据流向对于企业架构规划和变更管理至关重要。

上手技巧： 这个矩阵是识别数据冗余和集成问题的强大工具。特别关注多个系统都标有"C"（创建）的行，这可能表明数据重复或不一致问题。与系统架构师和开发团队一起验证矩阵的准确性。

8️⃣ 数据实体/业务服务矩阵

核心价值： 将数据实体与企业提供的业务服务之间的关系可视化，比业务功能矩阵更细粒度。

关键概念：

• 业务服务：企业提供给客户或内部利益相关者的明确定义、边界清晰的服务，与业务功能不同
• 关键性：表示数据对业务服务的重要程度，可能标记为"关键"、"重要"或"次要"
• 服务边界：通过矩阵可以清晰看到业务服务的数据边界，即服务需要访问哪些数据才能完成其职责

画法步骤：

1. 确定企业提供的关键业务服务列表作为列
2. 使用数据实体列表作为行
3. 确定每个交叉点的CRUD操作
4. 为每个数据实体标注对服务的重要性级别（可用颜色区分）
5. 识别每个数据实体的负责服务

应用案例：

下面是一个金融企业的数据实体/业务服务矩阵示例：

以上展示的金融企业数据实体/业务服务矩阵提供了业务服务与数据实体之间关系的详细视图。让我们分析这个矩阵的主要见解：

数据关键性分类

矩阵使用颜色区分了数据对各业务服务的重要程度：

• 红色背景表示关键数据，这些数据对服务的正常运行至关重要
• 黄色背景表示重要数据，虽非必不可少，但对服务质量有显著影响
• 无背景表示一般数据，对服务有用但非核心依赖

这种分类有助于确定数据保护和恢复的优先级，以及服务设计中的关注重点。

服务数据边界

通过分析每个服务列，可以清晰看到各业务服务的数据需求边界：

• 账户开户服务主要处理客户、账户和文档数据
• 贷款申请服务核心依赖客户、账户、风险和文档数据
• 资金转账服务关键依赖账户和交易数据
• 客户咨询服务主要使用客户、渠道、员工和文档数据
• 投资管理服务需要客户、账户、交易、风险和市场数据
• 欺诈检测服务关注交易、风险和合规数据
• 监管报告服务主要处理财务、合规和服务水平数据
• 产品营销服务依赖产品、渠道和市场数据

这种边界定义有助于服务设计和微服务划分。

数据责任分配

矩阵中的CRUD标记，特别是红色加粗的CRUD，表明了哪个服务对特定数据具有主要责任：

• 账户开户服务负责创建和维护初始客户和账户数据
• 资金转账服务负责交易数据的完整生命周期
• 投资管理服务负责投资相关的风险数据
• 监管报告服务负责合规数据和服务水平数据
• 产品营销服务负责产品数据和市场营销数据

这种责任分配确保每个数据实体都有明确的"主人"，避免数据治理混乱。

服务间数据共享模式

矩阵还揭示了服务之间的数据共享需求：

• 客户和账户数据几乎被所有服务使用，表明它们是核心共享数据
• 文档数据被多个服务创建和管理，需要特别关注文档版本控制和共享机制
• 风险数据在贷款申请、投资管理和欺诈检测服务之间共享，需要考虑风险评估的一致性
• 合规数据在多个服务间需要更新，表明合规控制是跨服务的共同责任

这些共享模式指导了服务间集成和数据同步策略的设计。

上手技巧： 这个矩阵特别适用于服务导向架构或微服务架构设计。在定义服务边界时，尽量让每个数据实体主要由一个服务负责，减少数据所有权冲突。

9️⃣ 业务服务/信息图

核心价值： 直观展示业务服务需要什么信息以及产生什么信息，以图形方式表达业务服务与信息之间的关系。

关键概念：

• 业务服务：企业向客户或内部利益相关者提供的、有明确边界的服务
• 信息类别：业务需要的信息集合，通常从数据实体中提炼出来，但更关注业务含义
• 信息流：表示信息如何被业务服务使用，包括信息的创建、消费和更新过程
• 信息依赖：表示业务服务对信息的依赖程度和性质

画法步骤：

1. 绘制核心业务服务及其边界
2. 识别每个服务需要的输入信息和产生的输出信息
3. 使用箭头展示信息流动方向
4. 标注关键信息依赖（如"必需"、"可选"）
5. 用不同颜色区分不同类型的信息或不同级别的重要性

应用案例：

下面是一个金融企业的业务服务/信息图示例：

上面展示的金融企业业务服务/信息图直观地表达了四个关键业务服务及其所需信息。让我们深入分析这个图表：

服务边界和职责

图表使用不同颜色的虚线框清晰地划分了四个业务服务领域：

• 蓝色区域：贷款申请服务，负责处理贷款申请的整个流程
• 绿色区域：风险管理服务，负责各类风险评估和合规检查
• 橙色区域：投资管理服务，负责客户投资组合的管理和优化
• 紫色区域：报告和分析服务，负责财务报告和业绩分析

这种可视化边界帮助理解每个服务的职责范围和专注领域。

信息依赖关系

图表中的箭头展示了信息如何在服务内部和服务之间流动：

• 红色箭头表示关键信息依赖，例如贷款申请服务对信用风险信息的依赖，这些依赖对业务至关重要
• 灰色箭头表示一般信息流动，如报告服务从各业务领域获取数据
• 斜体文本说明了信息流的性质，如"需要信用评估"、"接收风险评估"等

这些信息流帮助我们理解服务之间的协作方式和依赖程度。

信息聚合模式

通过观察信息实体的排列和流向，可以看出信息如何被聚合处理：

• 在贷款服务中，客户信息和产品信息共同流向贷款申请信息，形成完整的申请
• 在风险管理服务中，信用风险和监管要求共同影响风险评估结果
• 在投资服务中，产品信息和市场数据共同影响投资组合信息
• 在报告服务中，各类数据最终汇聚到业绩分析信息

这种聚合模式揭示了信息的转化和增值过程。

跨服务关键依赖

图表特别强调了几个跨服务的关键依赖：

• 贷款和投资服务都严重依赖风险管理服务的风险评估
• 风险管理服务与报告服务之间有强依赖关系，特别是在监管合规方面
• 投资服务向报告服务提供多种数据输入，支持绩效分析

识别这些关键依赖有助于理解服务间的协作重点和可能的风险点。

上手技巧： 这个图表特别适合与业务利益相关者沟通。使用业务术语而非技术术语，关注信息的业务意义而非技术结构。每个图最好聚焦于2-4个相关业务服务，避免过于复杂。

三、数据流动与分布类图表 🌊

这类图表解决的核心问题是"数据如何流动和分布"，帮助优化数据流动路径和存储位置。

1️⃣0️⃣ 数据流图

核心价值： 通过图形化方式展示数据在系统或业务流程中如何移动、处理和存储。

关键概念：

• 外部实体：系统外部与系统交换数据的人、组织或其他系统，是数据的来源或目的地
• 处理过程：对数据执行转换、计算或处理的功能或活动
• 数据存储：系统中存储数据的位置，可以是文件、数据库或其他存储形式
• 数据流：表示数据在系统组件之间移动的路径

画法步骤：

1. 先创建上下文图（0级图），显示系统与外部实体的交互
2. 展开主要处理过程，创建一级图
3. 定义数据流的内容和方向
4. 识别数据存储位置
5. 根据需要继续细化为二级图

应用案例：

下图展示了一个零售订单处理系统的一级数据流图。

以下是基于上述数据流图开展的一个电子商务平台订单处理系统优化项目案例：

背景和挑战： 某中型电子商务企业面临订单处理效率低下、订单状态追踪困难、库存管理不准确以及客户满意度下降等问题。随着业务量的增长，这些问题日益严重，导致了高达15%的订单履行错误率和平均2天的订单处理延迟。企业决定通过系统分析和优化解决这些问题。

数据流分析发现的问题：

1. 订单接收与验证流程：

• 客户订单数据重复收集，增加了处理时间

• 产品信息查询效率低下，导致订单确认延迟

• 缺乏实时客户数据验证，导致地址错误和订单退回

• 库存检查流程：

• • 库存数据更新不及时，导致"假缺货"或超卖情况

  • 补货请求流程手动触发，延迟库存补充

  • 缺乏与供应商的自动化数据交换接口

• 支付处理流程：

• • 支付网关集成不完善，导致交易失败率高

  • 支付记录与订单数据未实时同步

  • 多渠道支付方式处理逻辑不一致

• 订单履行流程：

• • 订单数据库与仓储系统之间存在数据延迟

  • 订单拆分和合并能力有限，影响履行效率

  • 缺乏优先级处理机制，导致重要订单延迟

• 配送管理流程：

• • 物流公司数据交换方式不标准，需要手动录入

  • 配送状态更新滞后，影响客户跟踪体验

  • 配送异常处理流程不明确

  系统优化方案

  基于数据流图分析，团队实施了以下优化措施：

  1. 订单接收与验证优化：

  • 实现客户注册用户的自动信息填充，减少数据输入错误

  • 建立产品目录缓存机制，提升产品信息查询速度

  • 引入地址验证API，实时验证配送地址有效性

• 库存检查优化：

• • 实现产品预留机制，在订单确认时临时锁定库存

  • 建立库存阈值自动触发的补货流程

  • 开发与主要供应商的XML/API数据交换接口

• 支付处理优化：

• • 重构支付网关集成架构，支持多种支付方式

  • 建立支付状态实时回调机制

  • 引入支付重试和异常处理流程

• 订单履行优化：

• • 开发智能订单分配算法，基于订单类型和优先级分配资源

  • 实现订单状态实时更新机制

  • 建立订单异常监控和预警系统

• 配送管理优化：

• • 标准化与主要物流公司的数据交换接口

  • 实现配送状态实时推送机制

  • 开发配送异常自动处理和客户通知流程

  上手技巧： 遵循DFD的平衡原则 - 高级图中流入的数据应该在低级图中保持平衡。从0级图开始，然后根据需要逐步细化。避免在一个图中放置过多处理过程（通常不超过7-9个），保持图表清晰易读。

  1️⃣1️⃣ 数据分发图

  核心价值： 展示数据如何在企业的各个系统、应用和位置之间流动和分布，帮助企业理解和优化其数据流转网络。

  关键概念：

  • 数据节点：企业中存储、处理或使用数据的位置
  • 权威数据源：特定数据实体的主要来源或"真相单一源头"
  • 数据复制：在不同节点间复制数据的过程，包括单向复制、双向同步和广播复制
  • 复制策略：定义何时、如何进行数据复制的规则，如实时同步、定期批量同步或按需同步

  画法步骤：

  1. 确定主要数据存储和处理节点
  2. 按地理位置或组织边界划分区域
  3. 绘制数据在节点间的流动路径
  4. 使用不同类型的线条表示不同的同步策略
  5. 添加数据量和频率信息

  应用案例：

  下面是一个企业数据分发图示例：

  

  以上展示的企业数据分发图展现了一个典型的多层次企业数据架构，包括总部、区域中心和分支机构。这种架构在大型企业（如跨国公司、连锁零售、银行等）中很常见。让我们深入分析这个例子：

  数据分层架构

  图表清晰地展示了三层数据架构：

  • 总部数据中心（蓝色区域）：包含企业级数据管理系统，如主数据管理系统（作为权威数据源）、企业数据仓库和企业服务总线
  • 区域数据中心（绿色区域）：包括区域业务系统和区域数据湖，处理特定地区的数据需求
  • 分支机构（黄色区域）：包含本地业务系统，直接支持分支机构的日常运营

  这种分层结构平衡了集中管理和本地自主性，适应全球分布式企业的需求。

  数据流动和同步策略

  图表通过不同类型的线条和箭头展示了不同的数据同步策略：

  • 实时同步（红色线条）：用于关键数据的即时更新，如主数据到企业服务总线和数据仓库的同步，以及区域业务系统到区域数据湖的同步
  • 批量同步（蓝色线条）：用于大量数据的定期传输，如企业服务总线到区域业务系统的每日同步，以及区域数据湖到企业数据仓库的每周同步
  • 按需同步（绿色线条）：用于非常规、事件驱动的数据传输，如区域系统到分支机构的数据下发
  • 双向同步（双箭头）：表示两个节点间的双向数据交换，如区域系统B和分支机构3之间

  这些不同的同步策略反映了对数据及时性、网络带宽和系统负载的平衡考虑。

  数据流量和规模

  图表通过小标签显示了主要数据流的数据量：

  • 总部系统间的数据流量相对较大（3-5GB/天）
  • 区域系统与总部之间的数据交换更为庞大（12-15GB/天）
  • 分支机构的数据流量相对较小（2GB/天）

  这些数据量信息有助于网络容量规划和性能优化。

  权威数据源和数据治理

  图表明确标识了主数据管理系统作为权威数据源，表明它是核心主数据的单一真相来源。这种明确的权威来源定义是有效数据治理的基础，确保数据质量和一致性。

  上手技巧： 关注企业的地理分布特点，特别是跨区域、跨国企业。使用不同颜色区分不同类型的节点或区域。确保标注主要数据流的数据量和同步频率，这对网络容量规划至关重要。

  1️⃣2️⃣ 数据迁移图

  核心价值： 展示数据从源系统到目标系统的流动过程，详细描述数据提取、转换、加载的路径以及各阶段的质量控制措施。

  关键概念：

  • 源系统：数据迁移的起点，通常是需要被替换或整合的遗留系统
  • 目标系统：数据迁移的终点，通常是新的应用系统或数据平台
  • ETL过程：Extract（提取）、Transform（转换）和Load（加载）的缩写，描述了数据从源到目标的处理流程
  • 数据映射：定义源数据字段与目标数据字段之间的对应关系

  画法步骤：

  1. 在左侧绘制源系统区域，右侧绘制目标系统区域
  2. 中间添加数据转换处理区域
  3. 绘制数据从源到目标的流动路径
  4. 标注各阶段的处理活动（提取、转换、加载）
  5. 添加数据验证和质量检查点

  应用案例：

  下面是一个金融企业的数据迁移图示例：

  

  以上展示的金融企业数据迁移图详细呈现了一个典型的银行系统现代化项目的数据迁移流程。这类迁移在金融机构面临技术更新、业务转型或合规要求变化时尤为常见。让我们深入分析这个例子：

  系统区域划分

  图表清晰地划分了三个主要区域：

  • 源系统区域（黄色）：包含各种遗留系统，如老旧的核心银行系统、客户关系管理系统、交易处理和报表系统
  • 迁移处理区域（蓝色）：包含ETL过程的各个阶段，从数据提取到转换、质量检查和加载准备
  • 目标系统区域（绿色）：展示新的现代化系统组件，如新核心银行系统、统一客户视图、集成交易平台和商业智能平台

  这种区域划分帮助理解数据流动的起点、处理过程和终点，清晰展示了整个迁移的范围。

  数据处理流程

  图表展示了一个完整的ETL处理流程：

  1. 数据提取：从四个源系统并行提取不同类型的数据
  2. 数据暂存：将原始数据存入临时区域，作为转换前的备份和缓冲
  3. 数据转换：应用映射规则和业务逻辑转换数据结构和格式
  4. 数据质量检查：验证转换后的数据，确保质量和一致性
  5. 数据加载准备：对数据进行分批、排序等准备工作，为加载到目标系统做好准备
  6. 数据加载：将处理后的数据分别加载到相应的目标系统模块

  这个流程代表了ETL的最佳实践，确保数据在转换过程中的质量和完整性。

  数据流和映射

  图表通过流线和标注清晰地显示了数据的流动路径：

  • 账户数据从遗留核心系统流向新核心系统
  • 客户数据从CRM系统迁移到统一客户视图
  • 交易数据从交易处理系统转移到集成交易平台
  • 历史数据从报表系统迁入商业智能平台

  这些流线帮助理解数据如何在系统间映射和流动，为数据映射规则的制定提供指导。

  数据转换规则

  图表底部的规则区域表明迁移过程中需要应用三类规则：

  • 数据映射规则：定义源字段与目标字段的对应关系
  • 数据验证规则：确保数据符合质量和业务要求
  • 数据转换逻辑：定义复杂的数据转换和业务规则应用

  这些规则是数据迁移成功的关键因素，需要业务和技术团队共同制定和验证。

  上手技巧： 数据迁移图通常针对特定项目，因此要明确迁移范围和目标。确保包含足够的质量检查点，特别是在数据转换后。与数据迁移团队一起验证图表的可行性，确保所有关键数据都有明确的迁移路径。

  1️⃣3️⃣ 数据生命周期图

  核心价值： 描述和可视化数据资产从创建到最终处置的完整生命历程，帮助企业理解和管理数据在各个阶段的流转过程、管理责任和治理需求。

  关键概念：

  • 数据生命周期阶段：数据从创建到结束的关键阶段，通常包括创建/获取、存储、使用/处理、共享/传输、维护/更新、归档和销毁/处置
  • 数据状态：数据在生命周期不同阶段的形态，如原始数据、清洗数据、转换数据等
  • 数据管控责任：在各生命周期阶段负责数据的角色或组织
  • 数据流转触发器：促使数据从一个生命周期阶段移动到另一阶段的事件或条件

  画法步骤：

  1. 确定数据生命周期的主要阶段
  2. 将阶段按顺序排列（通常使用循环或流程图形式）
  3. 定义每个阶段的主要活动和责任
  4. 添加阶段间转换的条件或触发器
  5. 标注各阶段的数据状态和质量要求

  应用案例：

  下图展示了一个完整的数据生命周期流程。

  

  以下是一个金融机构客户数据生命周期的典型应用案例：

  创建/获取阶段：

  • 通过数字渠道（网站、移动应用）收集新客户资料
  • 通过分行柜台人工录入客户信息
  • 从第三方数据提供商获取补充信息（如信用评分）

  验证/清洗阶段：

  • 验证身份信息真实性（身份证验证）
  • 执行地址标准化和邮编匹配
  • 检测和处理重复客户记录

  存储/分类阶段：

  • 将核心客户信息存储在客户关系管理(CRM)系统
  • 将敏感身份信息存储在高安全级别的特定数据库
  • 按照客户类型（个人、企业）和风险等级进行分类标记

  使用/分析阶段：

  • 用于日常服务提供和交易处理
  • 用于客户细分和产品推荐分析
  • 用于风险评估和信用决策

  共享/分发阶段：

  • 在内部系统间共享（银行核心系统、营销系统等）
  • 向监管机构报送必要信息
  • 基于客户同意向合作伙伴共享特定信息

  维护/更新阶段：

  • 定期联系客户更新信息
  • 根据生命事件（如婚姻状况变更）更新记录
  • 通过交易行为自动更新客户偏好

  备份/恢复阶段：

  • 每日增量备份和周末全量备份
  • 异地容灾备份存储
  • 定期恢复测试

  归档/保留阶段：

  • 非活跃客户（2年无交易）数据转移到归档存储
  • 依据监管要求（如反洗钱法规）保留历史数据
  • 按不同数据类型实施差异化保留策略

  销毁/匿名化阶段：

  • 客户关系终止后7年（监管保留期满后）安全删除个人识别信息
  • 将一些历史数据匿名化后保留用于统计分析
  • 按照数据销毁政策记录和审计销毁过程

  上手技巧： 不同类型的数据可能有不同的生命周期，建议为主要数据类别（如客户数据、交易数据、产品数据）分别创建生命周期图。特别关注法规要求对数据保留和销毁的影响，如GDPR对个人数据的要求。

  1️⃣4️⃣ 数据分散图

  核心价值： 描述和可视化企业数据资产在不同维度上的分布和离散情况，帮助企业理解其数据资产的分布格局，识别数据孤岛、重复和冗余。

  关键概念：

  • 数据分散维度：数据分布可从多个维度进行分析，如地理分散、组织分散、系统分散、业务领域分散等
  • 数据分散模式：数据在企业中的典型分布模式，如集中式、分散式、联邦式、混合式等
  • 数据密度：特定位置或系统中数据的集中程度
  • 数据流动：数据如何在不同分散点之间移动

  画法步骤：

  1. 选择2-3个主要分散维度（如横轴为地理位置，纵轴为系统平台）
  2. 创建矩阵或网格展示维度交叉点
  3. 在交叉点标示数据分布状况
  4. 使用大小或颜色表示数据密度
  5. 添加连接线表示数据同步或依赖关系

  应用案例：

  以下是基于上图数据分散图展开的一个简明实际案例：

  

  背景和挑战： 某中型零售连锁企业拥有总部、东区门店群、西区门店群和中央仓库。企业使用多个系统管理业务，包括总部的数据仓库、CRM和ERP系统，以及各门店和仓库的本地ERP和POS系统。随着业务扩张，企业面临数据分散、冗余和不一致等问题，影响了库存管理、客户服务和业务决策。

  数据分散现状：

  1. 按地理位置分散：

  • 总部集中存储主数据和汇总数据

  • 东区门店存储本地交易和客户数据

  • 西区门店存储本地交易和客户数据

  • 中央仓库维护详细的库存数据

• 按系统类型分散：

• • 数据仓库：存储企业级客户和销售数据分析

  • CRM系统：管理客户关系数据

  • ERP系统：管理产品和库存数据

  • POS系统：处理销售交易数据

  主要数据问题：

  1. 数据孤岛：西区门店系统与总部系统集成不完善，导致数据交换延迟和不完整。如图中红色虚线椭圆所标识，西区门店的数据与总部系统之间的连接较弱。
  2. 数据冗余：产品数据在总部、东区、西区和仓库的ERP系统中重复存储，造成存储浪费和数据维护困难。如图中横贯所有位置的橙色虚线所示。
  3. 数据一致性问题：各系统中的库存数据不一致，导致库存控制失准和补货决策错误。如图中连接所有库存数据的蓝色虚线所示。

  优化方案

  基于数据分散图的分析，企业实施了以下改进措施：

  1. 解决数据孤岛问题：

  • 升级西区系统网络连接，提高数据传输效率

  • 实施自动化数据同步机制，确保西区数据及时同步到总部

  • 建立数据同步监控机制，确保数据传输完整性

• 减少数据冗余：

• • 建立产品主数据管理系统，作为产品数据的唯一权威来源

  • 各区域系统只存储必要的产品数据副本

  • 实施数据缓存策略，减少数据重复

• 改善数据一致性：

• • 实施实时库存同步机制，确保各系统库存数据及时更新

  • 建立库存数据调节流程，定期核对并解决不一致

  • 引入数据质量检查工具，自动识别和报告数据不一致

  上手技巧： 数据分散图可以采用多种表现形式，如矩阵、热力图或气泡图。选择最能突出你关注问题的形式。通常，数据高度集中或极度分散的区域都需要特别关注。

  四、数据管理与安全类图表 🔒

  这类图表解决的核心问题是"如何管理和保护数据"，帮助建立有效的数据治理和安全控制。

  1️⃣5️⃣ 数据安全图

  核心价值： 可视化展示企业数据资产的安全控制和保护措施，回答"谁可以访问什么数据，在什么条件下，使用什么保护措施"等关键安全问题。

  关键概念：

  • 数据分类等级：根据敏感性和重要性对数据进行分类的框架，如"公开"、"内部"、"机密"、"高度机密"等
  • 访问控制模型：定义如何限制对数据的访问，常见模型包括自主访问控制、强制访问控制、基于角色的访问控制和基于属性的访问控制
  • 安全区域：数据所在的物理或逻辑环境，具有不同安全级别
  • 数据保护机制：保护数据的技术和方法，包括加密、匿名化、脱敏、审计跟踪等

  画法步骤：

  1. 定义企业的数据安全分类体系
  2. 划分不同安全级别的区域
  3. 将数据资产按安全级别放入相应区域
  4. 标注区域间数据流动的安全控制点
  5. 为每个区域定义适当的安全控制措施

  应用案例：

  下面是一个金融企业的数据安全图示例：

  

  以上展示的金融企业数据安全图提供了一个全面的数据安全视图，展示了不同安全区域、数据分类和保护措施。让我们深入分析这个案例：

  数据分类与安全区域划分

  图表使用不同颜色和区域清晰地区分了三个安全级别：

  • 高安全区（红色）：包含高度机密数据，如客户敏感数据、账户核心数据等
  • 内部区（蓝色）：包含机密级数据，如客户概要数据、交易历史等
  • DMZ区（绿色）：包含内部级数据，如产品目录、市场信息等

  这种分层设计反映了"深度防御"的安全原则，越敏感的数据位于越高安全级别的区域，受到更严格的保护。

  分层安全控制

  每个安全区域应用了不同级别的安全控制：

  • 高安全区：采用端到端加密、多因素身份验证、特权访问管理和全面审计
  • 内部区：使用传输加密、基于角色的访问控制、数据脱敏和标准审计
  • DMZ区：实施API保护和内容控制措施

  这种分层控制体现了"适度安全"原则，根据数据敏感性采用相应强度的保护措施，平衡安全需求和使用便利性。

  安全控制点

  图表标识了四个关键的安全控制点（编号圆圈），这些是数据流动过程中的重要保护位置：

  1. 客户数据脱敏控制：在敏感客户数据流向内部区时应用
  2. 账户数据安全控制：保护账户数据在区域间的安全传输
  3. 产品数据发布控制：确保只有经过审批的产品数据才能发布到DMZ区
  4. API数据安全控制：保护通过API暴露的数据

  这些控制点是数据安全实施的关键环节，也是安全审计和监控的重点。

  上手技巧： 数据安全图应该与企业的安全策略和合规要求保持一致。使用不同颜色明确区分安全区域，如红色表示高安全区，蓝色表示内部区，绿色表示DMZ区。特别关注安全区域间的数据流动，确保有适当的控制点。

  1️⃣6️⃣ 系统数据管理图

  核心价值： 描述和可视化企业系统环境中数据的管理职责、流程和控制机制，明确"谁负责管理哪些系统中的哪些数据，通过什么方式进行管理"。

  关键概念：

  • 系统数据管理职责：在不同系统中对数据进行管理的角色和责任分配
  • 数据管理流程：系统中数据管理的关键流程和活动，如数据创建和获取、数据质量管理等
  • 管理控制点：系统中实施数据管理控制的关键节点，包括验证点、审计点、批准点等
  • 管理能力等级：系统对数据进行管理的能力水平，通常分为基础级、标准级、优化级和创新级

  画法步骤：

  1. 确定主要系统及其边界
  2. 标识每个系统的数据管理角色
  3. 定义系统内主要的管理流程
  4. 标注关键管理控制点
  5. 评估并标示每个系统的数据管理能力等级

  应用案例：

  下图展示了一个金融机构的系统数据管理图。

  

  以下是上图所描述的金融机构系统数据管理优化项目的案例：

  背景和挑战：

  某大型商业银行面临着数据管理复杂性不断增加的挑战，尤其是在实施新的监管合规要求（如BCBS 239、GDPR等）和推进数字化转型的背景下。银行发现不同系统之间的数据管理职责不明确，导致数据质量问题、合规风险增加，以及无法充分发挥数据价值。

  系统数据管理现状分析：

  核心银行系统：

  • 作为账户和交易数据的主要来源，系统具备优化级的数据管理能力
  • 业务部门和IT运维共同承担数据所有权和管理职责
  • 设有完善的验证点、审计点和监控点，但跨系统协调存在不足
  • 缺乏与风险管理系统的实时数据集成，导致风险评估延迟

  客户关系管理系统：

  • 管理所有客户信息，具备标准级的数据管理能力
  • 市场部门是客户数据的所有者，但存在与核心系统客户数据不一致问题
  • 客户数据更新频率不足，导致客户视图不完整
  • 缺乏高级数据质量监控和主动治理能力

  风险管理系统：

  • 负责信用风险和合规数据管理，具备标准级的管理能力
  • 风险部门拥有风险相关数据的所有权
  • 与核心系统和数据仓库的数据同步存在延迟问题
  • 缺乏自动化的合规数据管理流程

  数据仓库：

  • 整合所有系统数据，具备创新级的管理能力
  • 由专门的数据团队管理，实施了先进的数据集成和管理工具
  • 设有全面的审计和监控机制，支持高级分析和报告
  • 负责历史数据的长期存档和管理

  监管报告系统：

  • 生成提交给监管机构的各类报告，具备标准级的管理能力
  • 合规部门是报告数据的所有者
  • 从其他系统获取数据时存在手动步骤，增加了错误风险
  • 缺乏自动化的报告验证和数据谱系追踪能力

  基于系统数据管理图的分析，银行实施了以下优化举措：

  1. 建立企业数据治理委员会：

  • 成立由各业务部门、IT和数据专家组成的治理委员会

  • 制定统一的数据管理政策和标准

  • 明确各系统数据的所有权和职责分配

  • 定期审查系统间数据流动和管理流程

• 强化核心银行系统的数据控制：

• • 改进账户和交易数据的验证规则

  • 实施实时的数据质量监控机制

  • 建立与风险系统的近实时数据接口

  • 自动化数据异常处理流程

• 提升客户关系管理系统能力：

• • 实施主数据管理解决方案，确保客户数据一致性

  • 建立客户数据变更的审批和跟踪机制

  • 部署数据质量评分卡，定期评估客户数据质量

  • 引入数据治理工具，加强数据控制和审计

• 优化风险管理系统的数据集成：

• • 建立与核心系统的近实时风险数据集成

  • 自动化合规数据收集和报告流程

  • 实施风险数据质量监控框架

  • 建立数据谱系追踪能力，支持风险分析

• 强化数据仓库与监管报告的集成：

• • 建立报告数据的自动提取和验证流程

  • 实施端到端数据谱系追踪

  • 建立报告数据质量控制框架

  • 自动化监管报告生成和验证流程

  上手技巧： 先关注企业最核心的业务系统，确保这些系统有清晰的数据管理职责和控制机制。使用图标或符号表示不同的管理角色和控制点，增强可读性。与业务和IT管理层一起验证图表，确保职责分配的准确性。

  图表选择指南 📋

  不是所有16个图表都需要在每个项目中使用。根据以下指南选择最适合您需求的图表：

  如果您需要：

  • 📌 理清企业有什么数据 → 使用数据实体/数据组件目录和数据实体目录
  • 📌 明确数据与业务的关系 → 使用数据实体/业务功能矩阵和业务服务/信息图
  • 📌 规划系统集成 → 使用应用程序/数据矩阵和数据流图
  • 📌 进行数据治理 → 使用数据生命周期图和系统数据管理图
  • 📌 确保数据安全 → 使用数据安全图和数据分散图
  • 📌 规划系统迁移 → 使用数据迁移图和数据实体/关系图

  结语 🏁

  掌握这16种数据架构图的画法，就像拥有了数据架构师的瑞士军刀，让你能够应对各种架构挑战。选择合适的图表，遵循正确的画法，你的数据架构将既专业又直观，让业务与技术团队都能从中获益。

  数据架构不仅仅是文档，它是企业数据战略的视觉表达，是技术团队与业务团队沟通的桥梁。通过本文介绍的方法，你可以创建既符合TOGAF标准又实用易懂的数据架构图表，为企业数据资产管理奠定坚实基础。

  希望本文能帮助你在数据架构的道路上走得更远！

  ---

  你可能还喜欢：
  

  始于业务，终于技术，敲开理解数据架构的大门！

  

  

  

  公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！