系列文章：
上篇《中台是什么？解决什么问题？》
下篇《有关中台的误解以及精选中台解读》

故事的开始

这个最早由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念，最近在国内大热。阿里、腾讯、百度、京东、美团、滴滴等一众互联网巨头，从去年到今年，接连开始组织架构的调整，意图建设中台......

而上周一个阳光明媚的下午茶时间，我正狗啃着手抓饼。老板忽然把我们一班人拉进会议室，语重心长跟我们说 —— 我们要搞数据中台！

虽然一个会议下来，连他都没说明白“中台”到底是什么？但秉承不懂就少说，我苟了过去...直到吃完月饼，我们来对比下有无“中台”的情况

项目现状

项目有很多对内/对外/辅助，但无论项目内部的如何复杂，大体的结构都是 “用户前台”和“管理后台”。

用户前台 

面向用户、直接产生交互，页面注重设计/交互，与服务端产生数据交换引导用户完成业务流程. 比如：

管理后台

面向运营人员的配置管理系统，后台为前台提供了一些简单的配置。比如：

用户前台、管理后台、用户之间的关系如下：

传统模式下，项目迭代周期基本以月、季度为单位。长开发周期也意味着需求一旦变动，要么996，要么交付推迟

而且项目之间相对独立，许多项目都在重复发明相同的“轮子”。让项目越来越臃肿的同时，也让开发效率越来越低。

但现实是互联网进入下半场，企业竞争越来越激烈的今天。产品项目不能够快速迭代、低成本试错的后果，就等同让企业处于一定的竞争劣势。

为了解决以上问题，而应运而生的是“中台”概念

中台概念的先行者 Supercell

容忍失败，甚至为失败喝彩

Supercell，失败从来不是可耻的记录，而反倒是一种进步的动力。一款游戏推出遭到失败后。其管理者的反应是“太好了，这款游戏失败了，证明了我们剔除一条错误的道路”。独特的“庆祝失败”根植于其企业文化之中，潘纳宁认为：“我们是在从失败中吸取教训的基础上建立了这家公司。失败得越快，我们学习得越快，也会变得越好”。

失败时成功之母，能够真正做到从失败中获取需要的信息，学习如何成功

深度利用云计算/微服务等技术，升级单个员工价值

Supercell采用的是亚马逊的aws服务，他们每天需要处理万亿字节的数据，这些日志将会被用来改善游戏体验。充足且统一的公共业务模块，辅助团队避免重复劳动，专注于玩法、游戏体验创作即可快速堆砌产品。提升单个员工价值的同时，也降低了试错的成本

小而精的团队

信息共享

总结要有想法

中台解决的问题

往技术层面说，中台解决的问题是 —— 多项目 且 项目相对独立，导致需要重复造轮子，如：文件上传 / 订单模块 / 支付模块 / 搜索模块...引起的研发周期长，程序员996了都不能灵活应对业务变化 的情况

往业务层面说，中台解决的是 —— 因为项目相对独立，技术重复造引起的 研发周期长 / 面对市场需求总是慢半拍(不灵活) / 试错成本高 / 不利于创新

中台解决的方式

• 通过 统一的公共技术模块 抽离形成服务。再次需要该服务时通过接口调用完成，避免重复造轮子，避免研发周期拉长
• 明确业务流程，封装成公共业务流程模块。当下次走同样业务流程时直接复用。降低试错成本，有利创新
• 到时候技术研发的就不是项目，而是这些 “公共模块” 形成的 服务，形成的 中台

说了那么多，举个例子：

中台实例

他们开发出的游戏看上去风格迥异，却存在许多共同之处。在业务上，共通的东西包括支付系统、用户系统等等，在技术上，共同的东西包括游戏引擎，内部开发工具等等。而这些共通的资源，都可以由一个强大的“中台”来提供：

中台的架构思想改变的不只是项目结构，也影响了研发团队的组织形式。SuperCell公司把这种高效的组织形式称为“部落”。 

 紧随其后，国内互联网公司也纷纷开始了各自的中台战略。阿里巴巴提出了“大中台，小前台”的战略：

图中，阿里巴巴许多产品线的共通业务经过下沉，形成了中台的各种业务中心，而Aliware则是阿里巴巴的技术中间件平台，为各大业务线提供技术支持。

以上就是中台概念的具体含义。

水了那么多终于水到个人感受

“中台概念”往小地说，就是“微服务”。但中台需要使用 产品管理 的方式来对待。因为中台对外提供的服务需要不停的迭代，适应业务的需求，而不是等业务来提需求。对，技术人员也要懂业务。

至于 产品 和 项目 管理有什么区别？这你得找产品交流下心得、切磋下武艺~

上篇《中台是什么？解决什么问题？》到这里就告一段落了。欢迎延伸阅读~
下篇《有关中台的误解以及精选中台解读》是针对 为什么需要中台、怎么样的中台是好中台 的好文章，值得参考

阅读参考

如果觉得我的文章对你有用，请点赞鼓励