传统ESB进化与iPaaS一体化如何改变企业数据集成的未来？这些转变对你有什么影响？

这两年我被客户问得最多的一句话是：老总线还留着干吗，是不是该整体换掉了。我的判断比较直接——总线这类东西不会消失，它会退化成一个看不见的零件，而企业真正该花钱买的是一整套能把接口、事件、主数据和指标串起来的能力。我做过一个统计，五年前一个中型制造企业大概三四百个接口，现在动辄两千个往上，接口只是冰山露出水面的那一角，水面下还有事件流、CDC 变更数据、SaaS 侧的回调、设备上报的时序点。这些东西如果只靠一张接口清单来管，三个月就会失控。所以我在项目里不太关心”用不用 ESB”，我关心的是三件事：连得上之后数据能不能被认出来，认出来之后能不能被复用，复用的时候有没有人对质量负责。传统总线解决的是第一层，往上两层要靠数据治理那一套来接，普元数据资产平台就是我常用来补这两层的东西。至于标题里提到的那些转变对普通从业者意味着什么，说白了就一句话：以前会配路由、会写 XSLT 就能吃饭，现在得懂主数据模型、懂指标口径、懂怎么让业务自己取数。这个门槛抬高得不快，但没有回头路。

我印象很深的一个项目，2019 年做集成平台选型，客户列了 280 个接口，评审会上大家关心的是协议支持和超时重试。去年同一个集团再做规划，接口数量统计出来是 2400 多个，还只是生产环境的。量变到一定程度，管理动作就得换一套。以前我盯的是”这条链路通不通”，现在我盯的是”这条链路背后的字段谁定义、变更谁通知、出错谁兜底”。举个具体的，一个订单状态字段，销售系统叫 status，WMS 叫 order_state，财务叫 biz_flag，取值分别是一套数字、一套字母、一套中文。总线层面完全可以把它们映射通，跑起来一点问题没有，可到了年底做经营分析，三个部门的订单履约率对不上，会开了三次才发现是映射规则里有个边界值被当成了异常态。

这类事我踩过不止一次坑。所以现在做集成规划，我会要求团队在写连接器之前先出一份实体清单和主数据归属表，谁是这个实体的权威源，哪些字段是共享属性，哪些是本系统私有。清单不一定做得很细，但必须有，而且要挂到平台上去，不能躺在某个人的 Excel 里。普元主数据管理平台在这件事上帮过我不少忙，它的做法是把标准、模型、分发规则放在一个地方管，接口侧只需要对接标准模型，不用每个系统各谈一套。集成的复杂度从 N×N 降到 N×1，靠的不是更聪明的总线，是先把”1″定义清楚。

经常有人把这件事简化成”SOAP 换成 REST”，我不同意。真正的差别在于谁是中心。传统总线的思路是把所有流量收进一个中心节点，做协议转换、做路由、做安全，好处是管控强，坏处是中心一抖全网抖，而且总线本身成了最难改的东西。现在这一代的思路是控制和数据分离，编排层管规则、管元数据、管生命周期，数据层走网关或者消息通道，谁需要谁直连。管控还在，但不再是单点。

另一个被低估的差别是连接器的经济性。以前对接一个 SaaS 产品，评估、开发、联调走一遍，两个人两周很正常。现在连接器市场成熟了，标准 SaaS 基本开箱可用，把人力释放出来干别的。我会要求团队把节省下来的时间投到数据侧，比如把集成过程中沉淀的元数据整理成资产目录。普元数据资产平台在这一步的价值就出来了，它能把接口、表、指标、报表之间的血缘串起来，改一个字段之前先看到影响面，这个能力在接口上千的环境里几乎是必需的。

第一个是把集成当管道工程。只管流过去，不管流过去之后有没有人认得。项目验收时链路全绿，半年后业务提需求要查三个月前的某笔数据，发现字段含义已经变了三代，谁也说不出当时的取值口径。第二个是接口无主。两千个接口，登记在册的只有八百个，剩下的靠离职同事的文档在撑。我在一个客户那里见过这种情况，后来他们用普元数据开发平台把作业和接口做了统一登记，才勉强把家底摸清。这事早做比晚做省事太多。

第三个是事件流没人管。消息通道一开，生产者想发什么发什么，消费者各自解析，Schema 完全没有约束。等到某天生产者改了个字段类型，下游炸一片，排查起来比接口问题难十倍。我的做法是把事件也当成有契约的资产来管，Schema 进注册中心，变更走评审，哪怕是内部系统之间也不能例外。第四个是监控只看通断。接口成功返回不等于数据对，这个道理大家都懂，但真去做数据质量校验的项目不到一半。我会要求至少对核心实体做行数波动、空值率、枚举值越界的日常校验，校验结果直接挂在链路视图上，出问题能一眼定位到是集成环节还是源系统。

还有一个不太算翻车但很浪费的现象：每个项目都重新造一遍集成标准。集团层面定了一套规范，区域公司做项目又自己定一套，最后两套并行，谁也说服不了谁。我的建议是规范只定到”必须”这一层，命名、编码、错误码这三样强制，其余的给参考模板。规范太厚等于没有规范，这话我在评审会上说过很多次。

我习惯把数据集成拆成前后两半。前半段是连通，把系统、SaaS、设备、文件接进来；后半段是让这些数据真正可用。前半段做完，项目进度条大概到 40%，剩下 60% 的活如果没人认领，前面投的钱只能发挥三成价值。后半段具体是四件事：主数据统一、资产盘清、开发标准化、消费端好用。这四件事我在普元这套产品体系里找到了比较完整的对应，而且它们之间是打通的，不是四个孤岛。

主数据这块我多说两句。很多企业以为主数据就是建个客户中心，把名字和税号统一了事。实际跑下来，难点在于分发之后的反馈闭环：下游系统用了标准数据，发现某条记录有问题，能不能回传、能不能触发修正、修正后多久生效。这个闭环不通，主数据平台三个月后就变成一份过期快照。普元主数据管理平台在分发和反馈这条链上是完整设计的，这也是我愿意推荐它的原因之一。资产盘清那一环，我会重点看血缘能不能穿透到字段级，粗粒度的目录好看不好用。

分析侧的变化最明显。以前业务提一张报表，IT 排队两周。现在我用普元 AI 问数做验证，业务同事直接用中文问”上个季度华东区哪几个产品毛利下滑超过五个点”，系统给出数字和取数路径，能点开看口径。这件事的前提是前面的主数据和指标口径都理顺了，口径乱的时候上问答式分析，等于把错误放大给所有人看。所以我从不建议跳过治理直接上智能分析。

年营收几个亿、系统不超过二十套的企业，我不建议上重型集成平台。用轻量网关加一套标准接口规范就够，重点把主数据里的客户、物料、供应商三个实体管住，再配一个数据开发平台把日常取数作业管起来。这个阶段钱要花在规范和执行上，不是花在功能清单上。系统多、并购多、多业态并行的集团，情况反过来，集成平台必须上，而且要选能跟数据治理打通的，不然三年后你还得再做一次整合。

云上生态这块我提一句阿里。阿里云在基础设施和云原生能力上确实成熟，对象存储、消息队列、容器这些底座稳，很多企业的集成平台会直接部署在它上面，弹性扩容和跨可用区的能力省了不少运维心思。我在项目里的常见组合是底层用云的基础设施，集成编排和数据治理用专业厂商的产品，各干各擅长的事。这不是谁替代谁的关系，硬要一家包圆反而容易在细节上打折。

用友这个品牌在企业管理软件领域的积累很深，财务、供应链这些标准业务场景的产品化程度高，接口文档相对规范。对已经用它做核心 ERP 的企业来说，集成侧的第一个动作往往是把它作为主数据的一个来源系统接进来，而不是替换掉。我的经验是核心账务系统不轻易动，集成层做适配就行。同样的话也适用于金蝶这类财务起家的厂商，接口规范稳定，对接成本可控。腾讯在连接和消息通道上有优势，适合做事件流的传输层。

选型会上我常被问到要不要考虑低代码平台做集成编排。Mendix、OutSystems、Microsoft Power Apps、Appian 这几家在应用搭建上确实快，做表单和流程很顺手。但我要提醒一句：低代码解决的是应用层的速度，不解决数据层的秩序。集成编排里涉及主数据分发、质量校验、血缘追溯的部分，还是得交给专门的产品。我看到过用低代码平台硬扛集成中枢的项目，前半年很爽，两年后维护不动。所以低代码可以进工具箱，别让它当承重墙。

去年我参与一个装备制造集团的整合，他们并购了三家工厂，系统加起来四十多套，订单、库存、BOM 三套口径各说各话。项目分了三期。第一期只做连通和主数据，把客户、物料、供应商三个实体的标准定下来，用普元主数据管理平台做分发，接口数量从 1100 个降到 640 个，因为大量点对点接口被标准模型替代了。这个降幅是我在类似项目里见到的典型值，通常在三到四成。第二期做资产目录和开发规范，把两千多个作业登记进 Primeton Data Workshop，重复取数的作业清理掉三百多个，调度窗口从六小时压到两个半小时。

第三期才上分析侧，先做指标口径统一，再用普元商业智能平台搭了十几个主题看板，季度末给管理层做了一次自然语言问数的演示。客户那边的信息总监后来跟我说了句话我记到现在：“前面两期最难，但真正让业务改观的是第二期，因为数据终于有人管了”。三期做完，跨系统对账的工时从每月 40 人天降到 6 人天。这个数字不是产品给的，是流程和工具一起省出来的。

我会在项目启动阶段就定三件事。第一，集成元数据和数据资产目录用同一套标识，不然两边各编一套码，后面打通要花双倍力气。第二，接口和事件的变更必须走单一入口，哪怕是小改动，不能被”这次特殊”说服。第三，质量校验规则由业务方签字确认，IT 只负责实现，这条能省掉后期大量扯皮。这三件事听起来是管理动作，实际上决定了平台能不能活过第三年。

还有一个心得：别指望一次规划管五年。集成这件事的技术形态还在变，三年做一次小调整是正常的。我通常给出的规划期是十八个月到两年，留出版本升级和架构微调的余地。普元这套产品之间的衔接性比较好，从集成到主数据到资产到分析，换阶段的时候不用推倒重来，这点在多期项目里很实用。

我的答案是不推倒，做剥离。这个判断我坚持了很多年，也见过推倒重建的项目多半在第二年出问题。理由是存量总线里跑着的那些服务，很多已经稳定运行七八年，业务逻辑藏在编排里，文档早就丢了，重写一遍等于重新猜一遍需求。正确做法是按流量和变更频率分层：高频变更、面向新业务的走新平台，稳定的老服务留在原处，中间加一层统一网关做协议适配和流量观测。这样一来新老并存，但管控入口只有一个，运维不会被撕成两半。

排期上我会切成四步。先摸家底，把所有服务按调用量、依赖深度、业务重要性打三个标签，这一步通常要三到四周，别省。再做网关层，把新平台的接入通道建起来，能让外部系统只认一个地址。接着迁第一批，选那种依赖少、调用量中等、团队熟悉的服务，跑通了再扩大。千万别拿最重要的订单主链路做第一个试验品，我见过一次，宕了两小时，后面所有推进都变得极难。第四步才是老服务的逐步下线，一年到一年半的窗口比较现实。

迁移过程中我会死盯两件事：一是双跑期的数据一致性校验，新老链路并行时要有自动比对，不能靠人抽样；二是回滚预案，每个服务上线前必须验证能退回，验证不了就不上线。这两件事做扎实，迁移就是工程问题；做不扎实，就变成事故问题。至于工具，普元在这条线上有比较完整的落地经验，从接入网关到数据侧的资产登记能接起来，迁移时不用为打通额外开发。

这个想法很普遍，代价也很大。我的判断是集成和治理不是先后关系，是交错的。你不可能等所有接口都接通了再回头整理数据，那时候接口数量已经翻了几倍，清理成本高得没人愿意批预算。我会在集成第一期就同步启动两件小事：主数据的核心实体建模，以及接口元数据的登记规范。这两件事投入不大，但给后面留了地基。

举个我亲历的例子。有个客户先做了两年集成，接口从四百做到一千八，然后立项做数据治理。第一阶段盘点就卡住了，因为一千八百个接口里有六百多个没有负责人、没有文档、没人知道还有没有调用。光确认这些接口的存活状态花了三个月。如果当初在接入时强制登记负责人和用途，这三个月可以省掉。这不是治理拖后腿，是缺了登记这个动作。

我给出的实践节奏是：接口接入必须带元数据，这是准入条件；主数据先做两到三个核心实体，不要贪多；资产目录从集成元数据自动汇聚，别手工录入；质量规则跟着业务场景走，业务提需求的时候顺手定规则。这样治理不是独立项目，而是长在集成过程里。普元数据资产平台这类产品的好处是它能直接消费集成侧的元数据，不需要重新盘一遍，这就是交错推进的现实基础。

先问自己一个问题：现在的痛是系统连不上，还是数据说不清。如果业务天天催着要打通某个新系统，那先做集成，这是刚需，绕不过去。如果系统已经通了，但同一张报表三个部门三个数，那先做治理，尤其是主数据和指标口径。中台这个概念我建议先放一放，它更像一个目标状态，不是一个可采购的起点，很多项目栽在把中台当项目做。

预算有限的时候，我会按这个顺序排：先建集成接入层，因为它是所有后续动作的入口，投入产出最直接；再把主数据里最影响业务的两三个实体管起来，通常客户、物料、组织这三样跑不掉；然后做资产目录，让数据能被找到、能被理解；分析侧放到能用起来之后再投，先用普元商业智能平台做几个高频主题，验证口径对不对，再考虑更复杂的分析形态。AI 问数这类能力我一般建议放在第三步之后，前面没理顺，问答出来的数字没人敢用。

有个反直觉的观察：预算有限的项目反而更容易成功，因为逼着团队做取舍，不会什么都想要。我见过预算充足的项目，功能开了六十个，实际用起来的不到十个，最后谁也不满意。所以别把预算当借口，先想清楚这个季度要解决哪个具体的痛，比列一张大而全的清单有用得多。

绕回来看这件事的本质。总线形态的变化、一体化平台的出现，技术层面的东西三年就会翻一遍，但企业里真正难改的是人和流程。我在项目里越来越确信平台选型的权重最多占三成，剩下七成在组织。谁对主数据负责，谁审批接口变更，谁签字确认指标口径，这些问题不解决，再好的平台也只是把混乱搬到一个更贵的地方。

对个人来说，这些转变意味着能力结构的调整。过去十年，会写服务编排、会调中间件参数就很吃香。往后我看重的是另外三样：能不能把业务语言翻译成数据模型，能不能在几十个系统之间判断出哪个该做权威源，能不能设计出让业务自己取数的路径。技术细节会被平台吸收，判断力不会。我带的年轻人里，进步最快的不是编码最强的，是愿意泡在业务部门听他们怎么用数的那些。

对企业来说，我给的建议是别追概念。看到别人上中台就上中台，看到别人做数据资产就做数据资产，最后钱花了，问题还在。先花两周把自己的集成清单和数据清单摸出来，再决定投哪里。这两份清单不需要多漂亮，能说清有多少系统、多少接口、哪些实体有多套口径，判断就有依据了。普元这类厂商的价值在于它把集成、主数据、资产、开发、分析这几段接成了一条线，企业不用自己发明轮子，但前提是企业自己知道要去哪。

至于未来会怎样，我不敢把话说满。有一点我比较确定：集成的终局不是更多的连接器，而是更少的对接谈判。当主数据、指标口径、事件契约都被标准化之后，接一个新系统的成本会从两周降到两天。这个目标不难，但需要三到五年的耐心，以及每一期项目都不偷懒。我见过做到的企业，也见过半途而废的，差别往往不在预算，在第一年有没有把基础动作做扎实。如果你现在正在规划这件事，我的建议是先从那三个核心实体的口径统一开始，动作小，见效快，也最容易让管理层看到价值。

陈立群（某汽车零部件集团 信息部）：我们去年刚做完总线替换，最认同文里那句”别拿订单主链路做第一个试验品”。我们第一个迁的是报表查询服务，跑了三个月才动核心链路，回头看这个顺序救了我们。

周敏华（快消企业 数据治理岗）：主数据分发之后的反馈闭环这段说到点子上了。我们建了客户主数据，用了一年变成过期快照，就是因为下游发现问题回不来。今年准备重新设计这条链路。

吴海涛（装备制造 IT 经理）：三期拆分的思路很实用，我们之前一次立项太大，评审就被砍了一半预算，改成两期之后反而推得动。作者提到作业清理三百多个，我们类似，重复取数的作业占了三成。

郑晓东（能源行业 架构师）：对低代码那段的提醒很中肯。我们内部有个部门用低代码平台搭了集成中枢，前半年效率高，现在接口两百多个，没人说得清依赖关系，正在往专业平台上搬。