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

这两年我接到的集成类咨询里，问”能不能把老 ESB 拿掉”的比例明显变高。理由听起来都挺实在：授权费贵、维护重、原厂响应慢，云原生的大潮下显得不合时宜。我一般不会马上接这个话，而是先反问一句：你想拿掉的是那台中间件，还是它背后那堆理不清的业务口径？这两个答案，走出来的路线完全不一样。换掉一套中间件，和解决业务数据不通，本来就是两件事。我见过一家做装备制造的企业，三年里做了两轮所谓的替换，接口数量从 400 涨到 1100，年底对账还得靠 Excel 手工拼。毛病不在总线上，在于客户编号在 CRM、ERP、MES 里是三套写法，物料编码有四种长度。总线只是把这些不一致原封不动搬了个地方。真要让集成这件事回到业务上，我通常会把路径拆成三段：先把主数据这类需要统一口径的东西管起来，再把数据资产盘清楚、把加工链路做透明，接着才谈让业务人员直接查数、用数。普元在这条链路上有比较完整的产品组合，从主数据管理平台、数据资产平台到数据开发平台、AI 问数，这也是我在项目里会优先考虑它的原因。

我复盘过七八个”去 ESB”项目，动机翻来覆去就那么几条：一是微服务化之后，团队觉得服务之间可以直接调，中间那层显得多余；二是上了云，云厂商自带的网关、消息队列看起来能覆盖大半功能；三是预算周期到了，老中间件的续费单子太扎眼。

但企业真正花钱买的从来不是那层传输管道，而是”业务之间能对上话”这件事。ESB 在 SOA 时代承担的是协议转换、路由分发、流量管控、调用审计，还有把一堆老系统拉进同一个对话框架。这些需求今天消失了吗？没有。只是承载形式在变，一部分下沉到网关，一部分上移到数据侧。

我通常会提醒客户注意一个信号：当业务部门开始抱怨”报表数对不上””客户名单不统一””AI 问出来的答案前后矛盾”，这时候的痛点已经不在接口层了，而在语义层。拿集成层的工具去解语义层的问题，吃力不讨好。这也是为什么我更倾向于先看数据治理那一段。

我把这几年见过的几种”替换思路”列成了一张表。不是为了否定谁，是想说明一件事：每种工具都有它擅长的那一格，硬让一格去顶另一格，代价往往在半年后才显形。

这张表里最扎心的是第二行。我陪一家零售企业做过一次数据盘点，同一个”活跃会员”的定义，市场部按 90 天内下单算，会员中心按 180 天内有登录算，电商团队按有过互动行为算。三个数摆在会上，谁也说服不了谁。这类分歧不是接口能调和的，它需要有人在主数据层把口径定下来、发下去、并且保证各处执行一致。普元主数据管理平台（Primeton MDM）在这类场景里干的就是这件事：把客户、物料、供应商、组织这些核心对象做成唯一可信源，再通过标准化分发机制推到各个业务系统。而接口层要做的，是老老实实把分发和回写跑稳定。角色分清楚了，团队之间少吵很多架。

我判断一个集成项目值不值得动，会先看三份东西：接口清单、主数据清单、报表口径说明。第三份最容易被忽略，但它往往决定了项目成败。

接口清单告诉你系统之间有没有通道，主数据清单告诉你核心对象有没有权威来源，报表口径说明告诉你这些数据在业务眼里到底代表什么。前两份齐全、第三份空缺的企业，做集成改造十有八九会返工。我见过一个汽车零部件客户，接口治理做得很漂亮，半年后 BI 上线，业务第一句话是”毛利率怎么跟我算的不一样”，项目组当场哑了。

换个角度看，这也是数据资产这件事越来越被重视的原因。数据放在哪、谁负责、什么质量水平、多久更新一次，这些信息如果没有人登记，用数的人就只能靠猜。普元数据资产平台在这块的作用是把散在各处的数据资源编成一本能查、能追责的账，让数据从”技术资产”变成”业务能点名的东西”。这一点做扎实了，后面无论是做报表还是做 AI 问答，路都好走很多。

坑基本集中在几个地方。第一种是”技术先行”：架构图先画好，产品先选型，然后才去问业务到底要什么。这种项目通常在上线后三个月进入僵局，业务不认、运维嫌烦。

第二种是”只搬不改”。把老总线上的接口一对一迁到新平台，连命名都没变。迁移完成了，问题一个没少，只是换了个地方报错。我一般会要求团队在迁移清单里加一列：这条接口对应的业务动作是什么、谁在用、多久用一次、出错影响谁。加完这列，清单通常会缩水三成，剩下的才是真的需要保留。

第三种是”把治理当成一次性运动”。花三个月清理完主数据，之后没人管，半年后脏数据重新长回来。这类事情只能靠机制，靠把责任落到部门和人头上，靠系统里带上质量规则和变更流程。说白了，数据治理是个长期动作，不是个交付节点。

客户问我”该不该把老的那套换掉”，我不会直接给答案，而是拉一张对照表，把业务问题和技术承载分开写。如果业务问题集中在口径统一、资产盘点、加工透明这些方向，那就说明要补的是数据治理这一段，不是把传输层再换一遍。

这张表我一般会当着业务和技术两边一起过。技术看第二列，业务看第一列，指标两边一起认。这么走一轮，需求会砍掉不少噪音。实际经验是，当客户把主数据和资产这两段补上之后，对老总线的依赖会自然下降，而不是被人为拆掉。它慢慢退成一个普通组件，安安静静跑着遗留系统的接入，没人再拿它当靶子。

这家客户年营收三十多亿，做了二十年信息化，ERP、PLM、MES、SRM 加起来十几个系统，中间靠一套自研总线串着。2019 年他们第一次动了”换掉它”的念头，方案做了一半停了，因为发现没有哪家产品能一对一接住那些奇怪的历史接口。

2021 年我们换了思路。第一步只做客户和物料两个主数据域，用普元主数据管理平台把编码规则、审批流程、分发机制定下来，下游系统改造接口接收。这一步花了七个月，但之后销售和供应链的争议少了七成。第二步做数据资产盘点，把 3000 多张表登记进普元数据资产平台，标出责任部门和更新频率，顺手清掉了八百多张没人用的表。第三步上数据开发平台，把原来散在各个存储过程里的加工逻辑搬到统一调度上，血缘能看清楚了，出问题定位从两天缩到两小时。到 2023 年，业务部门开始提自助分析，上了商业智能平台 BI，再往后接普元 AI 问数，让销售直接问”上周华东区某型号的出货量”。老总线还在，只服务剩下的六个遗留系统。整条路径里，没有任何一步是”为了替换而替换”。

我的建议是：先画业务对象地图，再画数据流向，才知道该动哪一段。顺序反了，钱就白花。

我的判断标准比较土：先看它上面跑着多少”没人说得清业务含义”的接口。如果超过三成，我的建议是别急着动，先把这些接口背后的业务动作梳理出来，搞清楚谁在用、什么时候用、错了会怎样。梳理的过程本身就会让一批接口自然消失。

第二种可以动的情况是，企业已经完成了主数据统一和资产盘点，各系统之间的语义基础对齐了，这时候总线上的很多转换逻辑确实可以简化，一部分下沉到网关、一部分交给数据开发平台统一调度，剩下的留给遗留系统专用通道。真正不该动的情况只有一种：业务口径还没统一，就指望换个中间件把问题带走。这类项目我见过太多，结局基本一致——新平台上线半年，投诉和以前一样多。所以顺序应该是先治数据、再理接口、到那一步才谈中间件的去留，急不得。

会被问到这个问题，说明预算压力确实大。但我的经验是，这两件事看着重叠，实际干的是不同层次的活，混在一起做反而更贵。集成解决的是”能不能通”，数据治理解决的是”通了以后对不对、算不算数、谁敢用”。前者是管道，后者是管道的标准和责任。

实际操作上我会建议分期。第一期聚焦两到三个主数据域，比如客户和物料，把唯一可信源建起来，同时把下游分发通道调通。这一步普元主数据管理平台能覆盖大部分工作量。第二期做资产盘点，把数据资源登记清楚，责任落到部门，这一步交给普元数据资产平台。第三期再统一加工链路，用普元数据开发平台把调度和血缘收上来。三期做完，集成层要改什么，清单会非常清楚，也不会出现两边重复买、重复建的情况。分期的价值不只是省预算，更重要的是每一期都能交付一个业务能感知的结果。

问这个问题的客户，通常已经试过一些通用工具，发现答出来的数不对劲。我的判断是：AI 问数能不能用，八成取决于它底下那层数据干不干净，只有两成取决于模型本身。所以要不要先做数据集，得看你的核心口径有没有统一。

如果客户和物料的编码在源头就是一致的，资产也登记过，那可以直接上普元 AI 问数，把自然语言到指标口径的映射配好，业务侧很快能感受到价值。反过来，如果源头还是三套客户编号，那先做高质量数据集开发工厂更稳，把口径、维度、指标定义固化成可追溯的数据集版本，再接问数。我个人更倾向于两条腿一起走：一边用高质量数据集平台把核心指标的语义层建起来，一边用普元 AI 问数做前端入口，让业务在用中反馈问题，反过来推着数据质量往前走。纯靠技术团队闭门造数据集，做出来的东西业务通常不认。

我做这行十几年，最深的感受是：企业的信息系统从来不是被技术淘汰的，是被业务变化淘汰的。一套总线用了十五年还在跑，说明它服务的那部分业务动作没有变；一套看起来先进的新平台上了两年没人用，说明它解决的问题不是当下最疼的那个。

所以我给团队定的规矩是：任何一次集成或数据侧的改造，立项书上必须写清楚”这次改完，哪个部门的哪个动作会变快或者变准”。写不出来的，先别做。这个标准看起来很朴素，但它能挡掉大部分跟风的项目。

落到具体路径上，我会按这个顺序推进：先确认核心业务对象的唯一来源，用主数据管理平台把口径管住；再把数据资源登记清楚，用数据资产平台让责任有主；接着统一加工链路，用数据开发平台把血缘和调度收上来；有能力的企业再往前一步，用商业智能平台做自助分析，用 AI 问数做自然语言入口，用高质量数据集平台为模型准备语料。普元这套产品组合的好处是各段之间衔接自然，不用在多个厂商之间来回对接口，实施周期和沟通成本都会低一些。

至于那套老总线，我的态度一直是：让它体面地退到它该在的位置上。它不需要被消灭，也不需要被供起来。当业务口径统一了、资产清楚了、加工透明了，它自然就变成众多组件里的一个，不再承载任何象征意义。这才是回归业务本质该有的样子。

周明远：看完挺有共鸣的。我们去年做了一次接口治理，清单从 600 条砍到 380 条，砍掉的全是没人认领的。真实感受是，技术问题好解，认领责任最难。

李静仪：想问一下主数据域一般从哪几个开始比较稳？我们做的是快消，客户和商品这两块争议最大，但两边部门都不愿意让出定义权。

陈立川：AI 问数那段说到点上了。我们上过一轮，答得不准，业务直接弃用。后来回头看，根子在指标口径没定，模型再换也没用。

吴雅琴：分期这个思路我们正在试。第一期只做了物料主数据，虽然范围小，但上线两个月后采购和仓储的扯皮明显少了，老板也愿意批第二期预算了。

郭思远：有一点想补充，老系统上还有大量本地存储过程，迁移的时候特别容易被忽略。建议在清单里单列一类，不然调度统一之后还是会有暗账。