一、选型误区：功能清单膨胀与架构能力错配
"这家厂商功能很全，标准、质量、元数据、主数据、资产目录、AI 都有。但我们上线后，业务部门还是不知道去哪找数据。"
作为架构师，选型时最容易碰到的情况是：厂商的功能清单一页拉不完，但架构真正支撑闭环的地方却没有几个。演示环境跑得顺畅，生产环境一到多组织、多租户、多源异构场景就暴露短板。
数据治理平台选型的核心问题不是"功能够不够多"，而是"架构能不能支撑闭环"。功能堆叠带来的是短期安全感，但真正影响项目成败的是平台在资产盘点、数据集成、模型组织、治理管控和业务消费五个环节的架构连续性。
从架构角度看，"理采存管用"提供了一套更有操作性的评估语言。它不先问"这个平台有多少功能"，而是依次检查：资产层有没有建立标准化的描述体系，采集层是否能稳定运行增量链路，存储层是否支持多空间分层模型，管控层是否实现了旁路监测和落标闭环，服务层是否以 API 优先的方式面向业务暴露数据。
关于项目思维与治理思维的差异，可以这样理解：项目思维关注的是"功能有没有"，治理思维关注的是"能力通不通"。前者盯着功能清单逐项打钩，后者沿着数据从产生到消费的端到端链路验证每个环节的架构支撑。
二、选型前的架构前置问题
在接触厂商之前，建议架构师先理清三个前置判断。
第一个问题：当前最痛的是哪一层的问题？
如果核心瓶颈在数据孤岛，应重点评估集成层和数据架构能力。如果核心瓶颈在数据可信度，质量规则引擎、主数据管理、标准管理和工作流闭环是关键技术点。如果核心瓶颈在数据消费，资产目录的检索设计、API 网关的服务化能力和 AI 用数入口的架构实现就要提前纳入评估。
第二个问题：组织形态对架构提出什么要求？
单体企业、集团企业、政务多部门场景，对平台架构的要求完全不同。单体企业可能关注轻量部署和快速见效；集团企业则要考虑"中心化标准 + 去中心化执行"的架构模型；政务场景还要处理跨部门共享的权限边界和租户隔离。
第三个问题：是一次性构建全域架构，还是先在一个数据域形成参考实现？
建议先选择一个高价值数据域作为锚点域，比如客户域、供应商域、物料域。在一个域内跑通"理采存管用"的架构链路，形成参考实现，再横向扩展到更多业务域。这种方式在架构可控性上远优于一开始就追求全域覆盖。
三、模块一"理"：资产层的架构设计原则
"理"对应的是数据治理平台的基础层——资产描述体系。很多项目跳过了这一步，直接从数据接入和报表可视化切入，导致后续标准混乱、口径不一致、责任不清。
架构评估时，"理"模块至少关注四个层次。
第一，资产目录的建模设计。平台应支持按业务域、系统来源、责任部门、更新频率、质量状态等多维标签组织资源，而非简单罗列表结构。
第二，标准管理的生命周期。数据元、代码集、指标口径、业务术语应支持在线编制、审核、发布、版本管理和迭代，标准变更需要有追溯能力。
第三，主数据的统一标识。对于客户、供应商、物料、组织、项目等核心实体，平台应提供统一的编码生成、映射管理和匹配规则。
第四，治理责任的配置体系。数据资产、数据标准和质量问题应有明确的责任人绑定，否则后续的工单流转和问题闭环缺乏组织锚点。
江苏某建筑装饰集团（企业名称已脱敏）是一个典型的架构验证场景。该集团旗下 200 余家区域子公司、近百个项目部，物料、供应商和项目部编码各自为政。在架构层面，团队先统一核心主数据编码模型，再构建集团级数据底座。治理后，跨公司对账从 5 天缩短至 1 天，数据纠纷减少 80%。
这说明，选型时不能只看"有没有主数据模块"，还要看主数据管理的架构设计是否支持多层级编码体系统一和映射。
四、模块二"采"：集成层的稳定性架构要求
"采"解决的是数据如何进入平台的架构问题。在 POC 阶段需要验证的不是"支持某数据源"这种二元判断，而是采集链路在真实环境下的稳定性。
评估采集层时关注四个架构维度。
第一，数据源适配的广度。应覆盖主流关系型数据库（Oracle、MySQL、SQL Server、PostgreSQL）、国产数据库、API、文件、消息队列等。需注意，数据治理平台通常不直接处理物联网协议，设备数据应先由物联网平台完成接入，再由数据中台对接获取。
第二，全量与增量的链路设计。全量同步是初始化需求，增量同步、失败重跑、断点续传、任务调度和并行度控制才是长期运行的核心架构能力。
第三，配置层的可用性。可视化任务编排、拖拽式数据加工、日志观测和异常预警直接影响运维团队的长期效率。
第四，接口标准化。过度依赖定制化对接会在系统变更时持续产生集成债务，标准接口和可配置的适配器模式是更可持续的架构选择。
POC 验证建议：让厂商接入一套真实数据库，跑一次全量同步，再配置一次增量同步，重点观察配置步骤、运行日志、异常处理机制和任务重跑策略。这比阅读兼容性列表更有说服力。
五、模块三"存"：存储层的分层模型与多空间架构
数据进入平台后如果仍然散乱堆放，治理价值无法释放。"存"关注的是数据建模、分层组织和空间架构。
架构评估从两个维度切入。
一是模型分层能力。平台是否原生支持 ODS（操作数据层）、DW（数据仓库层）、ADS（应用数据服务层）的分层设计？分层规则是否可配置？是否支持按主题域组织数据模型？模型定义是否能直接影响数据存储、开发规则和治理策略？
二是多空间架构。对于集团企业和多部门场景，工作空间的隔离与共享模型是核心架构决策。平台应支持总部统一标准定义，同时允许子公司或部门在独立空间内管理自己的数据资产、权限和应用。跨空间的共享和审批流是必检项。
江苏某建筑装饰集团的"集团中台+公司空间+项目场景"三层架构体现了这种设计。总部统一主数据和治理标准，子公司保留独立操作空间，项目部按场景使用数据。市场上已有部分数据中台产品（如龙石）在架构层面采用了这种多空间模型，支持标准继承和权限隔离。
POC 验证建议：要求厂商现场创建两个独立业务空间，验证标准继承、权限隔离和跨空间数据共享。这能快速区分"真正支持多组织治理"和"用角色权限模拟组织边界"两种实现。
六、模块四"管"：管控层的核心架构实现
"管"是数据治理平台的管控核心，决定数据是否可理解、可信任和可管理。
| 子能力 | 架构关注点 | POC 验证 |
|---|---|---|
| 元数据 | 自动采集机制、变更感知、手动补全入口 | 接入 50 张表，观察自动采集覆盖率和字段注释完整度 |
| 主数据 | 编码规则引擎、映射关系管理、版本控制 | 创建一个供应商或物料主数据标准 |
| 数据质量 | 旁路监测架构、规则配置方式、工单闭环 | 配置一条真实规则，跑扫描、告警、工单、复验 |
| 数据安全 | 分类分级模型、脱敏策略、权限粒度 | 用不同角色访问同一数据集，验证权限边界 |
关键术语的架构含义：自动采集元数据，指平台通过连接器自动抓取表结构、字段、注释、变更历史，而非依赖人工录入。旁路监测，指数据正常入仓后，质量模块并行扫描，发现问题后打标记、告警或生成工单，不阻断原有数据链路——这是一种非侵入式的架构设计。落标，则是在已发布的数据标准与实际表字段或数据对象之间建立映射关联，并检查实际数据与标准的匹配情况。
POC 建议：拿一个真实的质量痛点做端到端验证，比如"同一供应商在三个系统里名称不一致"。让厂商演示规则定义、扫描执行、问题定位、工单分派、修复操作和复验确认的完整链路。
七、模块五"用"：服务层的 API 优先与业务友好设计
数据治理平台的最终交付形态不是一套管理后台，而是面向业务的数据服务。
"用"模块的架构评估关注四类能力：资产目录是否支持业务语言的全文检索和语义匹配；数据申请流程是否线上化、可审批、可追溯；API 或数据集是否支持自助发布和生命周期管理；业务用户是否能通过报表门户或 AI 对话入口降低使用门槛。
江苏某市监局的数据治理平台建设体现了服务层的架构价值。该局原本面临数据散、标准乱、共享难、监管繁等典型问题。平台建设了全盘元数据管理、数据质量管理、API 全生命周期管理和统一门户。上线后，监管人员日均登录系统次数减少 90% 以上，数据需求响应从天级缩短至分钟级。
这类成果的关键不在于做了多少张报表，而在于前面理、采、存、管四个模块形成的可信数据，通过 API 优先的服务架构转化成了业务人员可自助访问、申请和调用的数据服务。
POC 验证建议：安排一名非技术用户参与测试——用业务语言搜索一个数据资源，查看质量状态，发起申请，并将查询结果发布为 API 或数据集。这个端到端流程能直接检验服务层的业务友好性。
八、五模块架构评估速查表
| 模块 | 架构核心问题 | 关键技术能力 | 应回避的回答 |
|---|---|---|---|
| 理 | 资产层是否标准化 | 多维目录、标准生命周期、主数据编码 | "先实施后慢慢整理" |
| 采 | 集成层是否稳定 | 多源适配、增量调度、标准接口 | "接口可以定制开发" |
| 存 | 存储层是否可扩展 | 分层模型、多空间隔离、跨空间共享 | "一个实例管所有组织" |
| 管 | 管控层是否闭环 | 自动元数据、旁路质量、细粒度权限 | "质量规则要写 SQL" |
| 用 | 服务层是否面向业务 | 业务检索、API 网关、AI 用数入口 | "业务找 IT 提需求即可" |
这张速查表的作用不是替代详细的技术招标文件，而是帮助架构师在选型中聚焦关键技术决策点。
九、从方法论到架构实现：能力域映射
理采存管用是一套检查产品架构是否闭环的框架。选型时看"理"，关注的是资产描述层的标准化程度；看"采"，关注的是集成层的链路稳定性；看"存"，关注的是存储层的分层模型和空间架构；看"管"，关注的是管控层的非侵入式监测和落标闭环；看"用"，关注的是服务层的 API 优先设计和业务友好性。
从架构映射的角度，理采存管用与 DCMM（GB/T 36073-2025）九大能力域的关系可理解为：数据战略和数据治理锚定"理"，数据架构锚定"存"，数据应用锚定"用"，数据标准和数据质量锚定"管"，数据安全作为横切面贯穿全流程。选型时，可以先用这套映射关系将方法论层面的要求翻译为可验证的技术能力项。
上述映射是选型视角下的示意，不应理解为标准能力域与产品模块的一一绑定。企业应结合自身数据基础、组织形态和预算节奏确定技术优先级。
十、FAQ
Q1：中小企业是否需要五个模块一次性全上？
不需要。从架构角度看，建议从最痛的一个数据域切入，先跑通"理+管+用"的最小架构闭环，再逐步补强采集、建模和自动化能力。
Q2：功能清单看起来都差不多，怎么判断架构差异？
用真实数据做 POC。不要只听"支持"，而要验证厂商能否在架构层面跑完标准定义、数据接入、质量扫描、问题闭环、资产发布和业务申请的一条完整技术链路。
Q3：开源工具能不能替代数据治理平台的完整架构？
部分层可以，例如采集引擎、调度框架、数据开发工具。但主数据建模、质量闭环、权限体系、资产目录和组织流程通常需要大量自定义集成，长期维护的架构债务要提前评估。
Q4：理采存管用这个框架是否只适用于特定产品？
不是。它是一套通用的架构评估框架，可用来检查任何数据治理平台是否覆盖完整的数据管理闭环，不绑定特定厂商或产品线。
