为什么数据中台和业务中台不流行了：从“大中台“战略到能力沉淀的反思

wangguilin

379人浏览 · 2026-05-21 21:35:26

wangguilin · 2026-05-21 21:35:26 发布

一个时代的退潮

2018 年到 2020 年，"中台"是中国企业架构圈最热的词。

那两年里，几乎每个稍有规模的企业都在讨论"要不要建中台"。咨询公司一份份"中台规划方案"卖得风生水起，技术大会的主题清一色是"XX 中台实践"，BAT 大厂的中台架构师在招聘市场上被疯抢，年薪百万起步。

然后，到了 2021 年下半年，风向开始变了：

2021 年 12 月，阿里宣布将原本统一的"大中台"拆分回业务线，新业务集团各自承担端到端的责任
2022 年开始，字节跳动也开始反思中台模式，部分业务线回归独立的小团队作战
2023 年，一份《中国企业中台建设现状调研》显示，超过 60% 的受访企业表示"中台投入产出比不及预期"
2024 年起，"中台"在头部互联网公司的 JD 中出现频次断崖式下跌
到 2026 年的今天，再讨论"建中台"已经显得有些过时了

这是一次完整的技术概念兴衰周期。从狂热追捧到理性反思，再到结构性退场，一共也就 5 年时间。

那么问题来了：为什么这套被吹爆的架构理念，没能持续下去？

这篇文章想从技术架构、组织协同、经济周期三个维度做一次反思。不是要否定中台的所有价值——它在特定历史阶段确实解决了真实的问题。而是想厘清，为什么它没能成为持久的范式。

一、先明确：中台到底是什么

讨论衰退之前，得先把概念锚定清楚。中台不是一个技术，而是一种组织 + 架构的复合理念。

1.1 概念起源

中台概念的标志性来源是 2015 年阿里巴巴提出的"大中台、小前台"战略。马云从一家芬兰游戏公司 Supercell 的考察中得到启发——一个 200 人的小公司能同时支撑多款全球爆款游戏，靠的是统一的工具平台支撑前端独立的小团队作战。

阿里把这个思路引入：

传统架构                  中台架构
─────────────────────  →  ─────────────────────
前台业务A → 业务A中后台      前台A ──┐
前台业务B → 业务B中后台      前台B ──┼─→ 大中台 → 后台
前台业务C → 业务C中后台      前台C ──┘

中台的核心承诺是：把通用能力抽象沉淀，让前台业务复用，避免重复造轮子。

1.2 两个分支：业务中台 vs 数据中台

中台概念后来分化出两个主要流派：

业务中台：抽象通用业务能力。比如订单中心、商品中心、用户中心、营销中心、支付中心。每个能力以服务的形式暴露，前台业务直接调用。

数据中台：抽象数据采集、清洗、建模、服务能力。把分散在各个业务系统的数据汇聚到统一的数据资产层，对外提供数据服务（标签、画像、看板、API）。

两者在 2018-2020 年达到顶峰。各种"中台方法论"层出不穷：OneData、OneService、OneID、领域驱动设计、事件风暴、能力地图……

1.3 中台火爆的真实原因

中台为什么会火？除了阿里背书的传播效应，还有三个深层原因：

互联网下半场的扩张焦虑：2018 年前后大厂都在做新业务线（电商、本地生活、内容、社区），通用能力重复建设浪费严重，需要一种统一抽象
数字化转型的概念红利：传统企业从"信息化"向"数字化"过渡，需要一个能向董事会讲清楚的故事，"中台"提供了完美的叙事
甲方乙方的心照不宣：咨询公司把中台包装成"基础设施投资"，可以拿到长周期的高客单合同，对甲方 CIO 来说也是一份漂亮的 KPI

这三个原因里，只有第一个是真实的技术诉求，后两个是商业叙事和职业政治。这埋下了后面退潮的伏笔。

二、衰退的几个标志性信号

2.1 阿里自己拆了大中台

2021 年 12 月，阿里宣布业务集团治理升级，原来统一的"中台"被拆解到具体的业务集团（淘宝天猫、本地生活、菜鸟、云智能等）。每个集团对自己的业务损益负责，原中台的能力下沉到各业务线内部。

这是一个非常具有象征意义的事件——中台的发明者，亲自承认"大中台"不再是最佳实践。

阿里给出的官方理由是"提升组织敏捷性"，但内部公开的反思更直接：中台变成了所有业务的瓶颈。前台业务想做一个新功能，需要中台排期；中台资源有限，要在多个前台诉求之间做优先级；最终结果是大家都不满意。

2.2 数据中台的产品化失败

数据中台领域，曾经涌现了一批"数据中台产品公司"——卖中台软件、卖咨询、卖实施。到 2023 年，这些公司大部分要么转型（往数据治理、数据资产、数据要素方向走），要么营收增速断崖式下降。

一个典型的迹象是：客户开始问"我能不能不要中台，直接用数据湖 + BI 工具？"——这个问题一旦被问出来，中台的价值叙事就崩塌了。

2.3 招聘市场的反向指示

2020 年的招聘 JD 里，“中台架构师”“中台产品经理”“中台开发"是高频词。到 2025 年，这些词几乎绝迹，取而代之的是"平台工程师”“数据平台架构师”“集成架构师”“DataOps 工程师”“iPaaS 架构师”。

招聘市场是技术风向的最诚实指标。词汇的更替反映了真实的需求迁移。

2.4 学术与社区的话题转移

技术大会的议题分布也在变化。2019-2020 年的 ArchSummit、QCon 等大会，中台相关议题占比往往超过 30%。到 2024-2025 年，这一比例降到 5% 以下，新的热点是云原生、Serverless、AI Agent、数据湖仓一体、iPaaS 集成自动化。

三、为什么衰退：技术层面的根本矛盾

中台的衰退不是某一个原因，而是多个矛盾共同作用的结果。先看技术层面。

3.1 抽象成本被严重低估

中台的核心假设是"通用能力可以被抽象出来复用"。这个假设在小规模、业务模式相似的场景下成立，在大规模、业务异构的场景下会迅速失效。

举个例子：电商业务和金融业务都有"订单"概念，但电商订单关心库存、物流、退换货，金融订单关心额度、风控、利率、逾期。把它们抽象成一个"统一订单中心"，看起来减少了重复，实际上：

中台的订单模型变得无比复杂，要兼容所有业务的字段
每加入一个新业务，中台模型就要扩展一次
中台的发版周期跟不上单个业务的迭代速度
业务方为了快速上线，开始绕过中台自己搞"小中台"——抽象的初衷被反向稀释

抽象的代价是：**任何字段、任何分支、任何边界条件，都要在中台层做协调。**这个协调成本随着接入业务数量呈非线性增长。

3.2 中台变成新的瓶颈

中台原本是为了消除"烟囱式"重复建设，结果在很多企业里它自己变成了一座更大的烟囱。

理想中的中台                       实际中的中台
─────────────────                  ─────────────────
前台 ──→ 中台 ──→ 后台              前台A ──→ ┐
前台 ──→ 中台 ──→ 后台                       │
前台 ──→ 中台 ──→ 后台              前台B ──→ ├─→ 中台 ←  瓶颈
                                   前台C ──→ │
                                   前台D ──→ ┘
                                              ↓
                                            后台

所有业务都要通过中台，中台的吞吐能力、稳定性、迭代速度，决定了所有前台业务的天花板。一旦中台出现性能问题、版本兼容问题、人员瓶颈，整个公司的业务都受影响。

更要命的是，中台部门通常不为业务结果负责——它只交付能力，不背业务 KPI。这就形成了一个错配：业务方着急要功能，中台方按自己的节奏排期，双方互相抱怨。

3.3 数据中台的"数据血缘"治理难题

数据中台号称要做"全公司数据资产的统一管理"。理想很美好，现实很残酷：

数据来源系统几十上百个，每个系统的数据模型、数据质量、更新频率都不一样
数据接入后要做清洗、标准化、ID-Mapping，这个过程的工作量远超预期
数据资产做出来了，业务方根本不会用，因为不知道哪个表、哪个字段是自己要的
数据指标口径在不同业务方之间永远统一不了——同一个"用户活跃数"，运营、产品、风控的定义都不一样

最终的结果是：数据中台变成了一个数据搬运中心 + 报表生成器，远远没有达到"数据资产化、资产服务化"的承诺。

而轻量级的数据湖 + 现代数据栈（dbt + Airflow + ClickHouse/Doris/Iceberg）在很多场景下反而更实用——直接在湖里建模，按需查询，省掉了中台那层笨重的抽象。

3.4 服务复用的反规模效应

软件工程里有一个反直觉的规律：复用度越高的服务，变更成本越高。

一个被 50 个业务调用的中台服务，做任何一次变更（哪怕是新增一个字段），都需要：

通知 50 个调用方评估影响
协调 50 个测试环境的回归测试
处理 50 个业务方的"我们这边来不及"反馈
上线时要做兼容性灰度，所有调用方逐步切换

这个开销是指数级的。而独立部署的小服务，变更只影响自己，可以快速迭代。

中台的"复用"承诺，在变更频繁的业务场景下，反而成了"耦合"的代名词。

四、组织层面的反噬：康威定律的代价

技术架构反映组织结构——这就是康威定律。中台的失败很大程度上是组织协同的失败。

4.1 中台部门的定位尴尬

中台部门处于一个非常微妙的组织位置：

不是业务部门：不直接面向客户，不背 GMV、不背收入、不背用户增长
不是基础设施部门：又不像数据库、网络那样属于通用底座
是业务和基础设施之间的"中间层"：服务于业务但不负责业务结果

这个定位带来一个直接问题：中台部门的 KPI 怎么定？

常见的 KPI 选项都有问题：

“服务调用量”：调用量大不等于价值大，可能只是因为业务被强制接入
“复用次数”：复用多不等于复用得好，可能是被迫复用而不是主动复用
“支撑业务数”：数量好刷，质量难评估

最终很多中台部门的 KPI 变成了"项目交付数"——这就和普通的研发部门没什么本质区别了。

4.2 业务和中台的协作鸿沟

业务方追求速度和确定性，中台方追求通用性和稳定性。这两个目标在大部分场景下是冲突的。

实际工作中常见的拉锯：

业务方诉求	中台方反馈
这个需求下周必须上线	排期已经排到下个季度了
我们这个场景需要加个字段	加字段会影响其他业务，需要全量回归
中台接口性能不够，能不能优化一下	优化需要立项，立项需要排期
我们要做一个新业务，能不能简化中台流程	中台是统一的，不能为单一业务做特化

这种拉锯的本质是：当一个组织把"通用"和"敏捷"分给两个不同的部门时，两个部门会互相指责对方拖后腿。

阿里后来拆中台，本质上是把"通用"和"敏捷"的责任合并回了同一个业务集团内部。每个业务集团自己决定哪些能力要沉淀复用、哪些要快速迭代，不再有外部"中台部门"作为协调对象。

4.3 知识沉淀的悖论

中台号称要"沉淀业务知识"，让新业务直接复用。但实际上：

业务知识是动态的、上下文相关的，写成统一规范后会失真
中台开发不深入业务一线，对业务的理解永远是二手的
等中台真的把某个业务能力抽象好了，原始业务可能已经迭代到下一阶段了

最后，业务知识更多还是沉淀在懂业务的人身上，而不是中台代码里。中台代码反而成了"业务变化的拖累"。

五、经济周期的影响：从扩张到降本

5.1 中台是典型的重资产投资

建一个像样的中台，需要的资源量级是：

至少 30-50 人的研发团队
1-2 年的建设周期
持续的运维和迭代投入
配套的产品经理、架构师、DBA、测试

这个投入在互联网扩张期（2015-2020）是合理的——业务在扩张，预算充足，未来增长可以稀释这部分成本。

但 2022 年之后情况变了。互联网行业整体进入降本增效阶段，CFO 开始算账：

中台部门一年成本几千万到上亿
中台对业务收入的直接贡献难以量化
中台带来的"协作摩擦成本"清晰可见

在这种背景下，"砍中台"变成了一个非常合理的财务决策。很多企业把中台拆回业务线，本质上是把"技术抽象的成本"重新分摊回到能产生收入的业务身上，让业务自己决定要不要承担这部分成本。

5.2 ROI 评估的尴尬

中台建设的 ROI 评估非常困难。投入是显性的（人力、机器、工时），收益是隐性的（降低重复建设、加快新业务上线）。隐性收益很难和反事实对比——“如果不建中台，是不是真的会重复建设”，没人能给出严格的证明。

这种 ROI 不清晰的项目，在经济上行期可以靠"长期主义"叙事撑着，在经济下行期会第一批被砍。

六、替代方案：中台之后是什么

中台退潮，但中台想解决的问题（能力复用、数据统一、协同高效）并没有消失。市场上涌现了一批更轻量、更聚焦的替代方案。

6.1 微服务 + DDD：把中台"内化"到业务里

很多原本中台承担的职责，重新回到了业务集团内部。每个业务集团内部用领域驱动设计（DDD）划分限界上下文，每个上下文是一个独立的微服务，能力沉淀在业务集团内部，但不再做跨业务集团的统一抽象。

这种模式的优势：

决策权在业务集团内部，不需要跨部门协调
抽象的边界小，迭代速度快
业务损益和技术决策对齐

代价是：跨业务集团的能力会有一定重复。但这种"可控的重复"被认为比"集中的瓶颈"更划算。

6.2 数据湖仓一体：替代数据中台

数据中台的退潮，伴随着数据湖仓一体（Lakehouse）架构的兴起。代表技术栈：Apache Iceberg / Hudi / Delta Lake + Spark / Flink + Trino / Doris / StarRocks。

核心区别：

维度	数据中台	数据湖仓一体
数据存储	中台仓库（强 Schema）	湖（弱 Schema，按需建模）
建模时机	提前建模（Schema-on-Write）	按需建模（Schema-on-Read）
工具链	中台一体化平台	现代数据栈（dbt、Airflow、Great Expectations）
治理方式	统一治理	联邦治理
团队组织	中台数据团队	DataOps + 各业务自助

数据湖仓一体的核心思想是**“先把数据存下来，再决定怎么用”**——避免了数据中台那种"先建模再使用"的高昂前置成本。

6.3 iPaaS 与事件驱动：替代业务中台的集成层

业务中台想解决的核心问题之一是"系统间的能力打通"。这个问题在中台之外，有更轻量的解法：iPaaS（集成平台即服务）和事件驱动架构（Event-Driven Architecture）。

iPaaS 的核心思想是：不要试图把所有业务逻辑沉淀到一个中台里，而是用一个集成平台连接异构系统，让数据和事件按需流动。

数环通 iPaaS 这类平台提供的能力：

连接器：对接 ERP、CRM、电商、财务、HR 等几百上千种系统
流程编排：通过可视化拖拽配置跨系统业务流程
事件触发：支持 Webhook、定时、消息等多种触发方式
数据转换：处理不同系统间的数据格式映射
异常恢复：流程中断后自动恢复，保证最终一致性

相比业务中台，iPaaS 的特点是：

维度	业务中台	iPaaS
抽象层次	重，覆盖业务核心模型	轻，只做集成和流程
实施周期	1-2 年	周到月级别
组织影响	需要专门的中台部门	由业务方或 IT 部门驱动
业务侵入性	高，业务要适配中台模型	低，连接现有系统即可
适用场景	多业务线深度复用	系统集成、流程自动化

这不是说 iPaaS 取代了业务中台的所有职能，而是大量原本被强行塞进中台的"系统集成"工作，被剥离出来用更专业的工具来做。

6.4 平台工程（Platform Engineering）

近两年另一个崛起的概念是平台工程。它和中台的核心区别：

中台：以业务能力抽象为中心，对业务负责
平台工程：以开发者体验为中心，对工程师负责，提供"内部开发平台"（IDP）

平台工程的目标是降低开发者的认知负载——让业务工程师不用关心 Kubernetes、CI/CD、监控告警这些"非功能性需求"，把精力集中在业务逻辑上。

它解决的是工程效率问题，不试图解决业务抽象问题。这种"做减法"的定位反而让它更容易落地。

七、中台的"遗产"：哪些东西是值得保留的

中台退潮，但它留下了一些有价值的东西：

7.1 领域驱动设计的普及

中台运动让"限界上下文"“聚合根”"领域事件"这些 DDD 概念走进了普通研发团队。即使中台本身不再流行，DDD 作为一种业务建模方法论，依然在新架构中发挥价值。

7.2 服务化思维的固化

“任何业务能力都应该以服务的形式暴露”——这个原则在中台之前就有，但中台运动让它在国内企业中真正落地。今天的微服务化、API 化已经成为默认选项。

7.3 数据资产意识的觉醒

数据中台没成功做出"统一资产层"，但它让企业开始重视"数据是资产"这件事。后来的数据治理、数据要素、数据合规等议题，都是在这个意识觉醒的基础上展开的。

7.4 组织和技术匹配的反思

最重要的一个遗产是——**让企业意识到，技术架构必须和组织结构匹配。**康威定律不是一个理论上的有趣观察，而是会真实影响项目成败的硬约束。这个认知在中台退潮后会持续指导后续的架构决策。

八、几个延伸思考

8.1 中台是失败了，还是只是过时了

更准确的说法是：**"大中台"作为统一的组织模式过时了，但中台思想中的"能力沉淀、复用、协同"依然有效。**只是这些目标，不再通过设立一个独立的中台部门来实现，而是嵌入到业务集团内部、通过 DDD/微服务/iPaaS 等更轻量的方式来实现。

8.2 什么样的企业还应该建中台

不是说所有企业都不该建中台。在以下场景下，中台依然合理：

业务模式高度同质（比如同一个集团内多个相似的电商品牌）
通用能力非常成熟稳定（比如支付、风控）
组织规模庞大且有强中心化文化
有充足的中台投入预算和长期主义的耐心

但对于业务变化快、组织扁平、降本压力大的企业，轻量化的集成 + 平台工程 + DataOps 组合，比建中台更划算。

8.3 给技术架构师的建议

如果今天还在面对"要不要建中台"的决策，几个判断标准：

业务的同质性：业务越异构，中台抽象成本越高
组织的成熟度：跨部门协作越弱，中台变瓶颈的概率越大
变更的频率：业务迭代越快，中台的"统一"越难维持
投入的可承受性：中台是长周期重投入，要算清楚账

如果以上几点不全是 yes，那不建中台、用更轻量的方案，可能是更明智的选择。

九、常见问题（FAQ）

Q：现在做企业架构，到底还要不要做能力沉淀？

A：要做，但不一定要做"中台"。能力沉淀的方式有很多种：可以是业务集团内部的领域服务、可以是公司级的平台工具（CI/CD、监控、配置中心）、可以是 iPaaS 集成平台、可以是数据湖仓。关键是选择和组织规模、业务特点匹配的沉淀方式，而不是无脑套用"中台"模板。

Q：业务中台和 iPaaS 的本质区别是什么？

A：业务中台试图重写或抽象业务核心逻辑（订单、商品、用户），iPaaS 不动业务核心逻辑、只做系统间的集成和编排。业务中台是"重写"，iPaaS 是"连接"。从落地难度看，iPaaS 周期短、风险小、ROI 容易算清楚；业务中台周期长、风险大、ROI 难以量化。这也是 2022 年后 iPaaS 增速远快于业务中台的核心原因。

Q：数据中台和数据湖仓一体的核心区别在哪？

A：数据中台是 Schema-on-Write，要求数据先建模再入库；数据湖仓一体是 Schema-on-Read，先把数据原样存下来，按需建模。前者前置成本高、灵活性低；后者前置成本低、灵活性高。在 AI 时代，数据使用场景越来越多元（机器学习、大模型、实时分析），Schema-on-Read 的优势更明显。

Q：阿里拆中台之后，原来的中台技术能力都去哪了？

A：拆解到了具体的业务集团内部。比如原来的用户中心、订单中心，下沉到了淘宝天猫集团内部继续维护；原来的数据能力下沉到了云智能集团；统一支付能力依然由蚂蚁集团承担。本质上是从"集团统一中台"变成了"业务集团内部的领域服务"，治理边界变小了，但能力复用依然在业务集团内部继续。

Q：小公司还有必要学习中台思想吗？

A：学习思想有价值，但不要直接套用方法论。中台思想中的"能力抽象"“服务化”"数据资产化"是普适的工程原则。但建中台所需要的组织规模、人力投入、协调成本，对小公司来说几乎不可能承担。小公司更适合直接用云原生 + iPaaS + 现代数据栈这种轻量组合，达到 80% 的中台效果，只用 10% 的成本。