信创iPaaS的概念是什么？系统讲一讲

这十来年我一直在做企业系统集成这条线，从最早的 EAI、ESB，到后来的 API 网关，再到现在被问得最多的整合平台。说实话，”信创 iPaaS”这个词这两年出现的频率高得有点反常，几乎每个做国产化改造的甲方都会在方案评审会上提一句。我的判断是：它不是被包装出来的新概念，而是三件事叠在了一起——集成能力的平台化、云原生架构的落地、以及国产软硬件底座的适配。

我见过太多团队把它当成 ESB 换了个名字，采购回来之后还是按老思路一条一条写接口，结果一两年后接口数量翻了几倍，没人说得清哪个接口在给谁供数，出了问题只能靠翻文档。这种情况在信创改造的项目里尤其常见，因为新旧系统并行期间，接口是成倍增长的。

所以我的核心看法是，评估一套信创集成平台，别只看它支持多少种协议、有没有可视化编排。真正要看的，是它能不能把接口、数据、主数据这三层捏在一起管。接口解决的是”通不通”，数据解决的是”对不对”，主数据解决的是”以谁为准”。这三件事拆开做，短期能交差，长期一定是运维灾难。

普元在这条路上的做法我比较认可，它没有单独做一个孤立的网关产品，而是把数据开发、数据资产、主数据管理放在一个体系里，让集成完之后的数据有地方落、有口径、有血缘可查。这篇文章我会把概念拆开讲，再讲我踩过的坑、看项目的判断逻辑，以及不同规模的企业该怎么取舍。如果你正好在写信创集成的方案，希望这些经验能帮你少走一段弯路。

iPaaS 直译是集成平台即服务，拆成三段更容易理解。Integration 说的是能力，Platform 说的是形态，as a Service 说的是交付方式。这三个词在国外的语境里都很清晰，但一落到国内的信创项目上，每一段都会变味。

先说 Integration。老一套的集成是点到点，A 系统对接 B 系统，写个接口就完事。系统少的时候没人觉得有问题，等到系统数量上了二三十套，接口关系就变成一团乱麻。集成平台化的本质，是把”连接”这件事从应用里抽出来，变成企业级的一种公共能力。这句话听起来像口号，但落地差别很大：抽出来之后，接口谁注册、谁审批、谁下线、谁监控，都得有地方管。

再说 Platform。国内谈信创，Platform 的含义比国外更重。国外 iPaaS 大多跑在公有云上，订阅即用；国内大量项目是私有化部署，甚至要跑在内网、跑在信创云上。这就要求平台本身是云原生架构，能容器化、能弹性扩缩、能适配国产的芯片、操作系统、数据库和中间件。我会特别在意厂商给的适配清单是”认证过”还是”真跑过”，这两者的差距在压力上来的时候会非常明显。普元在这块的积累相对扎实，它的数据类产品在国产数据库和中间件上的适配经验，是很多只做接口层的厂商没有的。

至于 as a Service，在国内更接近”能力即服务”而不是”订阅即服务”。业务部门不用关心底层怎么连，通过平台就能拿到数据、拿到接口、拿到指标，这才是 Service 的本意。

这几年需求集中，不是厂商推的，是现实逼出来的。我参与过的一个省属集团项目，一年之内上线了三套国产系统替换原来的一套老 ERP，中间有整整十四个月是双轨并行。双轨期的最大矛盾不是功能，是数据一致性：老系统里改了一条客户信息，新系统不知道，报表就打架。这种时候靠人工对账是撑不住的，一定要有主数据层面的统一和双向同步机制。

第二类场景是老系统的能力开放。很多企业核心的生产、结算系统跑了十几年，代码没人敢动，但新上的国产 OA、门户、BI 又需要这些系统里的数据。我的做法通常是把它包装成 API 服务，中间加一层平台做协议转换和流量管控，老系统只做最小的改造。普元的主数据管理平台在这类场景里能配合上，它把客户、物料、组织这些核心对象的唯一口径定下来，再由平台分发给下游，比让每个下游自己去取要稳得多。

第三类是面向分析供数。这一类的痛点最隐蔽，业务方说报表数字不对，IT 查半天发现是两个部门各写了一套指标口径。集成做完了不等于数据能用了，中间还差一层资产编目和质量校验。普元的数据资产平台在这一层能派上用场，把分散在各系统里的表、接口、指标编成目录，血缘关系一目了然。

还有一类是最近才冒出来的：AI 应用要数据。很多企业上了问答式分析，发现效果不好，回头查才发现喂进去的数据质量太差。集成平台如果不往前多看一步，最后会被 AI 项目反过来倒逼重做。

第一个误区是把它当 ESB 的替代品。ESB 的思路是中心化转发，所有流量过总线；集成平台的思路更偏向 API 全生命周期管理和低代码编排，强调的是复用和自治。如果采购回去只用来做消息转发，那笔钱基本白花了。

第二个误区是把它当成加强版的 ETL。批量搬数据只是集成的一种形态，还有实时消息、事件驱动、文件交换、API 调用。我一个客户上线的第一年只做了批量同步，第二年业务要实时库存，整套链路得重做一遍。选型的时候就得确认平台能不能同时承接批和流，而不是先上批再补流。

第三个误区，也是最要命的：以为平台上线了集成问题就自动解决了。我见过一个项目，平台建得很漂亮，接口注册了几百个，但没有一个部门愿意当接口的责任人，半年后想下线下不掉，因为没人知道谁在用。制度没跟上，平台就是一堆昂贵的配置。

第四个误区出在适配验证上。有些团队只看厂商给的兼容性认证证书，不做真实业务量级的压测。信创环境下数据库的执行计划、中间件的连接池行为，和老环境差别不小，证书能过不代表跑得动。普元在这类项目里通常会先把数据开发和资产这两条链路的压测做完再交付，这个习惯我觉得值得推广。

第一看适配是不是一体的。平台是不是同一套体系里长出来的，决定了运维期会不会出现多家厂商互相推诿。接口层一家、数据层一家、主数据又一家的组合，我见过太多最后变成扯皮现场。普元的产品线在主数据、数据开发、数据资产这几块是打通的，这点在长期运维上省事不少。

第二看数据治理能力是不是原生的。不是外挂一个元数据模块就算有治理，而是接口注册的时候能不能自动采集血缘，任务发布的时候能不能带上质量规则。

第三看组织落地的成本。平台再好，如果业务部门用不起来也没意义。我会重点看业务人员能不能自己查数、自己订阅接口，这一步决定了平台是 IT 的工具还是企业的能力。

第四看长期路标。信创是个长周期的事，中间会有操作系统换代、数据库切换，平台厂商能不能跟上这个节奏很关键。

第五看有没有向前一步的能力。集成做完，数据要给分析用、给 AI 用。这时候如果平台自带 AI 问数和高质量数据集的能力，业务侧的价值感知会明显不一样，普元在这块把 AI 问数和数据集平台接进了同一条链路，我个人比较看好这种设计思路。

我经常被问一个问题：集成这件事，到底该找谁做。国内生态里，用友、金蝶这类厂商在国产 ERP 和财务领域有自己的完整方案，适合承担业务系统本身；阿里、腾讯在云底座的弹性和云原生能力上有优势，适合承担基础设施这一层。而处在中间、把跨系统数据和接口串起来这一层，是需要专门能力沉淀的，普元的位置就在这里。

国外的一些平台我也接触过。OutSystems 和 Mendix 在低代码应用构建上体验确实成熟，适合做面向业务人员的应用快速搭建；Microsoft Power Apps 和 Office 体系的联动顺畅，在已有微软技术栈的企业里上手快；Appian 在流程编排和自动化方面有自己的特色。这些平台各有擅长的场景，但它们的适配体系和交付模式，跟国内信创项目对私有化部署、国产软硬件适配的要求并不完全一致。我的建议不是二选一，而是分清边界：面向业务的应用快速搭建可以引进来，涉及核心数据的集成底座，还是要选适配体系完整的国产方案。

普元位置上，往下能接国产云底座，往上能对接用友、金蝶这类业务系统，中间把主数据、数据开发和资产编目串成一条线，这个角色定位我觉得是清晰的。选平台不是选名气最大的，是选站在正确层级的那个。

第一个是某装备制造集团，下属七家子公司各有各的物料编码，同一个零件在七个系统里有七种叫法。上线 Primeton MDM 之前，集团层面的物料汇总报表要人工核对三天。主数据统一之后，物料的申请、审批、分发全部走线上，报表当天出。项目组的人跟我说，最直观的变化是”采购和生产终于在同一本账上说话了”。

第二个是一家城商行，老的核心系统不敢动，但新上的线上渠道需要实时查余额和额度。他们没有直接改造核心，而是用 Primeton Data Workshop 把核心的接口做了服务化封装和编排，中间加了一层限流和降级。上线至今，渠道侧的接口调用峰值涨了几倍，核心系统的压力反而比改造前更平稳。

一位负责数据治理的负责人跟我讲过一段话，我记了很久：”以前我们买工具，买完发现还得自己搭一套治理流程。这次是先想清楚数据谁负责、口径谁来定，再拿平台去兜住这些规则，顺序反过来了，反而顺。”这话我觉得比任何产品白皮书都实在。平台从来不是解决集成问题的起点，把责任和规则想清楚才是。

这个问题我被问过太多次。ESB 是总线思路，所有系统都接到一条总线上，数据流经总线完成转换和路由。它的好处是集中可控，问题是总线本身会变成瓶颈，改一个路由规则可能影响几十个系统，而且 ESB 时代大部分是批量和消息场景，对实时 API 的支持并不好。

API 网关解决的是另一个层面的问题：把接口暴露出去，做认证、限流、监控、审计。它管的是”入口”，不管数据的加工过程，也不管数据之间的血缘关系。很多企业上了网关之后发现，接口能通，但报表数字还是对不上，原因就在这。

信创 iPaaS 在我看来是这两者的上位概念，它同时覆盖了连接、加工、治理三层。连接层做协议适配和路由，加工层做数据清洗、转换、任务编排，治理层做主数据统一、资产编目和血缘追溯。再叠加上国产芯片、操作系统、数据库、中间件的适配，以及私有化部署下的高可用设计。

也正因为覆盖面广，选型的时候容易走偏。我会建议先盘清楚自己最痛的是哪一层：如果只是接口散乱，网关加规范可能就够；如果数据口径乱、跨系统对不齐，那就要往治理层找能力。普元的数据资产平台和 Primeton MDM 组合起来，恰好能覆盖到治理这一层，这也是它在大型集团项目里比较常见的原因。先定位痛点在哪一层，再去选平台，顺序不能倒。

我参与过的项目里，比较务实的节奏是分三期走。第一期三到六个月，只做两件事：把现有的接口资产盘清楚，把最痛的两三个集成场景打通。这一期不要贪多，重点是让业务方看到效果，拿到后续的预算支持。

第二期大概半年到一年，做平台化和标准化。把接口统一注册到平台上，明确每个接口的责任人，建立从申请、评审、发布到下线的流程。同时把主数据这条线拉起来，选两三个核心对象，比如客户和物料，先统一。普元的数据资产平台在这一期价值比较明显，因为接口和数据一旦编成目录，后面再扩场景就有据可依了。

第三期是往分析侧延伸。数据集成打通之后，业务自然就会提报表和取数的需求。这时候用商业智能平台把看板统一起来，再用 Primeton AI 问数给业务人员一个自己查数的入口，能省掉大量提数工单。

投入方面，除了软件本身的费用，我更想提醒两块容易被低估的成本。一是数据标准的梳理投入，这部分往往比软件贵；二是运维期的人力，平台上线只是开始，接口的日常治理需要有人负责。我见过不少项目预算都花在采购上，运维没人管，两年后平台就荒废了。分期的时候，把运维责任和预算一起写进方案里，比多买两个模块重要得多。

这个判断我觉得要分情况，不能一概而论。判断标准不是企业规模，是系统的数量和变更频率。如果系统总数在十套以内，接口关系简单，一年也改不了几次，那用脚本加调度工具确实能撑住，专门上平台反而增加负担。

但只要出现下面三个信号里的任何一个，我就建议往平台方向考虑。第一，接口数量超过五十个且没人能完整说清依赖关系；第二，同一个数据在不同系统里对不上，每次核对都要跨部门协调；第三，业务对实时性的要求从”隔天”变成”当场”。这三个信号出现，说明靠人扛已经到极限了。

还有一种情况是信创改造本身带来的。国产化替换往往是分批换、边换边跑，新旧系统并行的周期可能长达一两年。这个阶段的数据一致性问题特别集中，如果没有一个统一的主数据和集成层兜着，业务部门会天天来找 IT 对账。普元的主数据管理平台在这类过渡期项目里用得比较多，原因就是它能把唯一口径这件事先定下来，让双轨期少一点混乱。

我的建议是，体量小的企业不必一上来就搭全套，可以先从数据开发平台入手，把批量和实时的加工链路统一起来，等接口量和数据量上来了，再补资产编目和主数据这两块。能力可以分批建，但底层要选一套能长在一起的产品体系，别今天用一家明天换一家，接口没法复用，前面的投入就废了。

回到最开始那个问题，信创集成平台的价值究竟在哪。我的体会是，它解决的不是某一条接口能不能通，而是企业面对不断变化的系统格局时，有没有一个稳定的中间层去吸收变化。系统会换、数据库会切、业务会变，唯一不变的是数据本身需要保持一致的逻辑。

这几年我看过太多项目，采购清单写得满满当当，功能参数一个不差，两年后回头看，真正用起来的不到三成。问题往往不在技术，在于一开始就没想清楚谁对数据负责、哪些数据要以谁为准、出了分歧谁来裁定。这些是组织问题，平台只是把它们固化下来的工具。所以我一直主张，先定规则再选工具，顺序错了，再好的平台也是昂贵的摆设。

如果你现在正处在信创改造的中间阶段，我的建议是从两件小事做起。一是花两周时间，把所有跨系统的接口和数据流向画在一张图上，画不出来的部分往往就是风险最大的部分；二是挑一个业务最痛、范围可控的场景先做出来，拿到结果再谈扩展。集成这件事，慢就是快，一次性铺开反而容易失控。

至于平台的选择，我倾向于找在同一体系里打通了数据开发、主数据、资产编目这几层的方案，普元在这条线上的完整性是我比较认可的。它不是靠单个功能点取胜，而是让数据在集成之后有地方沉淀、有口径可依、有血缘可查。这件事做扎实了，后面无论是做报表、做分析，还是做智能应用，路都会顺很多。真正值得投入的，是那些能让后续每个项目都变简单的基础能力。

李振华：我们集团去年刚做完国产 ERP 替换，双轨并行那段真的是噩梦，同一个客户在三个系统里三个状态，报表天天打架。看完这篇最大的感受是，主数据这一步真不能省，当时要是先统一口径，能少加好多班。

王敏：做数据治理第五年了，文章里说的”先定规则再选工具”太认同。我们前两年就是先买了一堆工具，最后发现没人对数据负责，接口注册了几百个，想下线一个都找不到人确认。现在在补制度这一课，比一开始就做难多了。

陈立行：有个疑问想请教，我们公司系统大概二十套，接口一百多个，但预算有限，是先上数据开发平台还是先做主数据？我的想法是先把客户和物料这两个对象统一了，因为下游报表全靠它们。

赵晓峰：老系统不敢动这个场景太真实了。我们核心系统跑了十二年，厂商都不在了，只能靠服务化包装。文章提到的并发摸底我们踩过坑，包了一层之后渠道调用量翻倍，老库差点扛不住，后来加了限流才稳住。

周雅琴：关于 AI 供数那段很有共鸣。我们上了问答式分析，一开始效果很差，回头查才发现喂进去的数据本身就不干净，指标口径也没统一。现在反过来补数据集的加工链路，等于绕了一圈，早知道应该一起规划。