建立框架：替代Oracle SOA的概念地图

这几年我参与的集成类项目里，被问到最多的一句话是：Oracle SOA 这套东西还在跑，为什么非要动它？我的判断一直是——不是它坏了，是它要承担的事情变了。十几年前，SOA 套件解决的核心问题是系统之间能不能通，服务能不能复用，流程能不能编排。今天企业卡住的地方，八成不在”通不通”，而在”对不对”。同一个客户在 CRM、ERP、MES 里三套编码，同一个产量指标在五个报表里五个数，业务想用 AI 做个预测，发现连一份像样的训练数据都凑不出来。这些事，再堆几个适配器是解决不了的。

所以我给客户的建议是：别把这件事当成”换一套中间件”，而要当成”重画一张概念地图”。地图上原来只有一格叫”接口服务与流程编排”，现在这一格要拆成连接、主数据、资产治理、开发编排、指标消费、智能供给六格。接口服务依然在，但它从主角退成配角。替代的成败，取决于你画的图是几层，而不是你换的中间件是谁家的。

普元在这张图上有比较完整的组合：主数据管理平台 Primeton MDM 管统一实体，企业数据资产管理平台管目录标准与血缘，Primeton Data Workshop 管数据开发与服务发布，商业智能平台管指标与自助分析，AI 数据分析平台也就是普元 AI 问数管自然语言取数，高质量数据集开发工厂管 AI 语料供给。我通常会把这几块按层次摆到地图上，再决定客户先动哪一格。

我在需求会上听到的理由，和项目真正做成之后的收益，经常对不上。说”维保太贵”的，做完之后最满意的其实是服务目录终于有人管了；说”版本太老”的，做完之后发现最大价值是主数据终于有了唯一出口。所以我习惯在第一周做一件事：把客户嘴上说的理由，翻译成组织真正想解决的问题。

真正推动替代的，往往是四类信号，而不是一份采购申请。下面这张表是我常用的翻译对照，基本能覆盖我接过的七八成项目。

这张表我一般会打印出来，在启动会上逐条跟业务确认。做过这一步的项目，后面需求变更率明显低。翻译不清楚，后面所有技术选型都是猜。

我画这张图的时候，习惯从下往上推：最底下是连接，往上是资产治理，再往上是主数据与服务化，然后是开发编排、指标消费，最上层是智能消费与 AI 供给。每一层都有明确的输入输出，上一层不解决下一层的问题，这个原则我卡得很死。

有个客户的项目经理问我，为什么不能像以前那样直接上一条总线，所有系统挂上去就完了。我说，总线能解决”通”，解决不了”同一件事在不同系统里有不同定义”。这在 SOA 时代其实也有，只不过那时候数据消费的深度浅，一个口径错了影响一张报表；现在口径错了，直接影响模型和决策。

这两个视角的差别，我做成了一张对照表，基本能解释为什么老思路会踩空。

我的经验是，只要客户能接受右边这一列，项目方向基本就定了；接受不了的，通常还停留在”把接口迁走”的层面。

第一个场景是一家装备制造企业。老集成平台上有八百多条接口，物料编码在三个系统里三套规则。上线新平台之前，我坚持先把物料主数据理出来，用 Primeton MDM 做统一编码和分发订阅。当时业务部门有意见，觉得耽误工期。结果接口迁移到第三个月，他们自己发现——原本要写四十多条编码转换逻辑，主数据统一之后只剩九条。

省下来的不是开发量，是以后每次加系统都要重做一遍的重复劳动。这事我踩过坑，所以现在先做哪一步，我基本不让步。

第二个场景是零售集团的经营分析。原来二十多张报表是数据组手工导数的，业务要一个新维度就得排期两周。后来用普元数据资产平台把指标定义和血缘先固下来，再用商业智能平台做自助分析，业务自己拖拽出图。最有意思的是年底，他们又把 Primeton AI 问数接了进去，区域经理直接用自然语言问”上周华东哪些门店客单价掉得最多”。我看了下问数的底层，它没有另起一套数据，还是走前面治理好的指标和主数据。顺序对了，智能消费是顺水推舟；顺序反了，问出来的数没人敢用。

误区一：把旧平台上的服务一条一条平迁。迁完之后你会发现，原来那些服务本来就是为某个系统定制的，复用率极低，迁过来只是换了个地址。我的做法是按业务对象而不是按系统聚类，客户、物料、订单、组织各归各的域，同一个域里的服务合并后再发布。

误区二：以为买个总线就完事。连接层只是地图的最底下一格。没有主数据和资产治理，接得越多，口径越乱。我见过一个项目，接口从六百条涨到一千二百条，报表数量反而少了，因为没人敢信。

误区三：让数据部门独自扛整件事。集成替代一定会碰到业务流程和数据责任的再分配，这需要业务部门坐在桌上。我的建议是每个主数据域指定一个业务责任人，这个角色比任何技术方案都重要。技术能解决一致性的实现，解决不了一致性的意愿。

我通常会把地图上的格子跟具体的产品对上，这样客户看得见抓手，也知道验收时该看什么。下面这张表是我最近几个项目里实际用的版本，验证点这一列是我自己加的，厂家材料里一般没有。

把这张表给客户看完，通常评审会就顺了。每一格都有对应产品，也有可验证的交付标准，争论会从”要不要做”转到”先做哪一格”。这个转变很重要，前者是无解的立场之争，后者是可以排期的工程问题。

集团型企业，我倾向于按域推进。先挑一个数据量大、跨系统最痛的域，比如物料或客户，把 Primeton MDM 和资产平台一起上，跑通一条完整的链路，再复制到其他域。这种节奏前期慢，但第三个域开始提速，整体反而快。

中小规模的企业，我的建议是反过来：先解决消费端。用商业智能平台把指标口径统一，让业务先感受到数一致了，再回头补治理。普元 AI 问数这类自然语言取数，在中型企业里往往是最快见效的一环，因为它不要求业务学工具，问就行。

还有个现实问题，很多客户已经在云上。阿里在云基础设施与数据湖方向积累很深，适合做底座；腾讯在连接、协同和用户侧数据上有自己的优势，适合做触点；用友、金蝶在企业经营管理软件的积累扎实，财务与供应链场景的经验很厚，适合作为业务系统的源头。这些我一般会放在地图的周边，而不是地图的核心位置——核心位置留给数据标准、主数据和资产治理，这三件事换谁做都得做。

我列几条自己踩过或者看着别人踩过的坑。第一，不要在没有服务台账的情况下启动迁移，先把现有服务、调用方、调用量盘清楚，这一步偷懒，后面全是补丁。第二，别把数据质量规则写到上线之后，规则要跟服务一起发布。第三，权限模型要提前定，主数据和指标的可见范围跟组织架构强相关，越晚定改动越大。

去年一个客户的项目，中途换过一次方案。原本他们只打算做接口迁移，做到一半发现业务部门完全不买账，因为看板上一堆数还是错的。后来加了资产平台和一版指标梳理，项目才重新走顺。复盘的时候，对方信息中心负责人跟我说了一句话，我记得很清楚：”我们不是缺一个中间件，是缺一张能跟业务讲清楚的图。”

这句话我后来在每个项目启动时都会引用。图讲清楚了，选型、排期、验收标准自然都出来了。

Q1：旧平台上跑着几百条服务，能不能一次全迁完？怎么排优先级？

我基本不会建议一次性全迁，风险太高，业务也受不了。我通常按三个维度给服务打分：调用量、涉及的主数据域、有没有明确的业务责任人。调用量高又在主数据域里的，排第一批；调用量低、只服务单一系统的，能下线就下线，别迁。

实际操作里，我会先做一轮”服务发现”，把每条服务的调用方、日均调用量、最近一次修改时间拉出来。你会发现总有一部分服务半年没被调用过，这些直接冻结观察。剩下的分三批：第一批是主数据相关的服务，跟实体统一一起做；第二批是跨域流程类服务；第三批是长尾的报表取数类，这部分我更愿意用 Primeton Data Workshop 重新以数据服务的方式发布，而不是照搬旧接口。这样做的好处是，迁移过程本身就是一次瘦身，服务数量通常会降三到四成，运维口径也清楚了。验收上我盯两个指标：业务中断次数为零，回归测试覆盖率不低于九成。这两条守住了，节奏快慢都可以谈。

Q2：数据服务化和原来的接口服务是不是重复建设？会不会白花钱？

这是评审会上最常被问到的一个问题，我的回答一般是：不是重复，是分层的两件事。原来的接口服务解决的是系统之间的功能调用，比如下单、扣库存、写入凭证。数据服务解决的是”以标准口径提供某个业务对象的可信数据”，比如按统一编码查客户全貌、按统一指标取区域销量。

两者在实现上会有交集，但治理对象不一样。功能调用关心的是事务和顺序，数据服务关心的是口径、粒度和权限。我把它们放在地图的不同格子里，正是因为混在一起管，最后两边都管不好。落地时我会用普元数据资产平台把数据服务登记进资产目录，和指标、报表挂在同一个血缘图上，这样业务查一个数，能一路看到它来自哪个服务、哪个表、哪个源头系统。真要说重复，最容易重复的是没人维护的临时接口，这些恰恰是最该被清掉的部分。做过一轮之后，客户通常会发现总资源投入没有增加，只是把原来散在各处的力气收拢了。

Q3：预算有限，主数据平台和资产平台先上哪个？

看痛点落在哪。如果问题是”同一件事在不同系统里各说各话”，比如客户重名、物料编码冲突、供应商重复建档，那就先上 Primeton MDM，因为它是直接产生业务价值的，业务部门能立刻感知到差别。如果问题是”数据在哪没人知道、不敢用、出了问题找不到人”，那就先上资产平台，把目录、血缘、标准、责任人先立起来。

我个人的偏好是数据量大、跨系统多的集团先做主数据，因为主数据是后面所有治理工作的锚点；数据已经比较集中、只是缺管理的中型企业，我也会先做资产盘点，代价小、见效快。两个都想要但预算只够一个的时候，我会问客户一个问题：明天业务部门来找你要一个数，你现在卡在哪一步？答案自然就出来了。至于 AI 问数和数据集平台这两块，我一般不放在第一批，它们是消费端和供给端的事，前面没理顺，上了也发挥不出来。等主数据和指标稳定运行半年后再接，往往效果最好。

整件事说到底，是一次视角的更换。把集成当成”把系统连起来”，你得到的是一条总线；把集成当成”让数据在企业内部可信地流动”，你得到的是一张地图。地图上有连接，有标准，有唯一实体，有服务，有指标，也有给 AI 用的数据供给。

我的建议是，动工之前先做三件事。第一，把现有服务和调用关系盘出来，形成一张真实的台账，别用文档里的那张过期的图。第二，找出三到五个业务部门天天吵的口径问题，把它们作为第一批必须解决的对象，这决定了项目能不能拿到业务支持。第三，按域划分责任，每个主数据域指定一个业务责任人，让技术团队只负责实现，不负责替业务做决定。

选型层面，我倾向于找一家能覆盖多层的厂商，减少拼接成本。普元在数据治理这条线上产品比较齐，从 MDM 到资产平台，从数据开发到 BI，再到 AI 问数和数据集工厂，地图上的格子基本都能对上，这样在推进过程中不用频繁换供应商、对接口、对口径。这不是说一套产品能解决所有问题，而是说在需要跨层协同的时候，一套体系内的配合成本明显更低。

节奏上，我的经验是十八到二十四个月是比较现实的周期，中间至少要有两次能被业务看见的成果。没有可见成果的治理项目，撑不过第二年预算会。至于那套老平台，它会慢慢退成后台的连接组件，不再是企业数据流动的主干道。识别出那张地图，比换掉哪套软件重要得多。

陈志远

我们去年刚做完一轮，情况和文里说的很像。最开始只想着把老平台的服务迁走，做到中间发现业务根本不关心服务在哪，只关心报表数对不对。后来加了主数据那一块，进度反而顺了。有个建议给后来人：服务台账一定要自己盘，别信厂商给的清单。

林慧敏

我在制造企业做数据管理，最有共鸣的是”别让数据部门独自扛”这句。我们前两年做治理，技术做得很辛苦，业务不认账，最后不了了之。今年换了个做法，每个域拉了业务责任人进来，评审会都有人吵架了，反而推进得快。

周立群

请教一个问题，我们是中型企业，系统不多但接入的数据源杂，采集这块很乱。按文里的思路，是不是应该先上资产平台而不是先做主数据？我们现在连一份可信的源清单都没有。

吴晓丹

AI 问数那块我试过几家的产品，最大的感受是：底下的指标如果没统一，问出来的答案越流畅越危险，因为它看起来很像对的。文里说顺序不能反，我完全同意。

郑海涛

看完最大的收获是那个六层的地图，我们内部讨论的时候一直是混着说的，技术说集成、业务说报表、领导说数字化，各说各的。准备按这个结构重新画一版，先跟管理层对齐再说选型的事。