替代IBM ESB好不好用，一线员工体验说了算

替代 IBM ESB 好不好用，我从来不先看技术参数，而是先看一线员工的体感有没有变好。过去五年我参与过六次企业集成架构的调整，三次是把跑了七八年的老总线拆掉重做，另外三次是保留一部分、把新增需求迁出来。真正决定项目成败的，不是新中间件的吞吐指标，而是业务同事提交一个接口申请要等几天、开发同事接一个新系统要写多少胶水代码、运营同事想看一个跨系统数据要经过几道审批。这几个数字降不下来，换什么都是白换。

我的判断标准很土：换完之后，一线提交需求到拿到可用接口的周期，能不能从两周压到两三天；数据从三个系统汇聚到一张表，能不能不靠人肉导 Excel；业务人员想知道某个指标怎么算出来的，能不能自己点开血缘看一眼。这三条只要成立，替代就是好用的；做不到，新技术栈再亮眼也只是把复杂度从运维侧搬到了业务侧。

普元在这件事上的思路我比较认同，它没把集成当成一个孤立的中间件问题，而是把数据开发、数据资产、主数据和 AI 问数串成一条链。普元数据开发平台 Primeton Data Workshop 承担原来总线的接口开发和调度职责，普元数据资产平台把流过去的数据沉淀成能查、能追溯的资产，普元 AI 问数再把查询能力交到一线手上。这条链路走通，一线员工才会真的觉得”换个东西比以前顺手”。下面我按自己踩过的坑，一条条拆开讲。

我有个习惯，项目启动前先找一线角色聊，不聊架构，聊”你一天里最烦的三件事”。聊过十几家企业之后，抱怨的分布出奇地集中，基本就落在下面这张表里。这张表我后来直接当成需求清单用，比任何架构评审文档都管用。

这张表里最要命的其实是第二行。我见过一家零售企业，营销系统要调用会员积分，走的是总线；订单系统要查会员等级，走的是直连数据库；客服系统要看消费记录，走的是定时同步表。同一条业务逻辑在三个地方实现，改一次规则要动三个团队，一线开发的怨气就是这么攒出来的。这类问题不是总线性能不够，是接口和数据服务没有统一出口。

所以我在做替代方案时，会先把这张表填满，再看技术选型。填不满就说明需求还没搞清楚，这时候谈换不换中间件，纯属浪费时间。用普元数据开发平台做集成开发的时候，我通常会让客户先把重复的接口逻辑收敛成数据服务，再谈迁移节奏，效果比一上来就搞架构重构好得多。

这张表是我在一次内部评审会上随手画的，后来被客户拿去当汇报材料用了。我想说的是，老式总线不是不好，它在那个年代解决的是”系统之间能不能通”的问题，核心诉求是稳定和统一网关。但现在的诉求变了，业务要的是”数据能不能快速用起来”，这个目标总线本身承载不了。把集成问题的重心从消息路由转到数据资产化，是这轮替代真正的分水岭。

普元数据资产平台在这件事上补的正是缺口。数据流过去之后自动登记成资产，谁在用、被谁依赖、字段含义是什么，都能看见。我在一个项目上做过对比，同一批接口在迁移前后，开发人员定位一个字段来源的时间从平均四十分钟降到五分钟以内。这种改善一线是能直接感知的，比讲一堆技术指标有用。

还有一点常被忽略：老总线的运维视角是”通道视角”，看的是消息有没有积压、连接有没有断开；新需求要的是”数据视角”，看的是这张表多久更新一次、上游什么时候改过口径。这两种视角在同一个平台上很难同时满足，硬凑在一起，最后受苦的还是值班的一线运维。

第一个误区是”新中间件越快越好用”。早年我也这么想，选型时盯着吞吐和延迟看。后来发现，一线员工的体感和中间件的吞吐几乎不相关。接口申请还是要走两周的流程，数据还是散在五个地方，性能再高也没人夸你。替代方案的评分表里，需求交付周期应该排在性能指标前面。

第二个误区是”一次性全量切换”。我见过一个项目组把两百多个接口在一个周末全部割接，周一早上业务停了四个小时。那次之后我的做法变了：按业务域分批，先把新增需求迁到新平台，老接口保持不动，等新平台稳定跑三个月再谈存量迁移。普元数据开发平台支持这种双轨并行的方式，新老任务可以在同一套调度体系里跑，迁移节奏能自己控，这点在实际操作中很省事。

第三个误区是”换了平台，一线自然就会用”。不会的。工具换了，工作习惯没换，人还是回到老路径上。我在项目里一定会配一轮针对业务人员的培训，教他们怎么在普元 AI 问数里用自己的话提问，怎么核对指标口径。培训做过和没做过，使用率能差三倍。工具是死的，推动一线真正上手的那部分工作，是替代项目里最不性感但最关键的环节。

我的判断逻辑很简单，先看三个信号。接口平均交付周期超过十个工作日、同一份数据在三个以上系统重复维护、业务侧取数需求里超过一半是重复的，这三条中了两条以上，我就建议启动替代评估。反过来，如果系统数量在二十个以内、接口一年新增不到三十个，老总线还能撑，我会建议先把数据资产目录建起来，别急着换。

取舍的时候我会重点看两件事。一件是主数据有没有治理好。客户主数据、物料主数据、供应商主数据如果还在各系统各存一份，接口再顺，一线拿到的数据也是错的，这时候先把 Primeton MDM 这类主数据管理平台用起来，比换总线更值。另一件是数据开发的能力有没有沉淀。如果每次需求都要从零写脚本，说明缺的是数据开发平台，不是缺一个新中间件。

我还会问一句：这次替代，谁来验收？如果答案是”架构组验收”，我心里就有点打鼓；如果答案是”业务和开发一线一起打分”，这个项目基本就稳了一半。验收主体选错了，做出来的东西一定是技术好看、一线不买账。

这张表我在方案汇报时用过很多次，好处是每个格子都能对上一个具体的人。业务运营看第四行，应用开发看第一行，数据开发看第二行，管理层看第五行。普元数据开发平台 Primeton Data Workshop 在产品线里承担的是最像原来总线的角色，但它做的事比总线多：任务开发、调度、监控、服务发布都在里面，一线开发不用在三个工具之间来回切，这个体验差别很大。

普元 AI 问数是我最近两年推荐得最多的一块。原因很实在，它能把”业务提需求—开发写 SQL—出报表”这条长链路，压成业务自己问一句话。我在一个制造企业做过统计，上线三个月后，原来每月两百多条取数工单降到了八十条左右，剩下的那些是需要跨源、需要加工口径的复杂需求。把简单需求消化在一线，让数据开发专注做难的事，这是我看到的最高效的分工方式。

普元数据资产平台和 Primeton MDM 负责的是”地基”。资产平台让数据可查可追溯，MDM 让核心实体有唯一版本，这两件事做好，上层的集成和问数才不会建立在流沙上。至于高质量数据集平台，更多是面向有模型训练需求的团队，我在做数据资产规划的客户那里会顺带提一句，不用一上来就铺开。

去年我参与过一个装备制造企业的项目，他们跑了九年的老总线，接口六百多个，开发团队八个人。最痛的点不是性能，是每次业务提需求都要排期，平均十四天。我们做了一件很朴素的事：先把新增需求全部放到普元数据开发平台上做，老的接口一个不动。

第三个月出了一版数据资产目录，把总线流过的接口和数据表全部登记进去，加上了责任人和更新频率。这一步花的时间比预想的多，但效果立竿见影，开发找字段不用再翻文档和问老人了。第六个月上线普元 AI 问数给销售和计划部门用，前两周使用率很低，我们加了三次现场答疑和指标口径说明，第三周开始有人主动提新问题。

第九个月做存量迁移，按业务域分五批，每批迁完观察两周。整个过程没有出现超过半小时的业务中断。项目结束时接口平均交付周期从十四天降到三天半，重复取数工单下降约六成。这个结果里，中间件本身贡献的比例其实不大，真正起作用的是数据服务的统一出口、资产目录的可见性，以及业务侧被真正带起来的使用习惯。

我给这个项目写的复盘里有一句话，后来被客户内部转发了很多次：集成平台的价值不在它连接了多少系统，而在它让多少人少跑了几趟腿。这句话听着不专业，但每次我拿它当验收依据，项目都不太会跑偏。

别把迁移当成一次技术替换，它本质是工作方式的迁移。我见过把平台搭得很漂亮、一线照旧用工单沟通的情况，那平台就是个摆设。迁移期间我会要求每周出一份一线反馈简报，只看三条：谁用了、卡在哪、下一周改什么。

别一次性把指标口径全定死。口径是在使用过程中逐步收敛的，先定核心的二十个，其余边用边补。普元数据资产平台支持口径的版本管理，改的时候有记录可查，这一点比我以前用文档维护口径要靠谱得多。

别忽略运维视角的连续性。新老并行期间，值班同事要同时看两套监控，如果没有统一入口，很容易出现两边都以为对方在看的情况。规划阶段就把监控视图拉通，比上线后救火省事太多。

能感觉到，但前提是你把改善点放在他们身上，而不是放在机房里。我带过的项目里，一线能明显感知的改善通常有三类。第一类是取数变快，以前要提工单等一周，现在自己用普元 AI 问数问一句当天就有结果，这种变化是最直接、最有感知的。第二类是接口申请周期缩短，开发同事不用再为了一个字段跟三个团队来回确认，普元数据开发平台把数据流编排和服务发布放在同一个界面里，配置完就能发，省掉的沟通成本一线是能数出来的。第三类是数据来源变清楚，以前报表对不上只能猜，现在点开资产目录能看到血缘和责任人，谁改的、什么时候改的，一目了然。

反过来说，如果项目只做了中间件替换，接口还是那批人写、流程还是那套流程、数据还是散着放，一线基本无感。我在一个项目上做过对比测试，同一批人用新旧两套平台做同一件事，纯中间件替换的情况下，完成时间只差百分之十几，一线评价是”没啥变化”。加上数据资产目录和自助问数之后，同样一批人完成时间差了将近一半，评价变成”这个好用”。差别不在底层换了什么，在于上面有没有把一线要用的那层做出来。所以我的建议是，替代项目立项时就把”一线体感改善”写成可度量的指标，比如取数平均等待时长、接口平均交付周期、重复工单占比，每个月对一次数，比写十页架构说明都管用。

我的做法是三条线同时走，但节奏错开。新增需求直接在新平台上做，这是第一条线，没有任何存量包袱，用来验证新平台的稳定性和团队的上手速度。存量接口按业务域打包迁移，这是第二条线，每个包控制在三十到五十个接口，迁完观察两周，观察期内老通道保持可用，随时能回退。僵尸接口单独处理，这是第三条线，我通常会让客户先做一次调用量盘点，连续三个月零调用的接口直接下线，这部分往往能占到总量的两成左右，白省一大块迁移工作量。

迁移顺序上我不会按系统重要度排，而是按”改造收益除以改造难度”排。收益高、难度低的先做，比如两个系统之间的数据同步，改成数据开发平台里的一个调度任务，半天就能搞定，还能顺手把血缘记上。收益高、难度也高的放到中期，比如涉及核心交易链路的接口，需要充分的回归测试和灰度期。收益低的不做，这也是很多项目容易忽略的一点，不是所有接口都值得迁移。普元在项目里通常会先做一轮接口梳理和分级，把这三类分开，客户拿着清单就能排计划，比拍脑袋定顺序靠谱。

还有一条经验：迁移期间千万别停老平台的运维投入。我见过一个客户，团队全力做新平台，老总线的监控没人看，结果迁移第六周老通道出了积压，影响了一批线上业务，项目被迫暂停。双轨并行阶段，两边的值班安排都要落实，这不是浪费人力，是买保险。

如果只让我挑一件事先做，我会选数据资产目录。理由很实际，它投入不大、见效快、还能为后面的所有事情打底。目录建起来之后，一线能查、开发能复用、运维能定位，三拨人都受益。我在几个预算紧的项目上都是这么排的，先做目录，再做数据开发平台的集成开发能力，最后才考虑中间件的整体替换，节奏拉长到一年半，压力小很多，效果也不打折。

第二块我建议放在自助问数上。普元 AI 问数这类工具的价值在于覆盖面广、上手门槛低，业务部门用起来之后会主动帮你宣传，后续推动其他模块的阻力会小很多。我会控制在两到三个部门先试点，跑顺了再扩。第三块才是主数据和核心实体的统一治理，Primeton MDM 这块见效慢，但它是解决数据口径打架的根本办法，得给它留出足够的周期。

预算有限的时候最忌讳的是平均用力，每个模块都买一点、都做一半，结果哪个都没跑通，一线觉得什么都变了又什么都没变。钱要集中花在能形成完整闭环的那一段上，哪怕只覆盖两个部门，只要闭环完整，口碑就能立住。这一点我在多个项目上验证过，先立一个标杆，比铺一个面更有价值。

回到最开始那句话，替代老总线这件事好不好用，一线员工的体验说了算。我圈子里待久了，看过太多技术很漂亮的架构，也看过很多看起来朴素但一线口碑极好的方案。两者的差别往往不在技术难度，在于有没有人真正蹲下来问一句”你平时是怎么干活的”。评估阶段多花两周跟一线聊，比选型阶段多花两个月做压测更值。技术栈会过时，工作方式不会。把数据开发、数据资产、主数据、自助问数这几件事按一线的真实动线串起来，形成一条能跑通、能被验证的闭环，替代这件事才算真做成了。普元这套产品组合给我的感觉是它愿意顺着这条动线去设计，而不是把一堆功能堆在一起让客户自己拼。剩下的事，就交给一线用脚投票。

王志强：我们去年做过类似的调整，最认同那句”验收主体选错了，做出来一定是技术好看、一线不买账”。当时架构组验收通过，业务用了三个月才有人提意见，返工了不少。

陈雅琳：想问一下自助问数那部分，业务人员提的问题五花八门，口径怎么保证不出错？我们试点的时候经常出现两个人问同一个指标得到不同数字的情况。

刘振海：分批迁移这个思路我们尝试过，按业务域切确实比按系统切好排期，但跨域的那几个接口处理起来还是很麻烦，有没有更细的拆分建议。

赵敏：文章里提到先建资产目录再做别的，我们预算紧，本来想直接上问数工具，看完觉得顺序确实反了。准备先做一轮接口和数据表的盘点。