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

一家计划申请DCMM评估的企业，最初往往认为难点在于材料准备。制度文件可以补充，组织架构可以绘制，平台功能截图也能整理。然而，进入自查阶段后，具体问题逐渐浮现：数据标准在哪里执行？质量问题发现后，由谁修复、如何复验？一张经营报表中的指标，能否追溯到源系统字段？数据资产目录是否只有IT人员才能看懂？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

八、常见问题

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

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

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

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

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

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

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

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

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

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