一、前言：数据架构为何是企业架构的“核心轴”

在TOGAF的四大架构域（业务架构、数据架构、应用架构、技术架构）中，数据架构占据着独特而关键的位置。业务架构定义了“我们需要做什么”，应用架构回答“用什么系统来做”，技术架构解决“需要哪些基础设施支撑”，而数据架构则贯穿始终——它既是业务架构的信息投射，又是应用架构的设计约束，更是技术架构的选型依据。

数据架构是企业中最具穿透力的架构维度。 业务可能调整、应用可能替换、技术可能演进，但核心数据实体（如客户、产品、订单）往往具有跨越数十年的稳定性。正因如此，数据架构被称为企业架构的“核心轴”——它像一根主轴，将战略、业务、应用和技术四个层次串联起来，确保企业信息的一致性与可追溯性。

本文将系统拆解数据架构的核心构成，深入探讨其与TOGAF内容元模型的映射关系，并结合电商案例展示从理论到落地的完整图景。

二、数据架构的核心构成：四大组件与九大制品

2.1 数据架构的四大核心组件

根据TOGAF的界定，一个完整的数据架构应包含以下四个相互关联的核心组件：

（1）数据资产目录：识别并维护企业中所有关键数据实体及其存储位置。它是数据治理的基础，回答了“我们有什么数据、数据在哪里”的问题。

（2）数据模型：从概念模型、逻辑模型到物理模型，逐层细化地描述数据实体、属性及其关系。概念模型面向业务人员，逻辑模型面向架构师，物理模型面向数据库管理员。

（3）数据分布（数据流）：描绘数据如何在应用系统之间流转，包括数据的创建、读取、更新、删除（CRUD）路径，以及跨系统的数据传播链路。

（4）数据生命周期：定义数据从创建、使用、归档到销毁的完整演变过程。数据的状态变化通常由业务事件触发，但数据本身独立于业务流程存在。

2.2 数据架构的九大核心制品

在TOGAF ADM的阶段C（信息系统架构）中，数据架构的输出被规范化为三类九种制品：

类别	制品名称	核心用途
目录	数据实体/数据组件目录	识别和维护企业核心数据资产清单
矩阵	数据实体/业务功能矩阵	明确数据的所有权归属与业务依赖
矩阵	应用程序/数据矩阵	展示应用系统对数据的CRUD操作权限
图	概念数据图	面向业务人员，展示核心数据实体关系
图	逻辑数据图	面向架构师，细化属性与逻辑关系
图	数据传播图	展示数据在应用组件间的流向
图	数据安全性图	定义不同角色对数据资产的访问权限
图	数据迁移图	规划数据从源系统到目标系统的迁移路径
图	数据生命周期图	展示数据状态随业务事件的变化过程

三、TOGAF内容元模型：数据架构的“统一语言”

3.1 什么是内容元模型

内容元模型（Content Metamodel）是TOGAF架构内容框架的核心，它定义了企业架构中所有类型构建块的标准结构和关系。简单来说，元模型就是描述架构的“语法规则” ——它规定了我们可以用哪些元素（如数据实体、业务功能、应用组件）以及这些元素之间允许存在怎样的关系。

每个企业都应该建立自己的元模型。通用框架提供参考，但企业需要根据自身业务特点进行定制——例如，金融行业可能需要强化“风险数据”相关元素，制造业则需要突出“物料清单”和“工艺路线”等特定概念。

3.2 数据架构相关的核心元模型实体

在TOGAF内容元模型中，与数据架构直接相关的核心实体包括：

• 数据实体：对业务具有独立意义的信息单元，如“客户”“产品”“订单”。
• 逻辑数据组件：封装数据实体的逻辑边界，如“客户数据域”“产品主数据”。
• 物理数据组件：实际存储数据的物理载体，如数据库表、数据文件
• 应用组件：操作数据的应用系统或服务。
• 业务功能：使用数据的业务能力单元。
• 角色/组织单元：对数据负有权限和责任的业务主体。

这些元模型实体之间通过标准化关系连接，构成了数据架构描述的“语法骨架”。

四、映射关系：数据架构制品如何落地元模型

TOGAF的三种制品形式——目录、矩阵、图——本质上是对内容元模型的结构化呈现。理解这一映射关系，是数据架构从“画图”走向“建模”的关键。

4.1 目录：元模型实体的清单化呈现

目录是对特定类型元模型实体的枚举和属性记录。数据实体/数据组件目录直接对应元模型中的数据实体和逻辑数据组件。

以电商业务为例：

数据实体	逻辑数据组件	物理数据组件	说明
客户	客户主数据	CRM数据库.Customer表	核心主数据
商品	商品主数据	PIM系统.Product表	核心主数据
订单	交易数据	OMS数据库.Order表	核心交易数据
库存	库存数据	WMS数据库.Inventory表	实时变动数据

4.2 矩阵：元模型关系的结构化表达

矩阵用于展现两类元模型实体之间的关联关系。在数据架构中，两个核心矩阵直接服务于数据治理和应用设计：

数据实体/业务功能矩阵明确了数据的所有权和依赖关系。例如：

数据实体	商品管理	订单处理	客户管理	客户服务	财务核算
客户档案	-	-	所有权	查询/更新	查询
客户联系人	-	创建*	-	所有权	-
商品	所有权	查询	-	-	-
订单	-	所有权	查询	查询	查询
支付	-	创建	-	查询	所有权

*注：游客下单场景，后续需合并至正式客户档案。

这个矩阵的价值在于：当“客户”实体需要变更时，我们一眼就能看出哪些业务功能会受影响。

应用程序/数据矩阵则展示了系统对数据的操作权限（CRUD），是数据分布设计的核心输入。

矩阵中的CRUD权限分配，反映的是业务架构的真实设计决策，而非简单的直觉判断。每个“创建”权限的背后，都应该有一个明确的业务场景支撑。

4.3 图：元模型关系的可视化表达

图是数据架构最直观的输出形式，不同类型的图服务于不同利益相关者：

概念数据图面向业务人员，使用业务语言描述核心实体关系。电商场景中：客户拥有购物车，购物车包含商品；客户下达订单，订单关联支付；客户发表评价，评价关联商品。

逻辑数据图面向架构师，增加了属性定义和关系细化。例如客户实体包含客户ID、姓名、等级等属性；订单与订单明细构成父子关系。

数据传播图引入应用组件维度，展示数据如何跨越系统边界。例如：结账服务调用订单管理组件创建订单实体，再调用支付组件创建支付实体，箭头方向清晰展示数据流向。

数据生命周期图独立于业务流程，追踪数据自身的状态演变。电商订单从“待支付→已支付→已发货→已完成→已关闭”，每个状态转换由特定业务事件触发。

五、电商实战案例：从元模型到制品的完整推演

5.1 场景设定

某电商企业正在进行企业架构梳理，需要建立统一的数据架构视图，解决当前存在的“商品信息在三个系统中有不同定义”“订单状态在各系统间不一致”等问题。

5.2 步骤一：识别核心数据实体（基于元模型）

根据业务调研，识别出以下核心元模型实体：

• 主数据实体：客户、商品、供应商。
• 交易数据实体：订单、支付、购物车。
• 参考数据实体：商品类目、地区代码、支付方式。

5.3 步骤二：构建数据实体/业务功能矩阵

将数据实体与电商核心业务功能进行交叉映射：

• 商品管理功能拥有商品实体的所有权。
• 订单处理功能拥有订单、购物车实体的所有权。
• 客户管理功能拥有客户实体的所有权。
• 财务功能拥有支付实体的所有权。

这一步直接明确了数据治理的责任归属——谁使用、谁创建、谁负责。

5.4 步骤三：绘制概念数据图

使用ER图形式，绘制核心实体及其关系：

5.5 步骤四：绘制数据传播图

追踪“下单”这一业务服务的数据流转：

这张图清晰展示了数据在微服务架构下的传播路径，是识别数据一致性边界的关键依据。

5.6 步骤五：制定数据生命周期图

以订单实体为例，定义其生命周期状态机：

每个状态节点都定义了数据的有效性和可操作性规则。

六、数据架构与四大架构域的协同关系

数据架构不是孤立存在的，它与TOGAF其他三大架构域形成紧密的协同关系：

向上承接业务架构：业务架构中的业务对象（如“客户”“订单”）直接映射为数据架构中的数据实体；业务流程中的信息需求驱动数据模型的设计。业务能力与数据实体的矩阵关系，是数据所有权分配的依据。

向下指导应用架构：数据架构定义的数据实体和CRUD矩阵，直接约束应用架构中应用组件的功能边界。例如，如果订单数据只允许订单服务“创建”，那么其他服务想要修改订单状态，必须通过订单服务暴露的接口。

横向约束技术架构：数据架构中的数据分布（如读写分离需求）、数据量级（如日增千万订单）和数据生命周期（如冷热数据分层）直接影响技术架构中的数据库选型、存储策略和备份方案。

这种协同关系可以用一个简洁的视图呈现：

七、总结与展望

数据架构是企业架构中承上启下的“核心轴”，它通过目录、矩阵、图三类制品，将TOGAF内容元模型中的抽象定义转化为可沟通、可验证、可落地的架构资产。理解数据架构与内容元模型的映射关系，意味着架构师不仅知道“要画什么图”，更理解“为什么画这些图”以及“这些图之间如何关联”。

在数字化转型深入发展的今天，数据架构的重要性愈发凸显。无论是数据治理（DCMM）、主数据管理（MDM），还是新兴的数据网格、数据编织架构，其根基都在于对数据架构核心原则的深刻理解。建议企业架构师在实践中：

1. 先建元模型，再画图——确保团队使用统一的架构语言。
2. 从业务对象出发识别数据实体——保持数据架构与业务的紧密对齐。
3. 矩阵先行于图表——用矩阵理清关系，用图表展示洞察。
4. 保持制品的可追溯性——每一张图都应能追溯到元模型实体和业务需求。

只有将数据架构真正嵌入企业架构的全生命周期管理，才能让数据从“混乱”走向“清晰”，从“孤岛”走向“统一视图”。