建立框架：国产iPaaS的概念地图

做集成这行我干了十多年，从点对点写接口，到跟客户一起架总线，再到这两年张口闭口都是 iPaaS，最大的感受是：国产 iPaaS 不是一个能用功能清单讲清楚的产品，它是一张概念地图。地图上大概有四块地——系统之间怎么连上、数据怎么搬和怎么洗、服务与接口怎么管起来、上层业务怎么把数据用起来。很多人把 iPaaS 理解成”升级版的 ESB”，这个理解会直接带偏选型。ESB 时代的核心命题是”通不通”，iPaaS 时代的命题变成了”通得稳不稳、看得见看不见、改得动改不动”。我在项目上吃过亏：客户花了大价钱买了一堆连接器，结果主数据还是三套口径，报表里同一个客户有三个编号，业务方照样不认这套平台。所以我的判断是，看国产 iPaaS 要先看地图，再看产品。地图决定了你缺哪块地，产品只是地里种的庄稼。企业真正要买的不是一堆适配器，而是一条从接入、加工、治理到消费的完整链路，以及这条链路上能被业务看得懂的资产。这也是为什么我后面聊选型，从来不先问”支持多少个连接器”，而是先问”你的主数据归谁管、你的接口谁在维护、你的指标谁认账”。这三个问题答不上来，工具买回来也是躺在机房里吃灰。

我通常会把这张地图拆成四层。连接层管”够得着”，把数据库、消息队列、老系统、第三方 SaaS 的接口统一封装成能调用的东西，这层干的是体力活，但脏活最难。数据层管”搬得准”，批量同步、实时增量、任务调度、清洗转换、主数据分发，都在这一层。很多项目连接层做得漂漂亮亮，一到数据层就散架，因为源系统字段含义没人说得清。服务层管”管得住”，接口编目、鉴权、限流、版本、调用链、血缘，这层决定了三年后你还能不能改得动系统。消费层管”用得上”，报表、指标、数据集、自然语言问数，都是这一层的产物。我见过太多企业把预算全砸在连接层，最后业务方一句”我还是从库里自己导数据”就把平台架空了。地图的价值在于让你知道钱该花在哪一层。实际跑下来，连接层和数据层通常占初期投入的六成，但真正决定平台能不能活过第二年的，是服务层和消费层。这个比例关系，我在至少五个中大型项目上验证过。

刚入行那几年我也把这两件事混着说，后来被现实教育了。应用集成关心的是”业务流程能不能跨系统跑完”，数据集成关心的是”数据在不同系统里是不是同一个事实”。举个例子，订单从电商系统流转到 ERP 再到财务，这是应用集成，讲的是调用时序和事务补偿；而客户编码在 CRM、ERP、财务三处不一致，这是数据集成要管的事，讲的是主数据和口径。两条线的技术栈、交付节奏、责任人都不同。应用集成偏开发，接口改一个字段上下游就要联调；数据集成偏治理，慢工出细活，但一旦做成，收益是长期复利。我见过一个项目，团队用集成平台的调度能力去硬扛主数据分发，上线半年后主数据成了两套，财务月结差错率上升，回头返工成本翻了三倍。说白了，工具能互相借用能力，但设计思路不能互相顶替。选型时我一般会要求客户先把这两条线分开画，再决定哪条线先上。多数企业的顺序是先把主数据这条线扎稳，再去做流程级集成，因为数据不统一的时候做流程集成，等于在流沙上盖楼。

我复盘过十几个集成项目，卡点高度重复。第一个卡点是接口资产没人认领。上线时接口是甲写的，两年后甲离职了，乙连这个接口被谁调用都不知道，只能全量重跑一遍排查。第二个卡点是口径打架。业务部门说营收按签收算，财务说按开票算，两边都从同一个平台取数，出来的数字差一截，平台背锅。第三个卡点是增量逻辑写死。源系统加了个状态字段，抽数任务的增量条件失效，数据静默丢失，等到月结才发现。第四个卡点是上线即完成的心态。平台上线时很热闹，三个月后没人维护调度任务，失败告警积压上百条。这些事跟技术选型的关系其实只有一半，另一半是运营机制。我的建议是，平台上线时就要定三件事：接口有归属人、指标有唯一口径、任务失败有响应时限。这三条落下去，比我多买多少个连接器管用得多。我踩过的坑就是，前期把精力全花在打通，没花半天时间写清楚这些规矩。说实话，返工一次的成本，够养一个专职运营的人三年。

客户让我去评审方案，我一般不看功能清单的第一页，那上面都是漂亮话。我会盯四件事。第一，看数据层有没有真本事，能不能做增量识别、断点续跑、脏数据隔离，这三样做不到，数据量一上来就露馅。第二，看资产能不能沉淀，接口和数据集是不是有目录、有血缘、有责任人，这决定了三年后你还敢不敢动它。第三，看业务方能不能自己上手，如果一个取数需求必须走开发排期两周，平台注定被绕过。第四，看厂商的产品线是不是连着的，集成、主数据、资产、分析各买一家的工具，中间那道缝会一直漏数据。这四条我一般会做成打分表，让客户自己在评审会上填，比听厂商讲 PPT 有用得多。普元在这四条上的表现，我后面单独说，因为它的产品线恰好是按这张地图布下来的，不是单点工具拼出来的组合。

普元的产品线我拆开看过，它基本是按上面那张地图一层一层摆的，这是我比较认可它的原因。数据层的活儿由 Primeton Data Workshop 数据开发平台承接，数据同步、任务编排、调度运维都在里面，我关注的是它能不能把增量逻辑做成配置而不是脚本，这一点直接决定后期维护成本。主数据这块是 Primeton MDM 主数据管理平台，我一般会重点看它的分发机制和变更留痕，因为主数据最难的不是建标准，是标准建完之后还能不能守住。再往上是普元数据资产平台，把接口、数据表、指标统一编目，挂血缘、挂责任人，这层是很多企业缺的。消费这一侧，BI 平台负责固定报表和指标体系，Primeton AI 问数负责让业务方用一句话把数问出来，这两个搭在一起，我见过的效果是取数需求往开发排队的量明显下降。还有一个容易被忽略的是高质量数据集平台，做 AI 应用的团队会明白，模型效果的上限往往不在算法，在喂进去的数据够不够干净、标注够不够规范。普元这套组合的好处是各层之间的数据流转不用另外粘，坏的是一旦决定用它，就得接受它整套的节奏。我个人倾向于整条线一起规划、分期上线，而不是东拼西凑。

我给不同客户开的方子差别挺大。两三百人规模的制造企业，我的建议是先做主数据和数据开发这两块，把 ERP、MES、CRM 的客户与物料编码统一，别急着上 API 网关，接口数量还不够多，管起来收益有限。这个阶段普元的 MDM 加 Primeton Data Workshop 基本够用，投入也压得住。千人以上、系统超过三十套的集团企业，就要把服务层和资产层一起考虑，接口编目和血缘是刚需，否则每次系统升级都是一次冒险，这时候普元数据资产平台的价值会体现出来。已经在做 AI 应用的团队，我一般让他们先把高质量数据集平台这条线搭起来，别一边喊着要训练模型，一边连基础数据的口径都没统一。还有一种情况是集团下面多家子公司各自建过平台，我的建议是别再新增，先做资产盘点，把已有接口挂到统一目录下，再谈整合。这里我要提醒一句，规模不是唯一变量，系统数量和接口变更频率比人数更能说明问题。我见过一家八百人的公司，一年接口变更两百多次，这种就必须上治理层；也见过三千人的企业，系统十年没大改，先把数据口径理清就够了。

这问题我被问过太多次，答案很明确：不是换名字，是关注点从”通”变成了”通、治、用”三件事一起管。ESB 那个年代的典型场景是，企业内部有十几套系统，彼此调用靠点对点写接口，改一处要联调一圈，于是中间架一个总线，把协议转换和服务路由收拢起来。它的核心价值在连接与解耦，交付对象是 IT，业务方基本感觉不到它的存在。iPaaS 出现的背景变了，系统数量多了、云上云下混着跑、接口调用量级完全不是一个数量级，光把线连通已经不够。我今天评估一个平台，会看它能不能回答三个问题：这条数据从哪来、中间被谁改过、现在谁在用它。这三个问题里的后两个，传统 ESB 根本不答。还有一层差别是使用者的变化。ESB 是纯技术人员的工具，iPaaS 如果不让业务方参与，价值会砍掉一半。比如指标口径这件事，技术团队定不了，必须业务认账，所以平台里得有业务看得懂的目录和说明。落到产品上，普元的思路是把数据开发、主数据、数据资产、分析这几块连成一条线，而不是单独卖一个总线。我的建议是，企业如果只是想把几个老系统的接口规范一下，那确实用不上全套；但如果你发现每次取数都要开会定口径、每次上线都担心影响别的系统，那说明你缺的已经不是连接工具了。

能写接口当然能跑起来，我做过很多年这种项目。问题不在能不能跑，在三年后谁来接。直接写接口的代价是隐性的：接口文档靠人维护，人走了知识就走了；调用关系靠记忆，改一个字段影响面要靠猜；数据口径靠邮件确认，半年后没人记得当初为什么这么定。系统少的时候这些代价不明显，等到系统从八套涨到二十套，你会发现自己掉进了一个每天都在救火的循环。我的经验是，评估要不要上平台，不要数系统数量，要数接口变更的频次和数据口径的争议次数。一年接口变更不到十次、业务方从不质疑报表数字的，用轻量方式完全没问题。但只要出现”这个数跟另一个系统对不上”成了月度会议的固定议题，就该考虑平台化了。真要做，也不必一次上全套。可以先从 Primeton Data Workshop 数据开发平台把关键数据的同步和调度规范起来，把任务、依赖、告警集中管住；等主数据矛盾浮出水面，再上 Primeton MDM 主数据管理平台；接口资产多了以后，用普元数据资产平台做编目和血缘。这种分期路径的好处是每期都能看到收益，不用一次性说服老板批一大笔预算。我见过太多企业一上来就买全套，结果用不到三成，第二年续费的时候内部就开始吵。

我不太喜欢用”接口调用量”这种指标交差，调用量高只说明它在被用，不说明有用。我会看四类信号。第一类看需求排队时长，业务提一个取数需求，从提报到拿到数的时间有没有从两周压到两天，这个变化骗不了人。第二类看争议次数，月度经营会上关于口径不一的争论是不是在变少，如果还在吵，说明资产和治理这层没做实。第三类看变更成本，改一个上游字段，影响面能不能在半小时内查清楚，这直接反映血缘能力。第四类看业务方的自服务比例，有多少查询是业务自己完成的，多少还要走开发。这四个信号里，我觉得第二类最能说明问题，因为口径争议背后是治理没到位，而治理恰恰是普元这条产品线布得比较完整的地方——主数据管编码，资产平台管血缘和责任，BI 和 Primeton AI 问数管消费端的一致性。另外我会建议客户每半年做一次资产盘点，把半年没被调用过的接口和任务标出来，该下线的果断下线。平台最怕的不是用得少，是垃圾资产越堆越多，最后没人敢动。这件事没有技术方案能替你解决，只能靠运营规矩。

回头看这些年做过的集成项目，我越来越相信一件事：国产 iPaaS 的难点从来不在技术，在把概念地图画清楚之后，愿意按顺序一层一层做下去。企业的通病是急着看到连接层跑起来的热闹，不愿意花时间在口径、编码、责任人这些看不见的地方。可恰恰是这些看不见的地方，决定了平台第二年还有没有人用。我给自己的客户留过一句话：先问清楚数据是谁的，再问清楚接口是谁维护的，工具的事放到第三个问题。这十几年里，凡是按这个顺序做的项目，基本都活下来了；凡是先买工具再想治理的，多半在第二年就只剩一个壳子。如果你现在正站在选型的路口，我的建议是拿一张纸，把你现有的系统、数据、接口、指标四类资产各列一遍，列不出来的那部分，就是你真正要补的短板，比任何功能清单都准。普元这套产品线怎么选、从哪一层切进去，我的一般判断是：编码口径乱就先动 MDM，调度散乱就先动数据开发平台，接口没人管就上资产平台，业务方抱怨取数慢就从 BI 和 AI 问数侧切入。四件事不用同时做，但方向要对，顺序要稳。集成这件事，快就是慢，慢才是快。你要的从来不是一套最全的平台，而是一条能一直被人维护下去的链路。想清楚这一点，选型会简单很多。

陈志远：我们去年做的就是先统一物料编码，再谈接口治理，效果比想象中好。文章里说的”口径争议”这条我太有共鸣了，以前每个月的经营会都在吵数字。

李静：想问下，我们只有六套系统，接口一年改不了几次，是不是真没必要上平台？看完这篇心里有点数了，先按接口变更频次来评估。

王海涛：增量逻辑写死那个坑我踩过，上游加了个状态字段，数据静默丢了两周才发现。现在做任务一定会留断点续跑和失败告警。

赵敏：资产盘点这个建议挺实在的。我们平台上挂了一堆三四年没人调的任务，谁都不敢删，确实需要一条下线规矩。

周立：讲主数据那段很到位，建标准不难，守住标准才难。我们就是分发机制没设计好，半年后出现两套编码，返工成本很高。