摘要
数据中台建设中长期存在一个架构级决策难题：平台工程与数据治理的启动顺序。平台优先路线追求快速交付可见成果，但面临数据不可信的系统性风险；治理优先路线保障长期数据质量，却可能在前期陷入"蓝图困境"而失去组织支持。本文从架构演进视角出发，提出"螺旋迭代"的技术路径，论证治理基线应先于大规模平台建设启动，通过"理→采存管用→用治协同"三阶段模型实现平台能力与治理深度的同步增长，并给出架构设计原则和团队协作框架。
一、问题定位：两种架构范式的对撞
从架构层面审视，"先建平台还是先做治理"的本质是两种不同的技术范式选择。
平台工程范式（Platform Engineering Paradigm） 的架构假设是：数据可用性优先于数据可信性。其技术路径为快速搭建数据集成与计算层 → 接入多源数据 → 构建 BI 与分析服务层 → 在取得业务验证后回溯补齐治理能力。这一范式的架构风险在于：缺失了数据标准层和元数据管理层的平台架构，在后续规模化扩展时会遭遇数据口径一致性危机，导致上层应用输出不可信的结果。
数据治理范式（Data Governance Paradigm） 的架构假设是：数据可信性是数据可用性的前提。其技术路径为先建立数据标准体系和质量规则引擎 → 完成数据资产盘点 → 构建元数据管理层和资产目录 → 在此基础上搭建数据平台承载。这一范式的架构风险在于：治理体系建设周期长、前期缺乏可交付的运行态成果，容易陷入"过度设计"而失去组织推动力。
两种范式并非对立关系，而是同一架构问题在不同阶段的侧重。架构师需要回答的核心问题是：是否存在一条技术路径，在保障数据可信性的前提下，实现快速验证和持续交付？
二、架构反模式分析
反模式一：在缺失数据标准层的情况下启动大规模数据集成
某大型化工企业的实践是典型案例。其平台架构在未建立主数据管理层（Master Data Management Layer）的情况下，直接启动了 MES 与 ERP 系统间的数据集成管道。三个月后，因物料编码标准缺失导致映射关系错误——同一实体在不同系统中的标识符完全不可匹配——集成成果几乎全部作废。
架构根因：数据集成层（Data Ingestion Layer）的映射逻辑依赖于数据标准层（Data Standard Layer）提供的统一实体标识。跳过标准层直接构建集成管道，本质上是让下游依赖上游尚未确定的输入，系统性地引入了数据不可信的架构债务。
重构路径：优先构建主数据编码标准和质量规则引擎，然后重构集成管道的映射逻辑。重构后交付及时率从不足 70% 提升至 91%，库存周转率提升 28%。
反模式二：在缺失质量管控层的情况下直接构建数据服务层
另一种常见反模式是：平台接入数据后，直接构建可视化大屏和 BI 报表，跳过数据质量稽核（Data Quality Auditing）环节。当业务方发现同一指标在不同系统中数值不一致时，整个数据服务层的可信度被系统性摧毁。
架构根因：数据服务层（Data Service Layer）应依赖质量管控层（Data Quality Layer）提供的可信性保证。在质量规则未嵌入数据处理管道的情况下输出数据产品，等同于在没有校验的情况下发布软件版本。
三、螺旋迭代架构：三阶段渐进式技术路径
基于对两种反模式的分析，推荐采用"治理基线先行、平台能力同步"的螺旋迭代架构。该架构将治理工作内建至平台的数据处理管道中，而非作为外挂的后置校验。
第一阶段：治理基线建立（4-6 周）——架构重点：数据标准层与质量规则引擎
此阶段的架构目标是建立数据治理的"控制平面"（Control Plane），为后续的数据处理"数据平面"（Data Plane）提供标准和规则支撑。
架构设计要点：
- 数据资产盘点：梳理核心业务系统（ERP、CRM 等）的关键数据表与字段，形成数据资产目录。这是后续数据建模和集成的基础输入。
- 主数据标准定义：针对关键业务实体（物料、客户、供应商等），制定统一的标识符规范。这是解决跨系统数据一致性的内核。
- 质量基线规则引擎：为核心字段定义可自动执行的质量规则——非空约束、值域校验、格式规范——建立可量化评估的质量基线。
架构产出：数据资产清单 + 核心主数据标准规范 + 质量基线评估报告。
第二阶段：数据平面闭环验证（6-8 周）——架构重点：数据管道的治理嵌入
选择 1-2 个业务痛感最强的数据域，完整构建从数据采集到数据服务的全链路管道，并在管道各节点嵌入治理规则。
架构设计要点：
- 数据采集层设计：按需归集选定数据域的多源异构数据（数据库、文件、API 等），接入层设置标准符合性校验节点。
- 数据建模与存储层设计：依据第一阶段标准进行数据模型规划（星型/雪花模型选型），在数据仓库中规范存储。
- 质量管控嵌入点设计：在数据入库和加工流程中嵌入质量规则执行节点——不是在数据处理完成后做质量检查，而是让质量规则成为数据处理管道的一部分。
- 数据服务层设计：基于治理后的可信数据，构建 1-2 个业务应用场景（客户 360° 视图、精准营销标签等）。
架构产出：一个内建治理能力的数据处理管道 + 一个验证可信的数据应用场景。
第三阶段：架构横展与纵深（持续运营）——架构重点：可复制的治理模式与平台能力演进
将第二阶段验证的架构模式推广至更多数据域，同时深化各层的治理能力。
架构设计要点：
- 横向扩展策略：将已验证的治理标准、质量规则模板、管道设计模式复制到产品域、供应链域等新域。
- 纵向深化策略：基于业务反馈迭代标准体系和质量规则库；扩展数据服务形式（可视化报表、指标分析、API 服务）。
- 体系完整化：逐步补充元数据管理层、数据安全层、数据血缘追踪能力，形成完整的数据架构栈。
架构产出：覆盖多域的企业级数据架构 + 常态化的数据运营体系。
路径选择原则
江苏某自动化控制企业的实践验证了"治理基线先行"的有效性：在数据进场之前建立标准校验"安检通道"，让治理规则成为平台架构的内建模块而非外挂插件。市面上已有成熟的数据中台产品支撑这种内建治理架构——其治理能力（标准管理、质量稽核、元数据管理、资产目录）作为平台核心组件直接嵌入数据处理管道，不依赖平台完全建成即可独立运行标准定义和质量规则配置阶段。
四、给技术负责人的架构决策框架
如果你作为架构师正面临团队内部的范式之争，以下决策框架可帮助将争论转化为工程行动：
第一步：范式对齐（1 周）。 让两派用自己的语言描述对方的架构关切。平台派说明"治理派担心的架构风险是什么"，治理派说明"平台派担心的交付压力是什么"。底层目标一致——都希望构建可用的数据中台，分歧仅在于实现路径。
第二步：选域试点（第 2 周确定）。 不要在全局架构层面争论。选择一个业务痛感最强、数据源相对集中的数据域（如客户域），在该域上验证螺旋迭代架构模式的可行性。
第三步：交替里程碑。 每月交替产出治理成果（标准文档、质量报告、资产清单）和平台成果（接入新域、上线新服务）。双侧都有可交付的阶段性产出，维持团队信心和组织支持。
五、FAQ
Q1：治理基线先行是否意味着平台建设延后？
否。两者的关系是同步推进，而非顺序排队。第一阶段启动治理基线建设的同时，轻量平台同步搭建。区别在于平台范围与治理进度对齐：治理覆盖到哪个数据域，平台就承载到哪个数据域，不追求一次性全面铺开。
Q2：团队规模有限（如 5 人），如何执行？
选定最痛的数据域，集中资源在 2 周内完成核心标准定义和质量规则配置，随后 4 周搭建轻量平台跑通全链路验证。5 人团队的核心策略是"单域打透"而非多域铺开。一个跑通的域提供方法论模板和组织信心。
Q3：决策层要求 3 个月产出可见成果，治理能否满足？
可以。第一个月即可交付数据资产清单（系统、表、字段的全面盘点）和数据质量评估报告（数据现状的量化描述）。这两份交付物本身就是高价值的阶段性成果，且为后续所有工作的决策输入。
Q4：如何选择第一个试点的数据域？
优先选择以下特征的数据域：业务痛感强（每日因数据不一致产生实际摩擦）、数据源集中（2-3 个系统覆盖主流程）、业务价值可量化（有明确的应用场景可验证收益）。客户域、物料域通常满足这些条件。
Q5：治理过程中发现的数据问题超出预期怎么办？
问题超出预期恰好验证了"治理先行"决策的正确性。建议对发现的问题进行分级：P0 级（影响业务决策准确性的数据错误）立即修复；P1 级（影响跨系统一致性）纳入第二阶段修复计划；P2 级（规范性不足）建立分阶段整改路线图。数据的系统性问题不会因平台建好而自动消失。
结语
数据中台建设中的分歧，本质上不是"要不要治理"的价值判断，而是"治理何时嵌入架构"的技术决策。
平台先行的架构反模式是用交付速度换取技术债务——交付越快，后续返工成本越高。纯治理路线的架构反模式是用蓝图完整性消耗组织信心——设计越完美，落地时机越遥远。
推荐的螺旋迭代架构将治理定位为平台的内建能力而非后置补偿：治理基线决定平台的下限，平台能力决定治理的上限。当团队下一次面临"先建还是先治"的争论时，建议将问题重构为"我们选择哪个数据域率先验证螺旋迭代架构的可行性"。从范式争论走向工程验证，才是走出架构纠结的真正起点。
参考来源
- DAMA International,《数据管理知识体系指南》(DMBOK2) — dama.org
- GB/T 36073-2025《数据管理能力成熟度评估模型》(DCMM 2.0) — 全国标准信息公共服务平台
