中台到底是个什么鬼?

2019-07-19 18:56:00 产品大发pk10 John 分享

说起中台,大家很容易想到阿里在16年提出的“大中台小前台”战略,其实John现在也在思考搭建数据中台的想法,所以现在结合自己的思考来写写这篇文章。

中台价值就是——一切以快速响应需求为依归。

一、中台是怎样诞生的呢?

其实中台是想象出来的概念。中台和产品经理职位一样,中台并不是一开始就有的,而是基于“前台+后台”的架构发展演变的,先说下前台和后台。

前台:前台是系统的前端平台,是直接与终端用户进行交互的应用层。拿电商平台来举例,我们日常使用的app、H5端、pc端以及小程序都属于电商的前台系统。

后台:后台是指系统的后端平台,终端用户是感知不到他的存在的。后台的价值是存储和计算企业的核心数据。例如供应链管理系统存储商品及库存数据、客户管理系统存储用户信息。

产品经理都知道,用户的需求是瞬息万变的,用户需求的变化决定了前台系统需要快速迭代响应用户需求,而前端的变化需要后端的变化来支撑,因此这就对后台的快速应变产生了要求。而后台设立之初核心目的并不是服务于前台,而是提升后端数据的安全及系统的管理效率。

举例来讲:随着业务的扩大后端存储大量的合同、商品、订单及用户等私密数据,因为安全性及缘故,这些数据无法供前台拿过来直接用,同样也无法快速的改造系统来响应前台的变化。因此,出现了“前台为了用户需求,期望系统不断的快速迭代”与“后台为了数据安全与系统稳定,期望系统趋于稳定”的矛盾局面。

在这一矛盾的局面下,为了满足前台的快速迭代需求和后台的稳定性需求,伟大的架构师们,创造性的提出了“中台”概念,核心是将后台的逻辑层拆出来,形成”前台(应用层)-中台(逻辑层)-后台(数据层)“的产品架构。在这一产品架构下,当前台需求来临时,中台能快速的进行响应,从而提升了研发效率,降低了创新成本。

(图片放大后再看哦)

传统“前台+后台”系统架构

“前台+中台+后台”系统架构

中台并不是一开始就有的,而是系统为适应需求的快速迭代而产生的。具体来讲,中台其实是将系统的通用化能力进行打包整合,通过接口的形式赋能到外部系统,从而达到快速支持业务发展的目的。比如:

业务中台,更多的是对业务的支持,比如客户信息,组织信息、产品信息等,这些都来自某一个系统,且分别支持多个系统的业务。各个系统有相关需求时,需要重新开发。而业务中台的作用就是省去开发,直接从中台获取相关功能。

数据中台,利用获取的各类数据、对数据进行加工,获取分析结果,然后提供给业务中台使用。数据中台的数据来自各业务系统或者数据湖,有源数据、关联数据、加工好的数据(已经整理的主题数据、算法、模型),再提供给业务中台使用。以购物网站的大发pk10为例,数据中台根据数据提供算法,然后业务中台基于算法的结果,支撑关联大发pk10。

从技术角度,中台是为了搭建一个灵活快速应对变化的架构,可以快速实现前端提的需求,避免重复建设,这也是复合敏捷开发理念。从业务角度,根据中台沉淀的能力,可以支持快速创新,业务更敏捷,以应对未来市场变化。相关业务板块已经做好,那么底层只要组合一下即可,更加灵活和快速。所以归根到底,我们必须需要结合企业的实际情况,走出符合企业战略目标的中台之路。不能盲目跟风,为了中台而中台。

二、怎么做中台?

从产品层面,中台本质上是将后台的逻辑层抽象出来的一种系统模块,其目的在于快速的支持业务发展,因此,个人认为,中台实际上是站在“快速响应需求迭代”角度的一种产品设计思维。

当系统足够庞大时,产品、业务和用户的每个需求都会涉及到多个系统关联,尤其是针对多事业部的公司,这些系统都分布在不同的事业部,所以难免会有一些问题:

系统复杂,无法快速拿出产品方案

多重对接,沟通成本巨大

系统间耦合性较大,牵一发而动全身

基本上因为以上问题,新的业务需求无法快速满足。当一个业务诉求牵涉到系统较多时,需要对应配合的人数太多。因此,从产品/系统角度,我们就需要考虑以中台化的思维去进行方案设计:

通用性

对于业务需求,要跳出需求看本质,理解业务方的真实需求是什么;要跳出模块看全局,理解这个需求的实现,除了对消费者、商家的价值,要看到它对平台的价值。

例如之前负责的订单导出功能,其实用户需求很简单:快速导出数据,进行业务分析。但是站在平台角度,平台富有对用户数据保护的义务,因此需要考虑从数据及用户层面做权限控制;同时也考虑到商家不仅需要导出订单,后续可能导库存、商品及其他业务数据,因此需要考虑产品的通用性,以降低后续开发的成本。作为平台型产品经理,要通盘思考整体的结构,才能做到互不牵连。

结构化

在方案设计上,要做到通用性,需要将通用能力从解决方案中抽离出来,与业务场景进行解耦,从而实现“业务场景-通用能力”系统架构。

还是拿订单导出举例,刚开始设计订单导出时,权限控制,导出任务创建,导出数据下载,订单业务耦合,其他业务接入时费事费力,还有可能对现有业务产生影响。因此才将订单导出的通用能力从业务场景中解耦出来。

标准化

将通用能力与业务场景解耦只是第一步,我们要将通用能力进行打包,形成一套标准化模版,以接口化的形式赋能到外部的业务场景,供业务场景按照标准化的形式进行接入和开发,降低其他业务导出的开发成本。

声明:本站部分资源来源于网络,版权归原作者或者来源机构所有,如作者或来源机构不同意本站转载采用,请通知我们,我们将第一时间删除内容。本站刊载文章出于传递更多信息之目的,所刊文章观点仅代表作者本人观点,并不意味着本站赞同作者观点或证实其描述,其原创性及对文章内容的真实性、完整性、及时性本站亦不作任何保证或承诺,请读者仅作参考。
编辑: