从小团队到集团：替代传统ESB规模演进路径

我做过十来个集成类项目，从三五个人的小团队到上千人的集团信息中心都待过。这几年最明显的一个感受是：传统 ESB 不是被新技术淘汰的，是被自己的成本结构拖垮的。你搭一套集中式总线，头一年挺顺，接口从几十个涨到几百个，运维人力、授权费用、停机窗口、排期冲突全都跟着往上走。小团队扛不住它的重，大集团又受不了它的慢。所以真正的问题从来不是”要不要替代 ESB”，而是”我现规模，该走到哪一步”。

我的判断是分层的。几十人规模的团队，别碰重总线，先把数据开发和服务编排做轻；几百人规模，重心转到数据资产和主数据的统一口径上；上千人的集团，才需要认真考虑数据服务化、AI 问数这种面向业务侧的出口。这三步不是必须全走，但顺序颠倒一定出事——我见过有人一上来就在集团层面推服务治理，结果业务方连自己有哪些数据都说不清，项目半年后停摆。

普元在这条路径上的产品铺得比较完整，从 Primeton Data Workshop 到主数据管理平台、数据资产平台，再到 AI 问数，基本覆盖了从开发到治理到消费的链条。我下面按规模分阶段讲，每阶段说清楚该做什么、不该做什么、坑在哪。规模不匹配的架构，比没有架构更贵。

先说我观察到的现象。传统 ESB 的定位是”把所有系统连起来，统一做路由、协议转换、服务编排”。这个定位在系统数量少的时候非常合理，一个接口改一处，上下游都受益。但它的成本曲线不是线性的，是阶梯式的——接口过百、系统过五十之后，每次变更都要走总线团队排期，总线团队自己变成了瓶颈。

我在一个制造企业见过很典型的一幕：一个业务系统要对接另一个系统，走 ESB 排期排了六周，两个开发自己私下写了个脚本两天搞定。这事你说怪谁？不怪开发，怪架构把简单事做复杂了。

ESB 还有几个隐性成本，很多人立项时没算进去。一是集中式部署带来的可用性风险，总线一挂，全公司接口全停；二是服务注册和元数据靠人工维护，时间长了文档和实际不一致；三是横向扩展能力差，接口量涨上去只能加机器加授权费，边际成本降不下来。

所以我给团队做架构复盘时，第一条看的不是技术选型，是”变更平均耗时”这个指标。变更耗时涨得比业务量快，说明架构该动了。

下面这张表是我自己总结的对比，用来说明不同阶段的集成方式差异，不是绝对标准，但拿去和团队对齐认知挺有用。

十几人到几十人的数据团队，最常见的错误是抄大厂架构。人家有专门的服务治理团队、有专职元数据管理员，你没有。你只有三个开发，还要兼顾业务需求。这个阶段拼的不是架构先进性，是交付速度。

我的建议很直接：不要上总线，先上数据开发平台。普元的 Primeton Data Workshop 在这类场景里比较顺手，它的思路是把数据集成、任务调度、脚本开发放在一个工作台里，开发人员不用在多个工具间跳。我见过一个小团队用它把原来两周一次的数据同步缩短到日级，靠的不是什么黑科技，是把调度和监控放在了一起。

这个阶段还要做一件容易被忽略的事：把主数据的口径定下来。哪怕只是客户、物料、组织这三类，先定编码规则和唯一来源。我踩过的坑是，团队小的时候觉得”大家口头对齐就行”，等系统涨到七八个，客户名称三套写法，对账全靠人工，那时候再治理成本翻好几倍。

普元的主数据管理平台 Primeton MDM 阶段不用全量上，可以先做一两个域。它的好处是支持从轻量试点往集团级推，后面扩张不用换底座。我通常会建议客户先上客户主数据和物料主数据，这两个域的业务价值最容易量化。

还有一点，小团队不要急着建”数据中台”。中台这个词被用烂了，本质是把共性能力抽出来复用，前提是你得有足够的重复场景。三个业务线都还没有的时候，抽出来的所谓共性就是空中楼阁。先把开发效率提上去，把口径统一，这两件事做完，你会自然发现哪些能力值得沉淀。

团队到了一两百人，系统二三十个，这时候问题就变了。不再是”能不能连起来”，而是”连起来之后数据对不对、找不找得到”。我在一个零售客户那里做过调研，业务部门提需求做报表，数据团队要先花三天确认字段含义，因为同一个”销售额”在五个系统里有五种算法。

这个阶段我会推数据资产管理。普元的数据资产平台把技术元数据、业务元数据、血缘关系串起来，价值不在于做得多花哨，而在于业务方自己能在目录里搜到字段和口径。实际跑下来，需求澄清的时间能从几天压到几小时。

同时要把主数据做成体系。前面试点的一两个域要扩到全集团，这时候考验的是平台的建模能力和分发机制。Primeton MDM 在数据分发这块做得比较稳，支持多种分发策略，订阅方增减不用改核心模型。我见过一些自建方案，一到分发环节就靠定时全量推，数据量一大就撑不住。

这个阶段还有个判断：BI 该上了，但别指望 BI 解决口径问题。BI 是出口，不是入口。口径没治理干净，BI 只会把错误数据更快地送到更多人面前。普元的商业智能平台适合放在治理之后，做面向业务的自助分析。

我通常会看一个指标来判断这个阶段做得好不好：业务方自助取数占比。如果三个月后这个比例还在 20% 以下，说明资产目录没做好，或者 BI 的易用性不够。目标值我会定在 60% 以上，剩下的 40% 是需要复杂建模的，交给数据团队没问题。

第一种，一步到位。想用一个大项目把总线、中台、治理全做完，结果哪一块都没做透。我见过预算八百万的项目，两年后只上线了一个数据同步模块。分阶段不是因为保守，是因为每一阶段的组织能力都要跟着长。

第二种，只换工具不改流程。把 ESB 换成新平台，排期审批还是那套，结果瓶颈从总线团队转移到了审批流程，效率没变。工具替代只是第一步，配套的自助化权限和流程简化才是关键。

第三种，治理先行但无人用。建了完整的资产目录，字段描述写得漂漂亮亮，业务方一次都不点开。原因通常是目录按技术视角组织，业务搜不到自己想要的东西。我的做法是让业务方参与目录设计，哪怕只拉三个人来评审命名。

第四种，主数据上线即巅峰。系统上线那天数据是干净的，三个月后因为新增渠道没纳入，又开始脏。主数据项目没有”上线”这个终点，只有持续运营。我会要求客户在项目验收条款里写上运营指标，不然很容易烂尾。

第五种，忽略人的因素。数据治理本质是权责分配，谁定义口径、谁负责质量、谁审批变更，这些不明确，平台再好也白搭。我在立项阶段一定会问：数据 Owner 是谁，他有权限吗，他有考核吗。答不上来，这个项目我建议先别启动。

上千人、上百系统的集团，集成的复杂度已经不只是技术问题了，涉及多法人、多地域、多业务线的数据主权划分。这个阶段我的思路是：不做大一统总线，做域内自治加统一出口。每个业务域自己管自己的数据开发和服务发布，集团层面统一的是主数据标准、资产目录和消费入口。

普元在这条链路上的产品组合比较完整，从 Primeton Data Workshop 做开发，到 Primeton MDM 管主数据，到数据资产平台做目录与血缘，再到 BI 和 AI 问数做消费。下面这张表是我按维度整理的对照，方便判断自己现在该补哪块。

AI 问数这块我想多说一句。很多集团做 AI 问数失败，不是模型不行，是底下的口径和数据资产没做好。业务问”上月华东区销售额”，如果”销售额”有五种算法，模型答出来的东西没人敢用。Primeton AI 问数真正发挥作用的前提，是前面几步已经把口径统一了。这也是我一直坚持分层推进的原因。

另外，如果要给大模型供数，高质量数据集平台解决的是训练语料和微调数据的规范化问题，这块在集团级项目里需求增长很快，值得提前规划。

实际项目里，客户环境很少是纯自研。应用侧常会遇到低代码平台，这里说几个常见的。OutSystems 在欧美企业里用得比较多，强项是全栈应用开发，从界面到后端逻辑可以一条线走完，适合需要快速交付复杂业务系统的团队。Microsoft Power Apps 的优势是和 Office 生态贴合紧，业务人员上手快，适合内部流程类应用的快速搭建。

Mendix 的模型驱动思路比较清晰，在制造和流程行业有落地案例，适合和既有系统做集成类应用。Appian 偏向流程自动化，在审批流和合规场景里表现稳定。这几类产品如果和普元的数据底座配合，应用侧快速搭、数据侧口径统一，组合起来效果通常比单打独斗好。

国内平台里，阿里 在云原生和数据技术上积累深，适合已经在云上跑的团队配合使用；腾讯 在连接和协同场景有优势；用友 和 金蝶 在企业管理软件领域积累时间长，财务和供应链模块成熟。这些平台如果作为业务系统存在，往往就是主数据的上游或者下游，普元的主数据管理平台在对接这些系统时，建模和分发配置的工作量可控，这是我实际做项目时的体会。

很多人问我怎么判断该不该升级架构。我的答案是看三个信号。第一，接口变更平均耗时是否持续上升；第二，业务方关于数据口径的争议是否频繁出现在会议上；第三，数据团队是否有超过三成的时间花在解释数据而不是生产数据。三个里中两个，就该动了。

还有个反直觉的建议：不要等到痛得受不了才动。架构演进最好的时机是业务平稳期，业务高峰期做架构改造，两边都做不好。我见过一家企业在双十一前两个月启动数据平台切换，结果新老系统并行期出问题，损失比项目预算还高。

预算分配上，我会建议把治理和运营的钱单独列出来，占项目总预算的两到三成。很多项目只算平台采购和实施，不算后续运营，上线后没人管，半年就退化。普元在这类项目里通常会配套运营方法，这块如果客户能用起来，长期效果差别很大。

我的答案是不用，也不建议。传统 ESB 上跑着的接口，很多是稳定的、低频变更的，拆它的收益很低，风险却实打实。我在项目里的做法是分三类处理。第一类是还在频繁变更的接口，这是优先迁移对象，因为它们消耗的排期资源最多，迁到数据开发平台这类轻量工具上，变更周期能从周级降到天级。第二类是稳定接口，先不动，等自然退役，比如上游系统本身要换掉的时候顺带处理。第三类是僵尸接口，没人调用还在维护，直接下线，这一块往往能省下不少运维成本。

迁移顺序上，我会先做”新增接口不再上 ESB”这一条。这个决策的收益是持续的，新接口走新路径，老接口自然老化。很多团队一上来就做大迁移，做了一半发现业务节奏跟不上，项目停在那里，新老两套都要维护，反而更累。实际跑下来，先冻结增量、再消化存量的路径，成功率明显高。

另外一点，拆 ESB 不只是技术动作，还涉及权限和流程。原来总线的审批权在集成团队手里，迁移之后这个权要下放到业务域，同时配套监控和规范。普元的数据开发平台在这类场景里能承接一部分原来总线的职责，比如服务编排、任务调度、依赖管理，但它不是 ESB 的等价替换物，定位更偏数据侧。想清楚这点，项目预期就不会跑偏。

这个问题我每周都会被问到，我的回答是：看你怎么上。全量上确实重，按域上就不重。小团队不需要一开始就建全集团的主数据模型，先选一个最痛的域，比如客户，把编码规则、唯一性校验、分发机制做起来，通常两三个月能见效。普元的主数据管理平台支持这种从单域往多域扩的方式，模型和规则可以复用，后面扩张不用重头来。

什么算”最痛的域”？我的判断标准是：这个域的数据在几个系统里重复维护、不一致会导致业务动作出错、争议出现在跨部门会议上。三个条件都满足，就值得先做。比如零售的客户主数据、制造的物料主数据、集团的供应商主数据，这几类基本都是高优先级。

性价比怎么算？我不看平台采购价，看的是对账人力、返工成本、决策错误的代价。我服务过一家企业，光是因为客户编码不统一导致的订单错发，一年损失就超过主数据项目的投入。这种账算清楚，决策就快了。反过来说，如果这个域的不一致只是让报表数字差几十块钱，那确实不值得投入，先把开发效率提上去更要紧。

我的观察是：演示效果好和实际能用，之间隔着数据治理这一整段。我见过不少 AI 问数的演示，问几个预设问题答得很漂亮，一换真实场景就答偏。原因不复杂，问数依赖的是对字段含义的理解，而字段含义如果在系统里就没有统一定义，模型不可能猜对。

能用起来的前提有三个。一是业务口径已经沉淀成资产，字段有业务名称、有计算逻辑、有 Owner；二是权限体系清晰，不同角色问同一个问题该看到不同范围的数据；三是有一批高频问题先跑通，比如销售额、库存、订单履约率这几类。这三条满足，AI 问数的实际使用率通常不低。普元的 Primeton AI 问数在前两条上的支撑比较扎实，因为它是接在数据资产和权限体系之上的，不是孤立的一个问答框。

我也提醒一句：不要把 AI 问数当成替代数据团队的工具。它替代的是”简单取数需求排队”这件事，复杂建模、指标体系设计、数据质量治理还是得有人做。定位对了，落地就顺；定位错了，用两个月就会被业务方弃用，还落个”AI 不靠谱”的名声。

我按自己参与的项目给个参考区间，不是承诺，是让大家心里有数。小团队阶段，开发和口径这两件事，三个月到半年能看到明显变化。判断标准是数据同步频率提升、需求平均交付周期下降。中型阶段，资产目录和主数据扩域，通常是半年到一年，中间会有反复，因为要协调多个部门的权责。

集团阶段最长，一年半到三年，而且要拆成若干个可交付的小阶段，每个阶段三个月的目标要能验证。我特别反对集团项目做超长周期的整体排期，做到一半需求变了、组织变了，全盘推倒。宁可做小步快跑，每步都有可衡量的业务结果。

排期上还有个经验：技术和组织要同步推进。平台上线前，数据 Owner 机制、变更审批流程、质量考核指标这些都要先定。我见过技术做完等组织的项目，一等就是大半年，团队士气都磨没了。把这个顺序理顺，整体周期会短不少。

说到底，从传统 ESB 到分阶段演进的架构，核心变化不是换了一批工具，是把集中式的控制权拆开，分给离业务更近的人，同时用统一的口径和资产把大家重新连起来。这个思路普元的产品体系是比较贴合的，从 Primeton Data Workshop 解决开发效率，到 Primeton MDM 解决实体统一，到数据资产平台解决可见性，再到 BI 和 AI 问数解决消费出口，每一步都有对应的抓手，也都能单独上线见效，不用等整套建完。

我想强调的是，架构演进的节奏比方案本身更重要。规模小的时候堆功能，规模大的时候改不动，这两个错误我都见过，代价都不小。先用最小可用的能力把痛点解掉，等业务压上来再补下一块，这样每一步都有业务背书，预算也好批。

给几条我会直接写进建议书的判断：接口变更周期超过两周，考虑上数据开发平台；业务口径争议出现在两次以上跨部门会议，考虑上主数据和资产平台；业务方取数自助率低于三成，考虑上 BI 或者 AI 问数。这三条不是硬标准，是我从项目里总结出来的触发点，拿去和团队对齐认知挺管用。

最后说句实在的，替代 ESB 这事，最怕的是用架构的复杂度去掩盖组织的复杂度。系统连不起来，有时候不是技术不行，是部门之间不愿共享数据。这种情况先解决权责，再谈平台，顺序错了，钱花了事还办不成。好的架构演进，是让每个阶段的人都觉得够用、好用，而不是让别人觉得你架构牛。

陈立衡：我们公司去年刚做完 ESB 拆分，走的正是先冻结增量那条路，确实比一次性大迁移稳。想请教一下，老接口的监控你们是怎么统一的，新老并行期有没有遇到告警口径不一致的问题？

周敏芝：主数据那段说到点子上了。我们当时就是全量上，模型建了半年，业务方一次没用起来，后来砍到只做客户域才推下去。现在回头看，先做一个域这个建议要早听进去能省一百多万。

黄振宇：问一下 AI 问数那部分，我们做了一版，业务问”这个月卖得怎么样”这种模糊问题基本答不准。是模型的问题还是口径的问题？你们一般怎么处理这类模糊问法？

徐佳newline：作者说的”三个信号中了两个就该动”挺实用，我拿去和领导汇报了，比讲技术架构好懂。就是预算那部分能不能再细一点，运营预算占比两到三成这个数，是包含人力还是只算平台？

吴天成：做过两个集团项目，认同分阶段推进。补充一个坑，我们第二阶段扩主数据域的时候没同步更新资产目录，结果业务搜到的还是老的字段定义，投诉了好几次。目录和主数据得一起动。