说到中队，很容易想到阿里16年推出的“大众队小前台”战略。事实上，John现在也在思考创建数据中队的想法，所以现在和自己的思考一起写这篇文章。

重大价值是3354的一切都迅速响应需求。

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

事实上，中央大学是想象的概念。和中大和产品经理职位一样，中大不是一开始就有的，而是基于“前端后台”的架构发展，首先是指前台和后台。

前端：前端是系统的前端平台，是直接与终端用户交互的应用层。例如，我们日常使用的app、H5端、PC端、小程序都属于电商的前端系统。

背景：背景是系统的后端平台，最终用户不知道他的存在。背景的价值是存储和计算企业的核心数据。例如，供应链管理系统存储商品和库存数据，客户管理系统存储用户信息。

产品经理很清楚，用户的需求瞬息万变，随着用户需求的变化，前端系统需要快速反复地响应用户的需求，前端的更改需要支持后端的更改。因此，这就对后端的快速变化提出了要求。后台设立的首要核心目的不是为前台提供服务，而是提高后端数据的安全性和系统管理效率。

例如，随着业务的扩展，后端存储了大量合同、商品、订单和用户等个人数据。由于安全性和原因，该数据不能直接在前台使用，也不能快速响应前台的变化。因此，出现了“前台为了用户的需求，期待系统不断快速迭代”和“为了后台的数据安全和系统稳定，期待系统稳定”的矛盾。

在这种矛盾的情况下，为了满足前台的快速迭代要求和后台稳定性要求，伟大的建筑师创造性地提出了“重大”概念。关键是分离后台逻辑层，形成“前台(应用层)-重大(逻辑层)-后台(数据层)”。在该产品体系结构中，在当前需求出现时，中大通过快速反应，研发ampd提高效率，降低创新成本。

(照片放大后再看)

现有“前台后台”系统体系结构

“前台主管”系统体系结构

连队不是一开始就有，而是为了适应需求而快速迭代，导致了系统的产生。特别是，中央大学实际上通过打包系统的通用功能、通过接口形式分配给外部系统，实现了快速支持业务发展的目的。(阿尔伯特爱因斯坦，Northern Exposure)例如：

业务高管、客户信息、组织信息、产品信息等对业务的支持更多。所有这些都来自一个系统，并单独支持多个系统的业务。如果每个系统都有相关要求，则需要重新开发。业务主管的作用是跳过开发，直接从连队获得相关功能。

数据中队，利用获得的多种数据，加工数据，得到分析结果，然后在业务中队使用。数据中队的数据可以从每个业务系统或数据湖、源数据、相关数据、加工的数据(整理的主题数据、算法、模型)中获取，然后在业务中队中使用。以购物网站的推荐为例，数据中队根据数据提供算法，然后业务中队根据算法的结果支持关联推荐。

从技术角度来看，中央大学也是一个复合敏捷开发理念，为了构建灵活快速地应对变化的体系结构，可以快速实现前端要求，避免重复建设。从业务角度来看，根据重大沉淀的能力，能够支持快速创新，业务更加灵活，能够应对未来的市长/市场变化。相关业务部门已经完成，把底层组合一下就更灵活、更快了。因此，归根结底，我们要结合企业的实际情况，走出符合企业战略目标的重大道路。不能盲目跟风，不能为了连队进入连队。

在

二、怎么做中台？

产品层面，中央大学本质上是一个在后台抽象逻辑层的系统模块，目的是为了快速支持业务发展，所以个人认为中央大学实际上是从“快速响应需求迭代”的角度进行的产品设计思维。

如果系统足够大，产品、业务和用户的每项需求都会出现一些问题，因为多个系统连接，特别是面向多个业务部门的企业分布在不同的业务部门。

系统复杂，无法快速推出产品方案的多对接，通信成本巨大

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

通用性

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

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

结构化

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

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

标准化

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

以订单导出举例，我们将“权限控制”，“创建导出任务”，“下载导出数据”封装为不同的接口，形成导出中心，提供给不同的业务场景。

可拓展

到这一步，已经形成了“单通用能力对应多业务场景”的系统架构，若业务侧有定制化需求，可从业务场景角度进行单独定制，以致于不会对其他业务场景产生影响，也提升了定制化需求的研发效率。

John正在思考的数据中台

所谓数据中台，即实现数据的分层与水平解耦，沉淀公共的数据能力。

笔者认为可分为三层：数据模型、数据服务与数据开发。通过数据建模实现跨域数据整合和知识沉淀，通过数据服务实现对于数据的封装和开放，快速、灵活满足上层应用的要求，通过数据开发工具满足个性化数据和应用的需要。

这个图只是John思考的一个点，如何有效的讲数据打通，主体是建立更完备的用户画像。也许我的目的就达到了。

三、总结

以用户为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力，是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段，并不是⽬标本身。

中台（⽆论是技术中台、业务中台还是组织中台）的建设根本上是为了解决企业响应⼒困境， 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾，提供⼀个中间层来适配前台与后台的配速问题，沉淀能⼒，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应⼒。

所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于⽤户的响应⼒才是最重要的。⽽平台化或是中台化，只是恰巧走在了了这条正确的⼤道上。

当然，这篇文章只是John的思考，纯主观思考。也许并不是这么去解剖，但是过程中去快速试错，小步快跑或许能达到不一样的目的。那咱们去试试。

作者：John，产品狗一枚，微信公众号：产品狗聚集地。欢迎一起沟通交流。

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

题图来自Unsplash, 基于CC0协议