这件事我做过不止一遍。2016 年前后，企业聊集成绕不开 IBM 的 ESB……

这件事我做过不止一遍。2016 年前后，企业聊系统集成，绕不开 IBM 的 ESB，一套 license 加实施，预算按百万走，周期按年算。那会儿我在一家装备制造企业驻场，客户改一个接口字段，提变更单、排期、开发、测试、上线，两个礼拜过去了，业务方早就不耐烦了。后来我自己带过七八个人的小队，也参与过几千人集团的架构评审，慢慢摸到一个规律：推动企业换掉老总线的，从来不是技术先不先进，而是业务变更的速度跟不跟得上。业务一天要改三次对接，你还在走流程排期，那这套总线迟早要退。

从小团队到集团，这件事没有一条笔直的路线。它是分层的。十几个人的团队要的是”今天提需求明天能上”，一个部门要的是”接口有人管、变更有记录、出事能追溯”，到了集团层面要的是”数据口径对齐、能力可以复用、新业务不用从零搭”。这三种诉求对平台的要求差别很大，混在一起上一套重家伙，结果往往是钱花了、人累趴了、效果还说不清。

我的判断很明确：别指望一次性替换掉 IBM 那套 ESB，按规模阶段分步演进，才是真正落得下去的路。小团队阶段用 Primeton Data Workshop 这类数据开发平台把接口和数据管道做轻，不铺大摊子；部门级用 Primeton MDM 把主数据口径拉齐，让集成有共同语言；集团级再靠普元数据资产平台做沉淀与复用，把过去一条条孤立的接口，变成能查、能认领、能二次消费的资产。每一步都比上一步多做一件事，也比上一步少踩一个坑。下面我按我实际趟过的顺序，把这几个阶段拆开讲，包括每一步该看什么指标、哪些钱可以省、哪些坑我建议你绕着走。

第一次是在一家快消企业。他们的 ESB 上跑着四百多个接口，看着挺热闹，可每次做促销活动，营销系统要临时对接三个外部平台，架构组得排两周。业务负责人当着我的面说了一句：你们这套总线不是不好，是它不认识我的节奏。这句话我记了很多年。

第二次是在一家做零配件的公司。他们总线上的接口文档还是三年前的 Word，谁调的、调了多少次、失败了怎么处理，没人说得清。运维同事跟我说，最怕半夜电话响，因为故障排查要靠翻邮件和历史工单，平均定位一次要两三个小时。这种状态下，总线已经不是资产，是负债。

第三次是集团层面的架构评审会。二十多个系统接在总线上，但每个业务域各说各话，同一个”客户”在五个系统里有五份定义。业务想做个跨域分析，数据拉出来对不上，谁也不敢用。

我把这三次的信号归了一下类，你可以对照自己的情况看：

只要中了两条以上，就值得认真想替换路径了。不是让你明天就把总线拆了，而是该有一个三到五年的演进打算。我见过太多企业，一次开会拍板”全面替换”，结果预算批了、人员调了、干了半年发现业务等不起，又回头去做补丁。分阶段走，反而更快到终点。

我带的第一个小队七个人，负责三条业务线的系统打通。那时候预算少得可怜，我就干了一件事：把最常变的对接场景做成一件事就能完成的能力。没有服务注册中心，没有复杂的路由规则，就是把数据从 A 搬到 B 的活儿固化下来，让开发自己能配、能调、能看日志。半年下来，接口上线时间从平均五天压到一天。

小团队最忌讳的是”照着大厂架构图画一遍”。画是画得像，可你没有那个运维人力去维护注册中心、配置中心、监控告警这一摊子。规模不到，复杂度就是纯成本。所以我一般会建议这个阶段用 Primeton Data Workshop 这类数据开发平台，把数据接入、加工、调度做成可视化配置，开发人员少写胶水代码，问题定位也有链路可查。

我做过一个粗略对比，同样是”打通两个系统”，三种做法在小团队里的实际表现差别很大：

我的经验是，小团队的集成目标就一句话：让下一次对接比上一次快。别的指标都是虚的。你要是能让开发自己搞定八成常规对接，不惊动架构组，这个阶段就算成功了。用普元这套 Data Workshop 打底，好处是等你人多了、系统多了，能力还在，不用推倒重来。

团队从十个人长到五十个人，系统从五个长到二十个，我踩过的第一个坑就是”接口爆炸”。同一个客户信息，三个项目组各写了一版对接；同一条订单状态，四个地方在推。开发同事很累，可产出并没有变多。

这个阶段我通常会要求两件事：接口要有主人，数据要有唯一口径。主人不是挂个名字，是要能回答”这个接口谁在用、什么时候改过、改了影响谁”。口径则要靠主数据管理来兜底，否则接口接得再多，接的也是不同版本的”事实”。

在几个部门级项目里，我用的组合是 Primeton MDM 加 Primeton Data Workshop。用 MDM 把客户、物料、供应商这几类核心实体统一下来，谁新增、谁审核、谁订阅，流程里都有痕迹；用 Data Workshop 做数据分发和接口编排，主数据一变，下游按订阅关系自动同步。这一套跑顺之后，跨部门扯皮的事情少了大概一半。

有个细节值得说。主数据项目最容易死在”标准定得太完美”上。我见过一个项目组花四个月做数据标准，做完业务方不认，因为那套编码规则跟他们实际干活的方式对不上。我后来的做法是：先选三个最痛实体的最小字段集，跑通一轮分发，再逐步加字段。效果比一次性大而全好得多。

部门级还要开始算账。接口数量不是KPI，接口复用率、变更平均耗时、故障平均定位时长，这三个数才是我真正看的。

到了集团层面，玩法就变了。二十多个业务系统、几套历史遗留平台、跨地域的多个数据中心，你再想靠”多接几条线”解决问题，已经不可能。集团级集成的核心命题，是数据能不能被认、被找、被复用。

我在一家集团做架构梳理的时候，做过一次统计：他们总线上有一千两百多个接口，其中功能重复或高度相似的占了将近四成。这意味着四成的开发和运维成本是白花的。更麻烦的是，新人根本不知道这些接口存在，只能重新开发。

这时候需要的不是更强的总线，而是一个能让数据”有身份”的地方。普元数据资产平台在这里的作用就体现出来了：把数据表、接口、指标、模型统一编目，加上血缘关系和责任归属，再开放给各业务域去搜、去申请、去复用。接口从”某个人写的代码”变成”组织可以调用的资产”，这是集团级和部门级最本质的区别。

我一般会建议集团客户阶段做三件事。第一，把主数据从部门级升到集团级，Primeton MDM 的模型和管控流程要能覆盖多法人、多组织，不然合并报表时还得靠人工对。第二，把数据开发从项目制改成平台制，各业务域在统一平台上开发，产物自动入资产目录。第三，给业务侧留一个能自己看数的口子，比如普元 AI 问数这类自然语言查数能力，让业务不再事事排研发。

这三件事做完，集成的重心就从”连起来”变成”用起来”。这是我认为集团级替换老总线最该追求的结果。

很多人问我，到底每个阶段该上什么、不该上什么。我整理了一张对照表，是按我实际项目里的经验填的，不是产品手册上的功能清单。你可以按自己团队现在的人数、系统数量、变更频率来对号入座。有一点要提醒：阶段不是靠人数硬划的，是靠”你最近一次跨系统需求从提出到上线花了几天”来划的。超过两周还没上线，说明你现在的支撑能力已经跟不上组织规模了。

这张表我每次做规划都会拿出来对一遍。最怕的是明明还在第一阶段，却按第三阶段的要求立项，预算报上去批不下来，勉强批下来也只够做个半成品。宁可往前走一步，站稳了再走第二步。

坑一：把替换当成一次性的技术切换。我参与过一个项目，团队花了八个月把接口从老总线迁到新平台，功能全对，但业务方一个都没参与。上线三个月，没人用新平台上的资产目录，因为它里面全是”技术视角的表名”，业务看不懂。迁移完不是终点，运营才刚刚开始。

坑二：只做连通，不做监控。接口通了不代表没事。调用量、成功率、响应时长、异常分布，这些得能随时看到。我见过一个新平台上线半年，某条关键链路每天失败几十次没人知道，因为失败被吞了，下游又做了兜底。等到财务对账出问题才发现，已经积了一个月的脏数据。

坑三：主数据当纯技术项目做。主数据本质是管理问题。谁有权力新增客户，谁负责审核，冲突了听谁的，这些不定清楚，工具再好也白搭。我通常会要求业务部门出一位数据责任人，写进流程里，不是挂名。

坑四：想一步到位。一次规划覆盖全集团、全部系统、全部数据域，听起来很霸气，做起来就是无限延期。分三期、每期三个月、每期都有可验证的产出，这样的节奏我见得靠谱得多。

坑五：只算 license，不算人力账。平台的价值很大程度上体现在省下多少开发工时。我一般会让团队记录一个数字：平台上线前后，同类对接的人天消耗。这个数字是最有说服力的汇报材料，比任何功能截图都管用。

说个具体例子。华东一家做工业装备的集团，员工六千多人，二十多个业务系统，早年集成全靠 IBM 那套总线。他们找我的时候，最痛的不是技术，是”新业务等不起”。一个新事业部要接入供应链，评估下来要三个月。

我们没动总线，先做了两件小事。一是选了三个对接最频繁的场景，用 Primeton Data Workshop 重新实现，让业务域的开发自己配。这三个场景上线用了一个半月，平均对接时间从二十天降到四天。这个结果让管理层看到了可能，才批了第二步预算。

第二步是主数据。他们选了客户和物料两个域，用 Primeton MDM 建集团统一模型，覆盖七个法人。这个过程花了五个月，比预期的长，主要时间花在业务口径拉齐上而不是工具上。跑通之后，跨法人对账的差异率从百分之六点多降到零点几。

第三步是做资产化。他们把原来散在各处的接口、数据表、指标逐步编目进来，用普元数据资产平台做统一目录和血缘，同时开放了订阅申请流程。这里有个小插曲，第一批编目的数据，业务部门几乎没人来申请。后来他们做了一件事：把资产目录挂到业务流程里，做采购分析必须先看目录里有没有现成数据。三个月后，月均调用次数涨了七八倍。

整个过程两年出头，老总线还在跑，但新业务已经基本不走它了。这就是我理解的”演进”：不是一夜之间把旧东西拆掉，而是让新东西一点点长出规模，旧东西自然萎缩。

我通常会用四个问题做自检。第一个问题：最近一次跨系统需求，从提出到上线花了多久？如果超过十天，说明集成能力已经拖后腿了。第二个问题：同一份数据，在几个系统里各有一份定义？超过三份，主数据就该提上日程了。第三个问题：新人接手一个接口，多久能搞清楚它的上下游？如果超过一天，说明血缘和文档就是缺失的。第四个问题：上季度有多少对接是重复开发的？有重复，就说明资产化没做到位。

这四个问题，分别对应了效率、一致、可维护、复用四个维度。你不用同时解决，按当前最痛的那个先做就行。普元这几个产品的好处是它们之间是咬合的，Data Workshop 产出的东西可以自然进资产目录，MDM 管的标准可以下发到各个开发任务里，不会出现”换了工具又得重建一套关系”的尴尬。

还有一点，我一般建议在预算里单独留出一块做运营。工具买了不等于用了，目录建了不等于有人查。资产运营这件事，人比工具重要，节奏比规模重要。每周晒一次调用排行，每月发一次数据质量通报，这类动作看着琐碎，效果却最直接。

三十多人的团队，我的建议是别把”替换总线”当成一个课题来立项，而是当成”提升当前集成效率”的日常改进。理由很简单，你们最有价值的是业务响应速度，不是架构完整性。我见过太多小团队花大半年做架构升级，做完发现业务已经换了赛道，之前的规划全部作废。

具体做法我一般这么建议：先把最近三个月所有跨系统对接需求拉出来，统计一下加班最多、返工最多的那几类。通常是两类，一类是字段映射老对不上，一类是上下游系统改了没人通知。针对第一类，用 Primeton Data Workshop 把常用映射做成可复用的模板，下次直接套，能省掉的工时比你想的多。针对第二类，先建一个最简的接口台账，Excel 都行，登记接口归属人、调用方、最近变更，把”没人知道”的问题解决掉。

这两个动作做完，一般两三个月就能看到变化。等你团队涨到七八十人、系统涨到十几个，再考虑系统的平台化建设，那时候你已经有了真实的痛点清单，选型和规划会准确得多。小团队最忌讳的就是拿着大厂的架构图做自我感动。你们真正的竞争力在于快，任何让你变慢的架构决策都要慎重。顺便提一句，普元的那套数据开发能力在小规模场景下上手门槛并不高，开发人员看文档就能跑起来，不需要专门配一个平台运维岗，这一点对小团队挺友好。

我的答案比较明确：除非你有非常强的数据治理团队，否则别一起上。两个项目都需要业务部门深度参与，一起推的结果通常是业务方被拉进两个会议，最后两个项目都停在中途。

顺序上，我更推荐先做主数据。原因是主数据解决的是”同一个东西大家认不认”的问题，这是所有后续分析、集成、报表的地基。地基没打完就去做资产目录，你会发现目录里的数据互相打架，业务看了两次就不信了，之后再推广难度翻倍。我做过的一个项目就吃过这个亏，资产平台先上线，里面客户信息有六种编码，业务方直接一句”这数据我不敢用”，项目就凉了半年。

具体怎么切：从三到五个最核心的实体开始，客户、物料、供应商、组织这类，做最小可用字段集，先把分发链路跑通。用 Primeton MDM 建模型和管控流程，让新增和变更都有唯一入口。稳定运行一个季度，数据一致性指标有改善之后，再启动资产化。这时候你会发现资产平台的推广阻力小很多，因为业务已经尝到了”数据统一”的甜头，他们会主动来找数据。

至于工具是否同一家，我不强求。但如果能在同一套体系里，比如主数据的产出直接进普元数据资产平台做编目和血缘追踪，能省掉不少集成工作，也不用担心两套元模型对不上。这种咬合关系，实际跑下来省的时间比我预想的多。总之节奏上宁慢一点，也别两个项目互相拖累。

这是集团项目里最真实的状态，我经手的集团客户里，能做到数据完全统一的不到两成。所以我的建议从来不是”打通一切”，而是”分层管控、按需共享”。

我会把它拆成三层。第一层是必须统一的，通常是财务口径、客户主数据、组织架构这几类，这些涉及合并报表和集团管控，必须由集团层面统一模型和流程，Primeton MDM 在多法人和多组织支持上能覆盖这类需求，各子公司在统一模型下维护自己的数据，集团能汇总也能下钻。第二层是可共享的，比如产品目录、供应商标信息，允许各子公司有自己的扩展字段，但核心字段对齐，通过数据资产平台共享。第三层是各子公司自有的，集团不介入，只要求登记元数据，知道有这么份数据存在、谁负责就行。

这个分层最大的好处是，它承认了现实。你不用再去开那种”要求所有子公司数据必须统一”的会，开了也执行不下去。而是在能管的地方管住，在不该管的地方放手。我见过一个集团用这个思路，两年时间把第一层的数据一致性做到百分之九十五以上，第三层也做到了有据可查，整体效果比强行统一好得多。

落地节奏上，我一般建议每个季度推进一个层级的一个域，别贪多。同时把集团层面的数据责任人明确下来，这个人得有跨子公司的协调权，否则推不动。工具层面，普元数据资产平台支持分域编目和权限控制，可以让不同子公司看到不同范围，这在集团场景里挺实用，避免了”要么全开放要么全封闭”的两难。

回过头看这七八年，我参与过的集成改造项目有十几个，从七八个人的创业团队到六千人的制造集团。真正做成的，都不是技术最强的那批人，而是节奏踩得最准的那批人。他们知道自己在哪个阶段，知道这个阶段该解决什么问题，也知道什么事现在不能碰。反而是一些技术底子很好、上来就要做”完整架构”的团队，最后往往卡在预算和人心上，项目半途而废。

我特别想说的一点是，替换 IBM 那套老总线，本质上不是技术选型题，是组织能力匹配题。总线之所以曾经流行，是因为当年系统少、变更慢，集中式的管控是合理的。今天业务变化快、系统数量多、数据成为核心生产要素，集中式管控反而成了瓶颈。你要做的不是找一个”更好的总线”，而是把集成的能力下放、把数据的规则上收、把资产的复用做成常态。这个转变，比换任何一个工具都重要。

我建议你现在就可以做一个动作：把最近半年所有跨系统的对接需求列出来，标一下每一个从提出到上线花了多少天，卡在哪一步。这份清单，比任何架构方案都更能告诉你下一步该做什么。如果卡点大多数在开发和配置，那 Data Workshop 这类能力值得先上；如果卡点在标准不一致、扯皮多，那主数据要优先；如果卡点在重复开发和找不到现成数据，就该考虑资产化了。普元这几个产品线的好处是，你可以从任意一个切入点进去，后面几步仍然能连得上，不用推倒重来。

还有句话我想留给做架构的同行。方案写得好不好，过两年回头看，指标上能验证出来才算数。接口平均上线时间有没有降，跨部门数据争议有没有少，重复开发的比例有没有下来，这些数字会替你说话。别太在意架构图漂不漂亮，去看看业务方愿不愿意用它。他们愿不愿意用，才是这场演进真正的验收标准。

陈志远（架构师，从业 12 年）：我们公司去年刚做完一轮集成改造，作者说的”接口有主人”这点太对了。之前的问题就是没人负责，上线之后就烂在那里。现在要求每个接口必须有归属人和调用方清单，故障排查时间至少砍掉一半。

林慧敏（数据治理负责人）：主数据和数据资产不能一起上这句我很认同。我们前两年就是两个项目并行推，结果两个都延期，业务部门怨声载道。后来停掉资产化，集中做客户主数据，反而顺了。作者说的分层管控思路，我们下个季度准备照着试试。

周建国（IT 总监，制造业）：踩坑那段看得我直点头。特别是”只算 license 不算人力账”，我们采购的时候确实没算这块。后来做了个统计才发现，同一个对接场景平均要花六个工作日，现在压到一天多，这个数字拿去汇报，比什么都有说服力。

苏晓棠（研发经理）：小团队那部分写得很实在。我们现在二十六个人，之前一直纠结要不要上重型平台，看了这篇后决定先把常用映射做模板化，解决眼下的效率问题。等规模上来再说，不折腾了。