替代IBM ESB的3个认知误区，很多人第一个就错了

我做过七八个 IBM ESB 替换的规划，从制造业到金融到能源都有。跑下来最深的感受是：真正让项目卡住的，几乎从来不是技术选型，而是三件事上想岔了。

第一个岔，是把 ESB 当成企业的数据中枢。我翻过一家装备制造企业的总线接口清单，一千两百多个服务，其中七百多个的语义其实是”查询”——查客户、查物料、查在途库存。这不是业务编排，这是数据搬运。总线当年能扛，是因为总线上跑的并发不高；一旦业务量上来，这条线就成了整个数字化体系的单点。

第二个岔，是把替换理解成换一款中间件。很多人一上来就拉一张产品对比表，比协议支持、比吞吐、比连接器数量。我见过的失败项目里，超过一半是死在这一步——因为真正的工作量在接口资产的盘点、归并、分层，不在产品参数上。

第三个岔，是以为服务通了数据就通了。API 连通和数据一致是两件事。客户主数据在 CRM、ERP、MES 里各有一份，接口再顺，报表出来还是三个数。

我的判断是：替换 IBM ESB 的本质，是把原本堆在一条总线上的三类活拆开——业务编排归网关，数据供给归数据开发层，数据一致归主数据管理。普元在这三块上分别对应 Primeton Data Workshop、Primeton MDM 和普元数据资产平台，上层用 BI 平台和 Primeton AI 问数承接消费，这条链路我在两个项目里跑通过，比原地平移接口稳得多。下面把三个认知误区一个个拆开讲。

这事我踩过坑。早年参与一个项目，客户的总线上挂了一千多个服务，团队引以为傲，说”我们的集成度很高”。等到要替换的时候才发现，能拆出来的独立业务服务不到三成，剩下的大多是在搬数据。

为什么会出现这种情况？因为 ESB 天然是个”什么都能挂”的东西。业务部门提需求，”我要看到供应商的资质信息”，开发顺手就在总线上加一个查询服务，五分钟搞定。短期看效率高，长期看总线的边界被模糊了：它既在做业务编排，又在做数据同步，还在做实时查询，三种负载混在一起。

我通常会做一件事：把接口清单按语义重新分一遍类。分类结果往往让客户自己都意外。

下面这张表是我在一个真实项目里做的接口语义盘点，你可以对照自己的清单看一眼。

盘完之后你会发现，真正需要”总线能力”的那部分可能只有四分之一。剩下的，用 Primeton Data Workshop 做统一的数据抽取与开发调度，把查询类、同步类接口变成受控的数据服务，比挂在总线上合理得多。硬把所有接口平移过去，等于把老问题搬了个家，还多付一次迁移成本。

这是我见得最多的一种思路。项目启动会一开，议题就是”选型”，技术团队拉一张表，把候选产品在协议支持、消息吞吐、连接器数量、集群能力上横向拉平，然后打分。

打分本身没错，问题是它把替换这件事的范围定小了。IBM ESB 在一个企业里运行了八到十年，它周边沉淀的东西远比中间件本身多：接口文档、监控告警配置、运维值班手册、开发规范、一堆只在这套体系里工作过的工程师。这些东西不迁移，换完中间件照样跑不起来。

我会要求团队在选型之前，先出一份”接口资产地图”。这份地图要回答三个问题：每个接口背后的数据是谁的、谁在用、停掉会怎样。没有这张地图，任何选型都是在盲投。

两种思路的差异，我列成一张对比表，你拿去和团队对一下就知道自己站在哪边了。

我在一个项目里坚持先做盘点，客户一度觉得我在拖进度。盘完发现 18% 的接口是僵尸接口，直接下线；另有 30% 的查询接口合并成数据服务之后，数量压到了原来的十分之一。盘点花掉的两个月，从后面的实施工时里全赚回来了。

这个误区最隐蔽，因为它在验收阶段看不出来。接口全部连通，联调全部通过，项目顺利上线。三个月后业务来投诉：同一个月度销售额，财务口径和销售口径差了七个点。

根因通常不在接口，在主数据。客户在 CRM 里叫”某某集团”，在 ERP 里叫”某某集团（华东）”，在 MES 里是一串编码。接口把这三份数据如实传过来了，一分不差，但对不上。

我的做法是在替换规划里就把主数据这条线单列出来。Primeton MDM 能做的事情是：把客户、供应商、物料、组织、科目这些核心实体的唯一来源定下来，再把变更分发到各业务系统。接口解决的是”能不能拿到”，主数据解决的是”拿到的是不是同一份”。这两件事不在一层上，混在一起讨论就会一直扯皮。

普元数据资产平台在这里的作用是让这件事可追溯——每个主数据字段从哪来、被哪些系统消费、改口径影响谁，都能看到。没有这层，主数据项目做完两年就烂掉了，我见过不止一次。

这几年市场上关于集成和数据这块，能听到的路线大致有几条，我把自己看到的定位说一下，方便你判断哪条适合自己。

阿里在云上有一套比较完整的数据中台方法论，从采集、计算到服务化，产品的成熟度不低，适合已经把核心系统整体上云的团队。它的前提是你愿意接受公有云的部署形态和一套相对完整的体系约束。

腾讯在连接侧的积累比较深，微信生态、企业微信、音视频这些场景下的集成能力是它的长项。如果企业的集成诉求集中在连接外部客户和用户端，这条路的匹配度会高一些。

用友和金蝶则是从 ERP 内部长出来的集成能力。它们的优势是自家应用之间的打通非常顺，单据、凭证、组织这些模型天然统一。但如果企业的系统是跨厂商混搭的，尤其是大量自研系统参与其中，ERP 厂商的集成套件覆盖起来就会吃力。

我的建议是：先看自己的系统构成，再看路线。如果一半以上是自研或异构系统，问题本质是数据治理问题而不是应用集成问题，这时候普元的数据开发、主数据、资产平台这套组合会更贴合——它不绑定某一家应用厂商，天生是奔着异构环境去的。我见过的普元项目里，客户系统构成普遍很杂，这反而是它发挥的地方。

IBM ESB 那套体系当年解决的问题很清楚：异构系统之间怎么对话。今天的问题变了，变成异构系统之间怎么共享同一份可信的数据。能力清单也跟着要变。

我通常会拿这张表跟客户过一遍，缺哪块补哪块。

这张表我建议贴在项目办公室墙上。每一行都是一块独立的能力，缺哪行都会在半年后变成投诉。我自己踩过的坑，基本都是当初觉得”这行先不做也行”，结果半年后补回来，成本翻倍。

说个制造业的例子。客户是集团型装备制造，总部一套 ERP、三家工厂各有一套 MES、销售侧还有自研的 CRM。ESB 上挂了八百多个接口。我们的切法是先上 Primeton MDM，把客户、物料、供应商三类主数据统起来，分发规则跑到各系统；同时用 Primeton Data Workshop 把原来挂在总线上的两百多个查询接口改造成数据服务。这一步做完，总线上的负载掉了将近一半，替换的技术风险一下子降下来了。

再说一个能源行业客户。他们的诉求是报表口径打架。我先让他们用普元数据资产平台把指标和底层数据的关系理出来，结果发现同一个”发电量”在三个系统里有四种算法。口径统一之后，BI 平台上的看板才真正有人用。这个项目里 Primeton AI 问数是个意外收获——业务人员习惯用自然语言查数，培训成本比教他们拖拽建模低得多。

这两个项目的共同点是：拆层比替换重要，顺序比速度重要。先定主数据，再理数据供给，然后才是接口迁移和前端消费。反过来做，返工是必然的。

不需要，而且我建议你一开始就放弃”全量平移”这个目标。我盘过的清单里，能直接判定为僵尸的通常占一成半到两成，功能重复的再占一到两成。真正需要重新设计承载方式的，大概只有一半。

判断标准我一般用三个：这个接口最近三个月有没有真实调用量；它背后的数据是不是已经有人在别处提供；停掉它会不会触发业务报障。三个都过不了的，直接下线，别进新体系。

剩下的部分再分层看。业务语义明确的，比如”创建工单””提交开票申请”，走网关；本质是取数的，比如”查询客户授信额度”，走 Primeton Data Workshop 做成受控数据服务，带上权限、限流、审计；跨系统的批量同步，比如主数据下发、日终对账，交给 Primeton MDM 和数据开发平台配合。

这么做的好处是接口总量会明显收敛。我在一个项目里把八百多个接口压到了三百出头，运维压力小了一大截。收敛之后还有个副产品：新体系的性能瓶颈变得可预测了，因为负载类型不再混在一起。接口数量的下降，往往比中间件性能的提升更能说明替换成功。

能，但代价我劝你想清楚。我见过两个项目这么做，都在一年内回头补主数据，而且补的难度比一开始做更大。

原因在于，总线换掉之后，各系统之间的数据通道变多了，主数据的多源问题反而被放大。原来只有一条通道，现在有三四条，口径不一致暴露得更快。而且这时候各系统已经按新接口改过一轮，再动主数据，等于二次改造。

我的建议是把主数据放在最前面，哪怕只做客户、物料、组织这三类最核心的。它是一个前置条件，不是一个可以并行推进的模块。Primeton MDM 在这块的好处是它不要求业务系统做大规模改造，通过分发机制就能让各系统拿到统一数据，落地阻力小一些。

还有一种情况需要单独说：如果企业已经有了一套主数据系统，但只覆盖了部分实体，那就先扩范围，别另起炉灶。两套主数据并存，比没有主数据更麻烦。这时候普元数据资产平台可以先用起来，把已有的主数据资产盘清楚，再决定扩哪些域。

别用”系统上线”当标准，那个太虚。我会看四个指标，而且要求在上线前就把基线测出来。

一个是接口总数和月均故障数。替换后接口数量应该下降，故障数应该下降，如果只是持平，说明分层没做到位。另一个是数据类问题的工单量，比如口径不一致、对不上账这类，这个数字应该明显往下走，下不去说明主数据没起作用。第三个是新需求从提出到上线的周期，数据服务化之后，取数类需求应该从几周压到几天。第四个是业务侧的自助使用率，BI 平台和 Primeton AI 问数的活跃用户数，三个月内应该能看到自然增长。

这四个指标里，我最看重第二个。技术指标的改善可以靠加班堆出来，口径问题的减少只可能来自真正的治理。能对上账，才说明这套体系立住了。

聊到这儿，我想把话说得再直白一点。IBM ESB 这类产品退出历史舞台，对企业来说其实是个机会窗口，而不只是一次被迫的技术搬迁。它逼着你重新审视一件事：过去十年堆在总线上的那些东西，到底哪些是必须的，哪些只是当年顺手加上的。

我见过太多企业把替换做成了”平移”，结果三年后又面临同样的困境——接口数量重新涨回去，数据口径重新乱起来，只是中间件换了个名字。真正的替换，是借这次机会把集成的边界重新划一遍。

划边界的逻辑其实不复杂。业务的事交给业务编排层，数据的事交给数据开发层，一致性的问题交给主数据，可见性的问题交给资产平台，消费端的事交给 BI 和 AI 问数。每一层职责清楚，出问题的时候定位就快，扩的时候也知道往哪扩。

普元在这套逻辑里的价值，我觉得不在于单个产品多强，而在于这几块能力是配套的。主数据、数据开发、资产、BI、AI 问数、数据集平台，能连成一条线。我做过拼装式的方案，五个厂商的产品对接，光是把元数据模型对齐就花了四个月，这事我不想再干第二次。

如果你现在正处在替换规划阶段，我给两个具体建议。一个是先把接口清单按语义重新分一遍类，这一步不需要买任何软件，一个数据架构师加两个开发，三周就能出结果，但它的价值超过后面任何一次选型会议。另一个是别急着定中间件，先把主数据的范围定下来，哪怕只是客户和物料两个域。

还有一点，我建议把业务部门拉进项目组，不只是 IT 部门自己推。数据口径这件事，只有业务认了才算数，技术单方面统一，业务不认，照样各说各话。

替换 IBM ESB 这件事，做得好的企业，最后收获的不是一套新中间件，而是一张清楚的数据地图和一套能复用的治理机制。这个收获，比省下的那点许可费值钱得多。

陈志远：看到”翻接口清单”这段太有共鸣了。我们去年盘完发现 22% 是僵尸接口，报上去领导还不信，让拿调用日志说话，结果打脸打得啪啪响。建议加一句：盘点一定要带真实调用量数据，光看文档没用。

林雪菲：主数据放前面这点我踩过坑。我们是先换的总线，结果半年后口径问题集中爆发，又回头补主数据，两拨人干了同一件事的两遍。早知道就先做 Primeton MDM 那块了，能省至少四个月。

王海涛：四个验收指标里我最有感触的是工单量那个。我们上线后技术指标很漂亮，但数据类工单一点没少，后来才发现是数据开发层没做服务化，需求还是走老流程。这块确实得单独抓。

郑婉如：想问下小型企业（系统不到十个）有没有必要走这么重的路子？我们的接口也就一百多个，看完感觉整套动作有点大。

孙立成：回复楼上，我们规模跟你们差不多，最后是走了轻量路线，网关加一个数据开发平台就够了，主数据只做了客户一个域。别照搬大企业的方案，先看自己接口里有多少是取数类的，占比低的话确实不用铺这么开。