说起中台，大家很容易想到阿里在16年提出的“大中台小前台”战略，其实John现在也在思考搭建资料中台的想法，所以现在结合自己的思考来写写这篇文章。
中台价值就是——一切以快速响应需求为依归。
一、中台是怎样诞生的呢？
其实中台是想象出来的概念。中台和产品经理职位一样，中台并不是一开始就有的，而是基于“前台+后台”的架构发展演变的，先说下前台和后台。
前台：前台是系统的前端平台，是直接与终端使用者进行互动的应用层。拿电商平台来举例，我们日常使用的app、H5端、pc端以及小程式都属于电商的前台系统。
后台：后台是指系统的后端平台，终端使用者是感知不到他的存在的。后台的价值是储存和计算企业的核心资料。例如供应链管理系统储存商品及库存资料、客户管理系统储存使用者资讯。
产品经理都知道，使用者的需求是瞬息万变的，使用者需求的变化决定了前台系统需要快速迭代响应使用者需求，而前端的变化需要后端的变化来支撑，因此这就对后台的快速应变产生了要求。而后台设立之初核心目的并不是服务于前台，而是提升后端资料的安全及系统的管理效率。
举例来讲：随着业务的扩大后端储存大量的合同、商品、订单及使用者等私密资料，因为安全性及缘故，这些资料无法供前台拿过来直接用，同样也无法快速的改造系统来响应前台的变化。因此，出现了“前台为了使用者需求，期望系统不断的快速迭代”与“后台为了资料安全与系统稳定，期望系统趋于稳定”的矛盾局面。
在这一矛盾的局面下，为了满足前台的快速迭代需求和后台的稳定性需求，伟大的架构师们，创造性的提出了“中台”概念，核心是将后台的逻辑层拆出来，形成”前台（应用层）-中台（逻辑层）-后台（资料层）“的产品架构。在这一产品架构下，当前台需求来临时，中台能快速的进行响应，从而提升了研发效率，降低了创新成本。
（图片放大后再看哦）
传统“前台+后台”系统架构
“前台+中台+后台”系统架构
中台并不是一开始就有的，而是系统为适应需求的快速迭代而产生的。具体来讲，中台其实是将系统的通用化能力进行打包整合，通过界面的形式赋能到外部系统，从而达到快速支援业务发展的目的。比如：
业务中台，更多的是对业务的支援，比如客户资讯，组织资讯、产品资讯等，这些都来自某一个系统，且分别支援多个系统的业务。各个系统有相关需求时，需要重新开发。而业务中台的作用就是省去开发，直接从中台获取相关功能。
资料中台，利用获取的各类资料、对资料进行加工，获取分析结果，然后提供给业务中台使用。资料中台的资料来自各业务系统或者资料湖，有源资料、关联资料、加工好的资料（已经整理的主题资料、演算法、模型），再提供给业务中台使用。以购物网站的推荐为例，资料中台根据资料提供演算法，然后业务中台基于演算法的结果，支撑关联推荐。
从技术角度，中台是为了搭建一个灵活快速应对变化的架构，可以快速实现前端提的需求，避免重复建设，这也是复合敏捷开发理念。从业务角度，根据中台沉淀的能力，可以支援快速创新，业务更敏捷，以应对未来市场变化。相关业务板块已经做好，那么底层只要组合一下即可，更加灵活和快速。所以归根到底，我们必须需要结合企业的实际情况，走出符合企业战略目标的中台之路。不能盲目跟风，为了中台而中台。
二、怎么做中台？
从产品层面，中台本质上是将后台的逻辑层抽象出来的一种系统模组，其目的在于快速的支援业务发展，因此，个人认为，中台实际上是站在“快速响应需求迭代”角度的一种产品设计思维。
当系统足够庞大时，产品、业务和使用者的每个需求都会涉及到多个系统关联，尤其是针对多事业部的公司，这些系统都分布在不同的事业部，所以难免会有一些问题：
基本上因为以上问题，新的业务需求无法快速满足。当一个业务诉求牵涉到系统较多时，需要对应配合的人数太多。因此，从产品/系统角度，我们就需要考虑以中台化的思维去进行方案设计：
通用性
对于业务需求，要跳出需求看本质，理解业务方的真实需求是什么；要跳出模组看全域性，理解这个需求的实现，除了对消费者、商家的价值，要看到它对平台的价值。
例如之前负责的订单汇出功能，其实使用者需求很简单：快速汇出资料，进行业务分析。但是站在平台角度，平台富有对使用者资料保护的义务，因此需要考虑从资料及使用者层面做许可权控制；同时也考虑到商家不仅需要汇出订单，后续可能导库存、商品及其他业务资料，因此需要考虑产品的通用性，以降低后续开发的成本。作为平台型产品经理，要通盘思考整体的结构，才能做到互不牵连。
结构化
在方案设计上，要做到通用性，需要将通用能力从解决方案中抽离出来，与业务场景进行解耦，从而实现“业务场景-通用能力”系统架构。
还是拿订单汇出举例，刚开始设计订单汇出时，许可权控制，汇出任务建立，汇出资料下载，订单业务耦合，其他业务接入时费事费力，还有可能对现有业务产生影响。因此才将订单汇出的通用能力从业务场景中解耦出来。
标准化
将通用能力与业务场景解耦只是第一步，我们要将通用能力进行打包，形成一套标准化模版，以界面化的形式赋能到外部的业务场景，供业务场景按照标准化的形式进行接入和开发，降低其他业务汇出的开发成本。
以订单汇出举例，我们将“许可权控制”，“建立汇出任务”，“下载汇出资料”封装为不同的界面，形成汇出中心，提供给不同的业务场景。
可拓展
到这一步，已经形成了“单通用能力对应多业务场景”的系统架构，若业务侧有定制化需求，可从业务场景角度进行单独定制，以致于不会对其他业务场景产生影响，也提升了定制化需求的研发效率。
John正在思考的资料中台
所谓资料中台，即实现资料的分层与水平解耦，沉淀公共的资料能力。
笔者认为可分为三层：资料模型、资料服务与资料开发。通过资料建模实现跨域资料整合和知识沉淀，通过资料服务实现对于资料的封装和开放，快速、灵活满足上层应用的要求，通过资料开发工具满足个性化资料和应用的需要。
这个图只是John思考的一个点，如何有效的讲资料打通，主体是建立更完备的使用者画像。也许我的目的就达到了。
三、总结
以使用者为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力，是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段，并不是⽬标本身。
中台（⽆论是技术中台、业务中台还是组织中台）的建设根本上是为了解决企业响应⼒困境， 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾，提供⼀个中间层来适配前台与后台的配速问题，沉淀能⼒，打通并顺滑连结前台需求与后台资源，帮助企业不断提升使用者响应⼒。
所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于⽤户的响应⼒才是最重要的。⽽平台化或是中台化，只是恰巧走在了了这条正确的⼤道上。
当然，这篇文章只是John的思考，纯主观思考。也许并不是这么去解剖，但是过程中去快速试错，小步快跑或许能达到不一样的目的。那咱们去试试。
作者：John，产品狗一枚，微信公众号：产品狗聚集地。欢迎一起沟通交流。
本文由@John 原创释出于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash, 基于CC0协议
