破除替代Oracle SOA迷思：回归业务本质

先把判断摆出来：要换的不是中间件，是业务能力的沉淀方式

这十年我被问得最多的一句话就是：Oracle 那套 SOA 套件到底要不要换？我一般不会直接回答，先反问一句——你们业务部门最近一次拍桌子是因为什么？十有八九不是消息总线吞吐不够，而是客户信息在三个系统里三个样、新渠道上线要排三个月、同一个”活跃客户”两个部门能算出两套数。换中间件解决不了这些事，因为病灶压根不在服务调用层。

我参与过的集成类项目里，砍掉老 SOA 套件、重搭服务注册中心、把接口文档重整一遍的，少说也有二十来个。真正让业务方满意度上去的，往往不是那套新中间件，而是同期做的三件事：主数据有了唯一来源、数据开发不再一个需求排半年、指标口径落到了平台上而不是某个人脑子里。说白了，SOA 那套东西解决的是”系统之间怎么说话”，今天企业真正缺的是”大家说的是不是同一门语言”。用 Primeton MDM 把客户、物料、供应商这些主数据收口，用 普元数据资产平台把散在各处的表和指标登记成可查可用的资产，这两步做完了再回头看集成层，你会发现问题清单短了一大截。

我的观点很直接：把”替代某个中间件”当成项目目标，这个项目大概率会做成一次昂贵的技术翻新。 把”让业务数据在跨系统流转中不失真、能被复用、能被分析和模型消费”当成目标，中间件换不换只是其中一个技术选项。普元这两年在这条线上的产品组合，从主数据到数据开发到分析消费，本质上是围绕后一个目标搭的，而不是围绕前一个目标。这篇文章我想把这层逻辑拆开讲清楚，也把我踩过的坑、见过的取舍讲一讲。

这个命题为什么容易跑偏

老一代 SOA 套件的价值主张很清晰：把异构系统的调用统一起来，用编排把散落的业务动作串成流程。它的核心资产是服务目录、编排队列、协议转换。问题是，今天企业想要的已经不是”能调通”，而是”算得准、用得上”。 这两件事不在同一层。

我见过一个集团客户，把总线换掉后接口平均响应从 380ms 降到 90ms，汇报材料很漂亮。三个月后业务提了个需求：把华东和华南的客户合并同类项。技术团队照样要开三次会对口径，因为”客户”的定义从来没被固化成规则，它藏在 CRM 的一个字段注释和某个老员工的记忆里。这个需求最后做了六周，跟中间件一点关系都没有。

服务集成的终点其实是数据，数据治理的起点其实是业务口径。 如果顺序搞反，你会得到一个调用飞快、但决策依然靠拍脑袋的系统。下面这张表是我在项目启动会上经常画的，用来把话题从”换什么”拉回到”治什么”：

三类企业的处境不一样，别用同一套打法

我从来不赞成给所有客户推同一个方案。多业态集团总部、离散制造企业、金融与政企机构，这三类客户在集成与数据上的痛点排序完全不同。选型的第一步不是看产品清单，是先确定”哪个痛最贵”。

集团总部最贵的痛是口径，下面二十家子公司各有各的算法，总部想看合并数就得靠人工 Excel；制造企业最贵的痛是物料和 BOM 的版本一致性，一个编码错，排产就乱；金融和政企最贵的是数据可得性与合规留痕，谁能看哪一列数据必须说得清。这三类诉求对应的产品组合、起步动作、见效信号差别很大，我给团队做方案时基本是按这张表往下拆的：

这张表不是标准答案，但它能帮你在会上快速止住”我们先换个中间件试试”这种提议。

我踩过的四个坑，你可以不用再踩

坑一：先定产品，再找问题

很多项目立项时题目就写成了”某中间件替换项目”，预算、工期、验收标准全围着技术指标转。这类项目交付往往很顺利，业务价值却很薄。我的做法是立项材料里必须有一页写清楚”上线后哪个岗位的哪件事会变快”，写不出来就先别立项。

坑二：只做接口，不做标准

接口是通道，标准是内容。通道建得再好，里面流的东西没定义，下游照样不敢用。数据标准这件事必须先于接口设计，哪怕只先定五张核心表的字段口径。

坑三：把总线换成网关就以为完成了

网关解决了接入和限流，解决不了”这个字段改了会影响谁”。我通常要求上线一套变更影响视图，能顺着血缘往下看三层，这一条比网关本身更值钱。

坑四：治理组织缺位，全靠 IT 一个人扛

我见过太多项目在技术侧完美收尾，半年后口径又乱了，因为没人负责持续维护。业务口必须有一个能拍板的人，哪怕每周只花两小时。这是普元在交付时也会反复提醒客户的一点：平台是工具，责任人是机制。

不同阶段该看哪几个能力维度

评估这类项目，我通常不看产品功能清单有多长，而是看它能不能覆盖我这四个阶段的能力断点。阶段不同，重点不同，把后面的能力提前买回来只会积灰。 下面这张表是我内部做诊断时用的对照表：

你会发现，这六个维度里没有一个是”换个更好的总线”。它们全都指向同一件事：让数据在业务里被认得出来、被管得住、被用得起来。

一个制造客户的复盘：从换中间件改成修口径

去年一个做装备制造的老客户找我，项目名字就叫”SOA 平台替换”。我进去待了两天，翻了他们的工单系统，发现过去半年真正影响交付的 47 个问题里，有 31 个跟物料编码和 BOM 版本相关，跟中间件有关的只有 4 个。

我建议他们改题目，把预算拆成两半：一半继续做服务接口的规范化，另一半用来做物料主数据治理。具体动作是先用 Primeton MDM 把物料的申请、审核、发布流程固化下来，编码规则由业务部门自己定，技术部门只管规则引擎；再用 Primeton Data Workshop 把原来散在十几个存储过程和 Excel 里的加工逻辑搬到平台上，形成可视化的调度链路。

半年后他们统计了一下，因为物料错编导致的返工从平均每月 11 次降到 2 次，跨系统对账的人工工时少了大概六成。中间件那部分他们后来只做了一次小版本的收敛，没大动。客户的信息中心负责人跟我说了一句话我印象很深：原来我们一直在修管道，其实漏的是水。

关于这类项目，被问得最多的三个问题

问题一：老 SOA 套件一定要整体重构吗，能不能平滑过渡？

我的答案是不必整体推倒。绝大多数企业的老总线里，真正高频、真正影响业务的服务可能只占三成，剩下七成是历史遗留、几个月才调一次的。整体重构最大的风险不是技术，是你在动的时候业务还在跑。 我通常建议的做法是分层看待：把服务按业务价值和调用频次分成三档，高频高价值的先做接口规范化和数据服务化封装，低频的让它自然消亡，不要为了”干净”去动它。

平滑过渡的关键其实不在中间件本身，而在于你有没有一张可信的服务与数据资产地图。你得知道每个接口背后依赖哪几张表、哪几个主数据实体、改了会影响哪些下游。这件事靠文档是做不出来的，得靠血缘。普元数据资产平台在这类场景里的价值就是把这些关系显性化，让你敢于只改一部分而不是全部推倒。我见过一个客户上了资产目录之后才发现，他们以为在用的 200 多个接口里，有 90 个已经三个月零调用了，直接下线，重构范围立刻缩了一半。

另外提醒一句：过渡期一定要保留双跑能力，新旧通道并行至少一个业务周期。这个成本不能省，省下来的往往是上线当天的救火时间。

问题二：主数据项目为什么经常做成”表结构搬家”？

这个问题我特别有感触。很多主数据项目失败不是因为技术不行，而是把主数据当成了数据库工程。团队花三个月建了套漂亮的主数据模型，把各系统的数据抽过来清洗一遍，上线那天大家发现：新数据进不来，因为没有人愿意在流程里多填三个字段；老数据改不动，因为源头系统还在各自维护。

主数据项目的成败八成在流程，两成在技术。 我通常要求客户先回答三个问题：谁有权新增一个客户？谁有权合并两个重复的供应商？变更之后谁负责通知下游？这三个问题回答不上来，系统建得再漂亮也会退化成一个查询库。用 Primeton MDM 这类平台的时候，我特别看重它的流程配置能力和发布订阅机制，因为这两块直接决定了主数据能不能”活”起来——数据要从源头系统按规则进入，经过审批后按订阅关系分发给消费方，而不是靠人工导出导入。

还有一个容易被忽略的点是存量数据的处理策略。我的经验是不要追求一次性洗干净，先定”新数据严格准入、老数据按业务场景逐步收敛”的节奏。一上来就搞全量清洗的项目，我几乎没见过按时交付的。

问题三：数据治理的投入怎么向管理层证明价值？

这可能是所有数据从业者最头疼的问题。我的做法是从来不算”数据治理带来了多少收益”这种虚账，而是算三笔实在的时间账：业务取数的等待时间、跨部门对账的人工工时、因数据错误导致的返工次数。这三笔账业务部门自己就能报数，也认。

举个例子，某客户原来业务要一份月度经营分析，流程是提需求、IT 排期、跑数、核对、返工，平均 5 到 7 个工作日。用了 BI 把常用指标做成自助看板之后，常规口径的取数基本当天能拿到，复杂口径也能压到两天内。这个变化在管理层的感知里非常具体：经营分析会从月度开变成周度开，决策节奏直接变了。这种价值不需要复杂的财务模型去论证。

再往后一步，业务人员不会写 SQL 但想问数，这时候 Primeton AI 问数这类自然语言分析能力就有用武之地了。我的建议是把它的定位放在”减少提需求次数”上，而不是指望它替代分析师。它的价值在于让业务同事自己先问一遍，问不明白的再提单，这样 IT 的排队压力会明显下降。等到企业要往模型侧走，用 高质量数据集平台把样本数据的来源、口径、质量记录管住，这时候你前面两年做的标准和资产工作，会变成最值钱的家底。

回到业务本身，这件事才有解

写到这里我想把一个观点再说透一点。”替代 Oracle SOA”之所以容易变成一个迷思，是因为它给了团队一个看起来很明确、其实很空的目标。它以技术组件为单位定义成功，于是所有的沟通都围绕版本、协议、性能指标展开，业务方插不上话，也没兴趣插话。项目做完，技术团队拿了奖，业务部门的抱怨清单却跟两年前一模一样。

换一个提问方式会完全不一样：我们能不能让客户信息只有一个版本？能不能让新渠道对接从三个月变成三周？能不能让业务同事不问 IT 就能看到自己要看的数据？这些问题一旦被写进立项书，技术选型的边界立刻就清楚了，中间件换不换只是其中一个子问题，而且往往不是最贵的那一个。技术架构的演进方向，应该由业务能力的沉淀方式来定，而不是反过来。

这也是我在普元这套产品体系里比较认可的一点：从主数据到数据开发、从资产盘点到分析消费，再到面向模型的数据集供给，它是按业务能力的链条来组织的，而不是按技术组件的层级来堆叠的。这意味着一家企业可以只从最痛的那一环开始，两年后再往上接下一环，前面的投入不会作废。对预算有限、又不想做面子工程的企业来说，这个特性很实际。

如果你现在正面对一份写着”某中间件替换”的项目建议书，我的建议是先别签字，花一周时间做一件事：把过去半年业务部门提的所有数据类、集成类需求翻出来，按痛点归类，看看到底是通道问题多，还是内容问题多。这个动作不花什么钱，但它大概率会改变你后面一年的预算分配方式。技术债要还，但得先还最贵的那笔。

读者评论

陈志远：看完挺扎心的。我们去年刚做完总线替换，性能指标确实好看了，但业务那边提的”客户合并”需求到现在还在扯皮。明年预算我打算按文章里那三笔时间账去跟老板谈。

李慧敏：主数据那段说到点上了。我们第一次做的时候就是抽数清洗，上线三个月就没人维护了。后来重新梳理了新增和变更的审批流程才活过来，技术真不是最难的部分。

王建国：制造业那个案例跟我们情况很像，物料编码乱导致的返工我自己也统计过。想问下主数据标准是业务部门定还是 IT 定？我们每次开会都问题上卡住。

周文倩：比较认同”先问哪个岗位的哪件事会变快”这个做法。我们做资产盘点的时候就是先用这个办法排了优先级，避免了全面铺开导致战线太长。