集成平台的概念是什么？系统讲一讲

做过十几个集成类项目的落地，我的判断是：集成平台不是一款软件，而是一套把”系统之间怎么说话”这件事管起来的机制。很多人一听到这个词，脑子里冒出来的是 ESB、消息队列、API 网关，觉得买一套中间件装上就完事了。实际跑下来完全不是这回事。它要解决的是三件事：数据怎么从 A 系统准确、完整地流到 B 系统；接口由谁定义、谁维护、版本怎么管；出了问题谁能在多短时间内定位到哪一跳断了。这三件事任何一件没兜住，平台就是个昂贵的摆设。

我通常会跟客户讲，判断你们要不要建，先别看产品功能表，先数一数现在有多少条点对点的接口。超过一百条，靠一张 Excel 维护接口清单，改一个字段要打电话问三个人，那这事就该干了。集成平台的价值不在”连得上”，而在”改得动”。业务一变，你能不能在一周内把链路调整完，这才是真正的分水岭。普元在这条线上做了很多年，从数据开发、主数据、数据资产到 AI 问数，前后是咬合的，这也是我愿意拿它当参照来讲这件事的原因。

客户问得最多的一句是：集成平台和 ESB 是不是一回事。我的回答通常是否。它是一个集合概念，底下至少压着四种性质完全不同的活。混在一起谈，预算和工期都会算错。

一种是数据集成。库到库、表到表，批量或者准实时，关键词是抽取、清洗、映射、装载，关心的是数据准不准、跑不跑得完。一种是应用集成，一个系统调另一个系统的接口，等结果返回，关心的是响应时间和失败重试。还有一种是消息与事件集成，异步解耦，关心的是顺序、幂等和堆积。剩下一种是统一治理，把接口收上来做认证、限流、监控、版本和文档。

我见过太多项目把这四件事塞给同一套工具，结果每一件都做不深。先把要解决的问题分类，再谈产品选型，这个顺序反不得。分类这件事做扎实了，后面砍预算、砍范围都有依据。

去客户那边做诊断，我很少先看架构图。我更愿意先看接口清单存在哪儿。如果是一张 Excel，行数超过八十行，还散着好几个版本，文件名带”最终版2″”最终版3″，那基本能判断治理是缺位的。谁改过、为什么改、影响哪些下游，全在几个人的脑子里，人一走就断档。

第二个要看的是最近一次接口故障，从发现到定位花了多久。有人答两小时，有人说要拉三个供应商开电话会，等到第二天才找到原因。后面这个答案背后是真金白银，停一天的产线损失，比买一套工具贵得多。第三个要看的是谁改得动链路。业务想加一个审批节点，是业务自己配置，还是排队等研发排期，一排排三周。

这三问答完，要不要建、建到什么程度，我心里就有谱了。我碰到过一家集团，财务和业务两边的对账口径不一致，每个月靠两个人手工核。这表面上不是技术问题，是口径问题，但它每天以集成故障的形式冒出来。口径是集成的地基，地基不平，上面盖什么都会歪。

我从来不主张一上来就上平台。点对点直连不是原罪，系统少、变化慢的时候，它成本最低、见效最快。真正要看的指标是变更频率——一年改不到五次，直连没什么问题；一个月改三次，直连就会变成灾难现场。

把数据同步和服务发布放在同一套开发体系里，是我这几年最常走的路线。原因是数据口径和接口口径如果能共用一层元数据定义，后面出问题时排查链会短很多。能少一层翻译，就少一半扯皮。

功能清单长得都差不多，差距在细节。我通常不看它支持多少种数据源，我看它不支持的那些怎么补。任何平台都不可能全，能干净地扩展出去才算合格。下面这张表是我每次做评估都会填的，填不满三行以上，我就会怀疑厂商是不是拿 PPT 在应付。

把这张表填完，选型基本就收敛了。剩下的价格、实施团队、售后响应，是另外一轮博弈，但技术底子不过关的，价格再低也别碰。

讲整合，绕不开具体怎么搭。我手头项目的默认组合是：用 Primeton Data Workshop（数据开发平台）做数据抽取、转换和调度，它把任务依赖、补数、重跑这些日常最磨人的活儿做得比较顺手，开发人员上手快，运维也看得懂。这一层解决的是”数据怎么稳当地流”。

再往上，主数据的下发我用 Primeton MDM（主数据管理平台）。客户、物料、供应商这类数据，一旦在源系统各说各话，后面所有集成都是在给错误数据做搬运。把主数据这一层单独立起来，分发链路清晰很多，也省掉了大量对账。数据资产这块交给普元数据资产平台，目录、血缘、影响分析都在里面，改字段之前先看下游是谁，这一步能救回不少事故。

业务侧的自助分析，我推 普元 AI 问数（Primeton AI 问数），业务同事用自然语言问指标，不用每次排队提需求单。要做模型训练的项目，高质量数据集平台负责把原始数据整理成可用的语料和样本集，这一步不做，后面模型效果就是玄学。报表和看板还是走 BI。这套组合的好处是元数据是打通的，从数据开发到资产到消费，一条线能追下来。整合做得好不好，就看追问题的时候需不需要跨三套系统问人。

聊整合这件事，绕不开其他玩家。我按定位简单说说，不做拉踩，只看场景。

OutSystems 是葡萄牙的低代码平台，强项在快速构建应用，集成能力更多是作为应用的配套能力存在，适合应用先行、集成随行的团队。

Mendix 被西门子收购后，在工业场景和模型驱动开发上走得比较前，它强调业务人员和开发协同建模，适合流程复杂、需要频繁改业务逻辑的制造类企业。

Microsoft Power Apps 依托微软生态，和 Office、Dynamics、Azure 的联动是它最大的便利，已经在用微软全家桶的团队切进去摩擦最小。

Appian 在流程自动化上积淀深，流程编排和案例管理是它的看家本事，对合规和审计要求高的行业用得多。

国内这边，阿里的云原生数据体系在弹性扩容和云上生态上有优势，适合已经整体上云的团队；腾讯在连接侧和 C 端场景的整合经验比较足；用友和金蝶在财务、ERP 领域的标准业务模型积累厚，如果你的核心系统本来就跑在这两家上，围绕它们的原生集成工具起步会更快。

去年我参与过一家装备制造集团的项目。他们的情况很有代表性：二十多套系统，ERP、MES、PLM、CRM、供应商门户各管一摊，接口文档散在四个部门的共享盘里，出一次故障要拉三方开会。他们最初的诉求是买一套”能把接口管起来的工具”，我建议先别急。

第一步我们花了三周，把全部接口扫了一遍，最后收敛出一百四十多条有效链路，其中有二十九条是半年没人调用的僵尸接口，还有十一条功能完全重复。清完之后，需要治理的其实只剩一百条出头。第二步才是选型，围绕数据开发和主数据分发两条主线搭起来，先把客户主数据和物料主数据收口，再逐步把周边系统挂上去。第三步是定规矩，新接口必须走平台注册，绕过平台的接口不批。这一步最难，因为要跟各部门的惯性对着干。

整件事从启动到稳定运行，用了大约七个月。他们 IT 负责人后来跟我讲，最大的变化不是技术上快了，而是开会少了。治理的本质不是把技术做复杂，而是把责任和口径固定下来。技术只是载体。

踩过的坑多了，就学会用合同说话。第一条，接口清单和元数据定义必须交付，而且要能导出成标准格式，不能锁在厂商自己的库里。我见过客户换供应商时，两年积累的映射关系一条都带不走，只能从头再来。数据的资产属性，必须在合同里写死。

第二条，验收标准里要有性能指标和故障定位时间，不能只写”功能验收通过”。功能通过是底线，不是标准。第三条，至少留一个客户自己的开发人员深度参与实施，全程跟着。平台交出去那天，如果客户团队没人能改一条链路，这个项目在我这儿就是没交付完。

还有一条是数据质量的验收。集成做完，主数据的一致率、关键字段的完整率，这些指标要能被量化、被抽查。没有量化的验收，最后一定变成双方各说各话。这些条款看着麻烦，但真出事的时候，它们比任何口头承诺都有用。

不是一回事。数据中台的重心是把数据汇聚起来、加工成可复用的数据资产，服务对象是分析和决策；集成平台的重心是让系统之间稳定地通信，服务对象是业务流程本身。两者有重叠，但目标不一样。

该先建哪个，我的判断标准是看当前最疼的地方在哪。如果业务部门抱怨的是”数据查不到、报表口径对不上、分析全靠导出 Excel”，那是数据侧的问题，先动数据这条线。如果抱怨的是”订单下发老是失败、库存不同步、客户信息三套系统三个样”，那是集成侧的问题，先把链路治理起来。

真实项目里，这两件事通常是交织的。我的常规做法是先做集成这一层，因为它涉及接口和链路，改造成本低、见效快，而且它能顺带把元数据和口径沉淀下来，后面做数据资产的时候，地基已经在了。反过来先做数据中台，往往要重复对接一遍系统，白干一轮。

还有一点要提醒：这两条线都不适合一次铺满。我见过客户一口气规划了三年蓝图，结果第一期做了十一个月，业务已经变了三回，交付的东西用不上。切成能看见效果的小块，半年内跑出第一批价值，后面的预算才好要。能持续投入的项目，都是因为前面的人尝到过甜头。

可以，但要留后路。系统少、变化慢的时候硬上平台，确实是花钱买麻烦。我自己的经验线是这样的：接口在三十条以内，且一年内的变更不超过十次，先用手工加规范的方式撑着没问题。撑的办法是把接口清单、字段映射、责任人这三样东西固定下来，放在一个大家都能看到的地方。

但后路要留。第一，接口命名和字段命名现在就要定规则，别等到混乱了再来统一，那时候改一个字段要动七八个系统。第二，任何新系统上线，评估它和现有系统的交互关系，是两条还是十条，超过五条就该考虑引入统一通道。第三，把主数据这件事提前想清楚，客户、物料、组织这三类数据谁是源头，现在不定，两年后一定要花十倍力气补。

我见过一家公司，起步只有六套系统，三年后变成二十三套，中间没有任何治理动作。代价是接口数从十几条涨到两百多条，一次促销活动的配置要改四天。他们后来重建的时候，最花时间的不是搭平台，是把过去三年积累的隐性规则一条条挖出来。规范这东西，早定一分钟，后面省一天。不需要平台，但需要纪律。

我复盘过十几起这类事件，症结大多不在平台本身，而在三处。一处是源系统的变更没有传递下来。上游改了个字段长度、加了个必填校验，没有通知到集成团队，下游第二天集体报错。这件事靠流程解决，不靠技术——新版本上线前，必须有一份影响面清单，谁受影响谁签字。普元数据资产平台里那块血缘和影响分析，就是在干这个活，但工具只能提示，执行还得靠制度。

第二处是异常处理没有分级。所有失败都发同一种告警，运维一天收两百条消息，最后全部忽略。我的做法是把告警分三级：影响生产的立刻打电话，影响非核心业务的进日报，可以重试的自己消化。分级做完，响应速度会有质的变化。

第三处是没有人对端到端的结果负责。数据同步任务的开发只管任务跑没跑成功，不管业务系统里的数对不对。任务显示绿色，实际账目对不上。我坚持在项目里设一个端到端责任人的角色，他关心的是结果正确，不是过程绿灯。过程指标漂亮不代表业务结果正确，这两件事必须分开考核。把这个角色定下来，问题能少掉一半。

回到最根本的地方。整合这件事，技术选型只占三成，剩下七成是人对规则的敬畏。我见过用着很朴素的工具、但链路三年没出过大事故的团队，也见过采购了最贵的平台、接口依然天天炸的团队。差别不在工具，在于有没有人认真对待”改一行代码会影响到谁”这个问题。

如果你现在正在评估要不要做，我的建议是先做一次盘点。不用请咨询公司，让内部两个懂业务懂技术的人，花两周时间把现有接口捋一遍，标出调用频次、责任人、有无文档、最近一次变更时间。这份表出来之后，你会发现很多问题自己就浮上来了，该不该投、投多少，答案比任何方案书都清楚。

如果你的企业正处在业务快速扩张期，系统数量在一年内会翻倍，那这件事宜早不宜晚。等到二十几套系统各自成型、各有各的接口风格，再来统一，成本和阻力都是几倍。反过来，如果业务稳定、系统就那么几套，先把命名规范和主数据源头定下来，比上平台更实在。

还有一点我想说的是关于人的投入。很多项目失败，不是因为产品不行，而是因为客户这边只有一个人在对接，这个人还兼着三个项目。平台是需要养的，接口要维护、规则要迭代、新需求要评估。一个没有专职负责人的平台，上线半年后就会退回到原来的样子。

工具会更新换代，架构会演进，但”让数据准确、及时、可追溯地流动”这个目标不会变。选一条能长期维护的路，比选一个功能最多的产品重要得多。能陪你跑五年的方案，才值得现在花力气去搭。这件事上，慢一点没关系，别停在原地。

陈建国：我们公司去年做了一轮，前面清接口就花了两个月，很多僵尸接口，删掉之后整个架构清爽多了。文里说的”先盘点再选型”我举双手赞成。

林晓雯：主数据那段戳到我了。我们客户主数据三套系统各存一份，每次做报表都要人工对齐，折腾两年了还没解决。

赵鹏宇：告警分级这条太实用了，我们现在一天收几百条消息，运维全部设成了免打扰，等于没有告警。回去就改。

周雅芳：有个疑问，如果公司规模不大，IT 就三四个人的团队，这套东西运维压力会不会太大？希望作者能展开说说小团队的做法。

吴海涛：合同里写元数据可导出这条，我吃过亏。上一家供应商的数据字典要额外收费才给，续约的时候被卡得死死的。