什么是中台？企业为什么要建中台？从数据中台到AI中台

到处都在喊中台，到处都是中台，中台这个词在今天看来已经被滥用了。

* 在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。

 

* 在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。

 

* 在有些人眼里：中台应该是组织的事情，在释放潜能：平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念，这类组织中台在企业中主要起到投资评估与投后管理的作用，类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”

 

看完本篇你就会理解，上边的这几类“中台”划分还是靠谱的，更多的情况是大家为了响应企业的“中台战略”，干脆直接将自己系统的“后端”或是“后台”改个名，就叫“中台”。

中台到底是什么？它对于企业的意义到底是什么？当我们谈中台时我们到底在谈些什么？

想要寻找到答案，仅仅沉寂在各自“中台”之中，如同管中窥豹，身入迷阵，是很难想清楚的。不如换个 ⾓度，从各类的“中台迷阵”中跳脱出来，尝试以更高的视角，从企业均衡可持续发展的角度，来思考中台的价值，来试图反推它存在的价值。

所以，为了搞明白中台存在的价值，我们需要回答以下两个问题：

企业为什么要平台化？

企业为什么要建中台？

 

第一个问题：企业为什么要平台化？

 

先给答案，其实很简单：

因为在当今互联网时代，⽤户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。

不断快速响应、探索、挖掘、引领⽤户的需求，才是企业得以⽣存和持续发展的关键因素。

那些真正尊重用户，甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展；⽽反之，那些在过去的成就上故步⾃封，存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。

很残酷，但这就是这个时代最基本的的企业⽣存法则。

 

 

 

⽽平台化之所以重要，就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力：⽤户响应力。这种能力可以帮助企业在商战上先发制⼈，始终抢得先机。

可以说，在互联网时代，商业的斗争就是对于用户响应力的比拼。

又有点远大空是不是，我们来看⼏个经典的例子:

说起中台，最先想到的应该就属是阿⾥的“⼤中台，⼩前台”战略。阿⾥⼈通过多年不懈的努力，在业务的不断催化滋养下，将⾃己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。

 

 

海尔也早在⼗年前就已经开始推进平台化组织的转型，提出了“平台⾃营体⽀撑⼀线⾃营体”的战略规划和转型⽬标。构建了“订单合一”、“用户付薪” 的创客文化，真正将平台化提⾼到了组织的⾼度。

 

 

华为在几年前就提出了“⼤平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火” 这句话形象的诠释了大平台⽀撑下小前台的作战策略。这种极度灵活又威力巨⼤的战法，使之可以迅速响应瞬息万变的战场，一旦锁定目标，通过大平台的炮火群，迅速精准对于战场进行强大的火⼒支援。

 

可⻅，在互联⽹热火朝天，第四次工业革命的曙光即将到来的今日，企业能否真正做到“以用户为中心”，并不断提升自己的用户响应力来追随甚至引领用户的脚步，持续规模化创新，终将决定企业能否在这样充满挑战和机遇的市场上笑到最后，在商业上长久保持创新活力与竞争力。

 

而平台化恰好可以助力企业更快更好的做到这些，所以这回答了第一个问题，企业需要平台化。

第二个问题：企业为什么要建中台？

 

好，想明白了第一个问题，为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?

好，这就引出了我们的第二个问题：企业为什么要建中台？

来，先定义一下前台与后台

 

因为平台这个词过于宽泛了，为了能让大家理解本文在说什么，先定义一下文章上下文下所说的前台和后台各指什么：

* 前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。

 

* 后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。

 

后台并不为前台而生

 

定义了前台和后台，对于第二个问题（企业为什么要建中台），同样先给出答案：

因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题

大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。

我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。

总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。

有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个2.0问题不就解决了。

但就算是新建的后台系统，因为其管理的是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制。导致其同样往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，以⽀持前台快速的创新需求。

此时的前台和后台就像是两个不同转速的⻮轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；⽽后台由于⾯对的是相对稳定的后端资源，⽽且往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好， 转速也自然是越慢越好。

所以，随着企业务的不断发展，这种“前台+后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。

随着企业业务的发展壮大，因为后台修改的成本和⻛险较⾼，所以驱使我们会尽量选择保持后台系统的稳定性，但还要响应用户持续不断的需求，自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中，引入重复的同时还会致使前台系统不断膨胀，变得臃肿，形成了一个个⼤泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“⽤户响应⼒”，用户满意度降低，企业竞争力也随之不断下降。

前面我们提到的后台系统，例如CRM、ERP、财务系统等，它们⼤多都处于SOR的Pace-Layered。这些系统的建设之初往往是以规范处理企业底层资源和企业的核心可追溯单据(例如财务单据，订单单据)为主要目的。它们的变更周期往往比较⻓，并且由于法律律审计等其他限制，导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求，这就导致了它们往往变化频率低，变化成本高，变化⻛险高，变化周期⻓。无法满足由用户驱动的快速变化的前台系统要求。

我们又要尽力保持后台(SOR)系统的稳定可靠，⼜要前台系统(SOI)能够⼩而美，快速迭代。就出现了上文提到的”齿轮匹配失衡“的问题，感觉鱼与熊掌不可兼得。

正当陷入僵局的时候，天空中飘来一声IT谚语：

软件开发中遇到的所有问题，都可以通过增加⼀层抽象⽽得以解决!

⾄此，⼀声惊雷滚过，“中台”脚踏七彩祥云，承载着SOD(Systems of differentiation)的前世寄托，横空出世。 

我们先试着给中台下个定义：

中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。

中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。

 

 

有了“中台”，我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应⼒；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”支援。

所以，企业在平台化的过程中，需要建设自己的中台层（同时包括技术中台，业务中台和组织中台）。

总结

 

思考并回答了文初提出的两个关于中台价值的核心问题，解决了大家对于中台产生的一些困惑，总结一下：

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

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

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

 

数据中台功能架构

 

数据中台建设是一个宏大的工程，涉及整体规划、组织搭建、中台落地与运营等方方面面的工作，本节重点从物理形态上讲述企业的数据中台应该如何搭建。一般来讲，企业的数据中台在物理形态上分为三个大层：工具平台层、数据资产层和数据应用层。

 

4.1 工具平台层

工具平台层是数据中台的载体，包含大数据处理的基础能力技术，如集数据采集、数据存储、数据计算、数据安全等于一体的大数据平台；还包含建设数据中台的一系列工具，如离线或实时数据研发 工具、数据联通工具、标签计算工具、算法平台工具、数据服务工具及自助分析工具。

 

以上工具集基本覆盖了数据中台的数据加工过程。

 

4.2 数据资产层

数据资产层是数据中台的核心层，总体来讲，可以划分为主题域模型区、标签模型区和算法模型区。

 

 

①主题域模型

主题域模型是指面向业务分析，将业务过程或维度进行抽象的集合。业务过程可以概括为一个个不可拆分的行为事件，如订单、合同、营销等。

 

为了保障整个体系的生命力，主题域即数据域需要抽象提炼，并且长期维护和更新，但是不轻易变动。在划分数据域时，既要涵盖当前所有业务的需求，又要保证新业务能够无影响地被包含进已有的数据域中或者很容易扩展新的数据域.

 

②标签模型

标签模型的设计与主题域模型方法大同小异，同样需要结合业务过程进行设计，需要充分理解业务过程。

 

标签一般会涉及企业经营过程中的实体对象，如会员、商品、门店、经销商等。这些主体一般来说都穿插在各个业务流程中，比如会员一般都穿插在关注、注册、浏览、下单、评价、服务等环节。那么在设计标签的时候就需要充分理解这些业务流程，在流程中发现标签的应用点，结合这些应用点来搭建企业的标签体系。标签模型按计算模式一般分为客观标签和主观标签。

 

设计标签模型时非常关键的要素是标签模型一定要具有可扩展性。毕竟标签这种数据资产是需要持续运营的，也是有生命周期的，在运营的过程中随时可能增加新的标签。

 

③算法模型

算法模型更加贴近业务场景。在设计算法模型的时候要反复推演算法模型使用的场景，包括模型的冷启动等问题。整个模型搭建过程包含定场景、数据源准备、特征工程、模型设计、模型训练、正式上线、参数调整7个环节。

 

以新零售企业为例，常用的机器学习算法有决策树、神经网络、关联规则、聚类、贝叶斯、支持向量机等。这些算法已经非常成熟，可以用来实现商品个性化推荐、销量预测、流失预测、商品组货优化等新零售场景的算法模型。

 

4.3 数据应用层

数据应用层严格来说不属于数据中台的范畴，但数据中台的使命就是为业务赋能，几乎所有企业在建设数据中台的同时都已规划好数据应用。数据应用可按数据使用场景来划分为以下多个使用领域：分析与决策应用、标签应用、智能应用。

 

数据中台的意义

数据中台对一个企业，起着至关重要的作用。在数据中台这个称谓成型之前，各个企业也都在用不同的方式来尽可能地利用数据产生价值。只是在这个过程中，也不得不处理着数据带来的各种问题，比如各个业务系统经年累月以烟囱架构形式存在而导致的数据孤岛、数据隔离、数据不一致等等。因为这些问题实在是过于繁杂，企业开始建立数据团队，或者数据部分开始继续数据整顿工作，因此数据仓库、数据湖、主数据治理等一系列的工作职能应运而生。

本质上，这些工作都是因为业务需要不得不进行的一系列数据治理的动作，对于如何利用数据来发力，并没有形成一个强有力的底座。有点像“头痛医头、脚痛医脚”：各个业务系统规范不一致了，于是开展了元数据治理；数据分析的时候数据关联不上了，于是不得不进行主数据治理。

这样的数据治理工作在进行了很多年后，数据中台这个概念逐渐有人提出了，阿里的《企业IT转型直到：阿里巴巴中台战略思想与架构实践》这本书更是把用中台战略把这个概念推向了一个极致。中台战略中，人们常说：大中台，小前台。在这种模式下，频繁出现的字眼是：共享。那么，到底共享的是什么？答案便是数据的服务。中台战略，并不是搭建一个数据平台，但是中台的大部分服务都是围绕数据而生，更加巧妙的地方是中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环。于是，数据和业务系统融为了一体。

（数据中台所解决的问题）

过去，数据依赖于手工进行，没有软件；有了数据中台，以功能驱动，固定的数据输入，得到固定的数据输出，构建出能用的服务变得更快速、更加的标准化，解决了业务侧的“能用”问题。但是，如何以固定的输入，以产生更灵活多变的输出，提供比如个性化的服务，做到“好用”，数据中台并没有给出答案。

在建立了数据中台架构之后，我们逐步认识到，原来数据的价值并不只是个运营出个参考的分析报表，做一系列的预算。数据中台为大型企业数据利用最大化提供了一个初始的参照方向。当我们发现，深度学习、机器学习等等一系列技术开始在这个平台下施展拳脚的时候，我们可能已经清晰地认识到：中台并不是数据分析利用的终点。

从数据中台到AI中台

什么是AI中台？

数据中台本身还是围绕数据服务来进行的，而非围绕智能服务来进行的。未来的操作系统，一定会越来越个性化，甚至每一个人看到的登录界面都不一样，系统可以根据对应的终端用户自行呈现符合该用户习惯的系统界面。那么对于这样的场景和服务，我们需要怎样的平台？整个软件开发架构和流程是否也都会相应重造？

回到创造业务的需求。以简单的销售业务为例，数据中台提供的服务本质如下图所示：

（软件平台的业务模式）

这是目前最常见的软件平台的运作方式，开发人员开发出了对应的软件服务后，提供给终端用户使用，虽然会有销售售卖该服务。这种方式，好比是拿着一个锤子找钉子，而不是给钉子快速制作一把合适的锤子再去售卖。

能不能这样：将整个软件组装出来的服务，包装成个性化的产品一样去售卖，提供量身定做的服务？那么整个运营模式就变成：平台提供了一种快速构建智能服务的过程，服务售卖者利用这个平台，自己动手构建出服务，拿出去售卖，类似一个提供“智能业务服务的PaaS”。

（引入AI中台的软件平台业务模式）
 

如果尝试给AI中台下个定义：

AI中台是一个用来构建大规模智能服务的基础设施，对企业需要的算法模型提供了分步构建和全生命周期管理的服务，让企业可以将自己的业务不断下沉为一个个算法模型，以达到复用、组合创新、规模化构建智能服务的目的。

借助一个平台，将软件的服务个性化的创造，这将是未来的发展趋势。在麦肯锡的分析报告中，我们可以看到，各个企业或者行业，都在第三个阶段做了不同的探索和努力。

从数据中台演进到AI中台

从AI中台落地实施的方式来看，AI中台可以是数据中台的进一步延伸，从数据中台一步一步演进过去。

首先，从基础设施角度，可以将数据中台智能化

所谓的智能化，是指将在数据中台进行的一系列的数据服务构建操作进行智能化实现，让数据的接入、存储、分析展现、训练、到构建管道（pipeline）都更加自动化。例如，对于通用的CI/CD来说，测试不过则会构建失败，那对于AI中台下，就要考虑一个推荐模型构建失败的条件是什么？答案可能是“本次模型的准确率低于上一次构建的准确率”的时候，CI应该被构建失败。在实践中，这可能是CI构建过程的维度之一，还会有很多其他指标和维度。我们就需要在现有的数据平台的CI中，实现并自动化这些指标和维度，使之更加智能化。

其次，对于中台使用者来说，将烟囱式模型构建过程改造为可复用的模型构建过程

目前基于数据中台的一个智能服务模型开发来说，流程如下：

（烟囱式模型构建过程）

这基本类似于一个横向的烟囱架构，导致目前对一个基于算法模型产生的服务进行拆分的时候，都不是特别地顺畅。如果大部分业务场景依旧以流程为主还好，如果新业务需要引入多的智能服务，那么一系列的问题就会暴露出来：

借助于现有数据平台手工进行数据操作

烟囱架构开发，对人员能力要求高

环节无法有效拆分，响应周期慢

智能场景规模化，管理复杂

训练，部署，发布依赖于手工部署缺乏有效的流水线

和数据平台孤立，缺乏统一的数据服务接口

基础设施隔离，无法动态进行资源的分配和管理

AI中台需要具备构建智能服务的能力，就要求我们对服务构建的过程进行如下拆分：

（可复用的模型构建过程）

首先需要从基础设施层面进行集成。常规的数据中台依赖于大量的CPU和内存，相反，机器学习模型对GPU的依赖反而更高，但是又不能脱离数据中台，因为它依旧需要利用数据中台的存储和计算能力来处理大量的数据。所以如何通过一个接口、一个调度器、一个管道pipeline来集成整个工作流，就成了需要考量的事情了。

AI中台至少应该分为以下几个层级：

基础设施：对CPU做虚拟化的技术已经相对成熟，但是智能服务依赖的更多的是GPU，那么GPU如何做虚拟化，算法模型训练和数据是否需要共同使用相同的机器，还是集群相互隔离，都是需要在一开始设计好的。

资源管理：一切都是资源，无论是网络、内存，还是数据、服务，都是资源。对于模型构建者，关注的只是算法本身，如果该构建者需要数据，那这样的数据就是一个资源而已，无论资源是以环境变量的方式提供、还是以服务的方式提供，构建者本身并不需要关心。此时，必须一个资源管理系统，对数据服务进行统一管理。

中台和模型：中台有数据的计算和存储能力外，还应该具备算模型的能力，这里的模型指的是一些业界通用的、或者企业级通用算法模型。它可能是一个算法、可能是一个别人已训练好的模型，可以使用迁移学习的方式去使用。对于中台来说，它都是一个数据集的体现，不应该和一个表，一个文件有特别的区分。

流水线：流水是构建规模化智能服务非常重要的一个环节，工作如其名，让我们构建智能服务的时候，可以像流水线工作一样，达到这样的效果，则需要对整个任务进行非常详细的分解。

智能应用层：智能应用层直接面向终端，怎么利用元数据等功能，组合各自不同模型提供的服务，构建出组合效应的创新服务。

（AI中台的架构层次）

在数据中台的基础上，扩展对GPU级别资源的管理和整合能力，调度层提供统一的任务、服务、智能CI/CD等服务，来实现AI中台。这样以来，就可以达到：

和数据平台结合，利用数据平台的能力作为数据支撑，最大化的发挥数据平台的价值

拆分服务构建环节，智能服务开发流程化，快速响应业务需求

利用元数据管理方式，提供统一的标准格式，场景可以多人协同配合开发

基础设施共享化，模型的训练和发布与数据平台有效绑定，服务的构建自动化

统一的元数据管理系统，模型的全生命周期可管理

通用AI能力平台化，降低人员要求，提升协作效率

也即，利用算、模型、框架，动态、快速地组装服务，创造出新的个性化体验和新的业务新的业务模式，解决“好用”的问题。

结语

数据中台提供的是存储和计算的能力，基于不同的业务场景，构建出了用来支撑不同业务的数据服务，依托于强大的计算力，可以快速缩短获得结果的周期。而AI中台则是将算法模型融入进来构建为服务，让构建算法模型服务，更加快速高效，以更加面向业务。但无论是数据中台还是AI中台，都是一层基础设施，做好基础设施只是第一步，如何让它的价值最大化，还要依托于AI中台不断结合业务来持续优化，做到“持续智能”。

（本文来源ThoughtWorks商业洞见，由数据学堂整理编辑）