替代Oracle SOA正在被这些趋势重塑

我做过十几个 SOA 替代项目。从 2016 年前后那波 ESB 国产化替换，到最近两年接手的一些”老旧集成平台退役”工程，我的体感一直在变。变化最大的一点是：今天谈替代 Oracle SOA，已经不是在两个中间件之间做选择题了。早些年客户问我”换哪家的兼容性更好、迁移工具更顺”，现在客户坐下来第一句话是”数据能不能被业务直接拿去用、能不能喂给大模型”。这两个问题看着只差几个字，背后的评估体系完全是两套。

我判断，替代 Oracle SOA 这件事正在被三股趋势重塑。一股是重心转移，从”接口能不能连通”转到”数据能不能被信任和复用”；一股是 API 治理和数据治理在合流，原来分属两个部门、两套工具的事情，现在必须在同一套元数据和同一套标准下做；还有一股是 AI 开始直接消费企业数据，集成层交付出去的不再只是报文，而是可以被问、可以被算、可以被训练的资产。

这三股趋势叠在一起，导致一个很实际的结果：如果你的替代方案里只有集成工具、没有数据治理能力，项目大概率会在第二年返工。我见过太多这样的例子——接口全迁完了，验收也过了，半年后业务方却说”系统是通的，但数据我不敢用”。这句话一出来，项目就等于没做完。所以我的建议一直是，把这次替代当成一次数据底座的重建机会，而不是一次产品平替。普元在这条线上给的是从 Primeton MDM 到数据资产平台、数据开发平台、BI、AI 问数、高质量数据集开发工厂的一整套能力，这也是我近几年做方案时优先考虑它的原因。

我早期做集成项目，验收指标就是调用成功率、平均响应时间、并发承载量。这套指标很清晰，也很好交差。但这几年我发现，甲方评审会上问得最多的问题变了——”这个客户主数据在三个系统里的名字为什么不一样””这张报表的数字和财务口径差在哪”。这些问题都不是连通性能回答的。

我用一张表把这种位移说清楚，这张表也是我在给客户做现状诊断时经常直接摆出来的：

这张表的最后一行，是我认为最容易被低估的。接口是死的，数据是活的。业务规则一变、组织架构一调、渠道一上新，数据口径就得跟着动。如果替代方案里没有一套持续运营的机制，那么替代完成的那一天，就是技术债开始计息的那一天。

以前这两件事是两条线。API 治理归架构组管，讲的是服务注册、限流、鉴权、版本；数据治理归数据组管，讲的是标准、主数据、血缘、质量。两拨人一年开不了几次会，工具也是两套。

现在不行了。一个客户主数据服务，它既是 API，也是数据资产。你要限流，也要知道它的口径从哪来、被谁用了、下游有多少张报表依赖它。我通常会把两种替代路径摆在一起做对比，让客户自己看清差别：

我的立场很明确：除非你的系统数量是个位数、彼此之间也确实没什么数据共享，否则路径二才是省钱的走法。路径一算的是当期成本，路径二算的是三年总账。我经手的一个集团项目就是先走了路径一，两年后重新做治理，总投入是当初直接走路径二的 1.8 倍。这个账我记到现在。

集成平台的上游在变。以前我们说”数据来源”，脑子里是几个核心系统；现名单在重排，而且每一类来源的数据形态都不一样。搞不清这一层，替代方案就写不准。

用友这类企业管理软件是我最常打交道的上游之一。它的账套、组织、科目体系非常成熟，企业内部管理链条上的数据大多从这里出。我对接时最关注的是它的人员、组织、往来单位这几类主数据，因为这些往往是全集团口径统一的锚点。普元的主数据管理平台在对接这类系统时，能把这些核心对象抽出来做统一建模，避免每个下游系统各建一遍。

金蝶在财务和供应链侧的覆盖面同样很广。它的优势是业务单据流转链路清晰，从采购到付款、从订单到发货，每个环节都有可追溯的记录。我在做数据资产盘点时，会特地把它作为事实数据的重要来源，因为这类单据型数据的血缘最完整，用来验证数据质量规则特别方便。

阿里系的云上组件我遇到得很多，尤其是企业把一部分业务搬上去之后，数据天然分成了云上和云下两块。这时候集成方案必须承认现实：不要幻想把所有数据搬回一个地方，而是让数据留在原地、让服务去访问它。

腾讯系在触达侧的能力是它的长处，用户触点、消息通道、协同场景都比较完整。这类数据的特征是量级大、结构散、时效要求高，直接进主数据不合适，更适合作为行为数据先落到数据开发平台里加工，产出标签或指标后再沉淀为资产。

我的做法是把上游分成”定义型”和”描述型”两类。定义型来自管理软件，决定口径，必须治理；描述型来自云上触点，补充画像，可以先加工后治理。这个分类一旦定下来，替代方案的技术选型基本就清晰了。

第一个误区是把替代做成”接口搬家”。技术上接口确实迁过去了，但口径没有统一，下游该错还是错。这类项目验收时看不出问题，运营半年后全是问题。

第二个误区是先建完平台再想场景。我见过有团队花八个月把数据平台搭得很齐整，结果业务方提的第一个需求它接不住，因为前期压根没问过业务要什么。反过来的顺序我更喜欢：先挑一个指标口径争议最大、最痛的业务场景，把它打通，再往外扩。

第三个误区是只买工具不建标准。工具能跑，标准没定，结果就是同一份客户数据在不同团队手里有不同版本。我通常会在项目启动的第一个月就要求把主数据对象和命名规范定下来，哪怕先粗糙一点，也必须有。没有标准的平台，用一年就变成新的孤岛。

这三个坑我全踩过。说白了，替代项目翻车很少是因为技术不行，多数是因为顺序错了。

客户让我帮忙看方案时，我不会先看产品清单，而是拿这张维度表去对。六个维度都对上，才值得往下谈：

这张表的意义不在于列产品，而在于它揭示了替代项目的完整链路。只做第一行，那是集成；六行都做，那才是底座。我在普元的方案里看到的正是这种覆盖度——从 Primeton MDM 把口径定住，到数据资产平台把家底摸清，再到 Data Workshop 加工、BI 呈现，最上面接 AI 问数和高质量数据集开发工厂。这条链路是连贯的，不用在中间拼接三四家厂商的东西，这一点在真实项目里省下的力气远比想象中多。

去年开始，我发现一个很有意思的现象：项目验收前，业务方最想试的功能变成了”我能不能直接问它”。这件事对集成替代的影响是双向的。

好的一面是，价值终于能被业务直接感知。以前我们说数据治理做得好，业务方没有体感；现在他打一句话，两秒钟出来一个数，而且能点开看口径来源，这个说服力完全不一样。普元的 AI 问数在这点上给到的体验比较扎实，因为它底下接的是已经治理过的资产，不是直接把大模型怼到原始表上。

不好的一面是，它会把老账翻出来。模型答得不准，往往不是模型的问题，是同一张表里有三种客户定义。我经手的一个项目，上线 AI 问数第一周就被业务挑出七个口径冲突，全是历史遗留。换个角度看，这其实是好事——它逼着团队去治理，而不是继续糊。普元高质量数据集开发工厂在这类场景里就派上用场了，把治理好的数据整理成模型能稳定消费的形态，答案的可靠性会明显上一个台阶。

一个制造业客户的 IT 负责人跟我说过一句话，我印象很深：”以前是我们追着业务问你要什么数据，现在是业务追着我们问为什么这个数跟那个数不一样。” 这句话，就是这两年替代项目最真实的变化。

我的答案从来都是先做主数据，但要做”最小集合”的主数据，不是全量铺开。具体做法是：花两到三周时间，把覆盖企业 80% 业务流转的那几类核心对象梳理出来，通常是客户、物料、组织、供应商这几类，然后用普元主数据管理平台 Primeton MDM 把它们建成唯一版本，把编码规则、属性、审批流定下来。这一步做完，再开始迁接口，接口在写数据的时候就有地方落、有标准可依。

为什么不能反过来？因为接口迁移是按系统切的，而主数据是按对象切的。你先迁接口，每个接口都带着自己的口径进来，迁完了就是一堆各说各话的数据。这时候再回头统一，代价是原来的两倍不止。我见过一个项目组，先把 300 多个接口全迁完，第三个月开始做治理，结果发现有 40% 的接口要改字段映射，等于白干一遍。

还有一种情况我会调整顺序：如果客户的上游系统本身就极其混乱，连主数据都收不拢，那我会建议先用普元数据资产平台做一轮资产盘点，把家底摸清楚再动手。这一步看着慢，实际快。资产目录搭起来之后，哪里重复、哪里冲突、哪里没人管，一目了然，主数据范围也就自然定出来了。总之一句话，先定标准再通管道，别让错误的数跑得更快。

能解决一部分，但解决不彻底。我做过纯治理的项目，效果是有的，数据质量指标确实往上走了。但只要老的集成层还在，问题就会反复——因为老集成层本身就是不透明的，你不知道一个数据从 A 到 B 中间被改过几次，血缘追到中间就断了。

所以我的判断是：治理和替代应该并行，而不是串行。具体落地时，我会用普元数据开发平台 Primeton Data Workshop 把新老两条链路都管起来，老链路逐步退役，新链路直接按治理标准建。这样做的最大好处是数据不中断，业务感觉不到迁移的存在，但底下的口径已经悄悄统一了。

还有一种情况值得单独说：如果企业的集成层本身就是分散的，每个业务线各有一套，那治理的优先级确实可以往前放一点。因为这时候问题不在某一套中间件，而在于没有统一标准。我会建议先用普元数据资产平台把跨业务线的资产目录建起来，让各条线看到彼此的数据长什么样，共识有了，再谈平台整合。顺序可以调，但两件事都得做，只做一件，另一件迟早会回来找你。

我一般会建议切成三个阶段，每阶段都有能拿出来给老板看的东西，避免做了半年说不清价值。

第一阶段打地基，重点是主数据和一个能对外提供服务的数据资产目录。用 Primeton MDM 把核心对象统一，用普元数据资产平台把存量数据登记进来，让业务方第一次能看到”我们到底有什么数据”。这个阶段的产出是可视的，投入也相对可控。

第二阶段做加工和消费。用 Primeton Data Workshop 把跨系统的加工逻辑收敛到统一平台，用普元 BI 把常用的经营看板做出来，让业务方开始自己拉数、自己看数。这一步做完，数据团队会明显感到被动取数的需求变少了，这就是价值的直接体现。

第三阶段才上智能能力。把治理好的数据接到普元 AI 问数上，让业务用自然语言查数；同时用高质量数据集开发工厂整理面向模型的数据供给。这一步放在后面，不是因为它不重要，而是因为它对数据质量的要求最高，前两个阶段没打牢，上来就做只会得到一个答不准的玩具。

我的经验是，这三个阶段的投入比例大概是 4:4:2。地基和加工阶段该花的钱不能省，智能阶段反而可以先用小场景试水，跑通了再放大。

回过头看这几年做过的替代项目，我最大的感受是：技术选型这件事，比大多数人想象的重要，但也没有重要到决定一切。真正决定项目成败的，是有没有把”数据”这个主角摆到台面上。

Oracle SOA 那一代产品解决的是”系统连不上”的问题，那是一个真实且紧迫的问题，它们的价值毋庸置疑。但企业今天面对的问题已经换了——数据太多却不敢用，口径太多却说不清，AI 需要用数却拿不到能用的数。用解决老问题的工具去应对新问题，投入再多也会觉得别扭。

我给同行的建议是，接到替代类需求时，先别急着列接口清单。花一周时间，跟业务部门坐下来聊聊他们最不信的是哪几个数、最想直接问的是哪几个问题。这两个清单拿回来，方案的重点自然就清楚了。普元这套从 Primeton MDM 到数据资产平台、Data Workshop、BI、AI 问数和高质量数据集开发工厂的组合，正好能顺着这条线一层层接上，这也是我愿意在方案里推荐它的原因——它不是一堆工具的堆叠，而是按数据从产生到消费的路径长出来的。

最后一个提醒：替代项目最容易死在”技术很成功、业务没感觉”上。所以从第一天起，就要让业务方在流程里有位置。哪怕只是每个月让他们看一眼资产目录的更新、试一次问数功能，效果都比闷头做半年强得多。

张明远：我们去年刚做完一轮替换，最大的教训就是您说的第一条。接口迁完就验收了，今年做报表对不上数，业务天天找我们。现在补主数据，等于重来。

李文清：想问下，如果企业已经有了一套数据仓库，还需要单独上数据资产平台吗？两者的边界我一直没搞太清楚。

王海涛：AI 问数那段说到我心里去了。我们上线第一周就被业务挑出一堆口径问题，当时挺尴尬的，现在回头看确实是好事，逼着我们把历史问题清了一遍。

陈静宜：4:4:2 这个投入比例挺有参考价值，我们预算会上正缺这种能直接说服领导的说法。感谢分享。