这个问题我感觉自己还是有回答的资格：亲历过两个大厂的中台项目，撰写了《中台产品经理宝典》一书。

PS：我的新书《中台产品经理宝典》已经上架京东，涵盖中台完整建设方法论共计70讲！
双十一本书在京东限时参加满100减50的巨额折扣，对本书感兴趣的千万不要错过！

我用两个部分来解读下中台吧：

Part1：我摘取我的书中的一个生活化例子来解释下什么是中台；

Part2：以一个订单服务中心来拆解下怎么实战；

Part1：生活化例子来解释下什么是中台

在以往的互联网企业生产流程中，我们可以将研发团队宏观的划分为前台与后台两部分。

所谓前台就是用户直接接触到的产品部分，如可在应用商店下载的APP，像微信、抖音、淘宝，或者可以使用的网站等。

用户对产品的认知与体验也由此而生。比如大家对于微信的理解就是这个前台APP展示的一切给大家描绘的：一个绿色图标的应用，里面有我的A、B、C好友。

1. 企业的内部管理服务的统称，如：内部的CRM，ERP等；
2. 为前台提供服务能力的，如：数据压缩能力，并发等。

后台最重要的特点就是其提供的服务都是不被普通用户所感知的，就像用户不会因为应用的并发，传输速度而记住微信这个品牌。

在搞清楚了前台与后台的概念后，前后台模式的产品服务模式我们就可以用一张图来概括描述：

总的来说就是在应用中后台提供能力与计算，前台将后台的能力进行封装以图形化的形式展示给用户，让用户能更容易的使用公司提供的服务来解决个人需求。

在开始谈论中台之前，我们先要明白：当下的主流前后台模式并不是在业务实现上出现了问题，不支持眼下出现的种种新业务场景；相反地，这种前后台反而是公司最省事省力的一种提供服务的解决方案。因为这种模式不需要提供额外的建设，前台完成信息展示与交互，后台做好对应需求的解决逻辑就组成了一个产品。

实际上，中台的出现更多是因为公司业务在发展到某一阶段时，在拥有多个业务线时继续发展遇到瓶颈与障碍后，为了解决如何继续朝下走的实际问题而提出的一个组织前台业与后台关系新解决方案的统称，而不是某个新的系统。

在互联网进入日益复杂的市场环境的今天，市场中由于存在众多的竞争者，也逼迫着企业需要不断去更新产品去抢夺市场。

而作为实际用户真正接触的前台业务，如：APP、小程序、网站等，必须要快速迭代新的功能才能让用户感知到。

而在这个大背景下带来的矛盾就是——以往为了支撑前台越来越多的业务，后台不断地建设庞大起来的系统，由于一直在追求稳定性而生，反而在这个时候显得越发笨重起来。这样的后台变得越来越没法去快速响应前端变化所带来的改变。原来的前后台模式的这种直接关联决定了两者的冲突不可避免。

例如：传统我们的一个电商网站，由于用户前端需要组织各种新的销售方式（拼团，一元购等），导致每次活动页面开发的时候，不仅需要前端重新设计页面，从后台接口提供与数据表都要重新设计。

这无疑大大拉长了我们的需求响应时间，很有可能会导致在活动模块还没开发完成，我们的风口就已经过去了。因此我们需要一个能最少改动就能完成大部分需求的解决方案，这就是中台。

中台解决方案到底是什么呢？让我们举个通俗的例子来说，如果将互联网公司的研发中心比作一个厨房，将研发新产品的过程比做菜的话，我们就可以很容易理解这个概念了。

首先请大家想一个问题，在一家客流量非常大的餐厅中我们要如何缩短客人的等待时间呢？

相信很多人的第一想法就是增加多名厨师，但时大多数的餐厅单纯的增加厨师这是不实际的，因为每增加一个厨师是有很高成本的，而且每天忙的就是中午和晚上这两个时间点，虽然在饭点解决了问题，但是在一天中其他的时间里，厨师人员就显得非常冗余了。

而正确的做法是先将做菜这个任务拆分，让做菜这一件事变为多个环节来思考。也就是将做菜变为：

通过这样的拆分后我们可以发现无论是做什么菜系，买菜与配菜都是共有的两个步骤，我们完全可以只需要增加一位配菜的小哥来代替厨师去进行前两步，这也就是现在大多数上规模餐厅的组织架构：

这样我们每一位厨师新做一道菜时没有必要一定要从买菜，洗菜，切肉这些最基础的环节开始，而是完全可以直接使用他人切好的肉片，洗好的菜下锅，唯一需要关心的就是如何在搭配调料上研究不同的创意。完全可以大大提高厨师的做菜速度，同时在成本上我们只增加了一个人就解决了所有问题。

回到研发流程来看，买菜其实就是我们研发的后台，他们帮助我们解决最基础原料问题。厨师是我们的一个个业务前台团队，他们要做的就是根据不同地区口味烹饪出对应的菜系，而在业务多元化后洗菜，切菜，配菜都可以交给中台解决方案去完成，做菜的时候作为大厨只需要喊一句要什么材料既可，当然这里的配菜小哥就是我们的中台。

所以说有了中台之后我们的前台业务就可以快速尝试迭代，不需要每件事都是从0到1开始了。

让我们再站在架构的层面来看看中台对整个系统业务所起到的作用。

假设我们是一个电商平台在我们未使用中台的时候，每一个前台的用户终端都需要与后台进行一次对接，就像下图：

而后台的每一个模块都需要维持与前台业务的关联，并根据不同业务前台的特征加入适配。这样造成的结果：

• 后台的每一个模块都需要加入与前台适配的部分，从而大大加大了开发量；
• 每个前端在启动时需要分别对接不同的后台模块，也加大前台启动时的工作量；
• 当后台进行升级或架构调整时还需要考虑与前台的对接，并进行逐一的调整。

当我们引入中台后，让中台作为一个对接层，帮我们去统一对接前台的不同终端，同时对后台各个子系统进行统一的封装，让前台能无感知的使用各项服务而不需要单独设计通道，我们的系统也就简化成了这个样子：

通过对比我们能清楚的看到中台对于公司的整个业务架构起到了非常大的简化作用。

用一句话来概括就是：中台的核心本质就是服务共享，目标是支持前台的快速创新或试错，而实现的手段是微服务架构、敏捷基础设施和公共基础服务。

那么到这我们可以给中台解决方案下一个定义：

中台解决方案的组成 = 能力输出 + 标准化中间件

所谓能力输出就是要规划出什么是公司的核心竞争力，理清楚公司发展的战略与目标与未来公司里的主要业务会涉及到哪些方面。并在这些业务层面中去提炼哪些模块是以共性存在的，并会在每个新开拓的业务中不断使用，然后就把他归类到中台进行建设。这也就是中台的一个重要的意义：为不同的前台业务提供可以重复使用的能力，形成一次建设多次使用。

例如我们规划了公司的核心方向是视频方向，未来可能会涉及的业务形态有：

分析上面的业务方向我们不难判断出最基础要抽取的模块可以划分为：

完成拆分后我们就可以通过中台去实现这几个通用模块。

值得提一下的是虽然这里在说中台要考虑复用性、扩展性，但是要考虑多少，考虑多深这里又是一个非常考验产品功力的地方。

还是举上面的例子来说我在设计一个视频社区APP的积分商城系统时，需要将商城交易方式抽象为能力时，这里我们大体上可以抽象为如下三种交易方式：

但是同样的疑问来了，我们仅仅为了支持一个积分商城需要将中台的复用与扩展放大要考虑引入股票交易才使用到的撮合交易模式吗？

当然这里的案例比较极端我们能快速判断，但是在具体的中台规划中我们会碰到很多这种类似的范围决策，我们必须要按照公司的核心业务规划来严格定义中台的能力，避免在中台出现过度建设的现象。

第二部分：标准化中间件（整合能力，并封装头尾）

在我们确定了公司的业务发展需要哪些能力之后，中台解决方案的另一个组成部分就是需要做一个将每个能力进行封装，形成一个统一的可供前台业务端方便使用的中间件。

这里的统一具体表现在如下的几个方面：

• 不同终端中的叫法与含义；
• 定义统一化的输入输出；

以往的前后台模式中同一家公司内的不同业务如：直播项目组、短视频项目组各自为战的时候，经常会出现一个事物被不同项目因为场景化的需求，而出现两个称呼的现象，但是实际上他们本质上是同一个事物。这也是原来不同项目组想要进行复用前人的模块时一个天然的巨大障碍——无法快速对接。

例如：就那一个用户昵称这个字段来看，在不同项目组中的应用中可能会叫：用户名称、用户昵称、称号、花名等等，而在数据库中又可能会有不同的字段名称：username、UN、name等等。

因此我们需要一个中心化的产物帮助我们定义好这些个通用属性，使在公司中不同的业务端都能统一。

面对这种现象，在有了中台后，我们就可以通过定义标准化的中间件来解决。以后假设公司内部孵化的项目组再次要使用用户昵称这个字段的时候，无论具体是什么业务前端都会是一个叫法、一种存储，这样不仅能直接使用之前项目的模块，同时还可以和公司内部的管理系统如CRM/BI等快速完成对接。

在竞争日趋激烈的互联网行业中，如何低成本又快速地完成业务创新去占领市场是每个企业所追求的方向，而中台解决方案的出现给我们当下的互联网企业带来了一个全新的发展思路。

Part2：以一个订单服务中心来拆解下怎么实战；

相信大家一定在很多网上讨论中台的文章中看到一句类似的话，叫做中台建设的本质就是抽取共性，从而在企业内部进行复用。

但是究竟要什么是抽取共性呢？

我先上个定义：抽取共性实际上就是要去寻找企业内部多个业务线都使用的模块、节点、业务流程，从而将这些共用的部分提取出来，这就叫做抽取共性。

举个形象的例子来理解一下这个概念，如果我们把各业务线使用的功能以图形化的形式表示出来，我们可以看到下图中业务线一业务线二的具体功能节点如下：

在这基础上我们去寻找相似的功能有哪些？于是我们很快发现了有一个相同的模块，如下图的红框所示。

虽然这个红框里的圆形所代表的功能大小有细微的差别，但是他们都同属于一个形状，也就是圆形，这个时候我们就可以将它视为一个可服用的共性抽取出来。

那么这便是一个寻找共性的过程和定义，看起来没有太大难度是吧！

是的核心方法其实并没有太大难度，无非就是如下两步：

（1）准确拆解并梳理各业务线功能节点；

（2）寻找具有相似度的功能进行合并；

但是这里的难点在于我们如何去将业务线的各个功能拆分成如案例中这样边界清晰的不同形状代表的节点，从而方便我们快速发现业务的共性。

那么这里就需要用到我前面几篇文章（中台实战6，中台实战7），为大家介绍的去寻找业务SOP以及为业务进行建模，只有先进行建模，我们才能清楚的找到业务中的各功能节点。

具体让我们来看一个实战案例是如何剥取业务共性，形成一个中台内部的服务中心的，来为大家加深这个概念的认知。

为了好理解，我在这选择一个低复杂度的功能，以每个产品内部随处可见的批量导出功能为例（就像下图的这种导入导出）。

假设公司内部现在有多条业务线，分别是：

（1）电商业务线：包含订单导出功能；

（2）OA业务线：包含员工考勤导数功能；

（3）新零售业务线：包含线下注册用户导出功能；

那么到这我们其实已经发现了，公司内部各个业务线都有一个相似的功能——导出功能，那么这个相似的功能如何去提取它的共性呢？

我们需要对这个功能进行进一步拆解，可以得到各个业务线具体的导出功能构成如下

我们在这个基础上进行共性提取的最重要一步也是核心步骤就是要去将业务线的功能剥离业务特征，使其还原为一个基本的操作。

根据此原则我们通过对功能的拆解，也就是根据上面标注的红色字体，就可以剥离出导出功能的两个基本操作：

（2）导出格式自定义；

还没有完下一步，我们再搭建中台服务中心的时候，还需要考虑业务的扩展性，也就是未来业务线可能会发展出哪些功能，我们需要做一个预判，并且合并到中台服务中心中，以支持未来业务线的发展。

我们继续来看上面的功能：

这次我们关注蓝色字体所标注的内容，虽然说权限控制只在一个业务线中使用，但是这个功能属于一个，需要拓展的基础功能，那么这个时候我们就可以将它提前和病致中台，以便其他各个业务线使用的时候能够快速调用。

可能有同学会问了，我们要如何去识别扩展所需要的功能，其实这个时候就不能简单的分析各个业务线的功能了，而要去凭借中台产品经理的业务经验进行判断，通过他过往做过多个项目的经历，来判断哪些功能会是这个业务未来要用到的，所以有时候产品经理的经验也是非常重要。

那么至此我们的导出功能的中台服务中心，功能列表和清单就得到了：

我们就可以根据这样的一个功能清单去建设导出服务中心，从而让前台去使用时只需要告诉具体要导出哪些字段。

中台服务中心就可以根据请求，快速的读取对应的数据库表，进行返字段返回，配套的还可以进行返回文件格式的自定义，从而方便前台各个业务线快速去搭建一个导出功能。

至此我们一个从业务中提取共性，搭建中台服务中心的过程就讲解完了，大家可以根据自己的业务进行方案套用。

这里需要再多说一句的是，中台所提供的服务中心式的复用，与原来在中台出现之前，所建设的很多复用方式最大的不一样是为具体的一个问题域，提供了一个完整的一揽子解决方案，而不是像原来的拆分成很小的颗粒度，你要导出功能，我就只给你进行导出功能，至于格式选择以及权限控制等功能，都需要你在自己的服务中进行独立编码。

也就是说中台将原来的半自动复用模式变成了全自动解决方案，所以如果还是以以往的单点是复用来去看待中台的话，那么只能说对中台的概念理解还是不到位，这个概念我会在后面的文章中具体展开。

相关阅读：中台实战系列文章

对了，本书入选了电子工业出版社好书精选，如果想要了解更多高阶产品经理必备的业务建模技能与中台建设相关内容可以看看我的新书《中台产品经理宝典》，相信会给你带来不少启发！

文末提醒：双十一本书在京东限时参加满100减50的巨额折扣，对本书感兴趣的千万不要错过！