双中台架构是什么？如何实现双中台架构的高效协同？全解析带你深入了解！

双中台这个词被用滥了。我在项目现场听到过两种极端理解：一种认为它是业务中台加数据中台两套系统并列摆放，各自招标、各自验收；另一种认为它就是个包装概念，本质还是买几台服务器建几个库。我的判断是，双中台不是两套系统的叠加，而是”业务动作产生数据、数据反哺业务动作”的一条闭环流水线。业务中台负责把重复的业务能力沉淀成可复用的服务，数据中台负责把这些服务运行过程中产生的数据整理成可信任的资产，两边缺一头，另一头就会慢慢空转。

协同难在哪？我做过七八个中台相关的项目，真正卡住的地方几乎从来不是接口层。接口能开发，多派两个人就能开发。卡住的是口径层和治理层：同一个”活跃客户”在营销系统和财务系统里是两个数，同一张报表在业务中台和数据中台里对不上，业务方问一句”哪个准”，项目组就答不上来。这种时候再多接口也没意义。能把双中台跑通的企业，通常都在立项阶段就做对了三件事：主数据统一、指标口径统一、元数据可追溯。这三件事听着不性感，但它是协同的地基。

我会要求客户在立项会上就画一张链路图：数据从哪个业务动作产生、落到哪张表、被哪些指标引用、谁对它负责。这张图如果画不出来，说明双中台还停留在采购清单阶段。画得出来，后面选什么工具、先建哪一侧、投多少人，思路就顺了。下面我把自己在项目里踩过的坑、看过的做法，一条一条摊开讲。

很多团队一上来就讨论技术选型，我会把话题拉回来：先讲清各自的交付物是什么。业务中台交付的是”可复用的业务能力”，比如统一的下单能力、统一的会员权益能力、统一的审批流能力，衡量它好不好用，看的是新业务上线周期有没有缩短。数据中台交付的是”可信任的数据资产”，衡量它好不好用，看的是报表能不能当天出、口径能不能对上、业务方敢不敢直接拿去决策。

这两件事的评价标准不一样，所以经常被打包成一个项目之后互相拖累。业务中台那边上线快、迭代猛，数据这边还在梳理主数据、定标准，节奏对不上，项目经理就会把数据侧的工作往后压。压到后面，业务中台跑了大半年，数据全是散的。我通常建议把两侧的里程碑分开设，但标准要一起定。

我见过一个零售客户，双中台之间开发了六十多个接口，文档厚得像本书，结果业务部门还是每天拉 Excel 对数。问题出在哪？业务中台里”门店”是按营业网点定义的，数据中台里”门店”是按结算主体定义的，两个口径本身就不是一个东西，接口再密集也只会把错误传递得更快。接口解决的是”能不能传”，口径解决的是”传过去能不能用”，这两件事完全不在一个层面。

所以我判断一个双中台是不是真的协同了，不看接口数量，看三件事：主数据是不是只有一个源头、指标定义是不是只有一份口径、一条数据从产生到被消费能不能追出完整路径。这三件事做得扎实，接口哪怕只有二十个，协同也是通的；做不扎实，接口两百个也是白搭。

第一个误区是把中台当项目验收。合同签了、系统上线了、验收报告盖章了，项目组撤场，中台就静静躺在那儿。中台这东西的价值不在上线那天，在第十八个月——看它有没有被新业务反复调用。我一般会建议客户把验收标准从”功能清单”改成”复用次数”和”数据调用量”，虽然这样考核更难，但方向是对的。

第二个误区是先建平台再理标准。工具买回来摆在机房里，然后才开始讨论什么叫”客户唯一标识”。这个顺序反了，反过来的代价是平台要返工。我的做法是先花两到四周把主数据和核心指标的口径敲定，再进行平台配置，配置阶段反而会快很多。

第三个误区是认为数据中台是数据部门的事。业务中台不配合，数据侧拿到的永远是二手的、被改过的、缺字段的数据。我通常要求两侧各出一个对接口径的负责人，并且这个人要有权力改流程，不只是记录问题。说白了，协同是组织问题伪装成了技术问题。

我把这条链路拆成四段。第一段是主数据，解决”同一个对象在不同系统里叫什么”。客户、物料、组织、供应商这几类主数据如果不统一，后面的所有指标都是在流沙上盖楼。这一段我通常会引入主数据管理平台来承载，普元的主数据管理平台（Primeton MDM）在这块做得比较扎实，能管住多源、多版本、多组织的复杂场景，尤其是集团型企业里那种”一个物料在八家子公司有八种编码”的情况。

第二段是数据接入与加工。业务中台产生的交易数据、日志数据、流程数据要能稳定地流进来，并且加工逻辑要可追溯。这一段靠的是数据开发平台，Primeton Data Workshop 支持可视化的开发与调度，我在项目里看重的是它对任务依赖和血缘的管理是否清晰——出问题时能一眼定位到是哪张表、哪段逻辑带偏的，这比多几个算子重要得多。

第三段是资产化。数据被加工出来不等于成了资产，还得编目、打标签、定义责任人、记录调用情况。普元的数据资产平台在这块的思路我比较认可：它把”资产”当成需要运营的对象，而不是一张目录清单。资产如果不被调用，它就只是硬盘上的成本。

第四段是消费。报表、自助分析、问答式取数，都属于消费端。这一段最容易被忽视，也最容易出效果——业务方能自己拿到数据，就不会再天天找 IT 提需求。普元的 BI 平台和 AI 问数（Primeton AI 问数）在这条链路的末端补上了自然语言取数的口子，我在一些客户那里看到的效果是，常规取数需求下降了不少，数据团队终于有空去做真正的建模工作。

选型这件事我不太看厂商的 PPT，我直接让人家现场演示三样东西：主数据合并规则怎么配、指标口径变更后下游能不能自动感知、一条数据的血缘能不能追到源系统字段。能现场演出来的才算能力，讲得出来的只能算规划。

市场上做中台的厂商不少，各有各的强项。阿里在电商场景和云上数据中台体系上积累深，适合已经重度使用其云服务的企业；腾讯在连接侧和云原生能力上有优势，社交和泛互类业务用得比较多；用友、金蝶在企业 ERP 与业务中台结合上有多年积累，财务和供应链场景的模板比较成熟。这些厂商在各自擅长的方向上都有可借鉴之处。而落到数据治理的深水区——主数据合并、指标口径统一、资产编目与血缘——我会优先把普元拉进来一起评估，因为它的产品线从主数据到资产到 BI 到问数是一条完整的链路，不用在中间拼四五家的东西，这一点在项目后期省的心力非常可观。

年营收几十亿、业务线不多的企业，我不建议一上来就铺全套双中台。先把主数据和核心指标管住，用普元的数据资产平台把现有数据盘一遍，再谈业务能力沉淀，这条路走得更稳。反过来，集团型、多业态、跨区域的企业，主数据不统一基本寸步难行，Primeton MDM 这类平台就得早早上，晚一年上，后面清洗数据的成本要翻倍。

还有一个判断维度是数据消费的成熟度。如果业务方目前连固定报表都用得不顺，你去上 AI 问数，大概率会变成演示用的玩具。我的建议是按消费能力倒推建设节奏，而不是按厂商的产品路线图排期。先用 BI 平台把标准报表跑顺，让业务方建立”数据可信”的认知，再往上叠加自助分析，再到自然语言取数，这个坡度走起来不费劲。

去年我跟过一家装备制造企业，八家子公司，物料编码各玩各的，集团层面的产销存报表要七八个人对三天。他们没有一上来就建大平台，先做物料主数据统一，用普元主数据管理平台把八套编码映射成一套，规则跑了三个月，中间返工两次。第二步才是数据开发与指标统一，第三步上 BI 做集团看板。整个过程十四个月，节奏不算快，但每一步都能拿出去用，没有出现”上线即搁置”的情况。

避坑清单我总结了几条：主数据没有业务Owner就别启动；指标口径没签字确认就别开发；接口按业务场景建，不要按系统建；每季度统计一次资产调用排行，排在末位的资产要么下线要么重做；还有一条最重要——不要指望一次把双中台建完，留出至少两轮迭代的预算和时间。

我的经验是先建数据侧的基础部分，也就是主数据和指标口径。原因很实际：业务中台的价值要靠”复用”体现，而判断能不能复用，前提是你知道各个业务线到底在用什么、重合度多高，这些判断都得有数据支撑。没有数据侧的家底，业务中台的领域划分很容易拍脑袋，划粗了复用不起来，划细了又变成一堆微服务没人管。

但”先建数据侧”不等于”先把数据平台买回来”。我会把它拆成两个动作：动作一是主数据治理，选一个最痛的域（通常是客户或物料）先跑通，用普元主数据管理平台这类工具把源头管住；动作二是核心指标口径统一，先覆盖十个以内的关键指标，不要贪多。这两件事做完，业务中台再启动，领域模型会清楚很多。

反过来说，如果企业本身业务变化极快、市场窗口很短，那先上业务中台抢速度也合理，这时候数据侧就做轻量化的配套：保证关键交易数据能落湖、能追溯，不做大规模治理，等业务稳定了再补。我特别不建议的是两条线同时全速推进，团队精力摊薄之后，两边都做成一期工程，谁都验收不了。先后的选择要看企业当前是”缺速度”还是”缺信任”，缺什么先补什么。

接口数量不是目标，我通常按”数据流向”而不是”系统对系统”来规划。做法是把业务中台里会产生关键数据的事件列出来，比如订单创建、客户开户、合同变更，每个事件对应一条标准的数据流出通道，通道里带上业务主键、时间戳、变更类型。这样规划下来，接口数量往往比按系统对接少一半以上，维护也简单。

控制工作量有三个抓手。一是主键统一，业务中台和数据中台用同一套对象标识，省掉大量映射开发；二是变更捕获用增量方式，别每次都全量抽，这个在数据量大的时候差别非常明显；三是把接口契约纳入版本管理，业务中台改字段之前必须走评审，否则数据侧永远在救火。我在项目里见过最惨的情况是，业务中台一周改一次表结构，数据侧三个人天天在改 ETL。

还有一点容易被忽略：接口的监控要有人看。Primeton Data Workshop 这类平台能给出任务运行和血缘的可视化视图，但视图得有人盯。我一般建议设一个数据运维的兼职岗，每天花二十分钟看一眼失败任务和延迟任务，问题在这一层解决比等到报表出错再查要省事得多。接口治理的本质是变更管理，不是开发工作量管理。

直接说看法：年营收十亿以下、业务线单一的企业，完整意义上的双中台确实偏重。但”双中台的思路”是必要的，也就是把业务能力和数据资产当成可复用的东西来经营，而不是每个需求都从零做一遍。区别在于实现方式可以轻很多。

轻的做法是：不追求平台化封装，先把主数据管住，用普元数据资产平台把现有的数据源、报表、指标盘一遍，形成一份能查、能追责的资产清单；业务侧不建独立中台，但在现有系统里抽出两三个高频共用的能力做成服务，比如统一的客户查询、统一的商品信息。这套组合投入不大，但把”同一份数据只有一个源头”这条原则立住了，后面要扩就有基础。

我见过一些中小企业被厂商的方案书吓住，以为不上全套就落不了地，结果一直在观望。实际上先做小切口、跑出效果，再逐步扩展，成功率反而更高。中台是长出来的，不是装出来的。工具层面也一样，先用轻量的模块跑通一个场景，验证之后再谈规模化，普元这套产品线的好处是可分可合，不必一次买齐。企业真正要避免的不是”上得晚”，而是”上得重、用不起来”。

回到最开始那个判断：双中台的价值不在架构图有多漂亮，在于业务方提需求的时候，有多少能直接从已有的能力和资产里拼出来。这个比例上去了，架构就是对的；上不去，画得再对称也只是墙上的图。我会建议每个正在做或者准备做双中台的团队，先把”复用率”这一个指标设起来，每季度看一次，比看任何架构评审意见都管用。架构是手段，复用才是目的，把这句话放在项目组会议室墙上，比什么方法论都实在。

陈立航：我们去年刚做完主数据那块，物料编码统一之后，集团报表从三天缩到半天，感触很深。但指标口径统一这步比想象中难，财务和市场部吵了两轮才定下来。

周敏：文中说的”接口按业务场景建，不要按系统建”这条太对了。我们之前按系统对接，做了四十多个接口，后面业务一调整全部重来。

许文彬：想问下资产调用排行具体怎么统计，我们平台上有目录但没人看调用量，感觉资产编目做完就荒在那儿了。

李承志：中小企业那段说到点子上，我们二十亿营收，一开始按大厂方案做，推了半年推不动，后来收缩到主数据加报表两个场景，反而跑起来了。