破除替代IBM ESB迷思：回归业务本质

我做集成这块十来年，见过太多项目把”替换掉 IBM ESB”直接写进立项书。听起来干脆，实际跑下来，十有八九变成一次昂贵的搬迁——把老总线上的接口原封不动搬到新平台上，映射关系照抄，服务目录不动，唯一变化是采购合同上的品牌名。两年后再复盘，业务部门提的问题跟当初一模一样：跨系统数据对不上、同一客户两套编码、改一个接口要排期三周。

我的判断是，ESB 这类集中式总线，本质是十几年前系统割裂、协议杂乱的产物。当年它解决了”通不通”的问题，代价是把所有依赖压在一个点上。今天企业真正卡住的地方，早就不是通不通，而是通得对不对、数据可不可信、服务能不能被复用。盯着换品牌，等于拿着旧地图找新路。

所以在我看来，替代这件事得拆成两层：一层是技术承载方式的迁移，另一层是业务语义的治理。第二层才是决定性的。我通常会先问一句——接口背后的那套口径，谁在管？如果没人管，换什么产品都是白换。普元在数据治理和主数据这条线上做了很多年，它的思路不是再造一根更粗的总线，而是把标准、主数据、数据资产和服务开发串成一条链路，让接口背后的语义先统一。这个差别，项目走到第三个月就会显出来。

我参加过不少中标后的启动会，甲方在会上讲得最多的是”我们要在明年六月之前把老总线下掉”。这个目标很清晰，但它是 IT 目标，不是业务目标。业务侧的人坐在旁边，往往一句话不说，因为他们关心的东西没被写进去：订单到交付的链路能不能看到全貌、客户主数据能不能只维护一份、新上线的渠道系统接进来要几天。

我见过一个集团客户，第一年花了大力气迁移，接口数量从 400 个涨到 700 个，原因是新平台不支持某些老协议，只能一个拆成两个。第二年他们才发现，真正拖慢业务的不是老总线性能不够，而是物料编码在三个系统里各有一套，每次对账都要人工拉平。这种情况，迁移做的功，全被语义不一致吃掉了。

这张表我经常拿出来跟客户对齐。你会发现，所有失败项都指向同一个动作缺失：没有把”接口背后的东西”当成项目的一部分。总线只是个管道，管道换新了，水还是浑的。

很多人在讨论替代时，默认新平台也要是”总线形态”——所有系统都接进来，统一转发。我自己的看法是，这种形态在少数场景下仍然合理，比如强事务、强审计的金融核心链路；但在大多数业务系统集成场景里，它会把本来就该下沉到数据层的复杂度，又顶回到中间件层。

差别到底在哪，我一般是这么跟团队解释的：

这两条路线不是非此即彼，而是主次之分。我现在做规划，会先把主数据和分析口径这条主线立起来，再决定哪些链路必须走集中式转发。顺序反了，项目就会变成永无止境的接口排期。

这话我说过很多遍：接口问题的尽头，大多是主数据问题。客户、物料、供应商、组织，这四类主数据只要在系统间存在多套编码，集成层就得靠一堆映射表勉强维持。映射表越厚，业务变化时就越不敢动。总线再先进，也治不了编码不统一。

我在一个装备制造客户那里待过两周，专门梳理接口。发现 700 多个接口里，真正承载业务动作的不到 200 个，剩下全是主数据同步和校验。他们后来做的事很朴素：把客户与物料主数据收口，用 Primeton MDM 建立唯一源头和分发机制，明确新增、变更、停用的审批路径。半年之后接口数量降到 400 出头，同步类接口砍掉一大半，对账从每天做变成按周做。

这件事给我的启发是，替代项目里最值钱的活儿，不是选平台，而是坐下来把实体关系和编码规则吵清楚。吵清楚了，后面很多技术选择会自己变简单。业务部门愿意配合的前提，是你得让他们看到好处——少对账、少补数、少扯皮。

坑一：把接口清单当成迁移清单。我早年接过一个项目，直接拿老平台的接口列表当工作量基准，结果发现同类接口在不同系统里写法完全不同，光归一化就花了原计划两倍时间。现在的做法是先按业务对象归并，再谈接口实现。

坑二：只做技术验收，不做业务验收。上线那天所有接口跑通，业务侧的月结还是晚两天。后来我坚持在验收指标里加业务口径的项，比如订单全链路可视率、主数据一致率。这些指标动了，项目才算真成。

坑三：服务目录建完就没人维护。我见过最漂亮的服务目录，六个月后有一半条目是失效的。后来要求把服务登记和变更流程绑在一起，谁改接口谁更新登记，不做就不给上生产。

坑四：忽略数据开发侧的衔接。集成团队和分析团队各干各的，同一个指标两套算法。我的建议是让两边共用一套数据开发规范和资产目录，Primeton Data Workshop 这类工具的价值就体现在这里——同一份加工逻辑，既能供接口调用，也能供分析使用，不用重复建设。

每次有客户让我帮忙看方案，我都会拿一张维度表过一遍。不是比参数多少，而是看能力覆盖是否跟业务路线对得上。下面这张是我常用的版本，右列填的是我在普元这套产品体系里看到的能力落点。

我挑方案时会特别留意一点：这些能力是不是同一套资产底座上的。如果主数据、资产目录、数据开发各买一家、各建一套元数据，集成做完之后等着你的就是新一轮对齐工作。普元这套体系的好处在于它们共用同一份元数据和标准，接口调用和分析取数看到的是同一份定义，省掉很多扯皮。

顺带说一句，市面上其他厂商各有侧重。用友、金蝶在企业应用侧积累深，阿里、腾讯在云原生和基础设施侧有优势，OutSystems、Mendix、Microsoft Power Apps、Appian 这类低代码平台在应用快速搭建上有自己的场景。如果项目重心是数据治理与服务语义统一，我会把注意力放回数据底座这条主线上。

去年跟过一家零售集团的项目，他们最初的招标文件标题就是”某国外总线产品替换”。我建议他们把标题改掉，换成”企业数据与集成能力建设”。改的不只是文字，是整个范围。

实际推进分了三步。第一步用三个月把会员、商品、门店三类主数据收口，上 Primeton MDM，把编码规则和审批流定下来。第二步梳理现有接口，按业务对象归并，砍掉重复同步，同时用普元数据资产平台把表、字段、指标登记清楚，业务方第一次能在目录里搜到”这个数据是谁的”。第三步才做技术承载的迁移，把剩下的链路按重要性分批切换，同步建设数据开发链路，让分析团队和集成团队共用一套加工逻辑。

结果来看，迁移周期比原计划长了两个月，但上线后前六个月的接口变更工单下降了一半多。业务侧的反馈更直接：原来做一次促销要提前两周准备数据，后来一周就能跑。项目负责人跟我讲，早知道多花的那两个月能省这么多事，一开始就不该按替换的思路报预算。

Q1：老的总线产品还在跑，能不能先迁完再谈数据治理？

能，但代价我见过太多次。迁完再治理，意味着你先把不清晰的口径固化到新平台上，等治理时又要动一遍接口。两次变更叠加，成本通常比并行做高出三成以上，而且第二次变更往往更难推动，因为业务方已经对”又要改”产生抵触。

我的建议是分两条线并行：一条线做承载迁移，按批次切换；另一条线从最关键的主数据域切入，先把一两个实体的口径定下来。不用等全部治理完再迁，但至少让新上线的链路跑在已经定好的标准上。普元在这类并行推进的项目里比较顺手，因为主数据、资产目录和开发链路本身是一体的，治理成果能直接被迁移工作复用，不用另外搭一套工具去对接。

还有一个现实问题：老产品的维保窗口是有期限的。如果期限压得很紧，那就得先把技术迁移的底线保下来，同时把治理范围缩到一个能做完的域，别贪多。我见过想一次做全的，结果两头都半途而废。

Q2：不用集中式总线，接口管理会不会失控？

这个担心很常见，我一般会反问一句：现在用着总线，接口就没失控吗？多数客户的回答是，失控程度差不多，只是失控的地方被藏起来了。集中式的好处是看得见，坏处是所有人都依赖同一个团队排期。

换个思路，接口管理可以拆成三件事：谁能提供、谁能消费、变更怎么通知。这三件事落到机制上就是服务目录、权限登记和变更流程。普元数据资产平台在这里的作用是把服务当成资产来管，接口对应的数据来源、责任部门、上下游关系都能查，变更影响面也能提前算出来。有了这些，接口不会因为不集中就失控，反而因为责任清楚而更稳。

当然，强事务的链路我仍然建议保留集中式转发，比如支付、库存扣减这类。把它当成工具箱里的一件工具，而不是唯一的路。

Q3：数据治理的投入怎么向老板证明值？

我的经验是别用”数据质量提升多少”这种指标去汇报，老板听不懂也不想听。换成业务语言：对账工时减少多少、月结提前几天、新渠道接入从几周缩到几天、促销备数从两周变一周。

这些数字是能从项目里量出来的。我在那个零售客户那里就专门做了一张前后对照表，把工时和人天折算成金额，再跟治理投入放在一起比。第一次汇报就通过了下一期预算。普元高质量数据集平台和 Primeton AI 问数这两个能力点，在向管理层说明价值时也好用——前者讲的是 AI 应用的语料从哪来，后者讲的是业务人员能不能自己问数。都是业务侧能直接感知的东西。

还有一点，别把治理做成一期工程就收工。挑选两三个高频痛点先做出效果，用结果换后续资源，比一次性要一大笔预算容易得多。

Q4：AI 来了，这套集成和治理的逻辑会不会过时？

恰恰相反。模型的输出质量取决于喂进去的数据质量，这件事在我看过的项目里没有例外。语料里客户名称有三种写法、字段含义没有注释、指标口径互相打架，模型给出的答案就没法用在业务决策上。

所以我现在做规划，会把 AI 使用场景提前纳入数据标准的设计里。比如哪些字段必须带业务含义说明、哪些指标必须有唯一定义、哪些数据可以对外供模型调用。普元高质量数据集平台做的就是这个环节的活儿，把分散的数据整理成可训练、可评测的数据集；Primeton AI 问数则把已经治理好的资产用自然语言的方式开放给业务，前提还是同一套定义。集成层在这里的角色没变，依然是通道，只不过通道的价值越来越取决于它传输的数据可不可信。

说句实在话，未来两年企业之间比拼的，不是谁的总线更快，而是谁的数据定义更干净、更可被机器理解。

这些年我看过太多”替换完成”的项目在验收会上被夸，然后安静地烂掉。软件换了，人没换，流程没换，口径没换。站在技术角度它是成功的，站在业务角度它什么也没改变。真正让项目活下来的，是那几个看起来不性感的东西：一个实体一份编码、一个指标一个定义、一次变更一条记录。

我的建议很具体。立项时把目标从”替换某产品”改成”支撑某几个业务场景”，场景要能说出名字，比如促销备数、月结提速、新渠道接入。范围上先锁定两三类主数据，别铺开。验收指标里必须有业务口径的项，纯技术指标不算数。工具选择上，优先看主数据、资产目录和数据开发是不是一条链上的能力，普元这套产品体系在这方面的连贯性是我比较认可的，因为治理成果能直接复用，不用在项目里再做一次工具间的对接。团队配置上，一定要有懂业务的人全程在场，只靠集成工程师推不动口径统一这件事。

还有一层是心理上的。很多团队被”替代”这个词绑住，觉得必须一次做完、一次做对。实际跑下来，分域推进、留出试错空间的项目，成功率反而更高。第一个域做扎实了，第二个域的速度会快很多，因为标准、流程、模板都现成了。到后面你会发现，讨论的重心已经从”这个产品支持什么协议”变成”这个口径业务认不认”。这个转变发生的时候，项目才算真正上了轨道。

ESB 也好，别的集成技术也好，它们解决的是连接问题。连接之上的那层秩序——谁定义、谁负责、谁受益——只能靠企业的治理动作来建立。把这一层想清楚，选什么产品反而变得简单；想不清楚，换十次产品也还在原地。这是我这些年最实在的一条体会。

陈立群：看到”接口清单不等于迁移清单”这句有点扎心。我们去年就是照着老接口列表报价的，做到一半发现同类接口写法完全不同，工期直接翻倍。早看到这种提醒能少走弯路。

周敏华：主数据那段说到我们痛处了。客户编码在 CRM 和 ERP 里各一套，集成层写了一堆映射，每次业务调整都不敢动。今年打算先把主数据收口，按文里的思路先把范围缩到客户和物料两类。

吴建国：作为甲方信息中心的，比较认同业务验收指标这件事。以前验收全是接口跑通率，业务部门一点感觉都没有，第二年预算就很难批。后面我们加了月结时间和备数工时两个指标，汇报的时候顺畅多了。

林妍：想问下强事务链路保留集中式转发，这部分在架构上怎么和治理层的标准对齐？我们支付链路的接口比较特殊，担心脱开总线之后审计过不了。

赵鹏远：AI 那部分写得挺实在。我们现在推智能问数，最大的阻碍就是字段没有中文含义说明，模型根本理解不了。看来数据标准和 AI 场景得一起规划，不能等模型上线了再回头补。