从19年中开始，中台概念的热度突然间蹭的一下就上去了，而我所在的企业（某头部电商企业）则在去年年底提出了全面建设中台的战略，于是我便吭哧吭哧的在中台这个大坑里倒腾了大半年；期间起起伏伏的血泪总结，将在后文中与君分享，并借此分享真心希望帮助即将走上中台建设与正在进行中台建设的朋友们少走弯路。
中台的缘起
明确中台建设的目的十分重要！十分重要！十分重要！
关于中台的缘起，想必阿里的例子，大家已经听得耳朵起茧了：为了快速支持业务扩展，同时降低开发成本，阿里把能够通用的服务抽离出来并以中台的形式来提供共享服务。
那么，在这一句大家都耳熟能详的关于中台的定义中，中台它最核心的目标又是什么呢？
避免重复开发？
抽离通用服务？
不，这些都只是手段。
中台最核心的目标，没有之一，就是快速响应业务诉求。
以终为始，方得善终。
以我们中台项目团队的亲身经历来回顾的话，在整个项目的一开始，领导给项目团队制定的目标就是，减少系统之间的重复开发，最短时间内，先把能够抽象的公共服务完成打造。
整个项目团队，二三十号人，吭哧吭哧的搞了好几个月之后，总算是把第一阶段的公共服务完成交付了。
但是极其残酷的现实摆在面前：业务团队根本不买单，而且毫不避讳地说这个东西的作用不大。
而在这一堆的公共服务打造的这几个月里，所有的业务需求几乎全部停滞。
换句话来说，在这几个月的中台的打造工程中，我们只是把原来已有的系统进行重新整合或者重构，又或者说是把原来一些业务同学认为并不是十分重要的功能模块实现了通用化打造，但对于业务同学来说，最急最痛的一些东西，并没有得到很好的满足。
总结起来就是：你给的我不要，我要的你不给。
为什么会得到这一荒诞的结果呢？
很重要的一个原因就是把目的和手段搞反了：为了做中台而做中台，为了通用化而通用化。
但我们不妨再细想一层，我们为什么要做中台？我们为什么要做通用化？这不都是为了更快速的响应业务的诉求吗？
所以说，建设中台的目的，从来都是为了快速有效的响应业务诉求，通用化这些都只是手段而已。
中台的定义
关于中台的定义，我十分认同王健老师的观点：中台就是企业级能力的复用。
拿大家熟悉的阿里巴巴的例子来说，他们把电商业务核心的模块都梳理出来，并以共享的形式对前台提供服务，这些核心的业务模块包含：用户中心，商品中心，交易中心，支付中心，库存中心，物流中心。
而这些中心本质上就是阿里这个电商帝国核心的企业级能力，阿里通过把这些核心能力的中台化，让阿里的电商版图在业务扩张的过程中，能够快速的复用这些核心能力，最终达到快速响应业务的目的。
下面我们来一一细数这中台定义的关键词。
1. #企业级
企业级，就是说，中台这个东西，在设计的时候，就应该站在全盘来考虑，做出来的东西定位是企业层的某项能力，而不单单是某个业务线或者某个项目组内部使用。站在全盘的角度来进行业务的抽象与复用，站在全盘的角度来考虑数据服务的融合与通用，并借此支持业务的快速与低成本的扩展。
基于上面的阐述：中台做出来的东西定位是企业层级的某项通用能力，中台的打造大概率涉及业务线和组织的调整。
如原先独立的两条业务线的交易模块，在打造中台的交易中心的时候，必定涉及原先这两个团队中该系统模块的整合与人员的调整；这样的调整下，必定需要由公司高层出面推进，即自上而下的推动，推动业务线的整合，推动利益的重新分配。
2. #能力
这里用的是能力这个词，或者服务这个词，而不是用系统、功能、模块这些词——就像产品的定位一样，所有产品的，用户消费的时候，本质上都是为了得到某个能力或者服务。中台的打造也是一样的，中台的打造不是为了把原来的某个系统，某个功能在企业层面做整合打通，中台要做的是能力的抽象和共享。
这个能力每个企业都有自己的现实情况，如数据能力、技术能力、算法能力、业务能力等；具体要从哪些能力方面入手，要把哪些能力中台化，这个都需要每个企业结合自己的实际情况，结合企业的战略，结合企业的市场定位，综合再做决定。
而判断的标准说来既简单也复杂：业务在后续的发展中，最高频、最迫切需要解决的是哪些场景问题。
3. #复用
提到“复用“这个词，或者“共享“这个词的话，想必很多朋友对中台的认知都是如此吧？
其实复用这个概念在整个行业提了很多年了，例如编写代码的时候，封装函数，各方调用，就有点这个味道。
只是说，中台这个概念把「复用」这个概念的重要程度提升到了一个新的高度，而且从单单一个函数的复用，上升到了业务能力、数据能力、AI能力的高度。
读到这里的时候，其实不少的朋友一定会在心里默默地念叨：阿里的中台战略之所以这么成功，很大一部分原因就是因为阿里绝大部分的业务都是属于电商类业务，业务上面存在很多的共性，所以才可以复用，所以做中台对于像阿里这样的电商帝国来说，才是一个很好的选择。
但这是不是就意味着说做中台的企业，必须都是业务模式比较集中的呢？
这个我觉得倒是未必。
中台的本质
经历过了这大半年的实践之后，我对中台的本质最深的认知就是：中台的本质是一种企业级能力复用的设计思维。
在企业业务发展的过程中，在满足业务发展的系统建设过程中，每一个系统，每一个模块的设计和打造，我们都要去思考：是否有做通用化的必要？或者在未来的业务场景里是否有通用性的诉求？
至于说是否需要都像阿里那样，弄一个中台部门出来，把各大核心模块全部打造成一个中台系统——我倒是觉得未必。
例如我们在做电商卖场货品结构分析的时候：
在一开始的时候，我们只做了一个卖场，但是这个模块在设计之初就有一个很重要的考量点：这个模块后续能否为其他的卖场继续提供货品结构分析服务？以及这个服务直接复用之后是否能够直接满足其他业务线的需求？
又例如创业公司在打造自己的用户中心的时候：
在业务的前期，可能只有一两条业务线，而为了业务的快速扩展，在打造新产品线的时候，可能会为了求快而采取新的用户系统。但是这些用户系统设计的时候，都面临同一个问题的挑战：后续多个系统间的用户体系如何才能更加高效低成本的融合？
所以说，中台本质上就是一种企业级能力复用的设计思维。
也正因为这是一种思维方式，故而真没必要给自己加那么多的条条框框，没必要拘泥于市面上各种中台的系统现状和中台应该长什么样的定义：以快速支持业务扩张为目的，以企业级能力复用为设计思维——就可以了。
这就好比编程中的函数思维一样，把一些通用的逻辑，封装在一起，然后各方直接调用即可。
就像现在很多的算法，你要是刨根问底的解释起来或者从零开始写的话，那叫一个复杂；但是当前很多的算法调用对应到python的语句中，就是一行函数而已，各方调用同一个算法的时候都十分的方便——本质上，这也是一种复用的思维。
所以说，中台落地后到底长什么样？
这个真没有定论。
这个要看你希望中台化的业务形态：是业务线？还是技术实现？还是算法？又或者是AI能力？
除却要看你的业务形态之外，也需要和你们企业当前的系统现状做结合，进而再决定是中台是通过底层技术模块封装，还是通过中间层，又或者是通过微服务，还是说通过Sass来对外提供服务。
若实在需要给中台做一个形象的类比，我觉得各种云服务就是很好的类比对象。
例如阿里云中的各种能力，如：机器视觉、智能推荐、智能语音交互，其实就可以理解为某某中台能力，阿里把这些通用的能力封装成云服务，各个企业按需调用即可。
用的都是一样的接口，一样的服务，各个业务线再也不需要自己重新开发，直接拿来使用即可——而我们做中台，不就是为了这个目的么：当业务线需要扩张的时候，直接拿来使用即可，大大降低实现时间成本，提高市场响应速度。
借此回应上一节留下的疑问：做中台的企业，业务模式是否需要集中？
未必。
集中当然好，能够抽象和共享的内容就更多了，业务扩展的时候，能够复用的场景也很多。
就像suppercell在游戏领域，制作新游戏的时候，直接调用游戏引擎中台即可；就像阿里在开拓聚划算业务线的时候，直接拿原有的交易中心、商品中心等一系列中台元件组装即可。
但是，业务不集中的，例如腾讯，它的业务领域横跨游戏、社交、视频、内容等，你说他真没法做中台吗？
肯定不是的，不然人家也没必要成立技术委员会去干这个事儿了，例如用户方面总可以收拢吧？游戏引擎可以抽象和共享吧？又或者说底层一些消息推送服务可以抽离吧？等等…
还是那句话——中台是一种思维：企业级能力复用的设计思维。可以指导产品设计，可以指导技术设计，也可以指导AI能力设计。万事结合自己实际情况来，没必要拘泥于各项规则。
文章的最后，我们做最后的一次总结：
中台不是必须的，也不是万能的——支持业务发展才是永远的王道。
