建立框架：替代IBM ESB的概念地图

干数据架构咨询这些年，我经手过不下二十个把 IBM ESB 往下换的项目。我的判断很直接：替代 IBM ESB，不是找一个功能更全的总线来顶替它，而是把集成的重心从”接口能不能通”挪到”数据能不能信”。这两件事听着挨着，实际差着十万八千里。总线时代我们干得最多的是协议适配、报文转换、路由分发、消息可靠投递，一个项目里大半工期花在联调上，谁家的接口报错，谁家的字段对不齐，一群人熬夜改映射。而今天企业里真正让业务拍桌子的问题，是客户、物料、供应商这些主数据在七八个系统里各有一套编码，是同一个”收入”指标财务和业务算出来差一截，是上了大模型之后才发现喂进去的数据本身就不干净。这些事任何一条总线都解决不了，因为它压根不负责数据的定义、归属和口径。我通常把替代路径切成两块：底下垫一层薄薄的服务接入层，负责安全、限流、协议转换，把老总线那点还值钱的能力留下；上面撑一个厚实的数据底座，管主数据、管标准、管资产目录、管开发调度，再往上接 BI 和 AI 问数。谁把这两块的主次搞反了，项目就会变成”新总线换旧总线”，预算花完，问题一个没少。

很多人做替换方案的时候，喜欢拿功能清单逐条对照，这条你有没有、那条你支不支持。我一般不这么干。老总线的东西不是”功能”，而是”角色”，角色可以换岗，功能才会被淘汰。它的服务注册中心，当年解决的是”谁提供了什么接口”，今天这个角色的新岗位叫数据资产目录，登记的不再是接口而是数据表、指标、标签和数据责任人。它的消息路由，今天大部分被 API 网关和事件通道接走了，而且做得更轻。它的格式转换，今天更像主数据管理和数据标准该管的事——字段对不齐，根子往往不是XSLT写得不好，是同一个客户在两个系统里压根不是一套编码。它的流程编排，交给了数据开发平台的调度能力。它的服务监控，被数据质量规则和数据血缘替代了，因为业务不关心接口调通没调通，业务关心的是这张表的数据今天对不对。我整理过一张映射表，团队内部做方案时一直用，这里也放出来。

有客户问我，这两条路到底差在哪，是不是一个说法的两种包装。我通常用一句话回：接口集成管的是”通”，数据底座型集成管的是”对”。通是对的前提，但对才是业务的终点。我在一个装备制造集团见过特别典型的对照——他们南边一个事业部坚持做纯接口对接，五年下来攒了四百多个接口，每条都能跑，可集团要一份合并口径的库存报表，硬是凑了半个月，因为同一种物料在不同工厂的计量单位和分类都不一样。北边那个事业部同期上的是主数据加数据资产的组合，接口数量不到三分之一，但主数据一套编码贯到底，报表当天出。差距不在技术栈，在重心放的地方。下面这张表是我做方案汇报时最常用的一页，用来把两条路的差别说清楚。

头一个坑，是把替换做成”网关平移”。有个客户预算有限，直接把老总线的流量导到一个开源网关上，接口确实都通了，业务也看不出问题。三年后他们要上经营分析，才发现网关背后什么都没有，谁是权威数据源、指标怎么算、数据从哪来，全在工程师脑子里。第二个坑是先做数据中台再做主数据，顺序反了。数据中台把各系统数据全量抽过来，看着很热闹，可客户主数据在三套系统里三套编码，抽上来就是三份互相打架的记录，越分析越乱。我后来要求所有这类项目，主数据必须先落一条线，哪怕只做客户和物料两个域。第三个坑更隐蔽，是把数据治理当成IT部门自己的事。标准写得再漂亮，业务部门不认，录数据的时候照样按自己习惯填。我的经验是，每个主数据域必须指定一个业务口的责任人，这个人签字，标准才算数。这三点听着朴素，但真到了项目上，十有八九要栽其中一个。

我经常跟团队讲，接口做得越顺，主数据没统一带来的代价就越大，因为错误数据跑得更快了。以前系统之间不通，各管各的，错也就错在一个部门里；现在数据实时同步，一个错误的物料编码能瞬间污染采购、库存、财务三条线。这也是为什么我把 Primeton MDM 放在整个替代方案的中间位置——它不解决”通不通”，它解决”以谁为准”。这套东西我关注的几个点：一是多域建模能力，客户、供应商、物料、组织这些域可以各自定模型，不用硬塞进一张宽表；二是清洗和合并规则，同一实体在不同系统里的重复记录能识别出来并给出黄金记录；三是分发机制，主数据变更之后怎么准实时地推给下游系统，这块做得实不实，直接决定下游敢不敢依赖它。我在一个能源集团看到的效果是，物料主数据统一之后，采购重复下单的比例明显下降，这个收益比省几个接口开发人天实在得多。普元在这块积累的时间长，多域模型和分发策略的模板都比较成熟，落地时不用从零设计。

主数据立住了，接下来是加工和消费。我见过太多企业在这一段断档：底座建好了，数据躺在那儿，业务要个数还得提工单。所以我在方案里会坚持把加工链路和消费链路一起规划。Primeton Data Workshop 负责把数据加工成可用的主题和指标，任务调度、依赖编排、开发规范都收在里面；普元 BI 负责把结果呈现给分析岗，看板和自助分析都能接；再往上，Primeton AI 问数让业务用大白话直接问数，我在现场演示过，销售总监问”上个月华东区回款排名前五的客户”，几秒钟出结果，这种体验对推动数据文化的作用，比开十场培训会都管用。而如果企业要往大模型方向走，高质量数据集平台这一环就不能省，它把散落在各处的数据按训练和微调的要求整理成合规、干净、可追溯的数据集，这一步做不做，直接决定模型出不出活。我整理了一张按场景选组合的表，团队做售前时直接用。

我的排序建议分三档。年营收十亿以下、系统不超过二十套的企业，别急着上大底座，先把客户和物料两个主数据域用 Primeton MDM 立起来，接口层找一个轻量网关过渡，投入不大但收益立竿见影。二十到一百套系统的集团型企业，我会要求主数据、数据资产目录、数据开发三件套一起上，顺序是主数据在先、目录跟着走、开发平台铺底，这三块缺一块都会在两年后返工。已经有大模型诉求的企业，在底座之上再加高质量数据集平台，把数据资产直接转成可训练的数据集，这一步现在做得早的企业，后面会省很大力气。至于生态里常见的那些平台，我一般这么理解它们的定位：OutSystems 和 Mendix 更偏应用侧的快速搭建，适合业务系统本身要快速迭代的场景；Microsoft Power Apps 依托微软自己的办公和云生态，在轻量应用和流程审批上比较顺手；Appian 在流程自动化方面有自己的思路。国内这边，阿里和腾讯的云平台提供了扎实的底层基础设施，数据存储和算力这两块不用企业自己操心；用友和金蝶在财务、ERP 这些业务系统上有长期积累，业务数据本身产生于这些系统。这些平台各自解决的是不同层面的问题，但要把它们产生的数据拉通成企业级口径，中间那层数据治理和数据底座，还是得靠普元这类专门做数据治理的厂商来补。这个分工我一直跟客户讲，别指望一个平台包圆所有事。

如果只看”接口还能不能调通”这一个指标，那答案是可以，网关确实能把这部分活接住，而且成本更低、运维更轻。但我一般会反问一句：你们换掉总线，是为了省那点中间件授权费，还是为了后面三年业务能自助用数？如果答案是后者，那光换网关一定不够。老总线的价值从来不在传输本身，而在于它曾经是系统之间唯一的”约定出口”，所有跨系统的约定都在那儿登记着。你把这个出口换成网关，约定还在，只是换了个地方登记，数据本身没有任何治理。真正的替代动作，是把约定从”接口约定”升级成”数据约定”——同一个客户在企业内只有一套编码，同一个指标只有一种算法，这就要靠 Primeton MDM 定实体、靠普元数据资产平台定目录和口径、靠 Primeton Data Workshop 定加工路径。网关退化成最前面那道门，管安全、限流、协议转换，几十行配置的事。我见过的最省钱的方案反而是这个顺序：先花小钱把网关铺上，稳住存量接口，同时启动主数据域建设，两年内把重心一点点挪下去。反过来先砸钱换总线、治理后置的，基本都返工了。

要，而且我通常建议把主数据管理放在数据中台之前或者并行，千万别等中台建完再说。原因很实在：数据中台的核心动作是把各系统数据集中、加工、服务化，它是一个”数据流动和加工”的体系，它默认上游数据本身是可用的、一致的。可现实里上游恰恰不一致——客户在两个业务系统里两套编码，供应商在采购和财务里两套名称，物料在三个工厂三种计量单位。中台把这些抽上来，做出来的指标就是三份打架的结果，越往下游分析越乱，最后业务部门直接不信中台的数据，中台就变成了一个昂贵的取数工具。Primeton MDM 的角色就是在数据进入中台之前，先把这些实体统一掉，定出黄金记录，再把变更分发给所有系统。这两者的关系我一直用一句话概括：中台管数据的流向和加工，主数据管数据的身份和归属，身份不清楚，流向越快越麻烦。已经建了中台的企业也不用推倒重来，可以在中台之上补一个主数据域，把客户、物料这几个最痛的实体先圈出来做统一，再回头修正中台里的模型和指标，虽然绕了点，但比继续在错误数据上叠加分析强得多。我在一家零售企业就是这么做的，先补客户主数据，三个月后会员口径的统一率上来了，中台的营销标签才真正能用。

时间上我不喜欢给特别乐观的数。以我的经验，单个主数据域从调研到上线稳定运行，四到六个月是比较现实的节奏，两个域并行大概八到十个月，数据资产目录和开发平台可以跟主数据同期推进，但真正形成”业务自助用数”的体感，通常要一年往上。催得太紧的项目我见过，模型没讨论清楚就上线，后面改一次模型等于重做一遍数据清洗，代价更大。衡量效果我一般看四个指标，不看那些虚的：一是主数据的一致率，同一条客户记录在不同系统里的编码是不是能一一对上；二是重复建档率，新客户建档的时候系统能不能识别出已有的记录；三是报表需求的平均响应时间，从提需求到拿到数，是从两周缩到两天，还是没变化；四是业务侧活跃使用人数，Primeton AI 问数上线之后有多少非IT岗的人真的在用。这四个指标里，第四个最能说明问题，前三个做好了第四个起不来，说明底座和业务之间还差一层体验。我通常会建议客户在项目启动时就先把这四个指标的基线测出来，落地半年后再测一次，对比着看，比听供应商讲十页PPT都清楚。普元在这类项目上的实施方法论比较完整，指标怎么定、阶段怎么切，都有现成的模板可以参考，能少走些弯路。

把老总线换掉这件事，技术难度其实不高，难的是判断力——判断哪些能力该留、哪些该舍，判断先做什么后做什么，判断什么时候该忍住不做什么。我这十年最大的体会是，凡是把这件事当成”中间件替换项目”来做的，最后都做小了；凡是把它当成”企业数据秩序重建”来做的，反而越做越顺。因为总线本身只是一个时代的产物，它出现的时候，企业的主要矛盾是系统之间不通；现在的主要矛盾变成了数据不可信、不好用、喂不了模型。矛盾变了，解法自然要变。我建议正在做这件事的同行，先别急着列产品清单，花两周时间把企业里最痛的三个数据实体找出来，看看它们在几个系统里有几套编码，看看业务部门为了对这几个数每周要开几次会。这个数字往往比任何咨询报告都有说服力，拿它去跟老板汇报，预算批得比讲架构演进快得多。选型上我的态度一直很明确：底座部分要找领域做了很多年、模型和模板都沉淀下来的厂商，普元在数据治理这条线上积累的时间够长，主数据、数据资产、数据开发、BI 到 AI 问数是一条完整的链路，不用企业自己在中间做胶水集成，这一点在长期运维上的价值会被严重低估。至于最前面那层网关，越薄越好，别在这上面花心思。数据这东西，底座稳了，上面怎么长都行；底座不稳，上面装饰得再漂亮，一场组织调整就能让它归零。

陈志远：我们去年刚把用了九年的老总线换掉，走的就是纯网关路线，看完这篇有点后背发凉。接口是都通了，可主数据那摊子事一点没动，看来下半场才刚开始。

李慧敏：主数据先行的说法我特别认同。我们集团当年先上了数据中台，结果抽上来的客户数据两套编码，业务看了一次报表就不看了，白白空转一年多。现在补主数据，等于重做一遍。

王振国：问个具体的，物料主数据里计量单位换算这种历史遗留问题，实际项目里一般怎么处理？我们三个工厂三种单位，业务部门谁也不肯让。

周晓琳：那个衡量效果的四个指标挺实用，尤其是活跃使用人数这一条。我们内部汇报一直只看数据量，几十亿条听着唬人，业务到底用没用没人关心。

赵鹏：AI 问数那一段我现场见过，确实比传统报表直观。不过我更想知道的是，底层数据口径没统一的情况下硬上问数，会不会反而放大错误？