说透中台上 中台的概念和种类

开篇词 | 中台，昙花一现还是下一个风口/h2>

讲述：王健

你好，我是王健，是 ThoughtWorks 的首席咨询师，目前专注在企业架构和解决方案的相关方向上。因为近几年沉迷中台无法自拔，同事朋友们也给我起了个花名，叫“台长”，如果你乐意也可以这么叫我，很高兴能在这个专栏与你见面。

我与中台

与中台的第一次邂逅是在 2017 年，当时作为首席咨询师和系统架构师第一次实际参与到了一个大型企业的中台规划和落地项目中。作为一个已经在行业里摸爬滚打了 10 多年的老鸟，并且无论是在分布式系统架构、微服务架构、平台化建设方面都也有了非常多年的经验和积累，面对“中台”这样一个当时在我看来不过是新瓶装旧酒的概念，坦白来讲，一开始我并没有把它放在眼里。

但结果就是被啪啪打脸。整个过程推进得非常困难，从头到尾无论是我对于中台的理解还是我们规划与建设的方法都受到了客户不断的质疑和挑战，项目的范围无论从系统的层面还是从组织的层面也被扩大到几近失控。

但也就是这次过程，才让我开始意识到，中台这个概念跟我之前想象的可能完全不是同一个物种。也自此，我对中台产生了浓厚的兴趣，日思夜想，遍访高人，并将所学所思所想落笔成文，期望与更多人一起探讨。

截止目前，我主导或参与过的中台相关项目大大小小也有 10 多个了，很多疑问和困扰也在这个不断学习、思考与实践的过程中一一解开。同时今年也开始与公司和 区的小伙伴们一起，尝试沉淀一套通用的中台规划与建设方法，来帮助更多企业在中台的规划与建设过程中，少走一些我们走过的弯路。

关于专栏

虽然我对于中台非常痴迷，但当极客时间约我做中台的专栏时，我的心情还是非常复杂的。

首先肯定是非常开心，因为很希望能借助这样一个平台将自己的所想所得分享给更多的人，并且更希望能听到你的观点，你的意见和你对于中台有哪些问题。我们一起努力将这个概念或是工具理解得更加透彻，并最终利用它帮助我们解决实际的问题。

但同时也有一些惶恐，因为中台这个概念不像其他的技术那样成熟和清晰。业界对于这个概念本身也仍然没有一个统一的认识。我相信，这也是今天中台被大家热议的一个原因吧，大家都在关注，但是又很难讲清楚。

还有中台这个概念，无论是从涉及领域的宽度还是从战略到落地的纵深高度来讲，都是非常非常大的，向上可以触及到行业趋势、企业使命愿景战略，向下又可以落地到分布式架构、遗留系统重构、架构演进与守护、质量保证等等各个方面。而且就算是同一个行业，每家企业还都不一样。

想要通过一个专栏，既要把概念讲清楚，又不飘在天上，还可以指导和帮助大家将中台落地，在我看来这几乎是一个不可能完成的任务。

但幸运的是，在极客时间同学专业的支持，以及不断激（催）励（稿）下，经过不断的打磨，这个专栏最终还是跟你见面了，感谢的话留到最后再讲，我先来简单讲讲我是怎么设计这门课程的。

这门课是怎么设计的/h2>

今年 IT 圈中台的概念确实比较火，你可能在朋友圈或是各个媒体渠道上天天都能看到跟中台相关的文章和资讯。

但是大家讲的很多都是各个企业中台建设的结果，一张大大的线框图，对企业带来了怎样怎样的好处。

但中台到底是什么哪里来会到哪里去体又该怎么建设几个最基本的问题，谈到的其实并不是特别多，鲜有谈到的观点还都不太一致。

如果再将问题进一步展开，你就会发现有更多的问题仍然模糊不清。你可以跟我一起想一想，以下这些问题你有过同样的疑问吗/p>

• 中台与平台 / 微服务 /SaaS 的区别是什么/li>
• 中台与前台和后台的边界怎么界定了中台那后台是什么/li>
• 什么样的企业需要建中台，什么样的企业不需要建中台企业到底有哪些好处/li>
• 业务中台与数据中台的关系和区别又是什么/li>
• 中台建设有什么样的门槛，需要哪些准入条件/li>
• 中台该怎么建几个阶段要什么样的能力/li>
• 中台建设的结果好坏如何评估来评估/li>
• ……

相信这样的问题还有很多很多。这些问题也曾困扰着我，所以我希望能通过这个专栏，为你一一解答这些困惑，或者至少能给你带来一些启发。

在专栏的课程设计上，我的主要思路是分成三个部分：概念篇、落地篇和最后的答疑篇。

概念篇

在概念篇里，我首先会带你时光穿梭，重走一遍中台的诞生和发展之路，从时间的维度重新梳理一遍中台诞生的背景和几个关键点，看看它究竟从哪里来后会通过列举目前市面上常见的中台种类，在空间的维度同样发散，看一看各类五花八门的中台。最终通过收敛和归纳，一起来探究一下中台的本质，即当我们谈论中台时我们到底在谈些什么，给中台下个定义。

落地篇

在落地篇里，我会从概念引申到落地，看看为了避开中台建设过程中的各种坑，在开始中台建设前需要先想清楚哪些问题要有什么样的准入条件台建设方法论的本质是什么清楚了这些问题后，又有哪些方法和套路可以帮我们实现中台的平滑落地。

但是这里有一个前提需要提前声明一下，因为我们之前也提到了，中台的种类太多了，不同企业不同种类的中台，它们的建设方式可能完全不同，但是背后的思想都是相通的。

在落地篇里的后半部分，关于一个中台产品的设计与实施的内容，我会用一个最常见的业务中台建设场景来展开介绍，但是其中提到的方法和工具，对于其他的中台类型也同样适用。

答疑篇

这个专栏的答疑篇是我额外设计的一个小模块。因为中台涉及的范围之广、问题之多、复杂度之高，是很难在几次课程中就完全讲清楚的。我也非常希望在我们一起学习交流的过程中，你可以把对于中台或是我这门课程的问题提出来，我们随时在留言区进行沟通和讨论，同时我也会针对每个人都比较关心的问题，单独在答疑篇里有针对性地统一给你做一些解答。

业务中台

业务这个词，其实是有些宽泛的，我听到很多人口中说的业务都不是一个概念。为此，我还特地做了一些功课。业务，更白话一些来说，就是为了售出产品、换取利润，各行业中需要处理的商业上的相关事务。所以在早期我们通常会把于销售叫作业务员。

易副总裁汪源就曾在 易云创峰会上提到过：“所有的中台都是业务中台”。对于这个提法，我也是认同的，因为从广义上来看所有的中台，不论是业务中台还是数据中台，亦或其他，都是为业务，为企业可以更好地以更低的成本、更高的质量、更快的响应速度售出产品、换取利润服务的。

换个角度看，从企业架构的层面看，应用架构、技术架构、数据架构都是要匹配公司的业务架构的，因为“业务”，即售出产品、换取利润是企业的核心目标。

好，既然所有的中台都是业务中台，那我们经常提到的业务数据双中台中的业务中台，这里的究竟代表的是什么呢我来看，我们常提到的业务中台，是狭义层面的业务概念，业务中台需要具体承载支撑业务开展的必要业务元素，封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案。

这么说可能会比较空，我有一个技巧，当我思考业务中台时，我会不断地问自己一个问题：企业的业务能够顺利开展，需要解决哪些核心问题/strong>

比如电商的场景，如果我是一家电商企业，我业务要顺利开展，即把我的产品卖给用户，换取利润，一般要解决的核心问题无非包含：

• 我的用户是谁哪里来/li>
• 我卖的产品是什么哪里来/li>
• 怎么让用户知道我卖的产品/li>
• 用户为什么会买我卖的产品/li>
• 用户怎么买/li>
• 货怎么送/li>
• 用户怎么退换货/li>
• 怎么才能让用户不断地买/li>

而对于一家电商企业的不同业务线，大多是因为卖的产品不同，或是卖的区域不同，用户群体不同，但是这些问题也都是要解决的，大多数情况下解决的方法也是相通和类似的。这就是业务中台之所以能够存在的原因。

所以，我们常提到的业务中台，可以理解成狭义的业务中台，通过将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑。

介绍完了我们最常见的业务数据双中台，这里做个小结。

业务中台与数据中台相辅相成，互相支撑，互为输入输出。业务中台承载了企业的通用业务能力，为多业务线赋能；数据中台通过对于业务数据的二次加工，并反馈回业务中台，为业务进行数据和智能方面的赋能。两者的紧密配合一起为企业构建起了商业战场强大的后方炮火群，这也就构成了最著名的业务数据双中台模式。

非主流系列

在业务数据双中台之外，还出现过各式各样的中台，而这些中台的出现也让原本还比较清晰的中台概念变得有些模糊。那接下来我就快速为你介绍一些这几年我所接触过的中台，在我讲述的过程中，你也可以思考一下，这些中台中哪些是李逵，而哪些是李鬼，谁才真正配得上中台的称 ，谁又是来蹭流量的。

技术中台

除了业务数据双中台，最常被提到，在我看来介于主流和非主流之间的就得属技术中台了。技术中台相比业务中台和数据中台，边界也会更加清晰，简单来讲就是在 CloudNative 下将使用云或其他基础设施的能力、各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台和业务中台、数据中台的快速建设。不过业界也有说法，认为技术中台没有很强的业务属性，只是一些中间件的集合，顶多算是个中间件平台而已，称不上中台，你怎么看呢/p>

研发中台

软件开发是一项工程，涉及到管理、流程、测试、团队协作等等方面。如何将企业的开发流程、最佳实践沉淀成可重用的“能力”，从而助力创新性应用的快速开发迭代，也是我们看到的很多企业正在做的事情，我们可以管这种关注开发效能管理的平台叫作研发中台。

移动中台

在移动互联 时代，移动优先的原则已经成为不争的事实，将 App 开发过程中的通用技术组件进行封装沉淀到移动中台中，就可以在构建新的 App 时大量复用已有组件和能力，快速构建和响应。

管理中台

最近很多企业开始尝试把中台思维应用到企业内部，重新对“人”“事”“流程”“企业运营”进行平台化 / 中台化改造。试图通过中台化建设，加速企业管理标准化和提升运营能力。

组织中台

在穆胜老师的书《释放潜能：平台型组织的进化路线图》中，通过分析了海尔平台化组织的演进过程，他提出了组织中台的概念。组织中台很像企业中的内部风投和创新孵化机构，为前台组织和团队构建创新型前台应用提供类似于投资评估（项目甄别）、投资管理、投后管理（孵化与风控），真正从组织和制度上支撑前台组织和应用的快速迭代和规模化创新。

好了，非主流系列我们就介绍到这里。其实远远不止这些，其他还有像财务中台、采购中台、供应链中台、AI 中台、运营中台、安全中台、管理中台等等，也曾出现在我们的视野里，今天就不一一展开了。

总结思考

最后来做个总结。这一讲我带着你一起纵览了一下现在市面上比较常见的中台种类，此时的你可能比之前感觉更蒙了，原来还有这么多不同种类的中台存在，到底哪个是李逵那个李鬼，也傻傻分不清楚。而中台到底是什么这个终极问题，此时也一定还缠绕在你的脑海里。

不用担心，通过前两讲的发散，我想让你和我一样，先把视野打开，从时间的维度和空间的维度先建立起一个全局观，下一讲我们就将做第一次收敛，来探究中台的本质。

最后，给你留几个思考题：

• 你自己企业有中台吗哪种类型/li>
• 对于以上提到的这些中台，你是否也有不同的理解/li>
• 除了我们今天讲到的，你还见过哪些种类的中台/li>
• 你自己是否有一个标准来判断哪些是中台/li>

欢迎你在留言区发表自己的观点，期待和你一起讨论。也欢迎你把今天的内容分享给自己的朋友，我们下一讲见！

03 | 中台定义：当我们谈中台时到底在谈些什么/h2>

你好，我是王健。

前面两讲，我带你从时间维度重新走了一遍中台的发展历程，又在空间维度为你介绍了目前市面上出现过的各类中台。

估计你现在一定被这么多种类的中台搞的有点晕头转向了，这些中台都称的上是中台么觉和之前一直在做的平台也没有什么两样啊/p>

这也是我过去几年一直在内心不断问自己的问题。这一讲作为概念篇的最后一篇，我就试着带你跳出时间与空间的维度，来分析一下企业为什么要建中台我们谈中台时，我们到底在谈些什么/p>

企业为什么要建中台/h2>

我们先来看企业为什么要建中台要回答这个问题，咱得先解决另一个问题，那就是企业为什么需要平台化/p>

企业为什么需要平台化呢给我的答案：

因为在当今这样一个互联 时代，用户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。

这背后的逻辑很简单，不断地快速响应、探索、挖掘、引领用户的需求，才是企业得以生存和持续发展的关键因素。

那些真正尊重用户，甚至不惜调整自己、颠覆自己来响应用户的企业，将在这场以用户为中心的商业战争中得以生存和发展。反之，那些在过去的成就上故步自封，存在侥幸心理希望用户会像之前一样继续追随自己的企业，则会被用户淘汰。

很残酷，但这就是这个时代最基本的的企业生存法则。

好，现在我们想明白了第一个问题，企业为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起于企业来讲，传统的“前台 + 后台（或是平台）”的平台化架构为什么不能满足企业的要求呢/p>

这就引出了我们的核心问题：企业为什么要建中台/p>

同样，先给我的答案：

中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。

为了能够更清楚地讲解我的观点，这里需要先定义一下，在今天我们讨论的上下文下，前台和后台分别指什么。

• 后台：由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源（数据 + 计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。（在和很多互联 的朋友聊过之后，在互联 企业很多并没有后台的概念，更多直接使用平台的概念，例如分为前台层和平台层，但位置和作用与传统企业里的后台相似，我这里直接统一使用后台这个概念来代表。）

定义了前台和后台，我们再回过头来看企业为什么要建中台这个问题。

我们看到很多企业的后台，在创建之初的目标，并不是主要服务于前台系统的业务创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱采购的套装软件，需要每年支付大量的服务费，并且版本有的也已经非常老旧了，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，基本改不动了，也是企业所谓的“遗留系统”的重灾区。

可以这么说，大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度就根本跟不上前台业务发展的节奏。总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。

有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个 2.0，问题不就解决了/p>

这是一种解决问题的思路，不过就算是新建的后台系统，因为后台管理的往往是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制，这样的系统也往往?法被前台系统直接使用，或是受到各类限制?法快速变化，不能?持前台快速的业务创新需求。

此时的前台和后台就像是两个不同转速的齿轮，前台由于要快速响应前端用户的需求，讲究的是快速迭代创新，所以要求转速越快越好；而后台由于面对的是相对稳定的企业核心后端资源，而且往往系统陈旧复杂，甚至还受到法律法规、审计等相关合规约束，一般是追求稳定至上，越稳定越好， 转速也自然是越慢越安全。

所以，随着企业业务的不断发展，这种“前台 + 后台”的齿轮速率“匹配失衡”的问题就逐步显现出来了。

企业业务不断发展壮大，后台修改的成本和风险越来越?，这就驱使我们尽量保持后台系统的稳定性，但同时还要响应用户持续不断的需求，怎么办自然的就是将大量的业务逻辑（业务能力）直接塞到前台系统中，因为前台离用户近，响应也相对快。

但是这样也是有代价的，这样的后果就是引入重复，同时还导致前台系统不断膨胀，变得臃肿，形成了一个个大泥球的“烟囱式单体应用”。这个局面的结果就是，前台系统的“用户响应力”被渐渐拖垮，用户满意度逐渐降低，企业竞争力也随之不断下降。

对于这样的问题，Gatner 在 2016 年发布了一份 告 Pace-Layered Application Strategy。 告中给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次（正好契合前中后台的三个层次），不同的层次采用完全不同的策略。

而 Pace-Layered Application Strategy 也为“中台”产生的必然性，提供了理论上的支撑。

在这份 告中，Gatner 提出，企业构建的系统从 Pace-Layered 的角度来看可以划分为三类：SOR（Systems of record ），SOD（Systems of differentiation）和 SOI（Systems of innovation）。每一类的系统都有着不同的变化速率，因此也会有不同的生命周期，适合不同的技术架构和不同的开发过程，甚至是采用不同的投资模式。

回到之前说的后台与前台的两层架构，如果映射到这个模型上其实就是只有 SOR（后台）与 SOI（前台）的两层应用架构。这样的情况下，我们又要尽力保持后台（SOR）系统的稳定可靠，?要前台系统（SOI）能够?而美，快速迭代。因此就自然出现了上文提到的“齿轮匹配失衡”的问题，感觉鱼与熊掌不可兼得。

怎么办ace-Layered 中的 SOD 就是答案，它提供了比前台（SOI）更强的稳定性，以及比后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了?种美妙的平衡。

中台就是 SOD。有了这层“中台”，我们既可以将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层，为前台减肥，恢复前台的响应力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本；或者干脆直接对于后台进行中台化改造，通过配置化、自助化、白屏化等形式为后台加速，从而为前台提供更强大、更迅捷、更易用的“能力炮火”支援。

中台就像是在前台与后台之间添加的?组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁和润滑剂。它为前台而生，易于前台使用，将后台资源顺滑地通过前台导流向用户，支撑企业更好地响应用户。

好了，现在我们可以小结一下，回答企业为什么需要建中台这个问题了。很简单，企业在平台化的过程中，为了能不断地给前台业务提供更好的服务，来支撑企业对于用户的持续响应，增加企业的用户响应力，企业需要构建自己的中台。

给中台下个定义

讲了这么关于中台的来龙去脉，以及种种表现形式，也讲了我对于企业平台化与中台化的理解，但你可能仍然会觉得比较抽象，所以我想，一定要试着给中台下个定义。

为什么需要一个定义呢不是因为别的原因，我是觉得需要给自己一把简单的尺子，让我能轻易记住中台的特性，并能用它来快速判断一个所谓的中台是不是满足我对于中台的理解，所以我给中台的定义就是：

企业级能力复用平台。

很简单，是不是有点失望是为了找到一个我觉得还靠谱的定义，我几乎花了快两年的时间，期间有各种各样的定义曾浮现出来，但至少到目前为止，我觉得只有这个定义最贴切、最简单、也最准确，它能解释几乎所有我碰到的关于中台的问题，例如：

• 为什么会有那么多中台/li>
• 中台化与平台化的区别是什么/li>
• 中台化和服务化的区别是什么/li>
• 中台该怎么建设/li>
• ……

这 9 个字看起来简单，重要的是其背后对“中台”价值的阐释，下面就让我为你一一拆解来看。

1. 企业级

企业级定义了中台的范围。不是说一个企业只能有一个中台，也不代表一个中台就是只能包含一家企业，企业级更多代表的是中台处理的问题在企业级别，即至少包含多条业务线或服务多个前台产品（团队），如果一个中台只为了支持一条业务线或产品线，那就不是中台，即使它用了服务化或是大数据等技术。

企业级这一点非常非常重要。它让我想清楚了，中台建设的事情并不是一个技术问题，而是一个要上升到企业架构的问题。做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景。

想清楚了这一点，我对中台的理解就有了一次质的变化，也终于知道为什么一开始用做系统服务化的方式做中台会面临那么多的问题，比如最常见的组织和干系方以及利益再分配的问题。

从中台的兴起与爆发我们也能看到一个趋势，就是越来越多的企业，无论是想提升自身的运营效率，还是出于业务创新发展的需求，都已经把企业全局视角、跨业务线的能力沉淀，提到了前所未有的战略高度。

2. 能力

提到中台，最常听到的一个词就是“能力”。可能是因为能力这个词足够简单，又有着足够的包容度与宽度。

能力定义了中台主要承载的对象。

能力的抽象解释了为什么会有那么多种类中台的存在，也能解释为什么每家企业的中台都不一样，因为不同的企业之所以能够同时存在，就是因为其核心能力不同，可以满足用户不同层面的需求，也就是我们常说的差异化竞争力。

3. 复用

复用定义了中台的核心价值，也承载了上面讲到的从平台化到中台化的演进过程。传统的平台化对于“可复用性”和“易复用性”并没有给予足够的关注，更多关注的是如何消除掉重复的能力建设，既所谓的“去重”。

但中台的提出和兴起，体现出一种对于前台业务的使用体验更加关注的趋势。让人们通过对于“可复用性”和“易复用性”的关注，将目光更多地从平台内部的建设转换到平台对于前台业务的支撑上。这里有一个从治理到赋能的视角转换，既从“去重”到“复用”的关注上。

“去重”与“复用”虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情，目的不同，难度也不同。“去重”讲的更多是向后看，是技术驱动的；“复用”讲的更多是向前看，是业务驱动和用户驱动的。而正这个视角的转变，我认为是理解中台概念的关键，所以

• “复用”是中台更加关注的目标；
• “可复用性”和“易复用性”是衡量中台建设好坏的重要指标；
• “业务响应力”和“业务满意度”是考核中台建设进度的重要标准。

这也能解释为什么很多互联 企业，将对于平台的治理，通过业务抽象以及可配置化和白屏化的改造升级，把这个过程称之为对于平台的中台化改造过程。

4. 平台

平台定义了中台的主要形式。区别于传统应用系统拼凑的方式，中台通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务，来满足对于业务的快速响应和复用的需求。

“企业级能力复用平台”这个定义虽然看起来简单，但经过这么长时间对于中台的实践与思考，我觉得这个定义背后所代表的意义是目前对中台价值的最贴切的阐释。

• “企业级”定义了中台的范围，区分开了单系统的服务化与微服务；
• “能力”定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
• “复用”定义了中台的核心价值，传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上；
• “平台”定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务。

总结思考

今天我们从企业为什么需要平台化入手，讨论了企业又为什么需要建中台。结合前两讲的内容给出了我的观点，不知道对你有没有启发，让我最后再来总结一下。

以用户为中心的持续规模化创新，是中台建设的核心目标。企业的用户响应能力和规模化创新能力，是互联 时代企业综合竞争力的核心体现。平台化包括中台化只是帮助企业达到这个目标的手段，并不是目标本身。

中台（?论是技术中台、业务中台还是组织中台）的建设，根本上是为了解决企业响应力困境， 弥补创新驱动需要快速变化的前台和稳定可靠驱动需要变化周期相对较慢的后台之间的矛盾，提供?个中间层来适配前台与后台的配速问题，打通并顺滑链接前台需求与后台资源，帮助企业从整体上不断提升用户响应力。

所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于用户的响应力才是最重要的。而平台化或是中台化，只是恰巧走在了这条正确的大道上。

最后我们给中台下了一个定义，既“企业级能力复用平台”。有了这个定义后，我们不仅可以把它当作一把尺子来丈量一个中台是否货真价实，对于如何建中台的思路也能豁然开朗。

因为如果说“中台就是企业级能力复用平台”的话，那“中台化”也就是“利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程”。

好了，从下一讲开始我们就正式进入落地篇，一起来看看我们是如何规划与落地实施中台的。

最后，给你留几个思考题：

• 你的企业真的需要中台吗/li>
• 如果让你用一句话来给中台下个定义，你会怎么讲/li>
• 在你所在的企业，中台是解决方案还是问题本身/li>

中台还是组织中台）的建设，根本上是为了解决企业响应力困境， 弥补创新驱动需要快速变化的前台和稳定可靠驱动需要变化周期相对较慢的后台之间的矛盾，提供?个中间层来适配前台与后台的配速问题，打通并顺滑链接前台需求与后台资源，帮助企业从整体上不断提升用户响应力。

所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于用户的响应力才是最重要的。而平台化或是中台化，只是恰巧走在了这条正确的大道上。

最后我们给中台下了一个定义，既“企业级能力复用平台”。有了这个定义后，我们不仅可以把它当作一把尺子来丈量一个中台是否货真价实，对于如何建中台的思路也能豁然开朗。

因为如果说“中台就是企业级能力复用平台”的话，那“中台化”也就是“利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程”。

好了，从下一讲开始我们就正式进入落地篇，一起来看看我们是如何规划与落地实施中台的。

最后，给你留几个思考题：

• 你的企业真的需要中台吗/li>
• 如果让你用一句话来给中台下个定义，你会怎么讲/li>
• 在你所在的企业，中台是解决方案还是问题本身/li>

期待你在留言区分享自己的想法，也欢迎你把今天的内容分享给朋友，和他一起学习讨论。我们下一讲见！