一个业务型产品经理眼里的中台

人人都是产品经理 • 4年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

编辑导读：自从阿里巴巴提出“大中台、小前台”战略以来，关于中台是什么的文章讨论已经不胜枚举了，但是很多人对于中台仍然是一知半解。本文作者从业务产品经理的角度出发，结合业务案例，从是什么、有什么、怎么做三个方面对中台展开了详细说明，与大家分享，希望能够给大家带来一定的启发。

一个业务型产品经理眼里的中台

2017年秋天某个下午，星巴克大华风情店一楼，柜台后面冲咖啡的人换了一个，今天冲泡的香草拿铁比平时难喝，比起和店员理论，我更期待的是接下来的环节。因为我和朋友老A约在这里，向他请教有关“中台”的原理，这个让我身边不少人都焦虑了起来东西到底为何物。

他们中有些人是怕错过高科技，有些人是怕错过风口，有些人担心不知道中台会给自己成长带来不利，这也更加深了我的好奇心。

老A低着头，翻起笔记本电脑的盖子，一阵53231323的输入过后，微微抬起头，透过他那看起来好几天没擦过的眼镜片，开启了我们今天的谈话。

“钟华那本《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》看了吗？”

“好的，没看也没事儿，里面的内容你看起来也没什么帮助，讲技术架构的东西比较多，你们没有技术背景的产品经理看这本书会有启发，但实际上帮助不大”我还没听清楚书名，老A把他的电脑屏幕移过来对着我，自顾自的补充说到。

（我说话了吗？）

老A是特别资深的开发，在top2互联网大厂里参与过无数大小项目，在大厂10年的时间里，从工程师做到了业务架构师，出来后在一家创业团队做CTO。在他的授业计划里，今天准备把他们公司的内容脱敏后，跟我讲一个千万用户社交电商APP的技术架构，以及在这个过程中他们怎么中台得到实践。

到这里，如果你脑袋里瞬间闪过一些问号，那么，你和我当初刚听到“中台”时的情景一样。接下来本文我将分三个部分，来讨论你和我脑袋里闪过的问号，由此来了解什么是中台。

问号1：中台是什么？
问号2：中台有什么可借鉴？
问号3：中台该怎么做？

01 中台是什么？

和老A的面基结束后，我在京东买了钟华的书来看，书里面不少内容的语句风格是这样的，开放存储服务OSS、关系型数据库服务DRDS、消息服务MQ等等，从这里我能得出的线索也仅仅是NB两个大字了，毕竟这些技术术语听起来是很吃力。

现在回想起来，老A当时对我说的话，也不无道理。阿里巴巴提出“大中台、小前台”战略的一个初衷是为了规避重复开发相似功能的问题，这也就意味着中台是技术驱动。

至今我还清楚记得，老A他们的技术架构是按照业务来区分，总共是17个微服务，每个微服务提供了丰富的API接口，其他业务单元只需根据自身的运营需求来调用这些API就行。这样的架构能让单个业务的效率更高的同时，也能让系统更安全。

他举了个例子，比如在做中台构建之前的某次双十一，由于秒杀业务的流量飙升，导致了他们其他业务模块也收到了影响，有的用户在支付订时无法支付的情况发生。

这17个微服务之一的“用户中心”，支撑的业务有用户登录注册、用户画像生成、用户标签生成更新、风控系统、优质用户管理、黑名单用户自动生成等等，这里面单独一个业务都可以是一个复杂的产品，而这些业务之间又是高度关联的。

比如说黑名单用户就和风控系统离不开，而这两个东西又和用户的画像关联度高。把这些关联度高的业务集合在一个微服务里面，抽离出高度相似的场景，然后为这些场景去开发功能，当其他业务需要的时候就可以直接调用，这也是阿里巴巴提出中台时提到的一个关键特点，归拢高度相似的业务，把底层功能开发出来提供支撑，避免重复开发。

那中台是什么呢？

我们通过两个例子来尝试理解，中台是一个什么样的存在。

例子一

一个业务型产品经理眼里的中台

图1-1 中台示意图

我理解中台分为以下三步：

第一步，先把APP上的一切内容、数据抽象为底层；
第二步，把这些内容和数据管理的功能归纳成一层，这一层也就是中台了；
第三步，抽离出哪些端或业务在使用中台对应的功能，比如APP端、PC端、微信小程序分别用中台里面的哪些功能，这也就能理解中台了。

我们展开看第二层里面的商品管理，一个商品从采购计划制定开始，直到商品最终发送到用户的手中，中间至少需要经历入库、信息采集、上架、借调/出库，而这些环节并不是在相同的一个系统里面能完成的，比如入库、信息采集、出库是由商品管理系统进行管理的，也就是我们常说的WMS系统（Warehouse Management System），而上架和发货订单管理又是由商城的运营后台系统进行管理的，我们假设该系统为PMS（Plant Management System）。

同一个商品，需要先经过WMS系统入库、再上架到PMS系统去进行售卖，PMS系统售卖出去后又需要回到WMS系统进行发货出库，再把物流信息和库存信息同步会PMS系统。

针对商品管理的系统原理是一样的，那同一个商城如果有多个售卖业务的话，就不需要去重复开发雷同的功能了，只需要把最底层的商品管理做成可配置或可灵活调用的基础设施，其他业务只需要把其中的参数进行修改就能继续复用，节省团队大量的人力物力。

例子二

我在对接开放平台的过程中，越发觉得各种开放平台其实也是一种中台，比如说支付宝支付、微信支付能力是介于开发者和银行系统之间的一种服务能力。

比如一个卖书的APP，用户在APP端使用购书服务，中间的支付环节是由支付宝或微信支付承接的，至于最后面银行对应的清算系统开发者完全没有触碰到，在这个业务流程里面来看，支付平台也承担着中台的角色。

我们回想一下，用户网易严选APP上购买了一个拖把、又去得到APP上购买一套心理学课程，也就是说，不管用户支付实际商品、还是购买虚拟服务，这两个场景下都调用了同样的支付APP来进行了支付，支付是一个高度相似的场景。

支付开发平台给商家通过代付代收、科目明细服务，支付平台在后面已经把资金管理、支付渠道对接、支付订单建立与通知等等工作做完了，对外打包成一个简化的接口，开发者仅仅需要调用即可。

这里可以得出一个启发，在某些功能设计的过程中，产品经理可以借用中台的思想去进行构思。

结论：中台是一种高度集成、有共同特征的不同业务可复用的技术架构方案。

02 中台有什么可借鉴？

在拜读了钟华《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》后，我理解的中台至少有以下两个优势可以借鉴。

1. 避免重复开发

我的产品经历里面有一个案例，进入了一个新的项目组做增长，和团队合计下来后决定做砍价功能，Boss觉得原来的老系统太复杂了，希望我们冲洗做砍价功能。

明显，需要重新开发商品管理、订单管理，团队如实和Boss反馈了情况后，建议先在原有的系统上做延伸，若砍价业务的业务增长要求需要我们去做一个新的系统的时候，我们再重新做。

如果新作一套砍价系统，后面不仅仅是商品管理、订单管理需要重新做，商品库存的及时同步、运营平台和仓库管理系统之间订单状态的同步等功能也相当于是要重新对接，重复开发并不是什么好事。中台思想在这个过程中能起到较好的引导作用。

2. 简化复杂

作者在书中提到的一个事实，淘宝的WAR包里面有200多个功能，这些功能里面有些更新频次低，而运营类的功能更新频次较高，这样导致淘宝平台整体业务受到影响的情形出现。

随着淘宝业务的增长，功能变得越复杂，作者在书里有一张被无数错综复杂电线缠绕的电线杆，用来形容淘宝当时复杂的系统。经过沉淀，截止书出版时阿里集团超过25个业务单元均是由“共享事业部”提供服务（中台），如下图所示；

一个业务型产品经理眼里的中台

图2-1 共享业务事业部在阿里巴巴业务架构中的重要地位（截图来自钟华的书）

03 中台该怎么做？

在向老A请教完之后，已经有一个明显的结论在我心底产生，如果要回答中台该怎么做，我的结论是“中台是在业务上长出来的，不是刻意做出来的”。

管理学上有一个理论是组织结构是由业务决定的，团队里面需要什么样的人是由于公司的业务发展到那个阶段了，需要有对应技能的人才来做支持，所以业务的发展决定着公司的人员、管理结构。通过这个理论可以映射出一个结论，随着业务不断的新增和发展，对应的功能也变得越来越复杂，而中台在复杂的功能里面能够起到简化的作用。

那中台要不要做呢？

我不建议创业团队去构建自己所为的中台，这有两个原因：

第一个原因是构建中台对应的是一个完整的业务模型，我们回头看本文前面提到的那张图2-1，创业团队的业务不会复杂到需要这么个复杂的系统来支持，不要把简单的事情复杂化；

第二个原因是资源投入问题，小团队的问题不是去建立复杂的中台系统，如果小团队的目标是A，那么构建中台只不过是个方法，可能它能解决的问题是BCD，并不能解决A的问题，小团队应该把资源集中在重要的问题上。