要不要赶个时髦，去建设一个「 中台 」？

很多技术人总是抱怨 新技术/新框架/新概念 太多了，总是学不完，抱怨实在是学不动了。哈哈，这不，最近「 中台 」这么火热，要不要停止抱怨，再咬咬牙学一波？

“很多人都担心被技术新潮流所抛弃，所以当遇见不断涌现的新技术时，总是慌忙的去学习。可是其中到底有多少是真正有用的？又有多少是昙花一现的技术呢？当你无法分辨的时候，其实不必慌张，当一项新技术/概念刚出现的时候，你不必匆忙的去学习，更不必担心自己会错过它，如果它是一个真正有价值的东西，是一个真正经受得住考验得技术，它迟早会再次出现在你面前”

这是我很喜欢的一段话，对技术浪潮的见识太到位了。不过很惭愧，我不记得是哪位大神说的了。

回到「 中台 」这个话题，其实中台已经不算新潮流了，并且它还是被很多企业成功验证过的模式了。那么，既然这么靠谱，咱们是否应该赶个时髦，搞一个？

在回答这个问题之前，咱们先缕一缕啥是中台吧。

中台 这个理念在国内最早是由阿里巴巴带起来的，后来国内一些互联网大厂（滴滴、京东等）也开始在内部推行，加上今年腾讯在“全球数字生态大会”上再度提起中台架构，引起了大家一波又一波的追捧。不过这个架构理念也不是由阿里巴巴提出的，而是马云带着阿里团队拜访 Supercell 公司学习来的。Supercell 是芬兰一家著名的移动游戏公司 ，我说几个他们开发的游戏大家就能明白了这家不到两百人的公司有多牛逼了，比如著名的《部落冲突》《卡通农场》《皇室战争》。

Supercell公司公司人员人少，采用的就是“小前台”+“部落”的模式。就是有多个“前台”小组，这些小组就是专门用来快速研发游戏的，每个小组虽然人员不多但它包含了开发一款游戏所需的各种角色人员。这些“前台”小组只关注在业务侧，也就是游戏业务研发和创新上。而对于游戏的底层基础设施：游戏引擎、开发工具、服务器后台等这些都东西，前台小组不用去关心，这些基础功能交由一个称为“部落”的组织独立去负责。这种模式就像是战斗小组专门去负责打仗，后勤弹药又由另外的小组去搞定，分工明确，业务也能快速试错、快速创新。

根据这次拜访学习，阿里巴巴随后宣布组织架构全面升级，启动中台战略，构建“大中台、小前台”的组织机制和业务机制。

在2017、2018、2019年很多互联网大厂都对外分享了自己的中台实践成果，包括阿里、腾讯、京东等都为中台战略做出组织架构的调整。

在互联网大厂的领头、产业互联网的风口，传统企业的转型契机下，「 中台 」不火都不行啊。

对于中台的了解，网上资料简直多的不要不要的，但体系化的学习，我推荐看看云徙科技的几位大佬新出的**《中台战略》这本书，以及极客时间的《说透中台》**专栏，这两个资料算是对中台介绍的比较全面的。本文的部分观点也是吸取了这些内容后的收获，建议找来一读。

一、「 中台 」到底是什么？

想了很久，想用一句简洁清晰的语句给 中台 下个定义，还是有点难度（嗯，没错，还是我的认知太浅了，哈哈）。

中台 就是一个架构理念，它是介于前台与后台之间的（这句好像是废话），它是希望将一些可复用的“能力”统一起来，采用共享的方式去建设，用来解决各个业务团队重复开发、数据分散、试错成本高等问题，中台的核心就是**“对能力的共享”、“对能力的复用”**，它应该是公司内部的统一协同平台。

另外再给个参考，在《说透中台》专栏中王健老师将中台定义为：

企业级的能力复用平台

我觉得这个定义相当准确且简洁。受不了我上面一大段啰嗦定义的同学，可以按照这个简洁的定义去理解中台。

上面讲完了中台的定义，我们再来看看 前台、中台、后台 的区别吧。

「前台」是直接服务客户、触达用户的平台，能够洞察用户需求，进行产品创新、提升用户价值，保持精简和足够敏捷度的平台。比如阿里的 淘宝、天猫、聚划算等。

「中台」前面已经定义过了。它通过组件化的形式输出通用能力，为所有「前台」的业务运营和创新，提供专业能力的共享平台。中台部门提炼各业务线的共性需求，将各种资源转化为方便「前台」使用的能力，最大程度避免重复“造轮子”。

「后台」的职能是提供基础设施建设、服务支持，为「前台」和「中台」提供基础保障。后台会比中台更底层、更通用。「中台」有的时候会更关注在某一行业/领域内的，而「后台」应该是行业/领域通用的。

要注意的是，中台并不是专指技术，相反主流的中台更侧重于业务。

上面提到的 前台、中台、后台 全部都是从用户和职能角度出发的，很多开发同学一听前后台就理解成了技术架构了，技术架构中的前端展示层、技术中间层、后端数据层，与这里的前中后台完全不是一个概念。

阿里的中台战略是以业务中台和数据中台相结合，这也是目前市面上主流的中台架构。

业务中台是提供可复用的业务服务，包括如用户中心、会员中心、订单中心、支付中心等，既可拆箱即用，又可复用的业务能力。说白了，各个不同的业务线/业务部门其实有很多类似、共通的业务组件，大家就不要各自搞各自的了（传说中的烟囱式、单体式项目架构），既浪费资源，也不利于协同。干脆大家把这些共性的可复用的业务组件从前台里提炼出来，下沉到中台，一起建设一起用，你好我好大家好。

数据中台是基于技术和大数据能力为业务提供可复用的数据服务，将业务中产生出来的数据进行二次加工，将加工的结果再服务于业务，为业务赋能。但要注意的是，大家在理解上不能将数据中台与传统的数仓、大数据平台划等号。数据中台与它们的区别是，数据中台更贴近业务，数据中台不只关心技术层面，不只提供分析功能，更多关心数据资产化、关心数据对业务的运用，为业务提供服务。

业务中台与数据中台相辅相成、互相支撑。所以现在大家也很流行的说法就是：数据业务化、业务数据化嘛。

（图片来源云栖社区）

除此之外，在实际应用中，也衍生出了很多其它的中台概念，如：移动中台、算法中台、技术中台、研发中台、运营中台、组织中台 等等。下面挑选几个简单解释一下：

技术中台：提供通用的技术设施能力、技术中间件能力，过滤掉技术细节，像各个前台应用提供统一的易用的技术服务，避免重复造轮子（也有人认为技术中台不具备业务属性，属于技术中间件平台，不能归属中台）。

研发中台：研发中台是关注开发效率的平台，将公司的开发流程、最佳实践沉淀为可重用的能力，为应用的开发提供了流程、质量管控和持续交付的能力。

移动中台：将移动APP开发中的通用技术、框架、业务组件等进行封装，沉淀到移动中台，提高移动开发组件的可复用性，方便快速构建新的APP开发（有些人对移动中台的争议与技术中台类似）。

为什么会出现这么多的让人眼花缭乱的中台呢？根本原因是每个人自己的职业不同，所以看待的角度不同，出发点不同，并且每个公司的业务性质、形态也不相同。比如 电商团队、AI团队、运营团队、研发团队，他们眼中的中台肯定都是不一样的，但初衷是一样的：资源的复用。

另外，这里还得再啰嗦一句：“平台不是中台”。什么意思呢？

有的互联网企业在对公司内的模块进行定义和表述中，并不常用“后台”的概念，反而用“平台”比较多。比如 大数据平台、运维自动化平台、财务平台等等。这些“平台”与我们今天描述的“中台”并不是一回事。平台比中台更底层一些，更基础一些。平台一般是不带业务属性的，而中台，确必须是具备业务属性的，因为中台是直接为前台业务所服务的，是一个提炼业务能力共性的组织，在这一点上就与平台区别的很明显了。

二、我们要不要去建设「 中台 」？

「中台」这么火，大小企业都蠢蠢欲动，各种靠谱不靠谱的平台都往中台的概念上靠，要干的劲头挡不住啊。行吧，既然要干，咱们至少得先看看问题吧，把明显不适合搞中台的基本条件弄清楚嘛。

1. 公司得核心业务不成熟 或 公司业务线很少
   如果企业属于创业公司，主业务模式都不明朗，这种情况就真的不建议搞什么中台的。中台是讲究多业务服务用的，咱就一个业务，这个业务还在探索，搞啥子中台嘛，把技术平台搞好点就可以了。
2. 公司里没有相类似的业务
   即使不是创业公司，是一个中型甚至是大型公司了，但如果公司里虽然业务多，但是每个业务线做的领域都区别很大，比如业务线1做面向C端的电商，业务线2做游戏，业务线3做面向B端企业级产品。这种情况，很难沉淀共性的业务服务，也做不了中台，还是拉一个团队继续做基础平台给各个业务服务吧。
3. 公司没有足够的人力
   人力是硬指标，即使上面说的问题都没有，完全符合做中台，那也得考虑考虑人员安排。毕竟中台的建设是需要由独立的团队去完成，并且还应该是一个高效率的团队（不然前台业务会抱怨中台响应不及时），公司是否有这部分的人力预算去建设中台，人员从哪儿来，这个硬性条件必须提前考虑。

这篇文章阐述了 啥是中台、要不要建中台，但貌似缺一个“怎么建中台”了，这个以后聊。

另外，还有很多人担心「 中台 」会不会是昙花一现的新概念，我觉得纠结这个完全没必要。当咱们充分理解了中台，学到了其中的理念之后，它是不是昙花一现并不是很重要嘛。因为我们已经获得了成长，获得了视野和思维的提升，足以。您觉得呢？