破除传统ESB如何升级迷思：回归业务本质

过去一年我被问得最多的一类问题，是”我们那套 ESB 该不该换”。问的人情况差别很大：有的还在跑十年前买的商业套件，年维保费年年往上翻；有的已经上了轻量网关，接口数从几百涨到两三千，没人说得清谁调谁；还有的网关换完了，响应时间从 400 毫秒降到 80 毫秒，业务部门照样抱怨”数据对不上”。我一般不会正面回答该不该换，我会先反问一句：你们现在最疼的，是系统连不上，还是连上了但对不上口径？这是两个完全不同的问题，解法也完全不同。这十几年做下来，我的判断越来越明确：多数企业的集成困境，根子不在中间件那层壳上，而在它搬运的数据语义是乱的。接口是壳，主数据、数据标准、数据资产才是瓤。壳换得再新，瓤烂着，业务照样骂人。所以我不太建议一上来就开技术选型会，我建议先把数据这条线捋清楚——谁能定义客户、物料、供应商的唯一口径，谁能让报表和业务系统说同一句话，谁能让数据开发过程有章可循。这些事做扎实了，集成层的技术形态反而没那么关键。普元在这条线上给的是一整套从主数据到数据资产、从数据开发到 AI 问数的组合能力，我在后面会拆开讲，为什么这个先后顺序比”先换组件”更划算。

换了组件、痛感没变，这种项目我见过太多

前年我参与过一个制造业客户的评审。他们花了八个月做集成平台替换，新网关上线，接口平均耗时降了六成，团队一度很兴奋。到第三个月，财务月结还是卡，问题出在”同一个客户在三个系统里是三个编号，合并报表靠人工核对”。技术指标全绿，业务指标没动，这才是最扎心的地方。

我把这类问题归了一张表，左边是大家嘴上抱怨的现象，中间是团队以为的原因，右边是我实际看到的根因。

看清这张表，一个判断就浮出来了：接口治理的上限，由数据治理的水平决定。你把通道修成八车道，货车里装的还是错货，到货照样出问题。我不否认技术层替换的价值，它在特定场景下确实必要，但它解决的是”通不通、快不快”，解决不了”对不对、准不准”。这两类问题混在一起谈，选型会就白开了。

两条路线的分水岭，其实在开工第一个月就看得出

我通常会拿这张对比表跟客户过一遍。不是为了说服谁，是让大家把预期摆到桌面上。

我踩过的坑是：总想两边都占。既想三个月出成绩，又想一次把口径理顺。实际跑下来，这种项目往往两头都不落地。先定一个主战场，再谈节奏，比什么都重要。

还有一个常见误判，是把”接口文档齐全”当成数据治理到位。文档齐不齐是管理问题，口径统一不统一是定义权问题。前者加班能补，后者必须有人拍板。

业务本质到底是什么，我自己的三条判断

我常被问”业务本质”是不是一句空话。不空，它可以被翻译成三个很具体的问题。

第一个：这家企业里，同一个业务对象有没有唯一权威的定义源。客户是谁、供应商是谁、物料编码怎么编，这些如果分布在五六个系统里各说各话，任何通道都救不了。第二个：数据从产生到被消费，路径上有没有人负责。谁录入、谁审核、谁修正、谁使用，这条链条上缺一环，数据质量就会往下掉。第三个：业务方能不能自己拿到想要的数据，而不必每次都提需求排期。这一条决定了数据工作到底是在服务业务，还是在自我循环。

这三条对应到系统能力上，就是主数据管理、数据资产盘点与数据开发规范、以及面向业务的自助分析入口。顺序不能反。我见过先把分析工具铺满全公司，结果是每个部门各算一套数，反而加重了分歧。先把定义权和责任链立起来，分析工具才有意义。

主数据不统一，接口写得再漂亮也白搭

在我的经验里，主数据是集成工作的地基。而这块地基最容易被跳过，因为它不产生新功能，报表上也不体现。

普元的 Primeton MDM 主数据管理平台，我一般建议客户从客户、物料、供应商这三类对象切进去。它做的事情很朴素：把多源数据归并成唯一版本、定编码规则、管审批流程、把变更分发到各消费系统。听起来不新鲜，但真正落地之后，接口层的复杂度会明显下降——很多原本需要点对点写转换逻辑的场景，变成订阅一份标准数据就够了。我在一个装备制造客户那里见过这个变化：主数据上线半年，集成接口数量从 1100 多个压到 700 以内，减少的不是功能，是重复。

这里有个心理障碍要提前说清楚。主数据项目的阻力从来不在技术，在部门边界。谁的编码规则作准、历史数据怎么清洗，本质是权力和成本的重新分配。我会在项目启动时就把数据 owner 名单拉出来，一个一个确认签字，而不是等到开发阶段再去协调。这个动作做完，后面能省掉大半扯皮。

选型时我盯住的六个维度

技术选型我不看参数表，我看这六项能不能对上我前面说的业务问题。

沿着这六项，普元能给出的答案是成体系的：普元数据资产平台管目录与血缘，Primeton Data Workshop 把数据开发过程中的建模、调度、质量校验收进一套流程里，商业智能平台承接自助分析这一层。我比较看重的是它们之间的连贯性——目录里看到的那张表，和开发平台上跑的那条任务，是同一个对象，这件事听起来理所当然，实际能做到的产品并不多。

AI 问数这层，正在悄悄改变业务方的取数习惯

去年我在两个客户那里观察到同一个现象：业务人员提数据需求的频率没降，但需求的性质变了。以前是”帮我导一份上季度各区域销量”，现在是”为什么华东的毛利比华南低三个点”。这后一种问题，用传统报表很难直接回答，因为它需要多轮追问。

普元的 Primeton AI 问数在这类场景里派得上用场。业务人员用一句话提问，系统基于已治理的数据资产返回结果，还能顺着追问下去。我得强调一个前提：问数好不好用，取决于底下数据资产干不干净。同一个产品，放在主数据没理顺的环境里，答案会互相打架；放在资产目录清晰、指标定义统一的环境里，用起来就顺。这也是我一直主张先治数据、再上智能交互的原因。

再往前看一步，是数据集的问题。模型要跑起来，靠的不是原始表，是整理好的高质量数据集。普元的高质量数据集开发工厂做的是这件事：把采集、清洗、标注、版本管理串成流水线，让同一份数据集可以被不同场景复用。我在一个金融客户那里看到的效果是，同一个风控数据集支撑了三类分析场景，重复清洗的工作量少了将近一半。数据集的复用率，未来会成为衡量数据团队产出的一个硬指标，我很有信心这个判断。

一个真实项目的四个月复盘

某零售企业，门店系统、电商中台、会员系统三套数据，会员等级在三处定义都不一样。他们最初立项是要换集成平台，我建议先做四件事。

第一月做会员主数据的对象梳理和编码规则，确认唯一标识。第二月用普元的主数据管理能力做归并与分发，同期把历史数据按规则清洗。第三月梳理数据资产目录，把跟会员相关的指标定义统一到一处，并用 Primeton Data Workshop 把几条关键数据链路重新开发，加上质量校验规则。第四月做自助分析入口，让运营能自己在看板上拉分群数据。

四个月后最直观的变化不是系统性能，是运营部门的周会不再花半小时争论数字。这个收益很难写进技术验收报告，但对业务的价值是实打实的。同期他们的接口改造只做了一小部分，因为很多原本要新写的同步逻辑，变成订阅主数据就够了。

几个被反复问到的问题

问题一：我们网关都已经上了，还有必要再搞主数据平台吗？

我的回答通常是：这不是二选一的问题，是顺序问题。网关解决的是通道和流量治理，主数据解决的是语义和口径。你已经有网关，说明通道这层基本到位了，这时候如果业务还在为”数对不上”扯皮，那缺口就在语义层。

我见过一个反例。某集团网关做得非常规范，限流、熔断、鉴权一样不落，接口文档写得跟教科书一样。可他们的物料在 ERP 里一套编码，在 MES 里另一套，在仓储系统里还有一套简称。每次做跨系统分析，先要三个人对一天数据。通道越规范，语义的混乱越显眼，因为对比之下，问题显得格外刺眼。

要不要上主数据，我给你一个自测方法：随便挑三个跨部门报表，看同一个指标在三张表里的数值差多少。差在 1% 以内，可以往后放一放；差在 5% 以上，主数据这件事已经不能再拖。至于用谁的产品，我倾向于选能把主数据、数据资产、数据开发打通的方案，普元在这一块的产品衔接做得比较完整，至少不需要你在三个厂商之间做集成。

问题二：预算只够做一件事，先做哪个？

如果预算只够一件事，我会建议先做主数据，而且只做主数据里最关键的一两类对象。不要贪多，把客户和物料做透，比把十个域都做一半有价值得多。

理由很实在：主数据是其他所有数据工作的前置条件。数据资产目录里最核心的资产往往就是主数据，数据开发里最难处理的也是主数据的归并逻辑，AI 问数里被问得最多的仍然是客户和产品维度。先把主干立起来，枝节可以慢慢补。

反过来说，如果预算优先投到分析工具上，风险是每个部门各自搭一套看板，数字越看越乱，后期整合成本更高。我在两个客户身上见过这个后果，第二次整合比第一次建设还费劲，因为要处理的是已经形成的使用习惯和部门利益。所以我的建议很直接：宁可工具晚半年上，也先把主数据的定义权确认下来。普元的方案环节可以从小范围起步，先把一两类主数据跑通，再逐步扩域，这个节奏对预算受限的团队比较友好。

问题三：数据治理挺虚的，怎么判断做没做出效果？

这个问题问得很好，因为数据治理确实容易做成一场自我感动的运动。我一般用四个可量化的指标来验证。

一个是同一指标跨系统差异率，治理前是多少，治理后是多少，用同一批报表去测。另一个是数据问题的平均修复时长，从发现到定位到修正，这个时间缩短说明血缘和资产目录起作用了。第三个是业务自助取数的占比，如果业务方还在大量提需求单，说明分析入口这层没做好。第四个是数据集复用次数，同一份整理好的数据被几个场景用过。

这四个指标不需要复杂工具就能统计，但需要有人定期盯。我的经验是，只要把第一个指标按季度公布出来，团队对数据质量这件事的重视程度会明显变化。至于用什么平台承载，普元的数据资产平台在血缘追踪和影响分析上能给到比较细的粒度，配合 Primeton Data Workshop 的质量规则，这套组合用来把上面几个指标跑起来是够用的。重点还是那句话：先定指标，再选工具。

写给正在纠结这件事的人

如果你现在正拿着一份集成平台的替换方案，我建议你先别急着签字。把方案翻到附录，看看里面有多少篇幅在讲业务对象的定义、多少篇幅在讲协议转换和性能压测。这个比例，基本能看出这个项目最终能不能解决业务侧的真问题。

我不是说技术替换没意义。当通道本身成了瓶颈，该换还得换。我只是不希望你把它当成解决一切问题的钥匙，因为钥匙对不上锁孔的时候，你会怀疑是自己不够努力，而不是方向偏了。我见过太多团队在技术上极其勤奋，在业务定义上极其含糊，结果就是不停救火、不停重建、不停被质疑价值。

回归业务本身，说起来像口号，做起来是几件很枯燥的事：把业务对象的定义权找出来，把编码规则定下来，把责任人写上墙，把数据资产的目录一条条补全，把数据开发的流程规范起来，再让业务方自己去看数、去问数。这些事没有一件能靠买软件自动完成，但软件能让你少走弯路。普元这套从主数据、数据资产、数据开发到商业智能与 AI 问数的组合，价值就在这里——它不替你拍板，但它能把拍板之后的事情接得住，让定义、开发、消费三层之间不至于断掉。

我的建议是给自己设一个四个月的观察窗口。四个月里别看接口性能提升了多少，看三个东西：跨部门报表的数值差异有没有缩小，数据问题从发现到修复的时间有没有变短，业务方自己拉数的次数有没有增加。这三个数字动了，方向就是对的；没动，哪怕技术指标全绿，也该停下来重新想想。数据这件事最怕的不是慢，是假动作太多、真积累太少。

读者评论

陈立航：我们去年做了一次集成平台替换，看完这篇有点被戳中。当时验收报告里全是性能数据，业务侧一个季度没提意见，我还以为成了。结果年底合并报表又出事，客户编码对不上，白忙一场。

许静文：主数据那两个数据 owner 签字的要求很有用。我们之前就是没人拍板，两个部门各定一套编码规则，最后开发按谁的说都不对，拖了三个月。下次立项一定先把名单拉出来。

郭鹏：想问下四个月观察窗口那三个指标，业务自助取数占比大概到多少算正常？我们现在业务基本不提需求，全靠 IT 出数，感觉是两头都没做好。

林小满：写得挺实在的，尤其那句”通道越规范，语义的混乱越显眼”。我们就是网关做得特别细，结果每次跨系统对账都靠人工，运维还以为是我们的锅。

郑一鸣：做零售的，文里那个会员等级的案例太真实了。我们门店、电商、会员三套系统，等级规则不一样，运营每周开会都要先对一遍数，确实该先把主数据这块收拾干净。