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

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

“不少人都担忧被技术新潮流所抛弃，因此当碰见不断涌现的新技术时，老是慌忙的去学习。但是其中到底有多少是真正有用的？又有多少是昙花一现的技术呢？当你没法分辨的时候，其实没必要慌张，当一项新技术/概念刚出现的时候，你没必要匆忙的去学习，更没必要担忧本身会错过它，若是它是一个真正有价值的东西，是一个真正经受得住考验得技术，它早晚会再次出如今你面前”

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

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

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

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

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

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

在201七、201八、2019年不少互联网大厂都对外分享了本身的中台实践成果，包括阿里、腾讯、京东等都为中台战略作出组织架构的调整。

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

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

1、「 中台 」究竟是什么？

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

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

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

企业级的能力复用平台

我以为这个定义至关准确且简洁。受不了我上面一大段啰嗦定义的同窗，能够按照这个简洁的定义去理解中台。

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

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

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

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

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

上面提到的 前台、中台、后台 所有都是从用户和职能角度出发的，不少开发同窗一听先后台就理解成了技术架构了，技术架构中的前端展现层、技术中间层、后端数据层，与这里的前中后台彻底不是一个概念。

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

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

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

业务中台与数据中台相辅相成、互相支撑。因此如今你们也很流行的说法就是：数据业务化、业务数据化嘛。

 

（图片来源云栖社区）

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

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

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

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

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

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

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

2、咱们要不要去建设「 中台 」？

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

1. 公司得核心业务不成熟 或 公司业务线不多

   若是企业属于创业公司，主业务模式都不明朗，这种状况就真的不建议搞什么中台的。中台是讲究多业务服务用的，咱就一个业务，这个业务还在探索，搞啥子中台嘛，把技术平台搞好点就能够了。

2. 公司里没有相相似的业务

   即便不是创业公司，是一个中型甚至是大型公司了，但若是公司里虽然业务多，可是每一个业务线作的领域都区别很大，好比业务线1作面向C端的电商，业务线2作游戏，业务线3作面向B端企业级产品。这种状况，很难沉淀共性的业务服务，也作不了中台，仍是拉一个团队继续作基础平台给各个业务服务吧。

3. 公司没有足够的人力

   人力是硬指标，即便上面说的问题都没有，彻底符合作中台，那也得考虑考虑人员安排。毕竟中台的建设是须要由独立的团队去完成，而且还应该是一个高效率的团队（否则前台业务会抱怨中台响应不及时），公司是否有这部分的人力预算去建设中台，人员从哪儿来，这个硬性条件必须提早考虑。

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

另外，还有不少人担忧「 中台 」会不会是昙花一现的新概念，我以为纠结这个彻底不必。当我们充分理解了中台，学到了其中的理念以后，它是否是昙花一现并非很重要嘛。由于咱们已经得到了成长，得到了视野和思惟的提高，足以。您以为呢？

码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。😊

本文原创发布于微信公众号「 不止思考 」，欢迎关注。涉及 思惟认知、我的成长、架构