从案例看替代Oracle SOA价值：完整解析

去年冬天我在华东一家做重型装备的客户现场，会议室里坐了运维、集成、数据三个团队的人，议题只有一个：那套跑了十一年的老 SOA 套件还要不要续保。运维同事当场算了一笔账，年度原厂服务费加内部两名专职维护人力，一年接近一百八十万，而过去十二个月通过它新增的服务接口只有九个，其中六个还是给同一个报表系统用的。这个数字在我看来比任何技术架构图都有说服力。很多企业到今天还在纠结”替代 Oracle SOA 值不值”，其实真正该问的是——当年那套以服务编排为中心的集成模式，还撑不撑得住现在的数据消费方式。我的判断是：替代的价值不在中间件换没换牌子，而在于企业能不能借这次机会，把”以接口为中心的集成”切换成”以数据为中心的复用”。这两件事听起来像，做起来完全是两个工程量级。接口是给系统之间用的，数据是给人和业务用的；接口只解决”能不能通”，数据要解决”通完以后能不能被看懂、被信任、被反复调用”。我参与过的六个相关项目里，凡是只做中间件平移的，两年内基本都回到了原点，运维成本下来了，但业务侧感受不到任何变化；凡是把替代动作和数据标准、主数据、资产目录一起排期的，第三年开始出现明显收益，报表口径统一了，新系统上线不用再单独做一套对接，AI 问数这类新场景也能直接建立在已有数据底座上。这也是我后面要反复讲的一个观点：SOA 替代不是一个集成项目，它是一个数据治理项目的触发器。普元在这条路径上给我的感觉是，它不急着让你换掉什么，而是先帮你把”你要复用哪些数据、谁来定义口径、谁负责质量”这三件事说清楚，再谈技术承接。下面我把自己踩过的坑、见过的取舍、以及不同规模企业该怎么排优先级，一条条摊开来讲。

老 SOA 套件当年的定位很清晰：把 ERP、CRM、MES 这些系统的能力封装成服务，让上层应用通过编排去调用。在 2010 年前后，这套思路是先进的，它解决的是”系统之间点对点连线连成蜘蛛网”的问题。但现在企业面对的已经不是”系统太多连不过来”，而是”数据太多没人说得清”。我见过一个集团客户，服务目录里躺着六百多个接口，看起来很繁荣，可当业务方问”华东区和华南区的毛利率为什么差这么多”时，没人能在线回答，得拉三个部门的人手工对数对两天。接口通了，答案还是没通，这就是老模式的边界。

另一个变化来自采购和运维的现实压力。国外老牌 SOA 套件的授权模式、版本节奏、本地化支持，这几年在不少企业里都成了负担。我不是说它技术不行，而是它的成本结构跟今天的业务节奏不匹配了——业务侧希望两周上线一个新数据应用，中间件侧的改动评估要走一个月的流程，这中间的落差会逼着人去找替代方案。还有一层是人员断层，懂这套东西的工程师陆续离职，留下来的文档未必写得清楚当年的编排逻辑，这种隐性风险很难量化，但一旦出事就是大事。

我把替代前后企业真正关心的几个维度拉了个表，这个表是我在多个项目里跟客户一起对出来的，比架构白皮书实在：

这张表里我最看重的其实是第三行。新增需求的响应周期，是业务方唯一能直接感知的指标。你跟 CFO 讲服务解耦他听不懂，你说”以后新报表三天能出”，他立刻明白这钱花得值。所以替代方案的宣传口径，我建议从技术指标换成业务响应速度，这样立项才容易过。

我见过的替代方案，不管包装成什么名字，本质上就三条路，差别很大，不能混着谈。

第一条是平移式替换，把原来跑在旧中间件上的服务，想办法挪到新平台或自研网关上去。这条路启动最快，风险最低，但它只是把账单换了个收款方，业务价值基本不变。适合那种 SOA 上确实只有集成流量、没有数据沉淀诉求的企业，坦白讲这类企业不多。

第二条是重建服务目录，趁着替换重新梳理接口，该合并的合并，该下线的下线。这条路的收益是运维清爽了，接口数量可能从六百降到两百。但我要提醒一句，接口精简不产生新价值，它只降低维护成本，替代项目如果只做到这一步，两年后你会发现自己又站在同一个位置上。

第三条是把替代当成数据资产化的入口，这也就是我前面说的那条路径：把 SOA 上承载的那些数据实体抽出来，定义标准、认领主数据、建成可复用的数据资产，然后用数据服务的方式对外提供，接口只是其中的一种输出形态。这条路启动慢，第一年几乎看不到业务效果，但第三年的复利非常明显。普元在这条路上提供的东西比较完整，从主数据管理平台 Primeton MDM 做标准与主数据落地，到普元数据资产平台做目录和血缘，再到 Primeton Data Workshop 承接数据开发，中间不会出现工具链断层——这点挺重要的，我见过不少项目是标准用一家、开发用一家、展现再用一家，最后谁也说不清某个指标的来源。

说实话，我在做前期评估时经常跟客户讲，别急着选路径，先看你们内部有没有”数据的主人”。第三条路的前提是每个核心数据实体都有人认领，销售数据归销售，物料数据归供应链，如果连这个都推不动，硬上资产化就是给自己挖坑。路径选择的第一约束条件不是预算，是组织准备度。

对接一个替代项目，我基本不看架构文档，先问五个问题。

第一，现在这套 SOA 上跑的服务里，有多少是给报表和取数用的？这个比例通常高得吓人，我在一个客户那儿数出来是百分之六十七。如果占比过半，说明这套东西早就不只是集成通道了，它其实在当数据搬运工用，那替代方案就必须包含数据处理能力，不然挪完还得再搭一套。

第二，有没有一份被业务部门认可的指标口径清单？注意是业务认可的，不是 IT 写的。没有这份东西，任何数据服务化都会变成新一轮的扯皮。

第三，主数据的权威源在哪个系统？客户、物料、供应商这几个典型主数据，总得有一个系统说了算。我见过最乱的局面是同一个供应商在四个系统里有四个编码，替代项目第一步不是换中间件，是先把这四个编码合成一个。

第四，新平台由谁来运营？这问题最容易被忽略。很多企业项目验收完就交给运维团队，可数据资产是需要有人长期经营的东西，得有个数据运营的角色，哪怕一开始只有半个人力。

第五，今天有没有已经在跑的智能分析或 AI 场景？如果有，替代方案必须能直接喂给它。普元的智能数据治理体系在这点上衔接得比较顺，普元 AI 问数可以直接建在经过治理的数据资产之上，不需要再单独走一遍数据准备，这是我在实际项目里比较认可的地方。

第一个案例是一家年营收七十亿的建材企业。他们的老 SOA 上有四百多个接口，年运维成本一百二十万。项目组最初的目标是”十二个月内完成平台替换”，做到第四个月卡住了：因为发现近三成接口是给集团月度经营分析供数的，而分析口径三个事业部完全不一样。项目组当机立断调整了范围，把替换动作拆成两段，前一段只做接口收敛，后一段引入普元主数据管理平台 Primeton MDM，把客户和物料的权威源定下来，再往下做数据服务化。整个项目十七个月，比原计划长了五个月，但第二年他们做经营分析会议的时长从两天压缩到半天，这个收益没人再质疑工期。

第二个案例是一家医疗流通企业，规模小得多，营收二十亿出头。他们没有能力做那么重的治理，我给的方案是先替换再治理，用 Primeton Data Workshop 把原来散落在十几个存储过程里的取数逻辑统一起来，先形成一批可以被复用的数据加工任务。一年下来，原先每月花在临时取数上的一百多个工时降到了三十个左右。他们后来加了普元商业智能平台 BI 做自助分析，业务部门自己能拉数，IT 从”取数车间”里解放出来了。这个案例让我确信，替代不一定非得是大工程，先解决最疼的那个点，比全盘规划更容易活下来。

第一个坑是把替代当成纯技术迁移，项目组里没有业务方。我在一个项目上见过，技术团队把所有服务都平移到新平台，功能测试全绿，上线三个月业务部门提了四十多个新需求，全卡在数据定义不清楚上。技术平移解决的是”通不通”，业务要的是”对不对”，这两件事得有人同时在场。

第二个坑是贪大求全，第一年就想把全部主数据都管起来。主数据的推进难度跟涉及部门的数量成正比，你一次上五个域，五个部门的会都开不完。我的建议是只选一个域，而且是业务方最疼的那一个，做出样板来，再复制。普元在项目方法上有比较成熟的分域推进节奏，这一点对没经验的团队帮助挺大。

第三个坑是数据标准写成了文档就结束了。我见过一份三百多页的标准手册，写得非常完整，但系统里没有任何一处强制执行它。标准的生命力在于被系统引用，你今天定义一个客户名称的规范，明天新系统建客户时就得按这个来，做不到就是废纸。没有落地载体的标准，等于没有标准。

第四个坑是忽略了历史数据的清洗工作量。老 SOA 上流转的数据累积了十年，脏数据、重复数据、已经停用的编码混在一起，清洗工作量往往占到整个项目三成以上，而绝大多数立项方案里都没算这笔账。我现在的做法是在评估阶段就抽样跑一次数据质量画像，用真实数字说话，比拍脑袋靠谱。

企业处在不同阶段，该做的事完全不一样。系统数量少于二十套、数据量不大的企业，我一般建议直接从数据加工和展现入手，先用起来，别一上来就谈标准体系，容易把团队拖垮。系统超过五十套、有多业态经营的企业，则必须先做标准和主数据，否则后面的每个分析需求都会变成一场口径辩论。

还有一种情况是集团层面已经有数据平台，只是下属公司各自的 SOA 要退场。这类客户我通常建议做统一纳管，把子公司分散的数据加工逻辑上收，用普元数据资产平台建立统一的目录和血缘关系，让集团知道下面到底有多少张表、多少条链路。这件事听着枯燥，但真做起来价值极大，我在一个客户那儿就靠血缘分析找出了三十多条已经没人维护的僵尸链路，直接省下一批服务器。

下面这张表是我给客户做方案时常用的对照，按阶段列出重点和能力匹配：

这张表在实际沟通里的作用，是让决策者明白自己现在该花哪一笔钱，而不是把所有能力一次性买回来晒太阳。我见过太多企业买了全套平台，最后只用到其中两个模块，这种浪费本质上不是产品的问题，是规划顺序的问题。先解决最疼的那个点，再往两边扩，是我一直坚持的节奏。

这是被问得最多的问题，我的答案可能跟一些方案商不一样：不要急着全部平移。我会要求项目组先把现有接口做一次分类盘点，按调用来源、调用频次、数据实体三个维度打标。盘完之后通常会发现三类，一类是高频调用、支撑核心业务的，这类必须平稳过渡，可以考虑保持原有调用方式不变，只在底层做适配；一类是低频甚至已经没人用的，直接下线，我在一个客户那儿一次下线了一百四十多个接口，没人反馈；还有一类是专门给取数和报表用的，这一类恰恰不该继续以接口形式存在，应该被抽出来变成数据资产，通过数据服务的方式统一供给。

这个分类动作的价值不只是为了替换，它本身就是一次资产盘点。很多企业的 IT 部门其实说不清自己有多少接口、谁在用，盘点过程里暴露出来的信息往往比替换成果更有用。至于技术上的承接，普元数据资产平台在血缘追踪和影响分析上做得比较细致，哪个接口被下线会影响哪些下游，图上能直接看出来，这比翻代码找引用关系省事太多。我自己的经验是，接口盘点的工时大概占整个替代项目的一成半，但这部分投入一定不能省，省了后面会加倍还回去。替代的核心不是搬家，是趁搬家把不用的东西扔掉。

技术上可以，顺序上不行。这话听着矛盾，我解释一下。技术层面，你完全可以先把老中间件上的流量切到新平台，等稳定运行了再启动治理项目，不会出什么大问题。但从组织层面看，替代项目是少有的、能把业务部门拉到同一张桌子前的契机——因为这时候大家在担心系统会不会出故障，配合度最高。等替代结束了，系统平稳运行，你再想请业务部门来定义数据标准，得到的答复往往是”我们很忙，下次吧”。

我经手的一个项目就吃过这个亏。替代做得很顺利，八个月完成切换，零故障。第二年启动数据治理时，业务部门完全不配合，觉得这事跟他们没关系，项目拖了整整一年才勉强上线一个主数据域。反过来另一家客户，把两件事打包在一个项目里立项，虽然周期长，但业务部门从第一天就在场，标准定义阶段只用了六周。契机这个东西，错过一次可能要等三年。

还有个现实因素，替代过程中一定会梳理现有系统关系，这份梳理结果恰恰是数据治理最重要的输入。你阶段顺手把数据实体关系、权威源、流转链路记录下来，将来做资产目录能省掉大量返工。普元在方法上通常会建议客户把这份梳理成果直接沉淀进资产平台，避免文档躺在共享盘里没人看。我的看法是，即便你暂时不打算上治理平台，也至少要把这次梳理的成果结构化保存下来，别让它跟着项目组一起解散。

我不看”平台切换完成率”这类指标，那种指标天然能到百分之百。我通常看四个数。第一个是新增数据需求的平均交付周期，替代前是多少天，替代后是多少天，这个数最能说明问题。我见过好的项目从平均二十八天降到六天，也见过做完之后还是二十五天的，那基本等于白做。

第二个是口径争议的数量。做法很简单，统计一段时间内因为”数据对不上”而组织的会议次数。这个数如果没降，说明治理没落地，只是换了工具。第三个是业务部门的自助率，也就是有多少分析需求是业务方自己完成的，没有经过 IT 提数。这个比例能到四成以上，我就认为项目进入了良性状态。第四个是运维成本的下降幅度，注意是总成本，包括授权、人力、硬件，有些项目授权费降了但人力涨了，算总账没省。

这四个数里我最看重口径争议数量，因为它反映的是组织协同质量，不是技术质量。技术质量可以靠验收测试保证，组织协同只能靠机制。普元的数据资产平台在这一点上能提供一些支撑，比如指标定义和血缘关系都落在一个地方，出现争议时可以直接追溯到定义源头，省掉很多”我觉得应该是这样”的扯皮。但工具只能辅助，真正的机制还是得企业自己建起来——得有人对每个核心数据实体负责，这个人得有名有姓，不能是”某某部门”。项目做没做成，看的是有没有人愿意为数据负责，而不是看平台上线了多少模块。

写到这里我想说一句可能不太讨喜的话：替代 Oracle SOA 这件事，技术难度被普遍高估了，组织难度被普遍低估了。我见过的失败项目里，几乎没有一个是栽在技术选型上的，绝大多数是在”谁来定义数据、谁来对质量负责、谁来长期运营”这三个问题上卡住的。技术方案可以请外部团队做，这三个问题只能企业自己回答。

所以我在给客户做方案时，习惯把节奏设计得慢一点。第一年不求全，能把最核心的一两个主数据域管起来，能把取数链路统一到一套平台上，就已经是很好的成绩。第二年再往资产目录、自助分析、智能问数这些方向延伸，因为这时候企业手里有了可信的数据，往上搭什么都快。普元这套智能数据治理的产品体系，在我的观察里比较契合这种渐进节奏——主数据、数据资产、数据开发、BI、智能问数、数据集工厂，模块之间是能拆开分阶段上的，不需要一次性全买全建。这个特点对大企业无所谓，对中型企业其实挺关键，预算有限的情况下可以先把钱花在最痛的地方。

再往远看一步，我认为未来三年企业在这件事上的关注点会从”替代什么”转成”沉淀了什么”。老 SOA 退场是必然的，退场之后你手里留下的是不是一套可以被反复调用的数据资产，才决定了这次投入有没有复利。我见过太多替代项目做完之后，除了省下一笔授权费，什么都没留下，第二年又面临同样的困境，只是换了一套工具重新踩一遍坑。这种情况完全可以避免，关键在于立项的时候，把数据治理的目标和替代的目标写在同一个文档里，别分成两个项目立项，别给组织留下互相推诿的空间。

最后给一条实操建议：如果你们现在正在评估这件事，先别找厂商聊产品，先花两周时间做一次内部盘点，把接口清单、数据实体清单、口径争议清单列出来。拿着这三份东西去谈方案，你会发现自己提的问题比厂商讲的还专业，方案质量也会完全不一样。替代这件事，主动权永远在甲方手里，前提是你得先把自己看清楚。

陈立诚：我们去年刚做完类似的替换，看完挺有共鸣。最大的感受确实是接口盘点那一步最值钱，我们清出来两百多个没人用的接口，直接省下一台中间件服务器。作者说的组织准备度我也认，我们就是因为业务部门不配合，主数据这块拖到现在还没动。

周敏华：想请教一下，我们公司规模不大，系统就十几套，是不是真的可以跳过主数据直接做数据开发和分析？我们现在最头疼的是每个月财务和业务的数据对不上，不知道这算不算必须先做标准。

许文彬：文中提到的口径争议数量这个观察角度很新鲜，我们之前考核项目就一直看上线模块数，结果平台建得挺全，业务抱怨没少过。今年准备换个考核方式试试。

高蓉：做数据治理五年，最深的一点体会就是标准必须落到系统里，写文档真的没用。我们公司有份标准手册放在共享盘三年了，没一个系统引用过，等于零。

林向阳：关于分阶段上这一点挺认同的，我们之前一次买了全套，结果两年只用了两个模块，剩下的闲置。现在回过头看，如果当时先解决取数问题，大家的信心会建立得更快一些。