作为架构师，你可能已经注意到一个趋势：过去几年我们讨论数据中台，话题围绕着数据集成、数据开发、数据服务三层架构；而现在，你会发现需求侧正在发生根本性的变化——CFO开始关心数据中台能不能支撑资产入表，合规部门要求中台提供可审计的质量报告，数据安全团队则要求中台具备分类分级和流通管控能力。
这不是某个行业或某家企业的特例。三份重量级政策文件在两年内相继出台，从制度、财务、流通三个维度，正在系统性地重塑数据中台的架构需求。对于架构师来说，理解这种需求侧的变化，是设计下一代数据中台架构的前提。
一、政策驱动下的架构需求升级
我们把三份政策文件放到时间轴上，能清晰地看到一条能力升级链条。
2022年12月，"数据二十条"（《关于构建数据基础制度更好发挥数据要素作用的意见》）率先发布，以数据资源持有权、加工使用权、产品经营权"三权分置"的框架，第一次在法律层面为数据被界定为"资产"扫清了制度障碍。从架构视角看，这意味着数据中台需要从"数据存储和计算平台"扩展到"数据产权的技术载体"——谁拥有什么数据、谁可以加工什么数据、谁有权使用什么数据，这些问题需要在平台的权限模型和数据血缘中可追溯。
2023年8月，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）紧随其后，于2024年1月正式施行。数据入表进入实操轨道。对架构师而言，这引入了一个全新的非功能性需求：可审计性（Auditability）。资产范围需要清晰界定，数据质量需要被客观评价，价值评估需要量化依据——这些需求意味着数据中台的架构中必须内建资产目录、质量引擎和评估报告能力，而不是依赖事后的人工整理。
2024年1月，国家数据局发布"数据要素×"三年行动计划（2024—2026年），政策重心从"确权入表"进一步延伸到"合规流通"。从架构层面，这要求数据中台的安全管控层从"内部权限管理"升级到"对外流通的安全治理"——数据分类分级、脱敏策略、流通审计、使用追溯这些能力需要成为中台的原生功能，而非外挂的安全组件。
三份文件叠加在一起，对架构师的核心启示是：数据中台的架构定位正在从"数据加工平台"升维到"数据资产管理基础设施"。这个升维不是功能层面的加法，而是架构范式的转变——就像单体应用到微服务的转变一样，它改变了平台的核心抽象和模块边界。
二、架构升维的三个关键模块
如果把数据中台比作一个操作系统，那么入表驱动的架构升级相当于在这个操作系统上新增了三个内核模块。这三个模块不是可选插件，而是政策合规要求下的必选项。
模块一：资产目录层——从"数据地图"到"资产视图"
传统数据中台的元数据管理通常面向技术用户——这张表在哪里、字段是什么、ETL链路怎么走。但在数据资产化的语境下，资产目录需要回答的是另一类问题：企业拥有哪些数据资源？哪些具备资产属性？它们分布在哪些业务域？各自的治理成熟度如何？
这要求架构师在数据中台中设计一个独立的"资产视图层"，它位于元数据层之上，以业务域为组织单元，聚合技术元数据、业务元数据、质量元数据和合规元数据，形成"一张表看清一项资产"的全局视图。技术上，这一层可以通过元数据图谱（Metadata Knowledge Graph）来实现，将分散在数据仓库、数据湖、业务系统中的元数据按资产维度重新组织和关联。
模块二：质量引擎——从"数据监控"到"可审计质量评价"
很多数据中台都有数据质量监控功能——空值率、重复率、波动率这些指标看起来像是在做质量管控。但入表场景对质量的要求与运维监控有本质区别：运维监控关注的是"数据能不能用"，入表审计关注的是"数据值不值钱"且结论需要"可被第三方验证"。
这意味着质量引擎的架构需要做三个调整：第一，质量规则必须对齐GB/T 36344-2018的六个维度（规范性、完整性、准确性、一致性、时效性、可访问性），形成标准化的评价框架；第二，评价结果必须是结构化的、可追溯的——每一次评分、每一条问题记录都需要关联到具体的规则、字段和数据时间戳；第三，评价引擎需要支持"审计模式"——即在指定时间点对指定数据范围执行一次不可篡改的冻结评估，生成可供会计师事务所引用的质量报告。
模块三：流通管控层——从"权限管理"到"数据要素流通治理"
传统中台的安全管控通常是静态的——基于角色的访问控制（RBAC）、列级权限、数据脱敏。但"数据要素×"行动计划要求数据能够在合规前提下对外共享和交易，这引入了动态的流通管控需求。
从架构上，流通管控层需要在传统权限管理之上叠加三层能力：第一，数据分类分级引擎，依据《数据安全法》和相关行业标准对数据进行自动或半自动的分级打标；第二，流通策略引擎，基于数据等级、使用场景、接收方资质等维度动态生成流通策略（是否允许外发、以什么形式外发、需要什么审批流）；第三，流通审计引擎，对所有外发操作进行全量日志记录和行为审计，确保流通过程可追溯。
这三个模块共同构成了数据中台从"管道"到"资产管理基础设施"的架构升维路径。它们的共同特点是：不是独立的外挂系统，而是需要嵌入中台核心架构的"原生能力"。
三、DCMM 2.0：架构设计的"能力对照表"
架构师在设计上述三个模块时，DCMM 2.0（GB/T 36073-2025，于2026年7月正式实施）提供了一份很好的能力对照参考。
2025年发布的DCMM 2.0对能力域进行了结构性调整：能力域数量从1.0版本的八个扩展到九个，其中最引人注目的变化是新增了"数据资产"能力域，排在九大域中的第四位。同时，"数据应用"域更名为"数据应用流通"。
DCMM 2.0的九大能力域包括：数据战略、数据治理、数据架构、数据资产（新增）、数据标准、数据质量、数据安全、数据生存周期、数据应用流通。从架构师的角度，值得关注的是新增的"数据资产"域重点考察的三项能力和它们在架构层面的对应关系：
| DCMM 2.0 考察项 | 架构对应模块 | 关键技术能力 |
|---|---|---|
| 资产盘点 | 资产目录层 | 元数据图谱、业务域建模、资产标签 |
| 价值评估 | 质量引擎 | 六维度质量评分、成本/收益量化模型 |
| 资产运营 | 流通管控层 | 数据服务目录、API治理、调用审计 |
从九大域与数据中台架构的关系来看，数据架构、数据资产、数据标准、数据质量、数据应用流通这五个域与中台核心架构高度相关，数据治理、数据安全、数据生存周期三个域与安全管控和运维体系相关。对于架构师来说，DCMM 2.0不仅是一份评估标准，更是一份架构设计的"能力检查清单"——DCMM贯标评估中约有半数以上的能力域需要数据中台作为技术承载，平台架构的成熟度在相当程度上决定了企业DCMM评估能达到的等级。
四、理采存管用：从能力清单到工程分阶段的架构落地路径
架构设计不能停留在"需要具备哪些能力"——架构师还需要回答"分几个阶段建、每个阶段建什么、各阶段之间的依赖关系是什么"。
"理采存管用"五阶段方法论为架构师提供了一套经过工程验证的分阶段落地框架。它和DCMM标准、外部政策之间的关系可以概括为：DCMM定义了需要哪些能力（能力清单），政策规定了要达成什么目标（考核指标），理采存管用规划了分几个阶段来建（施工图纸）。
在数据资产化的架构语境下，五个阶段分别对应不同的架构建设重点：
- 理（资产盘点）→ 建设资产目录层：这一阶段的架构任务是构建业务域维度的资产视图。核心工作包括元数据采集适配器的扩展、业务术语到技术元数据的映射关系建模、资产目录的前端交互设计。产出物是一份可交互、可检索、可持续维护的企业数据资产目录。
- 采（数据归集）→ 打通数据供应链：这一阶段聚焦数据集成层的标准化。核心工作是设计统一的数据接入规范（包含数据格式、传输协议、异常处理等），建立从源系统到中台的标准化数据管道。对架构师而言，关键是定义好"接什么"和"怎么接"的标准，而非盲目接入所有数据源。
- 存（统一模型）→ 建立资产统一量纲：这是架构设计中最考验功力的环节。不同业务系统对同一业务实体（如客户、订单）的编码方式、口径定义各不相同，如果不在中台层做统一建模，资产目录就会出现"看起来有资产、实际上对不上账"的问题。架构上需要设计分层的数据模型（贴源层→标准层→资产层），并在标准层完成跨系统的口径统一。
- 管（质量保障）→ 嵌入质量引擎：这一阶段将质量评价能力嵌入数据流转的每一个环节。架构上包括：在数据接入层设置质量检查点（数据进来时是否满足基本规范），在标准层设置业务规则校验（数据口径是否正确），在资产层设置审计评估接口（能否输出结构化的质量报告）。质量不是"事后检查"而是"过程中保障"。
- 用（价值释放）→ 构建数据服务层：资产目录上线后，数据服务层将资产目录中的每一项资产暴露为可调用的数据接口。架构上需要设计API网关、服务目录、调用审计和SLA监控——让资产不仅仅是"账面上的数字"，更是"可被业务使用的资源"。
架构设计原则
基于理采存管用的分阶段路径，架构设计中有三个原则值得关注：
- 以"理"定范围，不要一开始就做大而全的架构。资产盘点清楚一个业务域，就先把这一域的采集、建模、治理、服务跑通，形成端到端的闭环后再横向扩展。这遵循了架构演进中的"纵向切片"原则——先跑通一条线验证架构可行性，再铺开。
- 质量引擎要内嵌而非外挂。入表场景对质量的要求是"常态化"和"可审计"，如果质量检查依赖独立工具或人工脚本，既无法保证持续性也无法满足审计要求。质量规则需要在数据流转的Pipeline中原生执行。
- 安全管控层要分层设计。内部权限管理和外部流通管控是两种不同的安全范式，架构上应作为独立的安全域来设计，避免在RBAC上叠加流通策略导致权限模型膨胀失控。
五、案例验证：一条已经走通的全链路路径
政策的窗口期不会一直敞开。在多数企业还在论证"数据能不能入表"的阶段，已有先行者完成了实践闭环。
福建某交投集团（企业名称已脱敏，下同）是负责城市数字化运营的核心主体，旗下拥有充电系统、调度系统、安防系统等多个业务系统，积累了大量数据资源。然而这些数据分散在上千张业务表中，家底不清、质量未知——这是多数企业在面对数据资产入表时的典型状态。
项目从资产盘点入手。团队花了数周时间梳理上千张业务表，依据资产入表条件划定边界，识别出充电订单、支付流水、用户档案、对账记录等核心数据资源，最终形成了一份标准化的《企业数据资产目录》。这一步解决的是"哪些数据能入表"的问题。
第二步转向质量保障。以GB/T 36344-2018六个维度为框架，对拟入表的数据资源进行全量自动化质量评价。通过问题清单协助完成了数据修复与整改，最终质量评价总评分达到99.53分，为会计师事务所提供了可审计的质量依据。这一步解决的是"数据能不能经得起审计"的问题。
第三步完成入表确认。律所依据质量报告和资产目录完成合规审查，资产评估机构基于治理成果进行估值，会计师事务所最终完成入表确认。企业资产负债表上新增了一笔数据资产，成为福建省某市首批完成数据资产入表的国有企业。
从架构师的角度回看这个案例，它验证了一个关键判断：数据资产入表链条上的每一个环节——资产盘点、质量评估、流通管控——都对数据中台提出了明确的架构能力要求。这些能力不是靠外部机构临时进场就能补齐的，它们必须内建在中台架构中。资产盘点（理）→ 标准建设（管）→ 质量评估（管）→ 入表确认（用），整个链条的顺利跑通，本质上是对中台架构资产化能力的一次全链路验收。
六、给架构师的三个行动建议
先做架构差距分析。 对照本文第二部分提出的三个核心模块（资产目录层、质量引擎、流通管控层），评估当前数据中台架构的覆盖度。如果这三个模块在当前架构中均为空白或仅有雏形，入表的架构准备就几乎为零——这不是渐进式迭代能解决的，需要一次结构性的架构升级。
选一个业务域做架构验证。 不要在全局论证中消耗窗口期。选1-2个数据相对规整的核心业务域，按理采存管用的路径跑通全链路——资产盘点→数据归集→统一建模→质量保障→服务发布。这个端到端的验证过程能在不投入过多资源的情况下，暴露架构设计中的关键问题。
把可审计性作为架构的非功能性需求。 架构评审中通常关注性能、可用性、安全性这些非功能性需求，但在入表场景下，可审计性（Auditability）应该被提升到同等重要的位置。具体来说：质量评价结果是否可追溯、资产变更是否可审计、流通操作是否留痕——这些应该成为架构评审的固定检查项。
参考来源：
[1] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月
[2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月，2024年1月1日起施行
[3] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》，2024年1月
[4] 全国信息技术标准化技术委员会，《GB/T 36073-2025 数据管理能力评估成熟度模型》（DCMM 2.0），2025年发布，2026年7月实施
[5] 全国信息技术标准化技术委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》，2018年发布
