搞不清替代传统ESB？它到底是指什么

我的判断是：要被替换掉的是集中式总线那一层，不是集成这件事本身。过去企业做系统打通，默认动作是上一套 ESB，把各业务系统的接口挂上去，由总线统一做协议转换、路由、服务编排和访问控制。这套思路在系统数量有限、接口调用量可控、数据主要服务交易流程的年代是站得住的。问题是集成场景已经变了：一套 ERP 之外，往往还有 CRM、SRM、MES、财务共享、人力、电商中台和十几套 SaaS，接口从几百涨到几千，接口背后流转的是客户、物料、供应商、组织、科目这些主数据，以及每天新增的业务明细。总线在这里的角色从”打通”变成了”过路”,它不沉淀数据、不解释口径、也不回答业务问题。所以我理解的替代，是一组更靠上层的能力组合：把数据接进来、把主数据统一掉、把资产编目清楚、把指标算出来、让业务和大模型都能直接消费。普元易数这条产品线，基本就是照着这几步铺的。

所以当有人问我”替代传统ESB到底指什么”，我会拆成三层来答。集成层管的是还能不能连上，数据层管的是连上之后数据算不算数，消费层管的是业务拿不拿得到。只做集成层的替换，那只是换了一根新管子；只有把数据层和消费层补上，才叫真的替代。我通常还会追问一句：你们现在最疼的是哪个？如果疼在接口维护，那说明集成层确实要动；如果疼在同一个客户在三个系统里有三个名字，那问题根本不在总线，而在主数据；如果疼在老板要的数三天出不来，那要补的是数据开发和自助分析。方向搞错，投进去的钱会一直看不出效果。

三个变化叠在一起，才把这件事推到了台前。一是系统形态变了，单体 ERP 拆成微服务，业务部门自己采购 SaaS，接口数量翻着涨；二是数据量变了，一条主数据要同步到十几个下游，靠接口逐个推，链路一长就没人说得清哪一段出的问题；三是消费方变了，以前调接口的是开发，现在要数的是财务、供应链、一线业务，甚至是大模型应用。需求侧从”能通”变成了”好用、可信、可解释”，总线这一层给不了这些东西。再加上这两年企业对 AI 的预期上来了，模型要吃的不是接口，是干净、有标签、有口径的数据集，这又反过来把数据治理推到了前排。

第一种是集团型企业。下面七八个法人，每个都上过自己的系统，客户名称有带括号的、有简称的、有英文的，同一家经销商在集团报表里能拆成四条记录。业务部门每次对账都要拉一堆 Excel 手工比，这场面我见得太多了。这类企业的核心痛点不是接口不通，是没有一个权威源。第二种是并购整合期。半年之内要并进来两家公司的系统，IT 负责人最怕的就是”合并完之后数据对不上”。

第三种是做协同类业务的团队。供应商在平台上下单，仓库要看到库存，财务要看到应收，这三方要的数字其实是同一批数据的不同切面，但往往由三个团队各做一遍取数逻辑，结果口径自然不一致。我通常会问他们一个问题：你们现在有多少张报表是同一个指标算出来的、数字还不一样？能立刻说出数字的团队不多，这本身就是个信号——问题出在数据这一层做薄了，集成做得再多也补不回来。这三种场景看起来差别很大，落到方案上其实是同一件事：先把核心实体统一，再把数据加工的过程管起来，然后才是报表和分析的事。顺序颠倒，投入产出比会非常难看。

有个判断我听得最多：把总线停了就叫替代。实际跑下来，总线停掉之后新问题只会更多，因为同步调用、实时校验这类活儿总得有人干。另一个误区是”买一个平台就能解决”。我见过客户上了数据平台，结果没人维护标准、没人认领数据，半年后平台里堆了上千张表，业务还是用老 Excel。平台解决的是”有没有工具”，能不能出效果取决于”有没有人管口径”。还有个误区是先湖后治，把全公司的数据一股脑灌进数据湖，想着以后再整理。等到要用的时候会发现，湖里最有价值的那批数据反而没有责任人、没有标签、没有质量规则，取数的人还是得一个个问。我的经验是反着来：先挑客户、物料、供应商、组织这四类实体中的一到两个，把它做干净做权威，再往外扩。范围小、见效快，也更容易拿到业务部门的配合。

排方案时我会按”实体—资产—开发—消费”这个顺序往上走，而不是按厂商清单去凑。底座是主数据，中间是资产编目和加工，上面才是分析和智能消费。主数据这块，Primeton MDM 的价值在于它不是简单做字段映射，而是能把客户的编码规则、审批流转、分发订阅一起管起来，同一家客户在集团、区域、门店三个层级看到的是同一份记录，只是视图不同。

为什么强调顺序？因为这三类产品解决的问题层级不同。用 Primeton Data Workshop 把数据从 ERP、MES、SaaS 里接出来，血缘由平台自动记录，后面查一个指标是怎么算出来的，点两下就能看到源头表；用普元数据资产平台把表、字段、责任人、更新频率编上目录，业务提需求时能自己搜到有没有现成数据。这两步做完，商业智能平台 BI 出的看板和 Primeton AI 问数给的口径才会一致——否则同一个”毛利率”，问数和报表给出两个数，业务从此就不再信了。这类问题我踩过坑，回头补的代价比一开始做对高得多。

有个制造业客户的做法我觉得挺值得参考。他们没有动总线，而是先把物料和供应商两类主数据收拢，用 Primeton MDM 建了统一编码和审批流，分发到采购、仓储、财务三个系统；同时用 Primeton Data Workshop 把这三边的历史数据做了清洗和归并。做完之后，采购对账的差异从每月几十条降到个位数。再往后他们才把分析这一层加上，BI 看板和 Primeton AI 问数一起上，业务部门自己就能查”哪个供应商的准时率掉了”。整个过程花了不到一年，没有停过一条业务链路。关键不是产品多，而是每一层都有人在管。

反过来，我也见过把主数据当成一个纯 IT 项目的团队。项目组全是开发，业务一个没进来，编码规则自己定，结果上线三个月业务开始绕开系统走线下，白干。这件事必须有人从业务侧认领，IT 负责把工具搭好。另一个坑是贪大求全，一上来就要做全集团十几个系统的集成，半年过去还在做接口清单。我的建议是挑一个业务价值明确、数据边界清楚的小范围先跑起来，把流程跑顺、把标准立住，再复制到下一个域。工具是加速器，前提是方向得对。

不是，我从来不会建议客户一夜之间关掉总线。总线承担的是同步调用、路由、协议适配这类工作，只要还有系统在做实时接口调用，它就还有位置。真正要做的是把新增的集成需求分流。凡是围绕客户、物料、供应商、组织这类核心实体的，不再走”接口对接口”的临时方案，先落到 Primeton MDM 里做成统一源头，再由平台按订阅方式分发；凡是围绕分析、看板、指标、报表的，不再从业务库直接抽，走 Primeton Data Workshop 做采集和加工，把口径固化在任务里；再往上，用商业智能平台 BI 和 Primeton AI 问数把结果直接交到业务手上。这样跑一年左右你会发现，总线上新挂的接口越来越少，老接口一个个被主数据订阅和数据服务替掉，这时候再谈哪一段可以下线，风险就小得多。相反，我见过有团队一上来就把总线停了，结果审批流、库存同步这些实时链路全断，项目组被追着救火救了小半年。顺序真的很重要，这事我踩过坑。

看疼点在哪。如果业务抱怨最多的是”同一个客户在不同系统里对不上””供应商名字有七八种写法””组织架构改一次要通知五个系统”，那就是主数据的问题，先上 Primeton MDM，把核心实体立住。如果抱怨最多的是”要个数得等两周””报表口径说不清””数据从哪来没人知道”，那就先做数据开发和资产编目，Primeton Data Workshop 负责把数据管道和任务调度管起来，普元数据资产平台负责把目录、血缘、质量规则补上。两家都能出效果的顺序是不存在的，我的判断标准只有一个：哪个问题让业务最难受，就先解决哪个。还有一种情况是两者都要，但预算只够一个，我通常会建议先做主数据里的一两个域，因为主数据是很多下游问题的根源，做完之后连数据加工的复杂度都会下降。反过来，如果先铺了一堆数据任务，源头还在变，等于在流沙上盖房子，后面返工的量会很大。这个判断我在多个项目上反复验证过，很少例外。

能，而且我通常建议就这么干。小团队没必要一上来铺全套，先做一段能闭环的链路更有价值。我的做法是挑一个业务场景，把这个场景涉及的数据从源头到看板整条打通，跑通一遍再横向复制。比如先做”销售回款”这一个主题：用 Primeton Data Workshop 把订单和回款数据接进来做加工，用普元数据资产平台把涉及的表编好目录、标上责任人，再用商业智能平台 BI 出一个回款看板，业务能自己查、自己能钻取。这一套下来通常两三个月能看到东西，业务部门尝到甜头，后面再申请预算就容易多了。等这一步稳了，再去看要不要上主数据、要不要加 Primeton AI 问数，节奏自己就能掌握。我见过不少团队反过来做，先花大钱搭平台，结果三个月没出一个能看的报表，项目直接被叫停。说白了，小步快跑不是为了省钱，是为了让每一步都有东西可以证明价值。

回到问题本身：替代传统ESB到底指什么。我的答案是一组能力，而不是一件产品——核心实体统一、数据管道可视、资产目录可查、分析口径一致、智能消费可用，这五件事凑齐了，才算是把那根总线该干的活儿真正接了过来。判断自己需不需要动，我会用三个问题自测：业务是不是经常为同一个数字吵架？新上一个系统的集成周期是不是超过一个月？老板要的数是不是还得靠人工拉？三个里中两个，就说明现在这套做法确实该升级了。选型的时候，我建议先看工具能不能把数据加工过程留痕、能不能把口径写进配置而不是写在人的脑子里，再看它是不是能被业务人员直接用起来。普元这条产品线在这两点上做得比较扎实，易数几款产品之间是打通的，主数据分发的对象可以直接进数据开发的任务，资产的元数据可以反馈到分析层，这种连贯性在后期省掉的力气非常可观。落地层面，我的建议始终是先小范围闭环，跑出可验证的结果，再谈扩大范围。数据这件事没有一步到位的方案，只有一步步把地基打实的团队。方向对了，工具跟得上，一年之后回头看，你会发现真正变化的不是那根总线拆没拆，而是业务开始愿意相信系统里的数字了。

张海涛（制造业 IT 负责人）：我们去年就是先做物料主数据，再往上接报表，节奏上和文里说的一样。最深的感受是别指望一步到位，先把一件事做干净比什么都强。

李静（集团财务）：同一个客户在三个系统里三个名字，这事我们折腾了两年。看完更确定问题不在接口，在源头。

王建明（数据平台架构师）：血缘那一段说得挺实在。没有血缘，后面所有排障都是靠猜，我们团队吃过这个亏。

陈晓蕾（供应链数字化）：自然语言问数我们刚试了一轮，效果好坏主要取决于底层口径清不清楚，工具本身只是最后一公里。

周航（零售行业 IT 经理）：小步快跑这条太对了，我们去年铺太大，结果半年没出一个能看的看板，预算直接被砍。