本文核心是用不同维度去科普“中台”到底怎么理解与一些小方法。实际工作中第一次“中台”实践，不单是纸上谈兵，不同见解请指教。

（对中台已经有一定了解的小伙伴可以略过前面一部分内容。）

一、​中台——追溯 “ 中台历史 ”  上古时期……

咳咳……开个玩笑。

最近1~2年 “ 中台 ” 这个词曝光率越来越多，某引擎指数接连不断地爆（上）发（涨），今天聊聊 Mr_z 眼中的中台，欢迎小伙伴留言 ~

本文会把概念落地在产品上，在真实业务中进行实践，方便理解 ~还是简单的以一个时间轴的形式做简要说明吧 ！

先言简意赅的上几个场景图 ，介绍一下：

早期没有中台概念的时候，在传统IT企业，产品结构如何呢？

无论产品复杂程度，均分为“前台”和“后台（管理端）”这两部分。

应用网上通俗解释，如下：

什么是前台？

首先，这里所说的“前台”和“前端”并不是一回事：

所谓前台即包括各种和用户直接交互的界面，比如web页面，手机app；也包括服务端各种实时响应用户请求的业务逻辑，比如商品查询、订单系统等等。

什么是后台？

后台并不直接面向用户，而是面向运营人员的配置管理系统；比如商品管理、物流管理、结算管理。后台为前台提供了一些简单的配置。

前台、后台、用户之间的关系，可以用下图简单表示：

在当时，项目的发展相对稳定，并不需要那么快速的去迭代和试错，所以这种结构并没有什么问题。

在互联网快速发展的今天，企业之间的竞争越来越激烈。只有以用户为中心，快速影响用户的需求，不断迭代和试错，才能让企业在竞争当中立于不败。

但是，现实情况下……

在传统的前台-后台架构中，各个项目相对独立，许多项目都在重复发明同样的轮子，即让项目本身越来越臃肿，也让开发效率越来越低。

这种时候，为提高开发效率，我们有必要整合出一个中间组织，为所有的项目提供一些公共资源。而这个中间组织，就是人们所说的“中台”。

中台的领跑者

SuperCell是一家芬兰的手机游戏公司，这个名字或许有些陌生，但是说起下面几款游戏，大家一定会很熟悉（当时下面几款手游火了好久）：

SuperCell公司就像是一个高产的游戏孵化器，在几年内开发出了10款以上的游戏，但是大部分用于试错的游戏都在研发过程中被腰斩了，最终呈献给用户的几款游戏都是经典中的经典。

是什么让SuperCell公司能够如此高效地试错和迭代呢？

他们依靠的是强大的平台资源，支撑起各个游戏开发的小团队。他们开发出的游戏看上去风格迥异，却存在许多共同之处：

• 在业务上，共通的东西包括支付系统、用户系统等等；
• 在技术上，共同的东西包括游戏引擎，内部开发工具等等。

而这些共通的资源，都可以由一个强大的 “ 中台 ” 来提供：

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

阿里巴巴在2015年12月进行组织升级，就是“大中台，小前台”的模式。主要的思路是打破原来树状结构，小前台距离一线更近，业务全能，这样便于快速决策、敏捷行动；支持类的业务放在中台，扮演平台支撑的角色。

阿里巴巴提出了 “ 大中台，小前台 ” 的战略：

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

华为提出了“平台炮火支撑精兵作战”的战略：

华为把作战小分队比喻为前台项目团队，把中台比喻成战地指挥部。在这个比喻当中，中台的作用就是提供资源支持：要数据给数据、要技术给技术。

不怕papa打脸，中台概念传出的源头作者还真没有摸清，不过起初从产品（业务、数据等，统称产品哈）层面有这个概念是由《部落冲突》所属公司的一个组织架构引发的血（思）案（考），这里说的血案就因为很多企业盲目跟风做中台，并没有完全理解中台概念，因此在中台这件事上吃了不少的亏。

这里不得不说马大大和一众高层切换共性视角思考企业组织架构与产品形态的调整问题，点赞。

（共性视角：麻烦抽象一下，性质/概念高度相似，切换维度合理运用）

题外话：

中台概念在我看来，在有微服务的技术之前就应该存在了，只为技术层面，未浮出水面而已；更有很多传闻，中台理念开发早早就有应用了（消息准确性待定）

什么是微服务？

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

“ 从字面意思不难理解，所有微服务需要一个支持吧？这个支撑是谁呢？嘿 ~  ”

二、利用中台概念搞事情——抽象一个场景

背景：

公司CEO长期出差，内部由我一手管理，不过刚刚好，因为这种上下对接形式，让我想到之前公司产品部门的结构可以抽象概念，来一个中台的简易模型~

偷换下概念，如下图：

前台应用→中台纽带→业务实现底层

整个产品部是一个公司的中台 ~看懂了没？我就是产品部的 “ 中台 ” 哎

1. 中台整体设计思路及应用

先上图：

实践项目背景说明：所处 “ 健康监测 ” 行业，该公司的业务方向有四：

• 监测A
• 监测B
• 监测C
• 监测D

中台建设分为四个类别：

1. 产品服务中台
2. 业务服务中台
3. 数据服务中台
4. 技术服务中台

我们的中台建设是从零开始的，虽然比重构业务（组织）框架进行整合来的轻松些，但是在真正抽象业务的时候，真是焦头烂额。

B端产品有一个惯性问题，就是一线用户接触机会很少，一般由总监或商务去前端洽谈，所以导致业务信息断层、业务流程有偏移；抽象的过程中，共性类的标签定义不精准，就会影响中台整体研发进度，这中间反复了几次，擦了把汗，最终是搞定了。

注：从零开始还是要说一下，这个零阶段不是企业初期，而是中期重构业务，由本人从零开始做中台系统。

下面整体案例介绍（需放大看 ）：

不同类型中台的属性及说明：

1. 业务服务中台：以主线业务流为核心，不影响业务的前提下进行抽取共性类（这里包含伴生性、附属性的也一同抽取）
2. 产品服务中台：脱离业务线，其他通用性的归属一类。
3. 数据服务中台：用户账户、子系统信息数据统一等；业务形态不同的，但业务数据是需要合并的，这类也可以进行抽取共性类。（eg：一个用户信息数据表单通过抽象后，删减、或增加，可以兼容不同业务形态流转过来的数据表单）
4. 技术服务中台：技术部分暂不做说明了。

举个栗子：“ 业务中台 ”中的功能模块又如何抽取共性类

如图所示，一个填报项目配置时的信息项会分为三类：

1. 维度配置：

在系统中有单独维护（可以理解为字典）维度配置的模块，此处根据不同项目进行判断回显。

2. 项目配置类型：

配置项目时，判断当前项目类别为 “ xx项目 ”后 ，此处字段默认调取本项目所属字段

（字段为最大包含）。

3. 通用字段：

任意一个项目中都包含这几个字段。

从一个功能的视角抽象理解：

1. 牵扯业务、伴生性功能、可维护
2. 业务主干、不可缺失、做包含
3. 通用字段、无需维护

2. 思维应用模型

其实从某些程度上来说，抽象后的框架换个角度思考一下，平台化？

下面有一段话，不敢苟同：

所谓“中台”，其实是为前台而生的平台，它存在的唯一目的就是更好的服务前台规模化创新，进而更好的服务用户，使企业真正做到自身能力与用户需求的持续对接。

emmmmm … …

笔者：

首先我们要清晰认知到中台的定位，如果只是给予前台支撑，那么中台的意义何在呢？

只是满足前台需求，用中台概念做平台化支撑前台不可以么？

前台产品是一个公司对外战略的一部分，一个方向，而中台是需要不断通过行业经验累积，不断下沉，只有能力沉淀下来，才体现了中台的意义。

这里需要说明一点，不要盲目跟风，需要根据不同公司的发展阶段来具体分析。

3. 企业不同阶段的 “ 中台 ”

企业阶段：0岁

没有必要搭建中台，但是一定要有中台的概念，先平台化，快速输出产品，在市场内野蛮冲刺，不断打磨产品，验证自身价值看，确定属于自己的商业模式，后根据企业在行业内业务的下钻能力，进而沉淀；不要浪费资源在前期做 “ 中台部分 ” 的投入！

os：当然，您的企业各方面资源 “ 非~常雄厚 ” ，提前预备也行，只不过后续优化还是需要资源，何必呢。

企业阶段：1~18岁

适合（不完全）搭建中台，当企业商业模式、产品模式都OK时，综合企业涉及业务的范围及复杂性进行梳理，此阶段进行能力下沉，根据业务能力下沉的量来确认，企业当前阶段是否急迫的需要 “ 中台 ” 的建设。

企业阶段：18+岁，成年

搭建中台势在必行，当企业已经有了很大的规模，各种产品、服务、部门错综复杂，且在上一阶段之后的过程中，没有业务能力下沉的战略，那么这时候做架构调整会比较痛苦；

这时有两种选择：

1. 如果所属行业优化迭代的节奏很慢，而且业务边界不在拓展，此时可以不做调整。
2. 如果业务边界持续拓展，此时必须快刀斩乱麻，肉痛就要有动作，不要等到痛到骨子了在行动。

只了解概念就盲目跟风并吃亏的企业不在少数；

需要明确 “ 自己 ”的当下情（业务的复杂性、多元化、边界拓展）景及未来的远瞻。

三、大厂的 “ 中台 ”——应用场景的多元化

1. 阿里（上文有提到过）

2. 腾讯

中台战略，All in产业互联网自去年CSIG成立以来，腾讯通过成立技术委员会来加强技术共享和协同，并设立「开源协同」和「自研上云」项目组来推动公司技术的整合、公司产品的开源与云端化。

腾讯开放的中台能力包括数据中台和技术中台。

其中，数据中台包括用户中台、内容中台、应用中台等；技术中台包括通信中台、AI中台、安全中台等。

企业与开发者可以灵活地把这些技术应用到业务场景中。
2.1 用户中台

指的是一整套囊括了用户增长、用户沟通、用户数据保护、会员管理等方面的客户管理工具。

2.2 内容中台

是腾讯以企鹅号为中心，为合作伙伴和内容创作者提供高效的内容生产工具。

2.3 应用中台是腾讯旗下的应用宝以「分发中台」作为核心功能全面向合作伙伴开放，打造全新的应用分发生态，提高应用分发效率。

2.4 技术中台

虽然腾讯过往并没有明确解释其具体的落实方案，但从名字上我们也可以看出一些端倪——通信中台基于的是腾讯从QQ和微信两端积累下来的即时通信技术。

2.5 AI中台

基于腾讯三大AI实验室的技术，涵盖了光学文本识别、人脸识别、图片识别、音频识别、文本分析等方面的技术。

2.6 安全中台

则是腾讯基于其安全运营经验和安全数据库为方便企业进行高效安全管理而打造出来的一站式大数据和智能化安全管理平台。

3. 百度

建立可复用的中台能力百度的中台，实际是从平台建设的基础上发展起来的。

之前的产品形态相对确定，因此可以提供完善的平台化能力，来满足这些相对确定的需求；如果有新的需求，那么就直接在系统核心模块增加功能、扩展能力即可。

百度中台的技术思路：提供完备的通用能力、定制能力，持续完善领域技术沉淀能力。
业务视角， 中台提供了灵活的可定制业务框架， 使得业务可以聚焦业务特有逻辑的开发；中台还提供了可以复用的业务组件， 使得业务可以通过配置化来复用优秀的中台能力；中台还提供了完备的文档建设、视频教程， 支持业务快速上手、快速迭代， 同时还提供了面向全流程开发效能提升的完整自动化工具链。

4. 小米的三大中台建设：业务+数据+技术

• 4.1 业务中台：从业务说起
• 4.2 数据中台：数字化转型的核心
• 4.3 技术中台：更敏捷的开发效率

5. 字节跳动：移动研发中台，效率提升7倍

卫哲曾在公开分享中提到：今日头条的崛起很大程度在于今日头条是大互联网公司中第一个率先实现强中台的公司。今日头条强就强在前台放四五个员工，就能做出今天抖音这样的产品来，在传统的互联网公司做不到，没有几十、几百个人，是做不出来的。

移动研发中台

字节跳动的研发中台从业务纬度划分包括组件平台、CI/CD、应用管理平台，目前还在规划整合预审平台、发布平台。

其中组件平台提供了通用的组件管理方案整合公司内所有的组件、CI/CD 平台使用了自研的分布式云编译专利方案，以头条为例可以提升接近 700% 的编译速度。

中台的出现是为了在解决技术架构与业务架构慢与贵的矛盾，进行业务‘配速’而生，合理的中台技术必然是以解决当前的业务与技术矛盾为出发点的，因此在中台的实践中，不必一味的去效仿，需要根据当前的业务痛点以及技术架构进行实践，设计一套最符合自身需求的中台服务。

6. 滴滴

构建最合适的业务中台滴滴业务中台的架构实践。在谈具体对策与实践之前，先来看看整个业务中台的架构设计。

• 6.1 服务化
• 6.2 异步化
• 6.3 配置化
• 6.4 插件化
• 6.5 数据化

7. 京东：打造共建、共享、标准化的数据中台

• 7.1 数据中台：破除企业数据孤岛
• 7.2 京东数据中台：千尺之台，起于垒土数据底层、数据服务层、数据应用层

8. 网易：胖中台、标准中台、平台组织

• 8.1. 网易的数据中台架构
• 8.2. 网易的“胖中台组织”“标准中台组织”和“平台组织”

 总结——些许实践经验，接受指点

业务中台从无到有，到被应用的实践过程中，积累些许实战经验；些许观点，接受批评：

1. 中台系统的建设把最复杂的业务搞定，业务落地，把控核心。
2. 不要妄图Copy最好的建设方案，要沉淀出属于自己 “ 私人订制 ” 的方案。
3. 通过业务不断的优化、沉淀，来巩固企业自身在业内的地位，成为巨头，方能定义新标准。（中台能力的沉淀，其实就是沉淀定义业内新标准的能力）

文末总结

中台是个好东西，同样，就像它的起源一样，从组织架构的角度可行，从产品角度可行，那么其他角度呢？

世间万物总归是有共性的、有异性的、可塑性的。

好的互联网思维一定是要有 “ 兼容性 ” 的，可以切换不同视角思考，

可以利用共性特点切换模拟场景（模拟场景 “ 抽象 ” ）

eg：

问：产品经理是做啥的？

答：你怎么回答呢？

需要以你的认知，利用互联网思维考虑共性问题，举例描述。

个人对于 “ 好的互联网思维 ” 有另一种看法：拥有 “ 互联网为基础，全视角的生命周期 ” 的思考模式。

安利两篇不错的中台文章，有讲到上文说的大厂们的中台内容（本文部分内容出自下面文章）

《腾讯、百度、小米等7家互联网各大厂的中台建设怎么样了？》《中台架构50篇资料精选，阿里/腾讯/京东 … 中台建设实践汇集 》

部分内容来源：网络文章（侵删）

部分图片来源：网络文章（侵删）

本文由 @Unique 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议