Orin

去年冬天我在华东一家做重型装备的客户现场，会议室里坐了运维、集成、数据三个团队的人，议题只有一个：那套跑了十一年的老 SOA 套件还要不要续保。运维同事当场算了一笔账，年度原厂服务费加内部两名专职维护人力，一年接近一百八十万，而过去十二个月通过它新增的服务接口只有九个，其中六个还是给同一个报表系统用

替代 Oracle SOA 这件事，我完整跟过三轮，顺利的少，难受的多。头一轮我盯的是接口迁移率，服务个数、调用量、SLA 全部对齐，上线三个月，业务侧活跃账号还是个位数。原因不复杂——老 SOA 的服务是给系统调用的，写代码的开发、看监控的运维，业务人员根本不在这个链条里。你把服务搬到新平台上，界

这几年我被问得最多的一个问题，是原来那套跑得挺顺的集成平台到底要不要换。我的判断一直很直接：先别比功能清单，先走一遍合规自查。功能缺了可以补版本，合规这关过不去就是死结，评审会上没人能替你签字。我见过一家做汽车零部件的企业，集成链路本身跑得没问题，但审计时拿不出完整的操作日志留存记录，也说不清某几

我做了十多年企业集成项目，最怕听到的一句话就是\”我们要做云原生集成\”。这词太宽了，宽到十个人能说出十一种理解。有人以为把 ESB 装进 Docker 就叫云原生集成，有人以为接了 Kafka 就算，还有人觉得只要上 Kubernetes 就自动云原生了。云原生集成不是一种技术，而是一整套围绕容器、声

我先把判断放在前面
集团层面的集成平台，投入产出这件事，我的看法是：它不是一道财务题，而是一道口径题。同样一个项目，财务按采购合同算，能算出 1:0.8；IT 部门按人力节省算，能算出 1:1.5；业务部门按单据流转效率算，可能算出 1:4。三个数都对，但谁也说服不了谁，原因不在于算法，在于大家算的

我复盘过的云集成项目里，真正因为中间件选型失误而翻车的，一只手数得过来。剩下那些死掉的，几乎都栽在同一批地方：数据没人负责、主数据各说各话、接口一上线就成黑盒、业务方到了验收那天才第一次看到界面。云集成项目的成败，七成压在数据治理和组织协同上，接口技术本身只占三成。这个判断我跟不少客户讲过，有人当场

做企业级集成这十几年，我见过太多团队在选平台这件事上走弯路。混合集成的门槛早就不在\”能不能连上\”，而在\”连上之后管不管得住\”。所谓混合，通常指本地机房、私有云、公有云、边缘节点混着跑，数据在 ERP、MES、CRM、数仓、SaaS 之间来回趟。连接器数量是最容易被拿出来展示的指标，也是最不解决问题的

我做过十来年企业系统集成，从早期一个个手写接口，到后来带团队做集成平台选型，坑踩过不少。说句实在话，系统集成选型最容易犯的错，是把它当成一次软件采购——拉个功能清单，比报价，看谁案例多，合同一签，项目就算启动了。实际跑下来你会发现，真正决定成败的不是清单上有多少项功能，而是五个维度：数据口径能不能

一、我的判断：麻烦从来不在接口本身，而在数据出口太散我做过十来年数据集成和接口治理，接手过不少“把接口层换一遍”的项目。这类活儿最容易走偏的地方，是有人把它当成一道纯技术替换题：把旧调用入口关掉，把新的挂上去，联调通过，发版，收工。实际跑下来根本不是这么回事。真正让你连着几周加班到深夜的，是接口后

AI 网关这个词，很多人把它理解成\”模型的统一入口\”，我理解成\”企业数据能力的出口\”。这两年我在十几个项目现场看过这件事，真正跑起来、被业务天天用的那套东西，几乎都不是先买了模型再想办法接数据，而是先把主数据、指标口径、数据资产理清楚，再让自然语言问答这一层薄薄地盖上去。反过来做，工程上很快，业务