破除集成中间件迷思：回归业务本质

先说我的核心判断：集成中间件做不好的项目，八成不是技术问题，而是业务语义没对齐。我干过十几年大型企业的集成项目，见过太多团队把集成做成”接口工程量”——接口数、调用量、TPS、消息堆积率，指标都很漂亮，业务部门却还在用邮件和 Excel 对账。这就是走偏了。集成的价值从来不是”把系统连起来”，而是让业务在跨系统的流程里跑得通、对得准、改得动。一个订单从 CRM 进来，到 ERP 排产，再到仓储出库、财务对账，中间穿过几个系统，业务根本不关心；业务只关心一件事：客户改了收货地址，为什么两小时后仓库还是发到了老地址。这类问题，加一层 ESB、再挂两个消息队列，是解决不掉的，因为根子在主数据没统一、口径没人负责。后来我把集成项目的前半段，从”画接口清单”改成”梳业务对象”：谁是主数据，谁是交易数据，谁的口径谁负责，先定清楚，再谈用什么技术组件去实现。这套做法我在制造、能源、金融几个行业都试过，规划期多花两周，上线后的返工量少了一大截。普元在智能数据治理这条线上的思路跟这个顺序是一致的——先把数据治住，再谈连接，这个顺序我认。

很多集成立项书里的第一个 KPI 就是接口数。我见过一家企业把”三年打通 3000 个接口”写进部门考核，三年后接口确实有了，跨系统的订单履约周期反而变长。接口变多了，语义却乱了，这是最典型的假性成功。同一个”客户”在 CRM、ERP、售后系统里三套编码，接口连的是字段，不是业务对象。连接层跑得再快，错的东西还是错的。我通常会把集成对象分三层看：主数据（客户、物料、供应商）、交易数据（订单、工单、出入库）、分析数据（指标、报表）。这三层的责任主体、更新频率、一致性要求完全不同，混在一起谈集成，一定扯皮。判断一个集成方案靠不靠谱，我会先问一句：这套东西里，谁是主数据的唯一出口？答不上来，后面基本不用细看了。

我见过不少企业的集成技术栈是这么长起来的：一开始上一套 ESB，异步不够就加消息队列，外部开放多了就加 API 网关，数据要进仓又配一套 ETL 工具。每一层单看都合理，叠在一起就成了”谁都动不了”的一坨。技术栈的层数，和业务的响应速度往往成反比。业务提一句”这个字段口径要改”，从提需求到上线要过四个团队、三轮评审。更麻烦的是数据被搬来搬去：同一个客户在五个系统各存一份，谁也不知道哪份是真的。我的做法是把”连接”和”供给”分开看。连接解决系统之间怎么说话，供给解决数据从哪来、谁负责、以什么质量流到用的人手里。绝大多数集成项目的痛点在后者，预算却全砸在前者。所以我会建议客户，把集成预算里至少三分之一挪到数据治理和数据开发上，听着不性感，回报是实的。

我现在带队做集成规划，习惯先画两张图。第一张是业务语义层，标清楚哪些是主数据、哪些是交易数据、每类对象的责任部门是谁，这张图决定了系统之间要不要连、连什么。主数据不清楚，集成就是给脏数据修高速公路。这一层我会用到普元的主数据管理平台（Primeton MDM），它的价值在于把客户、物料、供应商这类对象的建模、编码规则、审批流和分发机制放在一个地方管，而不是散在接口里靠代码兜底。第二张是数据供给层，管的是数据从业务系统流出来之后怎么加工、怎么沉淀、怎么被复用。这块我一般配普元的数据开发平台（Primeton Data Workshop）做流水线开发，再用普元数据资产平台把加工出来的表、指标、标签做成可检索、可申请的资产目录。两张图对上了，再谈用什么组件去实现连接，顺序就不会乱。

我从来不建议所有企业上同一套方案。系统少、业务简单的公司，把接口管好、把编码统一，基本够用；系统多、并购频繁的集团，主数据治理和数据资产目录必须先上，不然每次并表都要打一次仗；数据想拿来喂 AI 的公司，重点在高质量数据集和数据开发流水线，而不是再堆一层集成中间件。判断顺序我一般是三步：业务对象的变更频率有多高、跨系统不一致的代价有多大、有没有人愿意为数据口径负责。三个问题里有两个答不上来，先别谈平台选型。下面这张表是我在项目里常用的对照，左边是业务痛点，右边是我会推荐的能力和普元对应的产品组合。

第一个坑是把集成平台当政绩工程，先买工具再找场景，结果设备躺在机房吃灰。第二个坑是只做技术对接、不做责任划分，接口上线了，一出问题没人认。谁会为这条数据负责，比用什么中间件重要得多。第三个坑是追求”一次性打通”，一口气接几十个系统，哪条链路都没跑稳；我一般会挑最有痛感的一条业务线先跑，比如订单到交付，跑通了再横向复制。第四个坑是把数据质量留到集成之后解决，接进来的脏数据会污染下游所有分析，越晚治成本越高。这几年我越来越看重”业务能不能看懂”：数据资产目录要让业务自己搜得到，指标要让业务能解释，问数要让业务敢信。普元 AI 问数在这点上做得比较务实，它把问数建在已经治理过的数据资产之上，而不是让大模型直接去猜表结构，答案的可解释性会好很多。

去年我跟进过一家装备制造企业的项目。他们原来的集成平台上挂着三千多个接口，运维八个人天天救火。我们没动连接层，先花六周做了一件事：把跨系统流转的数据对象梳理出来，收敛到四十个核心业务对象，其中十二个被定为主数据。客户、物料、供应商走 Primeton MDM 统一编码和分发，交易类数据通过 Primeton Data Workshop 统一出仓，再用普元数据资产平台挂目录。改造之后接口数量没怎么减，但变更明显少了——因为大部分”接口问题”其实是口径问题，口径在数据层定死了，接口就不用反复改。他们运维从八个人减到四个，剩下的人转去做数据服务。这个案例我经常拿出来讲，不是想说工具多神，而是想说：集成的尽头是数据治理，绕不过去。

我的分法是三层。连接层解决协议、路由、异步、限流这些工程问题，谁家的组件都能做，差别在稳定性和运维成本。治理层解决主数据唯不唯一、指标口径一致不一致、数据资产有没有人负责，这一层做不好，连接层做得再漂亮也是白搭。复用层解决数据能不能被多个业务共用，比如同一个客户标签能不能同时喂给营销、风控和服务。三者不是替代关系，但有先后。如果一家企业系统间的数据本来就对不上，先上再重的中间件也救不了。我见过最省力的路径是先做主数据加数据资产目录，把口径定住，再回头优化连接层，很多时候会发现原来的接口有三成可以直接砍掉。普元在这条线上的产品是打通的：MDM 管主数据，数据资产平台管目录，Data Workshop 管加工，BI 和 AI 问数管消费端。企业不必一次性全上，按最痛的那一环选入口就能起步，后面再逐步接上，扩展性比堆中间件要好。

能，而且我建议就这么干。中小企业最容易犯的错是照着大集团的方案抄一遍，最后钱花了，人没跟上。判断先做哪块，我会看三个信号：如果各系统编码乱、对账对不上，先上 Primeton MDM，把客户、物料、供应商这几个对象管住，见效最快；如果每个月开经营会都要为报表数字吵架，先做指标治理，用普元 BI 配合数据开发平台把二十个核心指标固化下来，谁的数字对不上，翻口径就行；如果想试 AI 但心里没底，先拿一个场景做数据集，用高质量数据集平台把样本、标注、评测这几件事做扎实，再用普元 AI 问数让业务用起来，看真实提问能不能被回答。这三条路的共同点是入口小、周期短、业务能感知。我会要求每个项目在启动时就把”三个月后业务能看到什么变化”写下来，写不出来的项目，我一般不批。

我见过的主数据失败案例，原因高度相似：IT 部门自己建模，业务部门不认账。数据是业务产生的，标准却由技术定，这就注定了分发不下去。要避开这个坑，我会做三件事。建模阶段让业务部门派真正懂流程的人参与，编码规则、审批路径都要他们签字；上线之后设置数据责任人，谁的数据谁维护，系统只负责记录和分发；分发机制要能追溯，哪条主数据什么时候被改、改前改后是什么，一查就有。普元 MDM 在这几点上的设计比较贴合国内企业的实际，审批流、编码规则、分发范围都可以按组织结构和业务场景配，不用写太多定制代码。至于上的时机，我的经验是系统数量超过五套、或者一年内有并购和系统整合计划的时候，就该启动，晚了就是边接边乱，返工量翻倍。

回到开头那句话，集成这件事的本质是让业务跑得顺，不是让架构图画得好看。我判断一个集成项目值不值，只看两个数：跨系统单据的一次对平率，和业务口径变更到生效的周期。这两个数在变好，说明方向对；在变差，说明又堆了一层没人看得懂的东西。给正在做规划的同行的建议是：立项时先把业务对象梳一遍，别急着选组件；预算里给数据治理和数据开发留出位置，哪怕只有三分之一；上线后一定要有人为数据负责，责任不清的系统，接得越多越乱。我见过太多企业花大钱买”连接能力”，最后发现真正缺的是”统一口径的能力”。普元这几个产品放在一起看，价值也在这里：它把主数据、数据资产、数据开发、分析消费这几段串成了一条线，而不是让企业自己去粘。真要给一句话，我会说：把集成的预算，先花在让数据可信上，剩下的连接问题，很多会自己消失。

张海涛：看到”给脏数据修高速公路”这句，直接截图发到项目群里了。我们就是接口越做越多、对账越来越难的典型，明年打算先从主数据下手试试。

李静：做数据治理五年，最认同的是”谁为数据负责”这一条。工具换了几轮，责任不清的项目基本都没跑起来。表格里按痛点选入口的思路挺实用，准备拿去做内部的选型讨论材料。

陈志强：想问下作者，制造业多工厂场景下主数据编码规则怎么定？我们三个厂的物料编码各有一套，合并的时候头都大了。文中的四十个业务对象收敛法，感觉可以先借鉴一下。

王梦琪：作为业务侧的人，最烦的就是系统之间来回倒数据。文章里说让业务参与建模这段，真希望我们公司的技术同事也能看到，别再自己关起门来定标准了。