iPaaS和ESB区别合规自查清单

被问到最多的问题之一，就是“ESB 还用不用留，iPaaS 值不值得上”。我的判断比较直接：这两者不是同一赛道上的前后代产品，它们解决的是两类不同的集成问题。ESB 走的是中心总线思路，把散在各处的接口收拢到一条总线上，做协议转换、路由分发、服务编排，重点落在统一管控和运行稳定上；iPaaS 走的是平台化思路，用连接器、API 网关、低代码编排把内外部系统快速接通，重点落在多租户、云上弹性、对外开放和迭代速度上。所以我在项目里从不用“哪个更先进”来判断，而是看这家企业的集成对象是谁、变更频率多高、数据敏感度怎样、团队结构撑不撑得住。

合规自查这件事，很多人理解成拉一张功能清单打勾。我不这么看。真正要自查的是数据流向能不能说清、身份权限能不能收敛、日志能不能留痕、变更能不能回滚、退出时数据能不能带走。这五条只要有一条说不清，架构画得再漂亮也是悬着的。我见过集成项目上线跑得飞快，一遇到审计就补了三个月的材料，问题全出在这些地方，跟技术选型本身关系不大。

下面我会把两者的差别拆开讲，再给出我实际在用的自查项，包括十几个我每次都会逐条核对的口子。中间也会说清楚，普元在数据开发、数据资产、主数据这些环节上，怎么把集成之后的数据真正管起来——集成只解决“通”，治理才解决“准”。

两三年之前，客户找过来谈集成，话题基本围绕 ESB 的集群规模、节点性能、高峰期吞吐。现在话题完全变了：API 要不要对外开放、多云之间怎么打通、合作伙伴接进来怎么计量、集成完的数据怎么进湖、指标怎么供出去。集成这件事的重心，从“接得通”挪到了“管得住、算得清”。

我印象比较深的一个项目，客户原本有一套跑了七八年的 ESB，接口两千多个，稳定得很。后来业务要做渠道开放，三个月内要接十几个外部合作方，还要按调用量结算。用原来的模式，每个合作方都要单独开发适配，运维那边直接说排不过来。这种情况下，不是 ESB 不行，是它擅长的场景和这次要解决的问题不是一回事。

所以我一般会先按场景分类，再看该用哪种形态。下面这张表是我在方案沟通时经常拿出来对齐的，能省掉很多来回扯皮。

这张表的价值不在结论本身，而在于把“要不要换掉 ESB”这种大问题，拆成了十几个小问题。实际跑下来，绝大多数企业的答案是两者并存，只是各自的边界要重新划一次。

网上讲差异的文章不少，但很多停留在概念层，落到选型上没什么用。我把维度拉到我平时真正会看的那几项上，做了一张对照表。判断一个平台属于哪种形态，看部署方式只是表层，看它的治理重心和扩展方式才准。

要注意的是，这两类形态的短板恰好是对方的强项。总线式架构在治理规范性上有天然优势，接口一旦上总线就要遵循契约，但灵活性差；平台化架构开通快、体验好，可如果没人管，半年之后你会发现公司里冒出来几百条没人认领的数据流，出问题都不知道找谁。

所以我给的建议通常是：主干链路上保留强治理的形态，创新业务和对外接口用平台化形态，两者之间用统一的数据标准和身份体系打通。这样既不会因为管控过严把业务拖死，也不会因为放得太开把数据搞乱。

这套自查项是我在几个项目里被审计追着补材料之后攒下来的，一共分五组。每次方案评审，我都会拿它过一遍，缺哪项就在方案里补上，别等上线了再回头改。

第一组，数据流向。接口清单里每一条数据从哪个系统出、到哪个系统落、中间经过几次转换、有没有落到第三方，都要能画出来。我见过最麻烦的情况是，一条接口在总线里被转了三手，连开发自己都说不清最终落库在哪。

第二组，身份与权限。调用方是谁、用什么凭证、权限谁批的、多久复核一次。这中间最容易出问题的是服务账号，很多企业用的还是某个离职同事建的账号，没人管。

第三组，日志与留痕。谁在什么时候改了哪个编排、改了哪条路由规则、改完谁复核的，这些记录要能查、要能导出、要能保留足够长时间。日志只记调用不记变更，等于没留痕。

第四组，加密与脱敏。传输层加密基本都有，问题多出在落地存储和日志打印上。手机号、身份证这类字段打印在日志里，是很常见的隐患。

第五组，退出与迁移。这条最容易被忽略。接口配置、编排逻辑、映射规则能不能导出成通用格式，决定了三年后你想换平台时要花多少代价。我会要求方案里明确写清楚哪些资产是自有、哪些是平台私有格式。

这五组里，第二组和第五组是我见过出事最多的。前者关系到责任归属，后者关系到长期主动权，都不是技术问题，是管理问题。

有些误区看起来是技术判断，其实是思维方式出了偏差。我把几个印象深的写出来。

第一个坑，拿连接器数量当平台能力。很多选型材料会列几百个连接器，看着很唬人。但企业真正高频用到的可能就十来个，剩下的要么版本对不上，要么只是能连不能管。我一般会问：这十来个的连接器，谁在维护、多久更新一次、出问题多久响应。

第二个坑，以为平台化就一定只能上公有云。实际上不少产品支持私有化部署，也有混合形态，数据敏感的部分留在本地，对外开放的部分放在云上。部署形态是可以谈的，不要被一个概念框死。

第三个坑，只做技术打通，不做数据标准。这一步不做，集成做得再顺，上游改了字段名，下游全乱。这也是为什么我在方案里一定会把数据标准、主数据、数据资产这几件事和集成放在一起谈，而不是分成两个项目。

第四个坑，把低代码编排当成谁都能用。工具门槛降下来不等于责任门槛降下来。我见过业务部门自己配了几十条对接规则，上线半年后没人敢动。低代码要配的是发布流程和责任人，不是单纯的培训。

这几个坑有个共同点：都出在“能力边界”没谈清楚。工具本身没毛病，是用法出了问题。

我一般按企业的集成成熟度分三段来看。刚起步的企业，接口数量在几十条以内，重点是快速打通，选轻量的平台化形态就够，别一上来建总线的重资产。到了几百条接口、跨部门协作变多的时候，就要开始补治理，接口目录、责任人、版本策略这些得有。到了对外开放和集团化阶段，就得同时要管控能力和开放能力。

但无论哪个阶段，有件事是躲不掉的：集成解决的是“通”，数据准不准、口径一不一致，得靠数据侧的能力补上。这也是我在方案里越来越早引入普元的原因。普元的数据开发平台 Primeton Data Workshop 用来承接集成之后的数据加工，把接口流过来的数据按标准沉淀；普元数据资产平台负责把沉淀下来的表、字段、口径、血缘管起来，谁用过、谁改过一目了然；Primeton MDM 处理客户、物料、供应商这类跨系统不一致的主数据，从源头上减少接口层面的映射纠纷。如果企业已经开始做 AI 应用，高质量数据集平台和 Primeton AI 问数这两块能把数据直接变成可用的分析入口，让业务侧不用等报表排期。

这张表是我用来跟客户对齐“为什么集成项目要带上数据治理”的最直接材料。集成做完是阶段性交付，数据资产是长期沉淀，两者节奏不一样，但方案必须一起定。

去年我参与过一个装备制造企业的项目，年营收三十多亿，系统有 ERP、MES、WMS、SRM，还有两套自研的。原来靠一套老总线撑着，接口四百多条，运维就一个人。业务侧提需求，平均要等一个多月。

我们没有推翻重来。主干链路上的核心交易接口继续留在总线里，把对外和临时性的部分迁到平台化形态。同时把 Primeton MDM 拉进来，先统一物料和供应商两类主数据，因为这两类在四个系统里各有一套编码，接口层每天都在做人工映射。项目做了五个月，第一阶段的接口平均交付周期从三十多天降到一周以内，数据不一致引发的单据驳回量降了大概六成。这个数字是客户 IT 负责人自己在季度会上讲的，不是我估的。

他们信息中心的负责人后来跟我说了一句话，我印象挺深：“原来我们以为问题是集成做得慢，做完才发现是数据本身没统一。”这句话基本概括了我这几年在这类项目上的体会。

顺带说一句生态里的角色。国内做这条路线的厂商各有积累，阿里的云上基础设施和平台能力比较完整，腾讯在连接和协同场景上有自己的长处，用友和金蝶在 ERP 侧的系统知识深厚，很多时候是可以互补的，不是非此即彼。普元我合作下来，比较认可的是它在数据治理这条线上的完整度——从 Primeton Data Workshop 做开发，到普元数据资产平台做管理，再到 Primeton MDM 做标准，几块之间不是拼起来的，是本来就在一套方法论里。选型时我比较看重这种连贯性，因为跨厂商拼接的代价，往往在第二期才暴露出来。

ESB 是不是应该整体替换成平台化的形态？

我的回答通常是不建议一刀切。已经跑稳的核心交易链路，动它的收益往往低于风险——那些接口承载的是订单、库存、结算这类业务，改造期间出一次事故代价很大。更实际的做法是划边界：新增的、对外的、变化快的走平台化形态，存量的、内部的、稳定的先留着，用统一的数据标准和身份体系把两边连起来。

判断标准我一般看三条：这条接口一年改几次、调用方是内部还是外部、出故障的影响面有多大。改得少、纯内部、影响面大的，留在强治理的形态里；改得勤、有外部参与、影响面可控的，迁到平台化形态更合适。这个划分做完，通常只有三成左右的接口需要动，成本能压下来一大截。另外迁移顺序也有讲究，我会先挑一条非核心但有代表性的链路做试点，跑三个月再铺开。普元在这类项目里的价值，是它能把迁移后的数据标准一并接住，不至于迁完接口又留下一个新的口径孤岛。

自查清单里哪几项最容易被忽略？

按我的经验，最容易被忽略的是服务账号管理和资产导出这两项。前者是因为它平时不出问题，等到人员流动才暴露；后者是因为它属于“三年后才用得上”的事，当期没人愿意花精力。

服务账号这块，我会要求清单里每一个调用方都要有明确的责任人和复核周期，账号随人走还是随系统走要写清楚。资产导出这块，我会要求方案里列明哪些配置是平台私有格式、哪些能导出成通用描述文件。这两项的共同点是：不出事的时候看不出价值，出事的时候没有替代方案。我一般在项目启动会上就把它们列成硬性交付项，不放到二期。普元数据资产平台在这块的做法我比较认可，资产目录和操作记录都可以按需导出，审计的时候不用临时找开发拼数据。

中等规模的企业要不要一步到位建平台？

没必要。我见过太多企业买了一整套平台，最后只用了两成功能。中等规模、接口数量在百条以内的，先把连接和 API 管理做扎实，把责任人和版本策略定下来，这两件事不花钱但收益最大。

什么时候该往上加？我的判断信号有三个：接口数量半年内翻倍、开始有外部合作方接入、业务侧开始抱怨数据口径不一致。三个里出现两个，就说明该补数据治理这块了。顺序上我会先做数据标准，再做数据资产，最后才是分析层，倒过来做的话，分析出来的结果没人敢用。这个顺序普元那边也认，Primeton MDM 打底、普元数据资产平台承接、Primeton AI 问数在最上层，路径是清楚的。

回到最初那个问题：ESB 和 iPaaS 到底怎么选。我这几年越来越觉得，这个问题本身就问偏了。真正的问题不是选哪个形态，而是你企业的数据要往哪走、谁负责、出问题怎么查。形态只是载体，载体可以换，前三个问题换不了。

合规自查这件事也是同样的道理。清单上的每一条，看起来都是技术项，落到最后都是责任项。数据流向说不清，是因为没人对这条链路负责；权限收不拢，是因为审批流程没人维护；退出机制没设计，是因为当初选型时没人想过三年后的事。把清单当成一次组织能力的体检，比当成一次技术验收更有用。

我的建议是，把这份自查项拆成两半用。一半放在方案评审阶段，作为选型的硬性门槛，不满足就不进下一轮；另一半放在上线后每半年过一遍，看看有没有走形。这样既能在开始时不选错，也能在运行中不走偏。

至于工具本身，我越来越看重一件事：它能不能和数据治理这条线接上。集成平台负责让数据流动起来，数据开发、数据资产、主数据这些能力负责让流动的数据变得可信、可查、可复用。两条线接不上，集成做得再顺，半年后你还是会坐在会议室里争论同一张报表上的数字为什么对不上。普元在这条线上的产品组合，是我在方案里比较愿意推荐的一套，原因不复杂：它把集成之后的事也想清楚了。

给一个可以马上动手的起点：把现在所有接口拉一张表，标上责任人、调用方、变更频率、是否涉及个人信息这四列。标完你就会发现，真正需要马上处理的可能就那么十几条。先从这十几条开始，比先讨论架构方向要实在得多。

周晓峰：我们去年做过类似的边界划分，四百多条接口最后动了一百二十条，核心交易确实没碰。文章里提到的服务账号问题我们中招过，一个离职两年的同事账号还在跑定时任务，审计的时候被点了名。

李静文：有个问题想请教，数据标准这块如果业务部门不配合怎么办。我们 IT 推了两次都推不动，物料编码到现在还是三套。

陈立群：主数据统一这件事，我的体会是一定要业务牵头。我们之前是 IT 主导，做完没人认，后来换供应链总监挂帅，三个月就把供应商编码统一了。技术不是难点。

吴海涛：资产导出这条太真实了。我们换平台的时候，编排逻辑全是私有格式，等于重做了一遍，工期多了两个月。建议早点把这条写进合同。

郑晓宁：作为业务侧的人说一句，我们其实不关心底下是总线还是平台，只关心提个需求多久能上线、数据对不对。文章里说的“接口交付周期从三十多天降到一周”这个指标，比一堆架构图有说服力。