中台反思：中台的宿命：解构与融合

中台承担了企业太多的期望，在中大型企业数字化推进过程中它也的确起到了较大的作用。但是我们看到的更多情况却是“事倍功半”。很多人把中台建设的问题归咎于组织架构的问题，如同康威定律所阐述的组织架构与系统架构的强相关性一样，中台建设必然会涉及组织架构的调整、必然会涉及即得权益的重分配，所以大家都认同中台是一把手工程。那么“搞这么大动静，要达成的目标是什么？”。很多企业为中台而中台，尤其是数字化建设相对较晚的企业，听到这一概念如获至宝，“头脑发热”上中台，然而推进过程遇到各种问题，也就开始“打退堂鼓”了。所以说 中台建设的失败多因对困难的预估不足，对成果的期望过高。

归结上文的分析，中台建设最大的问题在于：中台建设是体系化的、非渐进式的，在没有明确可承诺的成果前投入高、风险大 。

中台，尤其是业务中台，我们最常听到的是“中台只是把小山头变成了大山头”，言下之意有二：一是中台仍未能解决跨业务共享的问题；二是“小山头”易破，“大山头”难攻呀。所以对于一个中大型、有着多个业务群的企业而言，建设各领域业务中台可以提升领域内的研发效能，但无助全领域的能力共享，更有甚者会强化各业务群之间的壁垒。当然我们可能会想“那为什么不建设一个统一的业务中台呢？”，只能说小企业或可以实现，但在中大型企业中上到组织架构的束缚，下到各业务/分子公司的独立性要求，这种想法是不现实的。

这就引出了中台定位的问题：中台是对企业领域共享能力的聚合，是有明确指向性的，解决领域内生性的问题，不关注外围需求，并不具备生态化能力 。

很多企业都认可多业务中台的存在，这也符合中台的定位，也是对现实的一种“妥协”。但是往往由于不同的业务中台由不同的厂商承建，或是同一厂商不同的团队承建，导致了虽都为业务中台可在技术架构、中间件选型、数据模型、流程流转、投产运营、服务等级等层面都不尽相同。这导致了各中台之间无法有效的融通，中台间的技术成果也无法共享。

因此，就中台自身的建设而言：各业务中台缺乏标准的建设规范，没有统一的、可共享的技术底座，导致了各中台能力重复建设、质量参差不齐、使用各有千秋、融通困难重重 。

软件工程最伟大也是最基础的思想是“分层架构”。没有什么问题是加一层解决不的。中台上述的问题如果仅从中台的演进出发，想着怎么迭代出中台2.0、3.0是于事无补的，我们更应该跳出中台，站在企业架构的视角去解耦中台，把它打散到各个能力层级之中。针对中大型企业，尤其是集团化的、有生态化需求的企业而言，IT能力共享架构应由：开放平台、技术平台、（领域）中台 、 业务应用 组成（如上文图）。

开放平台 天然具备了开放、生态化的能力，可解决跨业务群/跨企业共享需求，可用于接入各领域中台的能力，由其提供统一规范的共享能力支撑。并且开放平台仅为一层比较“薄”的共享能力封装，它也可以接入非中台化的后台系统或是二方/三方的服务，也就是说 如果只为实现企业数字化能力共享的话可以没有中台，企业现有的IT系统都可以直接注册到开放平台，这在一定程度规避了中台建设非渐进式，投入高、风险大的问题。

技术平台 之前也有叫技术中台，但笔者觉得还是应该回归平台概念。建设好技术支撑能力，着力于研与运。研发侧建设企业内部研发平台（IDP）把项目全流程统一纳管起来，在此之上辅以低代码的能力，进一步降低项目研发门槛；运维侧建设安全、稳定、可观测的容器运行环境及各类标准化的中间件集群。以此作为领域中台及业务应用的技术支撑底座。

领域中台 回归到中台的初心，仅用于领域内各类可共享服务的聚合，向开放平台提供经过梳理、整合后的更为标准化的业务能力。

业务应用 借由开放平台提供的共享服务能力及技术平台提供的技术构建能力，聚焦于业务本身，实现敏捷的业务交付。

中台经过几年“滚雪球”的发展或是资本地运作，已是个“庞然大物”，是到了“减肥”，“减负”的时候。一言以避之：解构中台，让他融合到更大的IT能力共享架构中，把共享交给开放平台，把技术还给技术平台，让中台专注于领域服务及事件 。

*本文所指中台多为业务中台，数据中台需另当别论。