03 中台定义：当我们谈中台时到底在谈些什么？
你好，我是王健。
前面两讲，我带你从时间维度重新走了一遍中台的发展历程，又在空间维度为你介绍了目前市面上出现过的各类中台。
估计你现在一定被这么多种类的中台搞的有点晕头转向了，这些中台都称的上是中台么？感觉和之前一直在做的平台也没有什么两样啊？
这也是我过去几年一直在内心不断问自己的问题。这一讲作为概念篇的最后一篇，我就试着带你跳出时间与空间的维度，来分析一下企业为什么要建中台？当我们谈中台时，我们到底在谈些什么？
企业为什么要建中台？
我们先来看企业为什么要建中台？想要回答这个问题，咱得先解决另一个问题，那就是企业为什么需要平台化？
企业为什么需要平台化呢？先给我的答案：
因为在当今这样一个互联网时代，用户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。
这背后的逻辑很简单，不断地快速响应、探索、挖掘、引领用户的需求，才是企业得以生存和持续发展的关键因素。
那些真正尊重用户，甚至不惜调整自己、颠覆自己来响应用户的企业，将在这场以用户为中心的商业战争中得以生存和发展。反之，那些在过去的成就上故步自封，存在侥幸心理希望用户会像之前一样继续追随自己的企业，则会被用户淘汰。
很残酷，但这就是这个时代最基本的的企业生存法则。
而平台化之所以重要，就是因为在这场以用户为中心的现代商业战争中，它赋予或加强了企业最核心的能力：用户响应力。平台化思想（Platform Thinking）恰好鼓励企业不断抽象沉淀自己核心的底层能力，通过平台化包装，得以更好地赋能前台业务，用底层的确定性来帮助企业应对前台业务以及最终用户需求的不确定性。
从结果来看，在不确定性当道的当今商业战场，真正的弄潮儿也大多是那些具备平台化思维并很早就开始发力平台建设的企业，这也在一定层面上佐证了平台化对于一家企业的重要性。
好，现在我们想明白了第一个问题，企业为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台+后台（或是平台）”的平台化架构为什么不能满足企业的要求呢?
这就引出了我们的核心问题：企业为什么要建中台？
同样，先给我的答案：
中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。
为了能够更清楚地讲解我的观点，这里需要先定义一下，在今天我们讨论的上下文中，前台和后台分别指什么。
- 前台：由各类前台系统组成的前端业务平台。每个前台系统都是一个用户触点，大多是企业最终用户直接使用的系统，是企业与最终用户的交点。例如用户直接使用的网站、手机App、微信公众号、小程序等都属于前台范畴。
- 后台：由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。（在和很多互联网的朋友聊过之后，在互联网企业很多并没有后台的概念，更多直接使用平台的概念，例如分为前台层和平台层，但位置和作用与传统企业里的后台相似，我这里直接统一使用后台这个概念来代表。）
定义了前台和后台，我们再回过头来看企业为什么要建中台这个问题。
我们看到很多企业的后台，在创建之初的目标，并不是主要服务于前台系统的业务创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱采购的套装软件，需要每年支付大量的服务费，并且版本有的也已经非常老旧了，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，基本改不动了，也是企业所谓的“遗留系统”的重灾区。
可以这么说，大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度就根本跟不上前台业务发展的节奏。总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个2.0，问题不就解决了？
这是一种解决问题的思路，不过就算是新建的后台系统，因为后台管理的往往是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制，这样的系统也往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，不能⽀持前台快速的业务创新需求。
此时的前台和后台就像是两个不同转速的齿轮，前台由于要快速响应前端用户的需求，讲究的是快速迭代创新，所以要求转速越快越好；而后台由于面对的是相对稳定的企业核心后端资源，而且往往系统陈旧复杂，甚至还受到法律法规、审计等相关合规约束，一般是追求稳定至上，越稳定越好， 转速也自然是越慢越安全。
所以，随着企业业务的不断发展，这种“前台+后台”的齿轮速率“匹配失衡”的问题就逐步显现出来了。
企业业务不断发展壮大，后台修改的成本和风险越来越⾼，这就驱使我们尽量保持后台系统的稳定性，但同时还要响应用户持续不断的需求，怎么办？最自然的就是将大量的业务逻辑（业务能力）直接塞到前台系统中，因为前台离用户近，响应也相对快。
但是这样也是有代价的，这样的后果就是引入重复，同时还导致前台系统不断膨胀，变得臃肿，形成了一个个大泥球的“烟囱式单体应用”。这个局面的结果就是，前台系统的“用户响应力”被渐渐拖垮，用户满意度逐渐降低，企业竞争力也随之不断下降。
对于这样的问题，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）能够⼩而美，快速迭代。因此就自然出现了上文提到的“齿轮匹配失衡”的问题，感觉鱼与熊掌不可兼得。
怎么办？Pace-Layered中的SOD就是答案，它提供了比前台（SOI）更强的稳定性，以及比后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。
中台就是SOD。有了这层“中台”，我们既可以将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层，为前台减肥，恢复前台的响应力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本；或者干脆直接对于后台进行中台化改造，通过配置化、自助化、白屏化等形式为后台加速，从而为前台提供更强大、更迅捷、更易用的“能力炮火”支援。
中台就像是在前台与后台之间添加的⼀组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁和润滑剂。它为前台而生，易于前台使用，将后台资源顺滑地通过前台导流向用户，支撑企业更好地响应用户。
好了，现在我们可以小结一下，回答企业为什么需要建中台这个问题了。很简单，企业在平台化的过程中，为了能不断地给前台业务提供更好的服务，来支撑企业对于用户的持续响应，增加企业的用户响应力，企业需要构建自己的中台。
给中台下个定义
讲了这么关于中台的来龙去脉，以及种种表现形式，也讲了我对于企业平台化与中台化的理解，但你可能仍然会觉得比较抽象，所以我想，一定要试着给中台下个定义。
为什么需要一个定义呢？倒不是因为别的原因，我是觉得需要给自己一把简单的尺子，让我能轻易记住中台的特性，并能用它来快速判断一个所谓的中台是不是满足我对于中台的理解，所以我给中台的定义就是：
企业级能力复用平台。
很简单，是不是有点失望？但是为了找到一个我觉得还靠谱的定义，我几乎花了快两年的时间，期间有各种各样的定义曾浮现出来，但至少到目前为止，我觉得只有这个定义最贴切、最简单、也最准确，它能解释几乎所有我碰到的关于中台的问题，例如：
- 为什么会有那么多中台？
- 中台化与平台化的区别是什么？
- 中台化和服务化的区别是什么？
- 中台该怎么建设？
- ……
这9个字看起来简单，重要的是其背后对“中台”价值的阐释，下面就让我为你一一拆解来看。
1.企业级
企业级定义了中台的范围。不是说一个企业只能有一个中台，也不代表一个中台就是只能包含一家企业，企业级更多代表的是中台处理的问题在企业级别，即至少包含多条业务线或服务多个前台产品（团队），如果一个中台只为了支持一条业务线或产品线，那就不是中台，即使它用了服务化或是大数据等技术。
企业级这一点非常非常重要。它让我想清楚了，中台建设的事情并不是一个技术问题，而是一个要上升到企业架构的问题。做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景。
想清楚了这一点，我对中台的理解就有了一次质的变化，也终于知道为什么一开始用做系统服务化的方式做中台会面临那么多的问题，比如最常见的组织和干系方以及利益再分配的问题。
从中台的兴起与爆发我们也能看到一个趋势，就是越来越多的企业，无论是想提升自身的运营效率，还是出于业务创新发展的需求，都已经把企业全局视角、跨业务线的能力沉淀，提到了前所未有的战略高度。
2.能力
提到中台，最常听到的一个词就是“能力”。可能是因为能力这个词足够简单，又有着足够的包容度与宽度。
能力定义了中台主要承载的对象。
能力的抽象解释了为什么会有那么多种类中台的存在，也能解释为什么每家企业的中台都不一样，因为不同的企业之所以能够同时存在，就是因为其核心能力不同，可以满足用户不同层面的需求，也就是我们常说的差异化竞争力。
3.复用
复用定义了中台的核心价值，也承载了上面讲到的从平台化到中台化的演进过程。传统的平台化对于“可复用性”和“易复用性”并没有给予足够的关注，更多关注的是如何消除掉重复的能力建设，既所谓的“去重”。
但中台的提出和兴起，体现出一种对于前台业务的使用体验更加关注的趋势。让人们通过对于“可复用性”和“易复用性”的关注，将目光更多地从平台内部的建设转换到平台对于前台业务的支撑上。这里有一个从治理到赋能的视角转换，既从“去重”到“复用”的关注上。
“去重”与“复用”虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情，目的不同，难度也不同。“去重”讲的更多是向后看，是技术驱动的；“复用”讲的更多是向前看，是业务驱动和用户驱动的。而正这个视角的转变，我认为是理解中台概念的关键，所以
- “复用”是中台更加关注的目标；
- “可复用性”和“易复用性”是衡量中台建设好坏的重要指标；
- “业务响应力”和“业务满意度”是考核中台建设进度的重要标准。
这也能解释为什么很多互联网企业，将对于平台的治理，通过业务抽象以及可配置化和白屏化的改造升级，把这个过程称之为对于平台的中台化改造过程。
4.平台
平台定义了中台的主要形式。区别于传统应用系统拼凑的方式，中台通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务，来满足对于业务的快速响应和复用的需求。
“企业级能力复用平台”这个定义虽然看起来简单，但经过这么长时间对于中台的实践与思考，我觉得这个定义背后所代表的意义是目前对中台价值的最贴切的阐释。
- “企业级”定义了中台的范围，区分开了单系统的服务化与微服务；
- “能力”定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
- “复用”定义了中台的核心价值，传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上；
- “平台”定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务。
总结思考
今天我们从企业为什么需要平台化入手，讨论了企业又为什么需要建中台。结合前两讲的内容给出了我的观点，不知道对你有没有启发，让我最后再来总结一下。
以用户为中心的持续规模化创新，是中台建设的核心目标。企业的用户响应能力和规模化创新能力，是互联网时代企业综合竞争力的核心体现。平台化包括中台化只是帮助企业达到这个目标的手段，并不是目标本身。
中台（⽆论是技术中台、业务中台还是组织中台）的建设，根本上是为了解决企业响应力困境， 弥补创新驱动需要快速变化的前台和稳定可靠驱动需要变化周期相对较慢的后台之间的矛盾，提供⼀个中间层来适配前台与后台的配速问题，打通并顺滑链接前台需求与后台资源，帮助企业从整体上不断提升用户响应力。
所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于用户的响应力才是最重要的。而平台化或是中台化，只是恰巧走在了这条正确的大道上。
最后我们给中台下了一个定义，既“企业级能力复用平台”。有了这个定义后，我们不仅可以把它当作一把尺子来丈量一个中台是否货真价实，对于如何建中台的思路也能豁然开朗。
因为如果说“中台就是企业级能力复用平台”的话，那“中台化”也就是“利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程”。
好了，从下一讲开始我们就正式进入落地篇，一起来看看我们是如何规划与落地实施中台的。
最后，给你留几个思考题：
- 你的企业真的需要中台吗？
- 如果让你用一句话来给中台下个定义，你会怎么讲？
- 在你所在的企业，中台是解决方案还是问题本身？
期待你在留言区分享自己的想法，也欢迎你把今天的内容分享给朋友，和他一起学习讨论。我们下一讲见！
- 笑若海 👍（67） 💬（0）
我觉得平台与后台的关系可以借助System of systems的概念来理解，后台对应systems，对应于企业建立的各种职能IT系统（如CRM ERP OA 库存管理 采购 供应链 研发 制造等）；平台对应system，将职能IT系统有机集成起来，作为一个整体对前台服务，而不是各个职能系统之间的点到点集成对前台提供服务。 平台层在互联网企业中兴起前已经存在，只是传统企业中IT部门作为辅助职能部门，缺少话语权和主导性，没能上升到企业级高度。而互联网企业敏捷、快速响应用户的企业文化将平台化做到了新的企业级高度。 平台与中台的异同——“中台是企业级能力复用平台”这一概念解释的非常准确，平台化刚被互联网企业喊出时，侧重于IT能力去重，是cost saving，中台则侧重业务能力灵活复用，是value add。 平台化/中台化本质上就是企业IT系统集成的一种设计理念，以高效的价值创造和成本控制为目标。
2019-10-06 - XuToTo 👍（37） 💬（6）
那么所谓的 BFF 是否算是一种「中台」呢？
2019-09-25 - MG 👍（21） 💬（3）
老师您好，请问“复用”和“去重”有什么区别呢？我能理解“去重”，即是“去掉重复的”，那么既然“去掉”了“重复的”了，不就是在“复用”了么？请老师指教，谢谢！
2019-10-01 - 业余草 👍（15） 💬（2）
中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。
2019-09-26 - vkingnew 👍（11） 💬（1）
中台 个人的理解，承上（前台）启下（后台），提高数据等公共资源的复用能力，提高开发和服务的效率，对前中后台来说即高内聚低耦合，各司专职。
2019-09-26 - rexzhao 👍（10） 💬（1）
老师你在文中说，中台关注为前台业务赋能，真正为前台而生。如果前台的概念是最终用户直接使用的系统，而后台则是企业内部的财务管理系统，资源管理系统。 那为什么中台不能也为后台赋能呢？我们之前给客户做的系统或服务就是在用户之前的HR管理或财务管理系统上做很多的报表的制作和修改，中台能帮到这类系统吗？谢谢。
2019-09-30 - hanbing 👍（7） 💬（3）
前台和中台的边界应该如何准确的界定？公司也在建中台，前台和中台经常因为边界问题该你做还是我做产生争执，应该如何准确的定义边界呢？
2019-09-28 - Mr_杨 👍（5） 💬（2）
一直关注中台相关的内容，但一直无法准确制定中台，平台，微服务这几个关系和边界。 说说我的理解，比如交易平台，提供的只是交易的通用服务，比如成单，查询，改单，可以认为这是微服务(不知是否准确)。这种服务只是抽象了功能，和交易行为，无法区分不同业务线的交易，这时候就需要中台将业务抽象化，比如外卖，线上，线下交易所需要的流程不同，(线上和外卖需要履约流程），这时候就需要中台将交易业务流程进行组合抽象，对外提供不同业务的执行流程。 总结一下就是微服务或者平台是对功能的抽象，中台是对业务的抽象，欢迎大家给不同意见
2019-09-30 - Darren 👍（4） 💬（1）
一个中台的构建过程是：功能->系统->平台->中台，我觉得老师的定义特别的棒，看到后恍然大悟，我在上节课的留言虽然和老师定义的‘企业级服用能力’有点类似，但是没有老师的清晰明了，最后稍微补充下，企业级的复用能力，可能各个能力在被复用的时候，或多或少有稍许不同，在中台化实现的时候们，可以通过扩展点去实现。
2019-09-26 - zart 👍（3） 💬（1）
请问老师，白屏化是指啥？
2019-10-10 - 未未的未来 👍（3） 💬（1）
个人理解，中台：满足业务需求的即开即用的工具箱。
2019-09-28 - 水源 👍（3） 💬（3）
我认为某些项目驱动型企业在刚开始的阶段，并不会从全局视角体识别出自己具备哪些可以复用的的“能力”，因为烟囱建的太多了。项目负责人、技术负责人都在围绕各类需求修补烟囱。这时开展中台策略，由于人手问题、项目进度问题，会另大家无从下手。而系统服务化，应该是比较好的切入点，对于烟囱中存在一个或者两个主要通病（痛点）的部分，抓出来进行服务化尝试，使他逐渐演化为中台的一部分，在不影响项目进度的前提下，体会到“能力”的存在。然后再对烟囱逐步拆分，中台化。
2019-09-26 - xiaosui1209 👍（2） 💬（1）
业务中台和数据中台的意义很清晰，但是技术中台呢？企业的技术架构一直以来就是向着平台化组件化演进的，技术架构提供的能力也本来就是企业级可复用的，那么我们为什么要说技术中台这个词，它和企业传统的技术架构的本质区别在哪里？
2019-10-14 - Gopher 👍（2） 💬（1）
老师的见解很深刻、全面，大赞，感谢解惑！～ 花了2个小时来学习这篇文章、查资料、做笔记～如获至宝🤪🤣
2019-09-30 - at三月 👍（1） 💬（1）
# 03 | 中台定义：当我们谈中台时到底在谈些什么？# 『中台就是企业级能力复用平台』——这是我听到最概括、但又是最准确的对中台的定义。原先困扰自己很久的平台和中台的关系，到此刻终于明白：平台只是中台的存在的形式，只要满足企业级、能力复用的基础要求，就能被称为中台，而不管是什么类型的平台。有时越精炼的语言越能直击要点，使人豁然开朗。
2019-12-20