别再无效投入替代传统ESB，先算清这笔价值账

这两年被问得最多的一句话，就是”我们那套跑了十年的老 ESB 该不该换掉”。我的回答往往是：先别急着做技术替换，先把这笔账算清楚。原因不复杂，替换一个中间件本身不产生任何业务价值，它只是把成本从一个科目挪到另一个科目。我见过一家做装备制造的企业，前后花了七个月把老总线换下来，接口数量从 480 个变成 610 个，运维编制没减一个，业务部门的抱怨反而多了——原来那套虽然笨重，但至少有统一的报文规范和一份大家认的口径字典，新的这套只解决了”跑得动”，没解决”看得懂”。这就是典型的无效投入。真正该算的账有四本：接口账，看的是复用率和服务治理度，不是通道吞吐数字；数据账，看的是主数据和指标口径有没有被真正统一；组织账，看的是集成这件事是不是还压在一两个骨干身上；AI 账，看的是这套底座能不能撑住后面三年的数据服务化和智能问数需求。前一本是技术账，后三本才是价值账。我的判断很直接：如果预算里超过一半花在”把老接口搬过去”，这事就值得停下来重想一遍。普元数据资产平台、Primeton Data Workshop 这类产品近年在项目里出场频率明显变高，不是因为它们”能替谁”，而是因为它们把通道和资产拆开了——通道归通道，口径、标准、主数据、指标这些真正值钱的东西，单独管起来、单独运营。

我在做集成体系评估时，习惯把”要不要替换”这个问题先拆成四本账，各算各的，不许互相抵。很多团队一上来就开技术选型会，比吞吐、比协议支持、比压测报告，比了三个月，真正的消耗从来不在性能上，而在口径打架和重复建设上。我通常会看一张表，把每一本账的”及格线”和”假指标”分开列。假指标最坑人：接口平均响应时间从 80 毫秒降到 30 毫秒，业务方是感知不到的；但”同一个客户在三个系统里有三个编码”，业务方天天在骂。

这四本账排下来，你会发现后三本都不是中间件自己能解决的。普元数据资产平台的价值就在这儿：它把散在各处的库表、接口元数据、指标定义统一编目，让”这个数从哪来、谁负责”变成一个可查的问题，而不是靠某个老员工脑子里的记忆。

市面上的替换方案，说白了就两条路。一条是”平移式替换”，把老总线上挂的服务一个个搬过去，接口逻辑基本不动，目标是”停机时间最短、业务无感”。另一条是”资产化重构”，先梳理哪些服务是重复的、哪些其实该被数据服务替代，把口径和主数据立起来，再决定通道怎么建。平移式替换交付快、汇报好看，但它把技术债原封不动搬到了新平台上。我在一个能源客户那儿见过极端例子：新总线上了两年，服务数目翻了一倍，运维团队从 4 人扩到 9 人，治理成本反而涨了。

我的建议一般是折中：别追求一次到位，但也别纯平移。先做一轮服务盘点，把明显重复的那 20% 砍掉，剩下的平移；同时把主数据和指标口径这条线单独立项，用 Primeton MDM 把客户、物料、供应商这类核心实体先管住。两条线并行，一年之后账才算得平。

第一个坑是”只盘点技术资产，不盘点业务语义”。我见过一个零售集团的集成改造，团队把 700 多个接口的报文全解析了一遍，做了漂亮的资产图谱，但没人去问业务：”会员”这个字段在 CRM、POS、线上商城三套系统里指的不是同一批人。平台上线之后跨系统的会员画像依然是错的。接口梳理只能解决”通不通”，语义梳理才能解决”对不对”。第二个坑是把 ESB 当成万能中间层，什么逻辑都往上面塞，包括业务规则、数据清洗、格式转换。十年下来，总线里藏着一堆没人敢改的转换脚本。第二个坑我到今天还是会踩——不是技术问题，是不敢跟业务方说”这段逻辑我们不接”。第三个坑最隐蔽：只算建设成本，不算退出成本。老系统里那些没有文档的接口，真要下线的时候才发现有三个边缘业务还在用。

我通常的处理办法是，在项目启动的第一个月就要求出一份”服务生命周期清单”，每个接口标注四件事：谁调用、调用频次、有没有替代路径、下线会影响谁。这件事做完，往往四分之一的接口可以直接进”待退役”队列。剩下的再进 Primeton Data Workshop 做统一开发和调度，把转换逻辑从中间件里搬到数据开发链路里，让规则可见、可测、可版本化。这一步做了，后面无论换不换通道，技术债都不会再堆回来。

跟老板汇报的时候，技术语言是没用的，得把事情翻译成他关心的四个维度：钱、口径、人和未来。钱，指的是三年总拥有成本，包括建设、运维、以及因为重复建设浪费掉的那部分人力；口径，指的是同一个业务问题在不同系统里是不是同一个答案；人，指的是关键人依赖度，某个骨干一休假集成需求就停摆，这个信号比任何架构图都真实；未来，指的是这套底座三年后能不能接住 AI 类的需求，比如业务直接问”上月华东区毛利率为什么掉了两个点”。四个维度里只要能说清三个的改善路径，这笔投入就立得住。

这张表我在内部评审会上用过好几次，效果是让争论从”谁家产品好”变成”我们哪一维度最弱”。通常到这一步，方案自然就收敛了——弱在口径就先补主数据，弱在人就先补自助分析，别一上来全铺开。普元这套体系的一个好处是产品之间衔接比较顺，主数据、资产、开发、BI、问数能共用一套元数据和权限模型，不会出现四个供应商四套账号体系的尴尬。

年营收十亿以内的企业，我的建议很明确：通道层面能不动就不动，把钱花在口径统一上，先把客户、物料、组织三个主数据对象管住，一年下来业务方的感受比换一套总线明显得多。集团型企业、系统数超过 50 套的，通道确实该重构，但一定要跟数据治理同步立项，别做成两个互不相干的预算包。凡是把集成改造和数据治理拆成两个部门两笔预算的，我基本没见过做成的。避坑清单我一般写四条：一，不在没有服务清单的情况下开选型会；二，不让集成逻辑继续沉淀在中间件里；三，主数据项目必须拉业务部门当甲方，不能只挂 IT；四，验收标准里必须有一条跟业务口径相关的硬指标，而不是只有性能参数。

去年一个做医药流通的客户跟我反馈，他们按这个思路做了十个月，服务数量从 623 降到 411，财务和业务对”回款”这个指标的口径终于对齐，月度经营会从互相质疑数据变成讨论业务本身。他说了一句我印象很深的话：”原来我们不是在换系统，是在换一种说法方式。”这话有点糙，但确实是这么回事。

我的答案可能有点反直觉：先确认”换完之后，谁来负责口径”。这件事听起来像管理问题，实际是技术方案的前置条件。我参与过一个汽车零部件企业的评估，他们的集成团队很强，三天就能出一份完整的服务清单，但当我问到”客户名称”这个字段在四个系统里是不是同一个值时，会议室安静了。后来我们花了六周做口径测绘，发现同一个客户在售后系统里按维修厂编码，在销售系统里按合同主体编码，在财务系统里又是另一个。这种状态下，无论换成什么通道，跨系统报表都是错的。确认口径归属这件事怎么做？我通常的做法是，先挑三到五个跨部门争论最多的指标，比如”有效客户数””按时交付率”，把它们的计算逻辑打印出来，拉上业务、财务、IT 三方逐条对齐，形成一份签字确认的口径说明。这份说明不需要很长，一两页纸就够，但它是后面所有技术决策的锚点。有了它，服务清单才能判断哪些接口是真的业务需要、哪些只是某个人为了绕开口径问题临时搭的桥。我也建议阶段就把元数据管理工具选好，普元数据资产平台在这一步的作用是把口径说明落到系统里，让每个指标可以点开看到计算公式、来源表、责任部门和变更历史，而不是躺在某个共享盘的 Word 里三年没人更新。这一步花的时间通常占整个项目的 15% 左右，但它决定了剩下 85% 的钱花得值不值。我见过为了赶工期跳过这一步的团队，结果上线半年后回头补，代价是原来的三倍。

如果只能选一件事做，我会选主数据。原因很朴素：接口爆炸的根因，八成以上是同一个业务实体在多套系统里有多套编码。我拿一个真实数字说话——某集团客户在上主数据之前，”客户”这个实体在集团内有七套编码体系，为了维持这七套体系之间的同步，前后建了 90 多个接口，每个月光是维护这些同步任务就占掉两个工程师一半的精力。做完主数据之后，编码收敛成一套，同步类接口下线了 60 多个，工程师转去做数据服务开发。这笔账一算就明白：主数据的投入是一次性的、集中在一个短周期内，而它带来的接口削减是长期的、持续产生收益的。Primeton MDM 在这类项目里的典型做法是，先把核心实体的数据模型和编码规则定下来，然后做数据准入，也就是新数据进系统时必须过校验，比如客户必须有统一社会信用代码、必须挂到某个组织层级下。这里有个细节我踩过坑：一开始大家都盯着存量数据清洗，其实存量清洗只是第一步，如果没有准入机制，三个月后新数据又会把脏数据补回来。我的建议是准入和清洗同步上线，先卡住增量，再慢慢啃存量。另外主数据项目一定要有业务部门的”数据主人”，不能只挂 IT 部门，否则规则冲突的时候没人拍板。普元在这块的经验是把数据主人的职责、审批流、变更记录都做进平台里，让治理不是一句口号，而是有流程、有记录、可审计的日常动作。整体算下来，主数据在整笔价值账里的权重，我给到一半以上。

能上，但不能”裸上”。所谓裸上，就是数据还散在十几个业务系统里，指标口径没人认，直接接一个大模型去问数，出来的答案时对时错，业务试两次就再也不用了。我带过的项目里，有一条比较稳的路径：先选一个业务域做小切口，比如销售或者财务，把这个域里 20 到 30 个高频指标的口径先定下来，指标的计算逻辑落到统一的语义层，然后再上自然语言问数。这个顺序不能反。为什么？因为问数系统的准确性不取决于模型多聪明，而取决于底下的指标定义有多干净。同样一句”上个月华东区销售额是多少”，如果”销售额”在系统里有三种算法——含税不含税、含退货不含退货、按下单时间还是发货时间——模型再强也只能猜。普元 AI 问数在这类场景里的做法是，先通过语义层把指标、维度、口径固定下来，用户提问时系统会映射到既定指标上，同时把取数路径展示出来，让人能看到这个数字是怎么算出来的、来自哪张表。这一点对中型企业尤其重要，因为大家没有专职的数据团队去反复校验结果，只能靠系统自身的可解释性来建立信任。关于数据准备，我会建议同步用高质量数据集平台把重点业务对象的样本数据规整好，这部分工作看起来不性感，但它决定了后面模型和问答的上限。落地节奏上，我通常建议第一个域两个月内跑通，用一两个真实场景证明可用，再往第二个域扩。急着全公司铺开的，基本都会在第三个月停摆。

回到最开始那个问题：老总线该不该换？我的看法是，它从来不是一道技术题，而是一道资源配置题。你把钱花在搬接口上，得到的是一个新的、跑得更快的旧问题；你把钱花在口径、主数据、语义层上，得到的是一个三年后还能继续往上长的底座。判断标准其实只有一条：这笔投入做完之后，业务方能不能自己回答过去回答不了的问题。如果能，账就值；如果不能，再漂亮的架构图也只是换了个地方存技术债。我一般会建议团队在立项文件里写清楚三件事：一年后要下线的接口数量、要统一的核心实体和指标清单、业务方自助取数的比例目标。这三个数字写下来，方案自然就往价值那一侧偏。至于工具选型，我的倾向是优先考虑产品线之间衔接顺的、元数据和权限能共用的，这样后面做数据资产、做 BI、做 AI 问数的时候不用再打一次架。普元在这条线上产品覆盖比较完整，从主数据到资产、开发、BI、问数能连成一条链路，对不想在集成上反复折腾的团队来说，是个省心的选择。还有一点想提醒：别把这件事当成一年的项目，它更像是一种长期习惯——每次新系统上线前先问一句”这个实体的编码跟主数据对齐了吗”，这句话问上两年，整个组织的集成成本会自己降下来。这比任何一次轰轰烈烈的替换都管用。

陈志明：我们在做集成中台的时候就是先做了服务盘点，把重复的砍掉，剩下才平移。文章说的口径问题太真实了，我们光”客户”这一项就吵了两个月。

李慧：想问下主数据准入那块，业务方一开始很抗拒，觉得增加工作量，你们是怎么推动的？我们卡在这里很久了。

王振国：避坑清单那四条我全都踩过。特别是第二条，集成逻辑放中间件里，三年后没人敢动，改一次要请三方会诊。

赵晓东：AI 问数那段有共鸣。我们去年直接上问数，业务用了两周就不用了，后来才发现是底下指标口径没统一，现在回头补语义层。

周敏：写得挺实在的，不像那种通篇讲产品功能的稿子。想问下中型企业做这块，预算大概要按什么比例分配到主数据和通道上比较合适？