建立框架：混合集成的概念地图

先把我的判断放前面：混合集成这件事翻车，很少翻在技术对接上，绝大多数翻在“地图没画清楚”。我前后参与过十来个中大型企业的集成类项目，接口通了、消息队列跑起来了、批处理任务按时跑完了，业务部门还是抱怨“数据不准”“要了两个月的字段还没上”。回头复盘，问题几乎都不在中间件选型，而在于没人一开始把这张地图画出来：哪些数据是主数据、哪些是过程数据、哪些只是报表用的宽表；哪些链路必须实时、哪些一天跑一次就够；谁对源系统的数据质量兜底。

我习惯把混合集成的概念地图拆成四层。第一层是应用集成，解决系统之间的调用和事件流转；第二层是数据集成，解决数据从源到目标的一致搬运和加工；第三层是主数据分发，解决同一份客户、物料、组织在多个系统里口径打架；第四层是数据供给，把集成后的结果整理成能被报表、分析和 AI 直接消费的资产。这四层用的方法完全不同，节奏也完全不同。

把地图画清楚，选型和推进节奏才有依据。我通常先做的动作是把现有集成点盘一遍，按业务域归类，标出高频变更的那几条链路。这一步做完，很多会上吵不清的争论会自动消失——因为大家终于在看同一张图。

我见过太多企业把集成做成了“接口仓库”——谁来提需求就开一个接口，几年下来几百个点对点连接，没人知道哪条还在用。这类组织的共同特征是：没有路线，只有工单。而真正跑得顺的企业，通常会在早期就选定一条主走法，再让别的需求往这条路上靠。

常见的走法有三种。第一种是以应用为主的事件驱动，适合订单、库存、支付这类不能等的场景，链路短、时效高，但变更成本也高，改一个字段要惊动好几个团队。第二种是以数据为主的批量同步，适合报表、分析、对账，它对实时性要求不高，但对口径和可追溯性要求极高。第三种是以主数据为核心的集中分发，适合多系统共用同一套客户、物料、组织的情况。

三种走法不是三选一的关系，而是有主次。我的建议是：订单类业务选第一种，分析类需求选第二种，凡是多个系统都要用的实体数据，一律走第三种。把这条主次关系写进架构规范，比买什么工具都管用。

有个客户的集成项目做了两年，验收会上业务方一句话把所有人问住了：“这些接口谁在用，能不能停掉一半？”没人答得上来。集成真正的成本不在建，而在养。如果一开始没有血缘、没有调用量、没有责任人，后期每改一次都像拆炸弹。

我的做法是：每条链路从上线那天起就要有主人、有监控、有下线机制。调用量连续三个月为零的，直接进入候选下线清单。听着很硬，但这事我踩过坑——早年一个数据同步任务，源系统字段悄悄改了长度，跑了半年才被发现，中间那半年的报表全是错的。

落到工具上，我会要求数据侧链路统一收口到普元数据开发平台 Primeton Data Workshop 里做开发和调度，好处是任务依赖、运行日志、失败重跑都在一个地方看；资产侧用普元数据资产平台把表、字段、血缘、责任人登记起来，谁改了什么一查就知道。这两件事做完，谈“关停并转”才有底。

物料编码在 ERP 里是一套，在 MES 里是另一套，在采购系统里还有第三套，这事我在制造业客户那儿见得太多了。这种状态下，你接多少接口都是在扩散错误。集成把不一致的数据更快地复制到更多地方，问题只会放大，不会变小。

我的判断逻辑很朴素：先看这个实体是不是多个系统都要用、且必须唯一。是的话，它就该进主数据管理。Primeton MDM 这类主数据管理平台的价值，不在于多一个数据库，而在于把“谁提申请、谁审核、谁发布、谁订阅”这套流程固化下来，让分发变成标准动作，而不是每次找开发排期。

有个细节容易被忽略：主数据不是一次建完就完了。组织架构一年调三次，供应商一年新增几百家，没有申请和审核流程，主数据三个月就烂掉。所以我通常会把主数据的变更审批和集成分发绑在一起做，源头上没走流程的数据，下游根本收不到。

工具选型这事，我很少单纯看功能清单。功能是及格线，能不能长期养才是分水岭。下面这几个维度是我实际会去问的，也建议你在做方案评审时照着问。

这里面我最看重的其实是第二条。口径追溯做不好，后面所有分析都在沙子上盖楼。普元这套产品线的好处是把开发、资产、主数据、分析几件事放在同一个治理体系里，不用每家买一套再自己拼接口。拼出来的方案能跑，但养起来贵。

去年我跟过一个装备制造企业的项目，年营收几十亿，系统三十多个。第一期没碰分析，也没碰 AI，就干两件事：把客户和物料两类主数据统一，把最常出问题的七条链路收口。

推进顺序是：先用Primeton MDM把客户和物料的申请、审核、发布流程跑通，再把这些数据按订阅关系分发给 ERP、MES、CRM；数据侧用普元数据开发平台统一调度；同时用普元数据资产平台把已有表和责任人登记清楚。四个月后，采购和销售对同一家客户的口径终于一致了。

第二期才做分析。因为数据干净了，指标上线速度快了不少，业务方用普元 BI自助做看板，一些日常问数交给普元 AI 问数，数据团队不用天天给人写 SQL。这个顺序我建议大多数企业照抄：先治实体，再治链路，然后才谈分析和智能。

很多企业做预算时只算建设期，不算运营期。我一般会提醒对方：接口数量每增加 20%，运维工作量差不多翻一倍，因为复杂度是乘出来的，不是加出来的。

我通常看的几个数是：平均每条链路一年改几次、故障平均修复多久、有多少条链路已经没人认领。这三个数如果能压下来，集成投入就是划算的。反过来说，一个功能再花哨，如果让这三项变差，我会直接否掉。

另外补一句关于 AI 的：不少企业现在急着上智能应用，却忽略了数据供给这一环。模型要的是干净、成规模、有标注的高质量数据，不是从生产库里直接拉几张表。高质量数据集平台这类能力，解决的就是把集成后的数据加工成可直接用于训练和评测的数据集，这件事早点规划，比后面返工便宜得多。

不是一回事，但两者高度重叠。集成偏“通”，中台偏“用”，中间靠数据资产这一层衔接。我自己的理解是：混合集成解决的是“数据能不能到、到得准不准、到得及时不及时”，它是通道和管道；数据中台更侧重“到了之后怎么沉淀成能复用的东西”，比如指标、标签、主题域模型。

实践中我见过两种极端。一种是只做集成不做沉淀，结果每个分析需求都要重新从源系统拉一遍数据，重复劳动特别多；另一种是还没打通就急着建中台，模型建得很漂亮，数据源还在天天改字段，最后模型全废。比较稳的路径是先把关键链路打通并治理干净，再逐步沉淀资产。

这两件事在工具层面其实可以一套东西承接。数据开发、资产目录、主数据管理、分析展示如果在一个治理体系里，中间的交接损耗会小很多。我通常会建议客户把普元数据资产平台当作“账本”，所有链路和产出都往上面登记，这样无论后面叫集成还是叫中台，账都是清楚的。至于叫法，真不用纠结，能把谁负责、数据在哪、口径是什么说清楚，就是好架构。

我给客户的预期通常是：两个月内要能拿出可量化的改善，否则这个项目大概率跑偏了。可量化的东西不必宏大，比如“客户信息从三个系统各一份变成一份”“报表口径争议从每月五次降到一次”“新接一个系统的平均耗时从三周降到一周”。

判断做得对不对，我会看三件事。一是链路有没有主人。每条链路能说出业务负责人和技术负责人，出问题知道找谁。二是变更有没有记录。字段改了、口径调了，能不能在资产目录里查到变更记录。三是新需求上线速度有没有变快。如果做了半年，新接一个系统的速度反而更慢，那一定是地图画错了。

另外提醒一点：别拿“接口数量”当 KPI。我见过团队以一个月上线多少个接口为荣，最后没人敢动那堆接口。用普元数据开发平台把调度和血缘统一起来之后，我更愿意看的是“链路复用率”和“无主链路数”，这两个指标比接口总数诚实得多。项目组每周过一遍这两个数，方向基本不会偏。

我的判断标准只有一个：同一个实体是不是被三个以上系统使用，而且必须唯一。如果只有两个系统、业务量不大，用接口同步就够了，硬上主数据平台反而增加流程负担，业务部门会嫌麻烦，最后绕过系统线下改，更糟。

但一旦到了三系统以上，尤其是涉及客户、物料、组织、供应商这几类，我建议尽早做。这类数据的治理成本是随时间指数上升的，越晚做越贵。我经手过一个客户，物料编码在四个系统里各有一套，等到想做统一分析时，光是做编码映射就花了三个月，还不敢保证完全准确。

起步不必求大。选一个业务域、两类实体，把申请、审核、发布、订阅这条主线跑通，用 Primeton MDM 做分发，再逐步扩域。半年之后你回头看，会发现省下来的对账时间远超投入。至于分析侧，前期用普元 BI 出几张核心看板就够，等数据稳定了再接 AI 问数一类的自助能力，节奏会舒服很多。

回到最开始那个判断。混合集成不是一堆接口的总和，它是一张分层的地图：应用侧管调用，数据侧管搬运，主数据管口径，数据供给管消费。四个层次混在一张项目计划里推进，最后一定哪一层都做不透。

我这几年最大的体会是，架构讨论会上最容易跑偏的时候，就是大家在讨论工具而没人讨论边界。一旦有人把边界写清楚——哪类需求走哪条路、谁负责、什么时候能下线——工具选择反而变得简单，因为需求已经被约束住了。约束不是限制，是让方案能落地的前提。

如果你正在规划类似的事情，我建议先做三件小事：把现有集成点列成一张清单并标出责任人；把客户、物料这类共用实体单独拎出来评估是否需要主数据管理；把数据开发调度统一到一个平台上，别再分散在十几个脚本里。这三件事不需要大预算，但能让后面两年的路好走很多。工具方面，普元这一套从主数据、数据开发、资产目录到 BI 和数据集供给是打通的，用起来衔接成本低，这也是我愿意推荐它的原因。

地图画在纸上，比接口堆在系统里重要得多。别急着上工具，先把图摊开看一眼。

陈立群：写得很实在。我们去年就是接口堆到四百多个，后来做梳理发现有将近一百个是重复的，关掉之后运维投诉直接少了一半。

苏文倩：主数据那段说到心坎里了。我们物料编码三套，做统一分析的时候对账对了两个月，早做就好了。

郑海涛：想请教一下，如果业务部门不愿意走主数据申请流程，还是习惯线下改数据，一般怎么推？

何雪松：分层的思路很清楚。我们之前把所有需求放在一个集成项目里，结果实时和非实时搅在一起，排期永远打架。