一、问题本质：数据质量问题，根源多在架构
在数据治理实践中，我们常常面临这样的困境：数据质量规则配置了、质量门禁也设了，但数据质量问题依然反复出现------字段为空、格式错误、引用不存在的代码值......团队疲于奔命地"救火"，却始终无法根治。
问题的根源，往往不在数据平台，而在于数据产生的源头------应用系统。 应用架构定义了系统的功能模块划分、服务接口、数据交互方式，如果这些设计缺乏对数据入口的系统性约束，脏数据便从源头不断涌入。后续的数据清洗、质量检核，本质上是在为上游的架构缺陷"买单"。
💡 好数据是设计出来的。 在数据进入系统的那一刻就确保其正确性，远比事后花数倍成本去修复更高效。
三种错误模式的架构根源：
| 质量问题类型 | 表象 | 架构根源 |
|---|---|---|
| 一致性 | 同一客户在CRM叫"华为技术"，在ERP叫"华为技术有限公司" | 多系统对核心数据同时拥有写权限，缺乏单一数据源约束 |
| 准确性/有效性 | 日期填了"2024/13/01"、手机号填了"123" | 应用架构缺少分层校验设计，从界面到数据库未设防 |
| 有效性/合规性 | 上游系统变更导致数据格式错误，下游批量报错 | 缺少接口契约测试，文档与实现脱节 |
二、从架构层面解决数据质量的三个关键点
2.1 服务化与单一数据源：确保"写操作"的唯一入口
在应用架构（AA）规划中，应识别核心业务能力并将其封装为领域服务 。明确规定：对核心数据的CUD操作（创建、更新、删除），只有一个服务入口。
这对应到我的《以DCMM为标尺，衡量企业数据架构的成熟度》一文中"数据战略 → 数据架构"的思考路径。具体落地方式：
- 写操作集中化：所有对核心主数据（客户、物料、供应商）的写操作，必须通过主数据管理（MDM）服务调用；
- 读操作放开：各业务系统可按需读取；
- 接口契约化：服务接口采用OpenAPI规范，明确定义输入参数校验规则。
正如笔者在数据治理系列文章中所阐述的：MDM的落地，本质上就是通过应用架构的服务化改造，将数据的"写"操作收敛到唯一权威源。
与TOGAF & 4A框架的衔接 ：基于笔者在《企业架构方法论对决：TOGAF ADM与华为4A架构的融合实践》中建立的融合框架，这一步应在TOGAF ADM的C阶段（信息系统架构）完成------设计应用架构时，明确核心数据的C/R/U/D职责划分。
2.2 前端数据校验：从界面到接口的层层"守门"
基于信息架构（IA）定义的数据标准（数据类型、长度、格式、值域、必填性），在应用架构的不同层次实施校验：
| 校验层次 | 实施位置 | 校验内容 | 与4A框架对应 |
|---|---|---|---|
| 前端校验 | 用户界面 | 格式、必填、范围 | 业务架构BA输出的业务规则 |
| 网关校验 | API网关 | 请求格式、Token、必填字段 | 应用架构AA的接口定义 |
| 服务校验 | 业务服务层 | 业务规则、数据关联、引用完整性 | 信息架构IA的数据标准 |
| 数据库校验 | 数据库层 | 非空约束、外键约束、CHECK约束 | 技术架构TA的物理实现 |
关键机制------API契约测试：在服务间调用中，通过消费者驱动的契约测试（如Pact），确保接口提供方与消费方对数据格式的约定始终一致，防止"文档与实现脱节"。
这里形成了一个完整的跨四层架构映射：业务规则由BA定义 → 数据标准由IA定义 → 接口契约由AA约束 → 物理约束由TA执行。这正是笔者在《企业架构方法论对决：TOGAF ADM与华为4A架构的融合实践》中核心主张------"TOGAF定义'怎么做架构'，4A定义'架构包含什么'"的具体体现。
2.3 数据质量监控：作为独立服务嵌入技术架构
即使源头控制再严格，依然无法完全避免质量问题------上游系统改造可能破坏接口契约、程序bug可能写入脏数据。因此，数据质量检查必须作为技术架构（TA）中的独立服务组件，对关键数据流进行旁路监控和主动探测。
这一设计呼应了笔者在《以DCMM为标尺，衡量企业数据架构的成熟度》一文中"数据质量"能力域的要求，同时将质量检核"左移"到数据流转的关键节点：
- 实时旁路校验：在关键数据写入的MQ或API链路上，旁路获取数据副本执行质量规则，不合规记录告警；
- 定时批量巡检：针对大批量数据部署独立定时任务；
- 异常闭环：发现问题时自动触发告警，同时在数据治理平台的"问题台账"中生成工单。
组织保障------嵌入架构评审门禁 ：参照笔者《从混乱到清晰：如何从零搭建一套实用的数据管理体系》一文中"生存周期管理"的理念，将数据质量要求纳入上线评审环节。新建或改造的系统，必须通过以下检查方可上线：
- 数据标准符合性：系统字段是否引用已发布的数据元？
- 校验逻辑完整性：是否在接口层实现数据校验？
- 数据质量监控接入：关键数据流是否已配置质量规则？
三、典型场景分析：主数据创建的源头治理
以"客户主数据创建"为例，说明上述三个关键点如何协同工作。本场景复用笔者在《华为4A架构中的信息架构设计方法：从数据资源到战略资产的治理之道》中"业务对象识别"的成果------"客户"作为核心业务对象，其设计体现了BA→IA→AA→TA的完整映射：
| 架构域 | 设计要点 | 与之前文章的对应 |
|---|---|---|
| BA | 识别"客户"为核心业务对象 | 《华为4A架构中的信息架构设计方法：从数据资源到战略资产的治理之道》- 业务对象识别 |
| IA | 定义数据标准（统一社会信用代码格式18位、必填） | 《华为4A架构中的信息架构设计方法：从数据资源到战略资产的治理之道》- 数据模型设计 |
| AA | MDM服务封装写操作，API网关校验 | 服务化与单一数据源 |
| TA | 数据库UNIQUE约束、NOT NULL约束 | 分层校验的最后一层防线 |
架构改造后的治理流程：
- BA & IA层（业务与信息架构）：基于业务流程识别"客户"业务对象，定义数据标准（统一社会信用代码长度18位、正则校验规则、必填字段清单）；
- AA层（应用架构）：CRM调用MDM的"客户创建"API。服务校验：信用代码格式及唯一性校验、必填字段校验 → 任一不通过，API拒绝创建；
- TA层（技术架构）：MDM数据库的UNIQUE约束和NOT NULL约束作为最后一道防线；
- 质量监控服务：旁路捕获"客户创建"事件，校验数据完整性，发现问题记录到质量台账。
通过这套机制，从用户输入到数据落库的每一个环节都设置了"守门员"，将质量问题拦截在源头。
四、总结：从应用架构出发的数据质量治理闭环
数据质量的源头治理，核心在于将质量要求"左移"到应用架构设计阶段。
本文打通了四个架构域与数据治理的闭环：
- 业务架构（BA） → 定义业务流程，识别关键数据实体及其Owner；
- 信息架构（IA） → 定义数据标准和数据分布；
- 应用架构（AA） → 通过服务化设计收敛写操作入口，分层实施数据校验；
- 技术架构（TA） → 提供校验框架、契约测试工具、监控告警平台的技术支撑。
最终形成一条完整的主线：建架构 → 做评估 → 找差距 → 改架构 → 保质量，覆盖数据治理从规划到落地再到持续优化的全过程。
💡 好数据是设计出来的。 数据治理的真正抓手，不仅在于数据平台的清洗和监控能力，更在于源头应用系统的架构质量。当每一次数据录入都被严谨校验、每一次数据流转都清晰可溯、每一个数据问题都能追溯到源头系统时，企业的数据质量才真正进入了"自治"的境界。
五、文章系列
| 期数 | 文章 | 核心观点 | 在治理框架中的位置 |
|---|---|---|---|
| 第0期 | 《业务架构：数据治理的起点》 | 回答 "数据治理从哪开始" ，提出BA→IA→DA递进逻辑，明确业务部门应转型为业务架构Owner | 原点层 ------ 治理的"业务输入"和"架构牵引" |
| 第1期 | 《企业架构方法论对决：TOGAF ADM与华为4A架构的融合实践》 | 回答 "怎么做架构" ，提供架构开发流程框架（ADM） | 流程层 ------ 架构建设的"施工图" |
| 第2期 | 《华为4A架构中的信息架构设计方法：从数据资源到战略资产的治理之道》 | 回答 "架构包含什么" ，明确IA四步法 | 内容层 ------ 架构要产出的"构件清单" |
| 第3期 | 《以DCMM为标尺，衡量企业数据架构的成熟度》 | 回答 "做得好不好" ，提供度量标尺 | 评估层 ------ 架构成果的"检验标准" |
| 第4期 | 《架构视角下的数据质量源头治理：从应用架构到数据治理》 | 回答 "如何落地" ，将治理要求"编码"到应用架构 | 执行层 ------ 治理落地的"最后一公里" |
| 第5期 | 《数据网格如何重构数据管理责任》（规划中） | 回答 "下一步去哪里" ，展望技术架构新范式 | 演进层 ------ 架构的"未来方向" |