1.3 数据与业务双中台解读

1.2节（中台的主要价值）提到了数据与业务中台的价值。

数据中台将前台、后台及业务中台所产生的数据进行抽离，以此打破数据隔阂，解决企业面临的数据孤岛等问题，并以此为基础进行数据产品的落地建设，让数据资产的价值得以更好地发挥。

业务中台是能力复用平台，它会抽象实际业务中的共有需求，为企业解决“重复造轮子”的问题。

但是，目前“中台”的概念尚未有一个明确的、统一的定义，所以我们有必要再来解释一些问题，方便大家更加透彻地理解中台的建设思路。

1.3.1 数据中台的几点讨论

数据中台的概念，从2018年逐渐火热起来，至今仍在节节升温。数据中台百度指数趋势（2018—2020年）如图1-2所示。

价值高与概念火热，并不代表大家对数据中台没有疑问。萦绕在大家心中的问题，可能有以下这些。

● 数据中台为什么这么火热？

● 数据中台和数据仓库有什么区别？

● 数据中台是不是可以成为一种工具或者一款产品？

下面就让我们解读一下上面的问题。

1.数据中台火热的原因

近些年，数据中台的概念火遍了科技圈，虽然部分企业有“概念炒作”的嫌疑，却也在一定程度上证明了数据中台的重要性。至于数据中台为什么会迅速火爆起来，主要有以下两点原因。

1）项目成果能见度高

数据中台不同于业务中台。虽然业务中台直接服务于前台，但其项目成果不易量化；反观数据中台，不管是数据治理（数据资产化），还是支撑业务决策（数据业务化），项目成果能见度高，容易出成绩，可以增强决策者对数据中台的建设信心。

2）对现有组织架构影响小

数据中台不像业务中台那样大刀阔斧地去劈开各系统间的壁垒，它更像一阵春风，悄无声息地滋润着企业的每个部门，也可以把它形容成藤蔓，缠绕在各系统上，从各系统中获取数据，然后经过加工反哺给各系统。这样的共生关系，不会影响各系统原有的运行，也不会对原有组织架构产生过多的影响。

基于上述原因，数据中台的火热也就不足为怪了。

2.数据中台和数据仓库的区别

数据中台和数据仓库有什么区别？这是很多互联网从业者的疑问。在实际工作中，数据仓库（简称数仓）会存储各类数据，并产出各种可视化报表，而数据中台所要完成的数据治理给人一种要做企业级数仓的感觉。

那么，数据中台和数仓到底有什么区别？在此我们提出如下两点不同。

1）数据实时性不同

数仓的数据建设大部分基于各业务系统的关系型数据库及各前台业务的埋点数据，其计算方式可以做到 T+1（延迟一天）的离线计算，实时计算能力较弱。而且传统数仓存储的结构化数据较多，对非结构化数据的处理能力较弱。反观数据中台，不仅需要解决各类数据的存储与融合问题，还要实现实时计算，甚至是智能计算。

2）业务目标不同

传统数仓讲究根据实际业务进行数据抽取并产出报表，解决的是“一城一地”的问题，而数据中台不仅面向报表，还服务于前台业务，从而实现数据资产化与业务化，在报表的基础上，提供个性推荐、营销决策、风险评估等内容，并为企业各系统提供数据 API（应用程序接口）服务。相比传统数仓，数据中台更像一个综合性数据服务平台。

3.数据中台和数据工具的区别

随着数据中台的火热，某些传统软件商将原有的数据产品改名为某数据中台，然后对外销售，好像数据中台就是一款可以即插即用的工具。那么实际上呢？数据中台是工具吗？

在介绍数据中台的价值时，我们提到除了实际功能，数据中台还是一种战略选择与运营解决方案，也是一套行之有效的数据运营机制。所以，我们不能将数据中台简单地等同于数据工具，而应将数据中台看作数据工具、数据服务模式与数据运营机制的结合体。

1.3.2 业务中台的几点讨论

关于业务中台是什么，我们在1.2.2节（业务中台的价值）中做过解释，但是仍然有几个问题摆在我们的面前，如下所述。

● 业务中台和前台、后台的功能边界在哪里？

● 业务中台和中间件、微服务的区别在哪里？

● 业务中台项目该由哪些人或哪个部门来主导？

这3个问题是业务中台落地前需要搞明白的，也是很多有关中台的文章未曾提及的，本节将对上述问题进行简单的解读。

1.业务中台与前台、后台的功能边界

在中台概念引进之前，企业中各项目之间相对独立，随着项目的成长，企业中“烟筒”林立，效率受到掣肘，于是项目模式逐步演进。中台的诞生过程如图1-3所示。

从前台、后台的完全隔离到后台系统的相对统一，再到业务中台的诞生，都是企业提升效率的举措。

其中，业务中台通过对公共技术模块与通用业务需求的抽离，形成中台服务，封装成公共业务模块供前台调用，以降低开发成本，提高开发效率。但问题在于，哪些业务流程是通用的？哪些功能是需要抽离出来放置在业务中台里的？简单地说，就是业务中台和前台、后台的功能边界在哪里？

为了让大家更好地理解上述问题，我们先来定义一下一般情况下的前台与后台，如下所述。

● 前台：前台面向用户，是可以让用户直接看到与接触的产品，如 PC 端网站、移动端App、微信小程序等。

● 后台：后台是提供给系统管理人员与内部用户使用的产品，如客户管理系统（CRM 系统）、企业资源管理系统（ERP 系统）、财务系统等，这些系统构成了企业的后台矩阵。

业务中台作为前台的服务者会承接前台业务方的各种需求，如果不做甄别地接受，就会沦为前台业务的外包团队，还“费力不讨好”。因为模糊的边界意味着无穷的撕扯，会使中台团队陷入两难境地。

为了避免这样的问题，我们尝试对业务中台与前台、后台的边界进行划分：业务中台要符合企业建设业务中台的初衷，以抽取通用需求为前提，适度完成弹性变化的需求。

● 初衷，是第一个关键词。业务中台所做的功能规划一定要符合企业建设业务中台的初衷，即无论企业想要用业务中台解决什么问题，都不能背离初衷。

● 通用，是第二个关键词。业务中台是企业的业务中台，不是面对单一业务、单一系统的中台，所以我们需要解决各业务线的通用需求，以及潜在的通用需求。

● 弹性，是第三个关键词。弹性需求对应着上面提到的潜在的通用需求，这样的需求可能当前只服务于某个前台业务，如果我们判断它具备一定的成长性与通用性，那么这样的需求同样可以成为中台的一部分。

上述内容就是边界的划分依据，大家可以结合企业的实际情况进行参考。

2.业务中台与微服务、中间件的关系

首先，看一下微服务与中间件的定义，如下所述。

● 微服务，是按照业务领域进行拆分的高内聚、低耦合的小型服务单元，各服务单元之间相互独立，既可以独立部署，又可以通过标准的通信协议进行相关访问。

● 中间件，是介于前端应用与后台系统之间的系统软件或服务，实现了不同系统之间的互连操作，如消息中间件、交易中间件等。

这样来看，是不是微服务和中间件就是业务中台呢？

答案是否定的，微服务和中间件是实现业务中台的技术手段，但并不等同于业务中台。并不是堆砌了服务组件就可以完成业务中台的打造，业务中台具备业务属性，是一个企业级能力复用平台，也是一种全新的企业组织架构。

如果把中台比作饭店的配菜中心（配菜中心需要根据菜肴的品种和各自的质量要求，把经过刀工处理后的两种或两种以上的主料和辅料适当搭配，使之成为一道菜的原料），微服务就是分菜、配菜的方法，中间件就是切菜的刀、盛菜的盘。

上述比喻可能不是很贴切，但是足够我们用来理解业务中台与微服务、中间件的关系。明白了三者之间的关系，我们再来谈一下业务中台该由谁来担纲负责。

3.业务中台项目的主导者

业务中台为前台服务，是不是就要在前台选择主导者，然后从各前台事业部调拨人马组建中台团队呢？

服务前台就选择了解前台业务的人来担纲，这是一种选择，不过我们需要认识到业务中台“破壁者”的定位，在打破原有“烟筒”式的系统格局的过程中，业务中台的主导者难免会遭遇到前台反馈回来的压力。

从前台调拨人马，可能会遭受“本是同根生，相煎何太急”的实施压力。另外，从前台“选帅”，也可能被业务目标影响，从而缺乏自上而下推动前台系统改造的力度。

业务中台建设是企业级战略项目，也可以说是“一把手项目”，所以企业“一把手”坐镇最好不过，不偏不倚，还具备强执行力。当然CTO（首席技术官）挂帅也可以，既保障了项目的中立性，又保障了中台的开发资源。

与此同时，我们还需要一份可以贯彻实施的纲领与制度。纲领源自企业建立中台的愿景与初衷，制度确保中台的中立性，既要满足业务需求，又不过度参与业务。

总之，中台需要的主导者是可以执行这份纲领与制度的人，至于具体是谁，因时因地而异，需要企业管理者来决策。