DCMM 三级评估框架下的数据治理平台技术架构与落地路径

一、三级评估对平台架构的核心要求

一家准备做 DCMM 评估的企业，最初以为难点在材料准备。制度文件可以补，组织架构可以画，平台功能截图也能凑。但真正进入自查阶段后，问题开始变得具体：数据标准在哪里执行？质量问题发现后谁来修、怎么复验？一张经营报表里的指标能不能追到源系统字段？数据资产目录是不是只有 IT 人员看得懂？

从架构视角来看，DCMM 三级（GB/T 36073-2025，稳健级）关注的不是平台有没有某个功能模块，而是数据管理能力是否已嵌入日常运行流程并形成可验证的闭环。平台架构需要支撑的不是“功能菜单的齐全度”，而是从标准制定到执行留痕、从问题发现到修复复验、从资产登记到业务使用的完整技术路径。

二、四类核心证据的技术支撑需求

从平台架构设计角度看，DCMM 三级准备中需要重点支撑四类证据的技术链路。

证据类型	评估追问方向	平台需提供的技术支撑
标准执行证据	标准是否只是文档？	标准在线管理、落标映射、执行记录追踪
质量闭环证据	问题发现后谁修、怎么验？	规则引擎、监测调度、告警分发、工单流转、复验归档
元数据与血缘证据	数据从哪来、影响到哪？	元数据自动采集、血缘自动解析、变更影响分析
资产使用证据	数据是否真的被业务使用？	资产目录检索、权限审批流、API 网关、使用统计

这四类证据对平台架构提出了一个共同要求：需要一条从“制度定义”到“执行记录”再到“结果验证”的完整数据链路，且链路中的每个节点都需要可追踪、可审计。

三、数据标准模块的架构设计要点

很多企业不缺数据标准文档，但标准与物理数据脱节的问题普遍存在。DCMM 三级要求的数据标准能力在架构上需要解决三个核心问题。

第一，标准的在线化管理。 数据元、代码集、业务术语、指标口径不能只存在于 Word 和 Excel 中，需要在平台中实现编制、审核、发布和版本更新的全生命周期管理。

第二，标准与数据对象的关联映射。 一个标准字段发布后，需要能够映射到对应的数据库表、字段、主题域和数据资产。这种映射关系是标准能够进入日常开发和治理流程的关键——可以理解为在平台的元数据层建立标准到物理模型的桥接层。

第三，标准执行的追踪链路。 哪些字段已落标、哪些字段不符合规范、整改状态如何，需要形成可追踪的过程记录。这意味着平台需要在数据接入、建模、质量检查等环节嵌入标准校验节点。

华东某大型化工企业（企业名称已脱敏）在建设数据中台时，优先统一物料、产品、指标口径等核心标准，而非先追求可视化展示。该企业原本 MES、ERP、CRM 等系统相互独立，物料编码不统一，经营分析依赖人工对账。通过建立企业级数据标准管理机制，为产销协同和经营分析打下了统一语言基础。

四、质量闭环的架构模式：强校验与旁路监测

数据质量是三级评估中最容易暴露问题的领域。从架构层面看，质量模块需要支撑从“发现”到“复验”的完整闭环，而非仅仅输出质量报告。

架构设计上需要区分两种模式。前置强校验适合关键主数据场景，数据入库前校验编码规则、必填字段等，不通过则拒绝入库。旁路监测则适用于大规模数据归集场景——数据正常入库，质量引擎并行扫描，发现问题后通过标记、告警和工单机制触发整改，不阻断主数据链路。

（此处原图为强校验与旁路监测两种模式的对比示意图，展示了两者在数据流中的位置差异：强校验位于入库节点之前，旁路监测为入库后的并行扫描通道。）

江西某国控集团的实践可以说明这一点。该集团原有 10 余套分散的业务系统，监管数据质量无管控。平台构建了完整性、准确性、一致性、及时性、唯一性等稽核规则，实现数据自动检测、异常告警、问题定位和整改跟踪。质量管理进入了监管数据的日常运行机制。

从架构设计原则来看，质量模块的核心能力不在于配置了多少条规则，而在于是否具备可配置的规则引擎、灵活的分发策略和完善的闭环追踪链路。

五、元数据和血缘的架构要求

当业务部门问“这个指标从哪来”时，如果数据团队只能翻脚本、问开发，说明元数据能力还没有建立。

从技术架构角度看，元数据模块至少需要三层能力：

第一层，基础元数据自动采集。 对接入数据库后自动采集表结构、字段类型、字段注释、数据量等基础信息，降低人工维护成本。这要求平台具备多数据源的元数据采集适配器。

第二层，平台内链路自动记录。 数据在平台内完成集成、加工、归集、共享时，输入输出关系需自动记录。这要求在 ETL/ELT 引擎、数据开发模块中嵌入血缘采集钩子。

第三层，平台外链路手动补全。 现实中企业总有外部脚本、第三方工具或历史任务。平台未覆盖的环节，血缘需要支持手动维护节点和连线，不能依赖“全自动”承诺。

江苏某市监局建设数据治理平台时，将全盘元数据管理作为基础能力。平台建立全局统一的数据资源目录，实现元数据自动采集、变更同步和版本追溯，让监管数据资产“看得见、找得到、读得懂”。

六、资产目录的设计原则：从技术台账到业务入口

很多企业的资产目录实质上是一张技术台账，业务人员难以使用。在 DCMM 2.0 背景下，数据资产和应用流通的重要性进一步提高。

从架构设计角度看，资产目录应具备以下特征：业务语言可检索（需要业务术语与资产标签的关联设计），数据质量状态可见（需要质量模块与资产目录的状态同步），权限申请在线化（需要审批流引擎），API 或数据集可服务化发布（需要 API 网关与数据服务层的集成），调用和使用情况可统计（需要埋点和统计能力）。

三级能力建设的核心认知：数据治理不是把数据管在平台里，而是让可信数据被业务安全、稳定、可控地使用。资产目录的架构设计需要从“管理视角”转向“服务视角”。

七、落地路径：工程化拆解 DCMM 三级要求

DCMM 给出能力目标，但企业还需要一条工程化路径把目标拆成可实施的任务。行业中一些厂商（如龙石数据）提出的“理采存管用”方法论，可以作为工程实施视角的拆解参考。

理采存管用	对应建设重点	平台动作
理	目标、组织、资产家底	数据资产盘点、治理职责、标准框架
采	数据来源与归集	多源异构接入、全量/增量同步
存	模型与架构	ODS-DW-ADS 分层、主题域模型
管	标准、质量、安全	元数据、主数据、质量规则、分类分级
用	共享和应用	资产目录、API、报表、AI 用数

需要说明的是，这是一种工程实施视角下的对应关系示意，并不是将 DCMM 能力域与产品模块做严格一一对应。“理”不仅包含战略规划，也涉及组织、制度和资产盘点；“管”也不只是质量规则，还包括标准、主数据、安全和责任闭环。

选型时，建议关注这些模块能否串成一条可执行的技术链路，而非只看功能清单。

八、常见问题

DCMM 三级是不是只要买数据治理平台就能过？

不是。平台提供的是执行、留痕和复验能力。组织、制度、责任机制仍然需要企业自身建立。没有治理组织和业务责任人，平台流程也无法真正运行。

平台演示时应该重点看什么？

建议用一条真实数据链路验证：从数据接入、标准关联、质量监测、问题定位，到资产发布和业务申请。能跑完一条闭环，比看完功能清单更有价值。

旁路监测会不会影响数据入库效率？

旁路监测的设计是不阻断入库。数据正常入仓，质检并行扫描，发现问题后生成告警和整改任务。适合在不修改业务系统的前提下建立持续质量治理机制。

三级建设从哪里开始比较稳妥？

先选择一个高价值数据域，完成标准、质量、元数据和资产目录的最小闭环。跑通后，再横向扩展到更多业务域。

数据治理平台的技术架构选型有哪些关键评估点？

建议关注三个维度：一是模块间是否具备自动化联动能力（如标准变更后质量规则能否自动感知）；二是血缘解析的覆盖深度（是否支持字段级血缘、跨系统血缘）；三是闭环追踪的完整性（从标准执行到资产使用的全链路是否可审计）。