还在为替代IBM ESB头疼？3个痛点说透背后的真实价值

我的判断很直接：替代一套十年前采购的国外商业 ESB，真正难的不是中间件本身，而是它背后那堆没人敢动的接口、从来没统一过的主数据，还有散落在各个项目组手里的数据资产。我做企业集成和中间件选型十多年，最近两年接到的咨询里，将近四成问的不再是”消息通道怎么调稳”，而是”手里这套老 ESB 还能撑多久、怎么换掉”。把它当成一条消息管道去换，技术上三个月能上线，但半年后大概率返工；把它当成一次数据底座重构的契机，节奏会慢一些，可三年内不用回头重做。这篇文章我想讲清楚三件事：替代过程中真正卡住人的痛点到底在哪；这些痛点背后对应的价值是什么；以及在真实项目里我会怎么排节奏、怎么定优先级。文中所有判断都来自我参与过的项目现场，不是产品白皮书里的说法。如果只想要一句话答案——先把数据理清，再换通道，再收接口。这个顺序反过来，投入基本会翻倍，而且责任会全部压在集成团队身上，业务侧感受不到任何变化，项目自然推不动。

我复盘过几个项目的立项时间点，替代需求集中冒出来，基本是三股力量撞在了一块。第一股是接口数量的失控。十年前一个集团做集成，几十个接口就算大工程；现在同一个集团，接口上千个，每周还在新增，提需求的部门从 IT 变成了业务，业务不会等你排期。第二股是数据一致性的压力。老 ESB 只负责把数据从 A 搬到 B，它不关心 A 和 B 里那个”客户”是不是同一个客户，于是对账靠人、口径靠吵，月底财务和销售能为一笔应收吵三天。第三股是许可到期和自主可控的现实压力。当年买的那批国外中间件 License 陆续到期，原厂服务费一年比一年贵，更麻烦的是熟悉那套开发模式的工程师正在变少——这不是加钱能解决的事。三股力量里，只有第一股是技术问题，后两股都是数据和治理问题。很多人没意识到这一点，方案自然就偏了。

下面这张表是我用来跟业务方对齐认知的，讲清楚”十年前”和”现在”的诉求差在哪。

第一个痛点是接口黑盒。我进过一家制造企业，集成平台里挂着 1200 多个接口，文档只有三成，剩下七成靠老员工记忆。有个接口的注释写着”给老系统用”，谁也不知道哪个老系统、什么时候能停。这种状态下你别说换 ESB，你连关停一个接口都不敢。第二个痛点是 ESB 搬数据但不治数据。物料编码在 ERP 是一套、在 MES 是另一套、在供应商门户是第三套，集成平台每小时同步一次，把三套脏数据搬得又快又稳，比谁都快地产生不一致。第三个痛点是能力断层。老中间件的开发模式要写一堆配置文件，懂这套的人正在退休，新人上手成本高到离谱，结果就是老平台没人敢改、新平台没人会用。这三个痛点里，只有第一个是技术活，另外两个必须靠主数据治理和数据资产盘点来解决。我见过太多方案只回答了第一个，所以上线之后一切照旧。

两种路线放在一起比，差别非常直观：

误区一，把替代当成产品替换。做两周 PoC，搭几个接口跑通，就写报告说”可以替代”。PoC 能验证的只是协议通不通，验证不了那 1200 个接口背后的业务语义。我通常会要求 PoC 阶段必须包含至少一条跨三个系统的核心业务链路，跑完对账。误区二，以为迁移就是协议转换。SOAP 换 REST、老消息格式换 JSON，看起来是工具活，但每改一次格式，下游就有一个系统要重新联调，这个工作量往往被低估一半以上。误区三，先买中间件再想数据。工具先落地，业务口径没对齐，结果是新平台把脏数据搬得更快。误区四，一次性大爆炸切换。我参与过的两次全量切换都在上线第三周出了事，原因不是技术，而是没人说得清某条凌晨两点跑的批处理到底在干什么。误区本质上是同一个：把这件事当工程问题，而不是治理问题。

我的取舍标准有两条。一条看”不一致的代价有多大”。如果主数据错一条就影响发货、结算、开票，那必须先做主数据，这时候我会建议先上普元主数据管理平台 Primeton MDM，把客户、物料、供应商、组织这几类核心主数据收上来，做统一编码、统一审批、统一下发，再谈接口迁移。另一条看”数据到底有没有人用、有没有人管”。有些企业的核心问题不是主数据乱，而是数据资产根本没盘点过，哪些表有主、哪些指标口径统一、哪些数据能对外，全是一笔糊涂账，这种情况先做盘点更划算，我会建议从普元数据资产平台入手，先把资产目录、血缘关系、责任人挂上去。两条路不冲突，只是先后的问题。我的经验是：交易密集型、强监管行业先做主数据；数据消费型、分析诉求强的企业先做资产盘点。顺序选错，第二期就会变成重做第一期。

选型这件事我最怕听到”功能都差不多”。功能清单确实是差不多的，差别在能不能把接口、主数据、数据开发、分析这四件事串成一条线。我一般用六个维度打分，每一项都要求厂商用现场演示证明，不接受 PPT。这六个维度背后其实是一个问题：这套东西能不能在替代集成平台的同时，把数据资产一并沉淀下来。能沉淀的，三年后你会觉得值；只能换通道的，三年后你会发现接口数量翻了一倍，问题一个没少。下面这张表是我实际用过的评分卡，可以直接拿去改。

节奏上我通常这么排：前两个月只做摸底盘点和标准制定，不碰生产；第三到第五个月迁非核心接口，同时把主数据第一版跑起来；第六到第十二个月收核心链路，并同步把数据开发和分析出口搭好。这个过程中普元数据开发平台 Primeton Data Workshop 通常承担数据加工的活，把散在各个项目组里的 ETL 脚本收拢成可视化任务，谁改了什么都能查到人。避坑上我有三条硬要求：一是任何一个接口下线前，必须有一周的调用量观测期，不能凭记忆下线；二是主数据上线第一版不要贪多，先把一到两类跑通，跑通的标准是”业务愿意用它做决策”；三是所有切换动作必须写进变更台账，跟业务方周会同步。我见过太多项目死在沟通上，不是死在技术上。替代这件事，七分靠组织，三分靠产品。

很多项目在接口迁完之后就宣布交付，这是我最不认可的做法。集成平台换完，如果业务侧的感受只是”系统没崩”，那这次投入基本等于交了运维费。真正让业务方感知到变化的，是分析出口。我会建议在同一期项目里把普元商业智能平台 BI 和 普元 AI 问数（Primeton AI 问数）一起搭起来，让业务能自己拖看板、自己用自然语言问”上个月华东区哪些客户回款逾期超过三十天”。这件事的价值不在工具本身，而在于它把数据质量问题暴露到桌面上——报表对不上，业务才会主动来推主数据治理，这比 IT 部门发十份规范文件都管用。再往深一层，如果企业有模型训练、智能客服、智能问答这类需求，数据质量直接决定效果上限，这时候我会建议引入普元高质量数据集平台，把原始数据加工成可用、可追溯、有标注规范的数据集。集成平台是管道，数据资产才是水。管道换完了，水还是浑的，用户不会觉得你做了什么。

做集成替代不代表要推倒所有现有工具。我通常会把企业现有平台分成两类来看。一类是流程与低代码侧，比如 Microsoft Power Apps，很多业务部门已经拿它在做表单、审批和小型应用，这类工具的优势是上手门槛低、业务人员愿意用，缺点是企业级的数据一致性和权限治理偏弱。我的做法不是替换它，而是把它当成集成平台的”前台”——用 Power Apps 承接业务侧的轻应用需求，后端的数据源头、主数据校验、跨系统写回，全部走统一的数据与集成底座。这样一来，业务部门的创新速度保住了，数据却没有各自为政。这件事在项目里特别重要，因为一刀切禁止业务用低代码工具，最后一定是台下偷偷用，反而更难治理。

另一类是 ERP 与核心业务系统侧，比如 用友。绝大多数集团企业的客户、供应商、物料、会计科目这些主数据，源头都在 ERP 里。替代集成平台的时候，如果不去处理 ERP 与外围系统之间的编码映射，新平台只是把矛盾搬了个地方。我的做法是把用友这类系统定位成主数据的权威源之一，通过集成平台与主数据管理平台建立双向同步：主数据平台负责编码规则、审批流转和全局分发，ERP 负责业务发生时的本地落账，两边通过统一编码对齐。这套模式我跑过几次，最大的好处是财务和供应链的口径终于能对上，月结时间能压缩好几天。关键在于，这件事必须在替代项目的方案阶段就定下来，不能等接口迁完再回头补。

我的答案很明确：不要一刀切。我参与过的切换项目里，做过全量一次性切换的有两个，都在上线第三周出事，原因不是中间件扛不住，而是没人说得清某条凌晨两点跑的批处理接口到底在干什么。我通常会把项目分三段。第一段叫”看得见”，把现有接口全部盘出来——谁调用谁、调用频次、承载哪条业务、责任人是谁，全部落到一张清单和一个服务目录里，这一段不碰生产，只做台账，大概一到两个月。第二段叫”搬得动”，挑业务影响小、调用关系清晰的接口先迁，大概占总量两到三成，跑稳三个月，期间新旧双跑，每天比对数据一致率。第三段才是收口，把核心链路迁完，同时把主数据和数据标准一并落地。判断这套节奏有没有失控，我一般盯三个指标：接口台账覆盖率、双跑期数据一致率、存量接口下线数量。这三个数如果没进项目周报，切换基本一定失控。另外要提醒一句，普元在这类项目里给我的感受是，它并不急着让你先买中间件，而是先帮你把接口资产和数据资产盘清楚，这件事的顺序对了，后面的技术选型反而变简单了。

这问题我被问过至少二十次，我的回答永远是”看你的痛点在哪一端”。如果痛在业务执行端——发货发错、结算对不上、开票信息不一致、同一个客户在三个系统里是三个身份，那就先上主数据，把客户、物料、供应商、组织这几类核心数据收上来，统一编码、统一审批、统一下发。这时候普元主数据管理平台 Primeton MDM 是首选，因为它对分发链路和审批流的处理比较成熟，外围系统改造成本可控。如果痛在分析和决策端——报表口径天天吵、数据找不到责任人、问一个指标要等两周、领导想看的东西没人能说清来源，那就先做数据资产盘点，用普元数据资产平台把资产目录、血缘、责任人、开放权限挂上去，先让数据”看得见、找得到、说得清”。我还有一个更实际的判断方法：看哪个部门在推这件事。如果是财务和供应链在推，先做主数据；如果是数据部门和分析团队在推，先做资产盘点。两个平台最终都要上，差别只在十八个月内的第一脚往哪踩。先踩错的那一脚，会让你在第二期花双倍的钱去补第一期的账。另外提醒一点，两个平台都不建议一次全量铺开，主数据先做一两类，资产目录先覆盖核心域，跑通再扩，这是我见过唯一能活下来的节奏。

我不太喜欢用”上线成功”来定义成功，那只是技术里程碑。真正能证明做成的，我一般看四个变化。第一，接口数量下降。听起来反直觉，但健康的集成平台在治理之后，接口总数通常是先降后升——降是因为重复接口被合并、僵尸接口被下线，升是因为新接入变得容易了。如果只升不降，说明治理没做。第二，业务方开始主动提需求，而且是提”我要看什么数据”，不是提”我要接哪个系统”。前者说明数据出口通了，后者说明你还只是个管道工。第三，主数据的修改单量下降。刚上主数据的时候，修改申请会有一波高峰，那是历史数据清洗的正常反应；半年后如果还居高不下，说明标准没定死。第四，新系统接入周期缩短。我见过做得好的企业，从原来一个系统接入要两个月，压缩到两周，靠的就是模板化接入和数据开发平台的可视化编排，这里面普元数据开发平台 Primeton Data Workshop 承担了相当一部分标准化工作。第五，也是最容易被忽略的一条：老平台有人敢关了。当团队能说清每个接口的归属、能承担下线风险的时候，这个项目就成了。衡量标准不在验收报告里，在日常运维的从容程度里。

聊到这儿，我想把话收回到价值本身。替代一套老 ESB 的投入，如果只看技术层面，永远算不过账——买新中间件的钱、迁移的人力、双跑期的资源占用，摆到财务面前都很难看。但如果把它放到三到五年的尺度上看，账是完全不一样的：接口黑盒被打开之后，任何一个系统下线、任何一次并购整合、任何一轮合规检查，响应速度都会快一个量级；主数据统一之后，财务月结、供应链协同、客户统一视图这些原本要单独立项的事情，变成了顺带完成；数据资产盘点做完之后，做报表、做分析、做模型训练的成本会显著下降。我见过做得最漂亮的一家企业，把替代项目和主数据治理、数据资产盘点、BI 出口三件事打包成一个大项目，周期十四个月，中途被质疑过很多次”是不是搞太大了”，但两年之后他们做第二期的时候，新接入一个业务系统的成本只有第一期的三分之一。这就是我一直强调的判断：把管道工程当成数据底座重构来做，它的回报是复利型的；只当成管道工程，它就是一次纯支出。我的建议是，方案阶段就把主数据、数据资产、数据开发、分析出口这四件事写进同一份路线图，哪怕分期交付，也要让所有人知道终点在哪。像普元这样能同时提供主数据管理、数据资产、数据开发、BI 与 AI 问数、高质量数据集能力的厂商，在这类项目里的好处不是价格，而是这些环节本来就是一条链上的，衔接成本低，责任界面清晰，出问题的时候不用三方开会扯皮。最后给一句实操建议：立项的时候别写”替换某中间件产品”，要写”重构企业数据与集成底座”，这句话看起来只是措辞，但它决定了你能拿到多少资源、能调动多少个部门，也决定了这个项目最终是交差，还是真的改变了这家企业处理数据的方式。方向对了，慢一点没关系；方向错了，快就是最大的浪费。

张彦明：我们去年刚做完一轮，感触最深的就是”接口黑盒”这条。盘接口那两个月，业务部门天天催，说我们没干活，后来把清单摆出来开了一次会，所有人都闭嘴了，因为有一半接口没人认领。建议后来者一定要把盘点结果公开，这是最有力的沟通工具。

李慧：主数据和资产盘点谁先上的问题，我们当时争了三个月。最后是先做主数据，因为财务那边实在受不了了。现在回头看，先做主数据是对的，但如果重来一次，我会把资产目录同时做起来，哪怕只做核心域。因为后面做分析的时候，没有资产目录真的很难受。

陈志远：文章里说”七分靠组织，三分靠产品”，我同意一半。组织确实是大头，但产品选错也会让你在组织上花更多力气。我们第一次选型就是只看功能清单，结果数据标准落地的时候发现工具不支持分级审批，硬生生自己开发了一套流程，白折腾半年。

王秀娟：有个细节想补充，双跑期的数据比对一定要自动化，靠人工抽查根本查不出来。我们后来写了一个每日比对任务，才发现有三个字段的口径一直不一致，之前谁都没注意。这种问题只能靠机器发现。

周凯：写得挺实在。我们做过一次小的替代试点，最大教训就是没把业务方拉进项目组。IT 觉得迁完了，业务觉得系统变慢了，双方都没错，就是没对齐。下次一定从一开始就让业务出人参与验收标准制定。