最近连发二篇文章分别讲了业务架构和应用架构，这是第三篇，即数据架构。

数据架构是企业架构的核心部分，而对于很多人来说，理解其构建过程可能仍是一个难题。我之前为大家分享了《数据架构的本质到底是什么 by 傅一平》，详细解释了数据架构的概念。然而，很多读者更想进一步探讨的是如何构建出高效的数据架构。

为此，我参考了TOGAF的指导原则，为大家整理出了数据架构的主要交付物，总结为九大核心制品：

1、目录：数据实体/数据组件目录

2、矩阵：数据实体/业务功能矩阵、应用程序/数据矩阵

3、图：概念数据图、逻辑数据图、数据传播图、数据安全性图、数据迁移图、数据生命周期图

希望通过这些核心制品，大家能对数据架构有一个更加全面和系统的认识。而在文末，我还对《华为数据之道》、DAMA、DCMM等数据架构的定义进行了比较分析，以供大家参考。

一、企业架构全景图

TOGAF（The Open Group Architecture Framework）是一个工具集、术语集和流程集，提供了一个全面的方法来开发企业架构。TOGAF的中心是一个被称为"架构开发方法"（Architecture Development Method，简称ADM）的流程，如下图所示：

我们最关注的是业务架构、数据架构、应用架构及技术架构，这些架构层次的描述体现了从高层策略到低层实施的逐渐细化的逻辑。

1、业务架构：它描述了组织的核心业务流程、策略、治理、组织结构和关键业务功能。业务架构提供了一种视角，以便于理解组织是如何为其客户创造价值的。这也是其他三个架构域的基础，因为它们都是为了支持特定的业务目标和要求。

2、数据架构：描述了组织的数据结构、数据管理和数据治理策略。这包括对实体、关系、数据流和数据存储的定义，以确保组织内部的信息是准确、一致和可靠的。

3、应用架构：这关注的是组织的应用组合、如何它们支持业务功能和流程、以及这些应用是如何相互交互的。它为应用开发、集成和维护提供了一个框架。

4、技术架构: 是描述硬件、软件、网络和其他技术组件的架构域。它描述了为了支持应用、数据和业务流程所需的基础设施。技术架构确保所有的技术组件是互操作的，并且可以满足组织的性能、安全性和可靠性要求。

四种架构域是层层递进、相互关联的。业务架构定义了“我们需要做什么”，数据架构和应用架构描述了“我们将如何做到这一点”，而技术架构则提供了“我们需要哪些工具和技术来实现这一目标”的答案。当一个组织制定企业架构策略时，这四个域通常需要协同工作，以确保策略的完整性和连续性。

二、数据架构的内容

根据The Open Group Architecture Framework（TOGAF）的定义，数据架构描述了一个组织内的数据结构和与之关联的数据处理活动。简言之，数据架构概括了如何存储、访问、管理和保护数据。这不仅仅是关于数据库和数据仓库，还涉及到数据流、数据分发、数据标准等方面。

那么，数据架构具体长啥样呢？

架构是比较抽象的概念，目录、矩阵和图能够以结构化和易于理解的方式提供架构信息，从而满足利益相关者的需求。TOGAF在各阶段的架构输出物中，给出了可能需要创建的目录、矩阵和图的指导，具体如下所示：

在阶段C中，TOGAF为数据架构定义了以下三类关键交付物，共有9个核心制品：：

1、目录：数据实体/数据组件目录

2、矩阵：数据实体/业务功能矩阵、应用程序/数据矩阵

3、图：概念数据图、逻辑数据图、数据传播图、数据安全性图、数据迁移图、数据生命周期图

接下来，我们将结合实际案例，深入浅出地探讨这9个制品的内涵和价值，带领大家了解数据架构的完整蓝图和其所能带来的益处。

1、数据实体/数据组件目录

数据实体/数据组件目录的目的是识别和维护企业跨部门使用的所有数据，包括数据实体和存储数据实体的数据组件。

一个经过共识的数据实体/数据组件目录支持信息管理和数据治理政策的定义和应用，同时也促进了有效的数据共享和重用，该目录包含以下元模型实体：

■ 数据实体

■ 逻辑数据组件

■ 物理数据组件

以电商业务为例，一个简单的数据实体/数据组件目录可能如下：

2、数据实体/业务功能矩阵

数据实体与业务功能矩阵旨在揭示数据实体与业务功能间的相互关系。在此背景下，业务功能受到明确界定的业务服务的支撑，并通过业务流程进行实现。这种关系映射带来了多个明确的优势：

■ 为数据实体确立明确的所有权归属。

■ 深入理解业务服务所需的数据及其间的信息交互需求。

■ 通过缺口分析，鉴别是否有必要创建新的数据实体。

■ 为数据实体明确定义起源应用、记录应用以及参考应用。

■ 推动整个企业的数据治理进程，如设立数据管理员角色和制定与业务功能紧密相关的数据标准等。

这个矩阵主要涵盖：

■ 数据实体

■ 业务功能

■ 数据实体与组织单位的关联性

以电商为背景，我们可以通过一个简化的数据实体/业务功能矩阵来深入探索这些关系。

在这个表格中：

■"所有权"表示该业务功能负责该数据实体的创建、更新和删除。

■"查询"表示该业务功能需要读取或查询该数据实体。

■"-"表示该业务功能与数据实体没有直接关系。

这个矩阵有助于组织理解不同业务功能如何与数据实体相互作用，从而进行更有效的数据治理和优化业务流程。

3、应用程序/数据矩阵

应用程序与数据矩阵专注于呈现应用程序（也就是应用组件）如何与它们所接触的数据实体互动。以CRM应用程序为例，它可能涉及创建、读取、更新和删除客户的相关信息。

这种应用与数据实体之间的关系映射带来了以下显著好处：

■ 将数据访问权限分配给组织中的特定应用程序

■ 理解不同应用程序内数据重复的程度，以及数据生命周期的规模

■ 理解哪些相同的数据由不同的应用程序更新

■ 支持缺口分析，确定是否有缺失的应用程序需要创建

针对电商领域，以下是一个简洁的应用程序与数据矩阵示例：

在这个表格中，不同的应用程序与数据实体之间的交互用 CRUD（创建-读取-更新-删除）的形式来表示，这样的矩阵有助于明确哪个应用程序对哪种数据实体有哪种操作权限，从而能更好地进行数据治理和优化数据流程。

4、概念数据图

概念数据图的主要目的是描述企业内关键数据实体之间的关系，该图主要面向业务利益相关者，如业务分析师、高级管理人员的关注点而开发。

以电商业务为例，一个简单的概念数据图可能如下：

我们有以下实体和关系：

（1）实体和扩展：

■ User（用户）：是一个通用的用户实体。

■ Customer（客户）和 Admin（管理员）：是 User 的扩展，表示特定类型的用户。

（2）其他实体：

■Product（商品）

■Category（分类）

■ShoppingCart（购物车）

■Order（订单）

■Payment（支付）

■Review（评价）

■Address（地址）

（3）关系：

■一个客户（Customer）可以拥有一个购物车（ShoppingCart）并且购物车可以包含多个商品（Product）。

■一个客户可以下多个订单（Order），每个订单可以包括多个商品。

■每个订单都有一个支付信息（Payment）。

■订单可能会收到评价（Review）。

■客户可以编写多个评价。

■商品也可以有多个评价。

■商品可以属于一个分类（Category）。

■客户可以有多个地址（Address）。

■订单会发送到一个地址。

■管理员（Admin）管理商品和分类。

5、逻辑数据图

逻辑数据图的主要目的是展示企业内关键数据实体之间逻辑关系的视图。该图往往是为了解决以下应用开发者、数据库设计师等角色的关注点而开发的。

以电商业务为例，一个简单的逻辑数据图可能如下：

6、数据传播图

数据传播图旨在绘制数据实体、业务服务及应用组件间的连接和流向。这种图形展示了如何通过应用组件将逻辑实体转化为物理存在，帮助评估规模并对IT环境进行精细优化。更为重要的是，通过为数据赋予业务价值，我们能更清晰地识别各应用组件对业务的关键性影响。

以电商为背景，下面我们来探索一个简洁且清晰的数据传播图示例：

这个数据传播图包括以下几个部分：

■ 业务服务：结账业务服务（Checkout Service）。

■ 应用组件：包含两个应用组件，分别是订单管理（Order Management）和支付处理（Payment Processor）

■ 数据实体：应用组件进行数据实体的操作，实现订单和支付两个数据库的相关数据实体的CRUD。

■ 关系：用箭头展示了业务服务、应用组件如何与数据实体进行读写操作，以及业务服务之间如何相互使用。

■ 业务价值：用注释来标明不同业务服务的业务价值，以指示它们的业务关键性。

7、数据安全性图

在企业领域，数据不仅是一项宝贵的资产，更是业务运营的基石。因此，确保数据安全，防止其受到任何形式的威胁，并对数据访问进行适当的管理，显得尤为关键。数据安全性图正是为了明确地描绘出哪些参与者能够访问特定的数据资产。这些访问权限可以通过矩阵直观地呈现，或者进一步细化为详尽的映射关系。

以电商平台为背景，考虑以下参与者：

■ 客户

■ 销售团队

■ 财务部门

■ IT支持团队

■ 第三方支付平台

与此同时，我们关心的数据资产可能包括：

■ 订单细节

■ 客户信息

■ 支付记录

■ 产品目录

■ 客户评价与反馈

接下来，我们将通过表格详细展示各参与者对这些数据资产的CRUD权限：

电商业务的数据安全性图示例如下：

8、数据迁移图

在数据的生命周期中，迁移是一个至关重要的环节。数据迁移图为我们提供了从源系统到目标系统数据的流转蓝图。这不仅使得源与目标的数据流动一目了然，而且为数据审计和追踪提供了强大的工具。根据不同的需求和复杂性，数据迁移图的细节和深度可以有所不同。它可以简单地概述迁移的主要步骤，或深入到每一个数据元素的具体迁移细节。

数据迁移过程通常包括：

■ 从原始应用程序（即基线系统）中提取数据。

■ 调整和配置抽取的数据。

■ 进行数据转换，这涉及：

— 数据清洗，例如标准化、规范化和删除重复项。

— 整合来自不同源的数据，并确保数据的一致性。

— 定义源数据到目标数据的映射关系。

■ 将整理好的数据导入到新的目标系统。

以电商平台为例，考虑从一个旧版电商系统（2010版本），迁移到一个功能更丰富的新系统。旧系统中的商品、客户和订单信息需要完整地迁移并整合到新系统中，同时新系统还增加了供应商、库存和评论等新的数据模块。在此过程中，特别重视的是客户信息的准确性和完整性。以下数据迁移图为您呈现了这一数据迁移的概览。

9、数据生命周期图

数据生命周期图详细展示了数据如何随时间在不同业务流程中流转和演变。与其说数据跟随业务流程，不如说数据独立地经历自己的生命阶段，由特定的事件或规则触发其状态变化。这种数据与业务流程的解耦有助于我们识别公共的数据需求，进而优化资源使用和共享。

以电商行业为例，考虑“订单”这一核心数据实体。从客户下单到商品最终交付，订单会经历一系列不同的状态。接下来，我们将通过一个简化的数据生命周期图为您展示订单从诞生到完成的旅程。

三、数据架构的辨析

尽管DAMA、华为数据之道、DCMM等均提供了对数据架构的定义，要真正理解它们与九大制品间的联系，我们首先需要深入挖掘这些制品的核心含义。我归纳出以下六大核心观点：

1、概念数据图和逻辑数据图为业务建模提供了基础。它们定义了数据的形态和结构，决定了数据的最终呈现。

2、数据实体/业务功能矩阵、应用程序/数据矩阵和数据安全图揭示了数据的分布和权属，明确了谁能够访问哪些数据。

3、数据传播图从技术视角描述了数据如何从源头生成并随之变化，展示了数据的生命周期轨迹。

4、数据生命周期图则从业务视角展现数据从生成到消亡的完整历程。

5、数据实体/数据组件目录推动数据的流通与应用，强调数据的共享和再利用，与元数据管理及数据标准紧密相联，是数据治理领域的核心要素。

6、数据迁移图为我们呈现了在架构演进过程中如何确保数据的连续性和完整性。

虽然九大制品在某些方面存在重叠，但其目的明确——满足不同利益相关者的需求。例如，虽然概念数据图和逻辑数据图都关注数据设计，但前者更偏重于为决策者和架构师提供视角，而后者则专为开发者所设。又比如虽然数据传播图和数据生命周期图都反映数据变更的来龙去脉，但前者更偏重于为开发者服务，而后者则为业务人员所设。

1、华为数据之道

《华为数据之道》把数据架构定义为指以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范，共包括四个部分：数据资产目录、数据标准、数据模型和数据分布。

我们可以做个简单的映射，数据资产目录跟数据实体/数据组件目录类似，数据标准实际上跟其他组件不在一个维度，其是数据治理的重要手段，是为所有组件服务的，TOGAF并没有将其纳入数据架构的制品；数据模型跟概念数据图、逻辑数据图对应；数据分布跟数据实体/数据组件目录、数据实体/业务功能矩阵、应用程序/数据矩阵、数据传播图都息息相关。

没有比较就没有鉴别，《华为数据之道》给出的数据架构更多是一种观点或视点，而TOGAF通过目录、图和矩阵的形式更加结构化，具象化的表达出了数据架构的内涵，同时通过区分关注点、视点、视图这些概念，让具备同样视点的利益相关者可以看到不同的视图，从而满足不同角色沟通架构的需要，这是非常全面和具有指导意义的。

2、DAMA

《DAMA数据管理知识体系指南 第二版》把数据架构定义为识别企业的数据需求，并设计和维护总蓝图以满足需求，使用总蓝图来指导数据集成、控制数据资产、并使数据投资与业务战略保持一致，包括二个部分：

（1）数据模型：企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。企业数据模型包括数据实体（如业务概念），数据实体间的关系、关键业务规则和一些关键属性，它为所有数据和数据相关的项目奠定了基础。

（2）数据流设计：定义数据库、应用、平台和网络（组件）之间的需求和主蓝图。这些数据流展示了数据在业务流程、不同存储位置、业务角色和技术组件间的流动。

我们也可以做个简单的映射，数据模型跟概念数据图、逻辑数据图对应；数据分布跟数据实体/数据组件目录、数据实体/业务功能矩阵、应用程序/数据矩阵、数据传播图息息相关。相比TOGAF少了数据实体/数据组件目录等内容。

但我以前曾经讲过，如果从架构定义本身看，数据模型和数据流（或叫数据分布）就是数据架构最本质的东西，其让业务切分的合理并且切分后沟通顺畅，其他都是为了方便数据使用服务的。

3、DCMM

《DCMM数据管理成熟度模型》把数据架构定义为通过组织级数据模型定义数据需求,指导对数据资产的分布控制和整合，部署数据的共享和应用环境，以及元数据管理的规范。包括四个部分：

（1）数据模型：使用结构化的语言将收集到的组织业务经营、管理和决策中使用的数据需求进行综合分析,按照模型设计规范将需求重新组织。从模型覆盖的内容粒度看，数据模型一般分为主题域模型、概念模型、逻辑模型和物理模型。

（2）数据分布：针对组织级数据模型中数据的定义，明确数据在系统、组织和流程等方面的分布关系，定义数据类型，明确权威数据源，为数据相关工作提供参考和规范。通过数据分布关系的梳理，定义数据相关工作的优先级，指定数据的责任人，并进一步优化数据的集成关系。

（3）数据集成和共享：是建立起组织内各应用系统、各部门之间的集成共享机制，通过组织内部数据集成共享相关制度、标准、技术等方面的管理，促进组织内部数据的互联互通。

（4）元数据管理：元数据管理是关于元数据的创建、存储、整合与控制等一整套流程的集合。

数据模型、数据分布及元数据管理不再赘述，这里重点谈谈数据集成和共享，其跟数据迁移图有很强的联系，但内涵还是远大于数据迁移图。TOGAF在业务架构、应用架构等章节都特别强调了互操作性的内容。

比如业务架构里提到了业务互动矩阵，应用架构里专门提到了接口目录、应用程序互操作矩阵，唯独数据架构里没有专门的制品。虽然如TOGAF所述，企业可以根据需要自行扩展TOGAF的内涵，但TOGAF的确需要在数据架构中单独考虑数据集成和共享这个制品。

我起步于数据仓库领域，常常局限于数据仓库的视角来看待数据架构，如同在井底观天，使我在面对某些问题时往往难以找到根本的解决方法。

实际上，数据仓库并不是孤立的岛屿。它深深地嵌入于业务、应用和技术之中。当我们放眼于更广阔的数据领域，会发现无论是OLTP还是OLAP，在数据结构上都并无太大差异。真正想要解决数据问题，我们需要深入到业务和应用的源头去探索，明白其背后的技术架构，从而找到问题的核心所在。这点在我做了企业级数据治理后感受特别深。

而TOGAF为我打开了一扇新的大门，它提供了一个系统化的方法来洞察数据架构，也是我撰写此文的原动力。虽然多年前我其实学习过TOGAF，但要真正的理解它，的确不太容易。