2.3.2 中台战略与数据中台

2015年年底，阿里巴巴对外宣布全面启动阿里巴巴集团2018年中台战略，构建更具创新性与灵活性的“大中台，小前台”组织和业务机制。也就是说，中台将集合整个集团的运营数据能力和产品技术能力，对前台业务形成强力支撑，使得前台的一线业务更敏捷、更快速地响应瞬息万变的市场。

那么什么是“中台”？从直觉上理解，它似乎是介于“前台”和“后台”之间的一个新增的平台。在解释中台之前，本节先回顾一下企业互联网架构中“前台”与“后台”的定义。前台是用户直接与企业业务交互的各前端系统组成的平台，如企业的门户网站、企业App，或者微信企业号都属于前台；后台是企业核心资源的电子化管理平台，如企业的产品系统、仓储物流管理系统、客户服务系统、数据库系统等。我们可以看到，企业后台设立的主要目标并非支撑前台的快速响应，而是实现对企业后端核心资源的电子化管理，解决企业管理的效率问题。由于后台管理的是企业的核心资源，修改的成本和风险较高，所以后台系统趋“稳”；而前台系统是和用户交互，需要响应市场持续不断的需求，所以前台系统趋“快”。随着业务不断扩张，后台对前台业务的响应越来越力不从心；为了响应市场不断的需求，又不能影响后台系统的稳定性，大量的业务逻辑被直接并入了前台，使得前台系统日渐臃肿，极大地降低了前台业务的响应效率。

如何将前台从重复、复杂的业务功能中释放出来，恢复前台的响应力，又不影响后台的稳定性呢？“中台”的概念应运而生。中台，又称BFF（Backends For Frontends，为前端存在的后端），顾名思义，中台是为前台服务的，是为了前台能够更好地履行自己的职责而存在的。中台将前台中通用的、公共的业务功能进行沉淀，避免功能的重复建设和维护；也将后台中经常与前台交互的，或者时常变化的业务功能提取出来，赋予这些业务员更强的灵活度和更低的变更资本，从而为前台提供稳定、专业的业务服务。

我们以阿里巴巴共享业务事业部的发展为例进一步地介绍中台。2008年，阿里巴巴集团的1688网站、淘宝和天猫三大电商体系的架构是完全独立的，各自独立地进行开发和运行。业界把这种企业架构称作“烟囱式”架构。传统的“烟囱式”架构至今仍在很多企业中经常见到：业务部门提出业务需求后，IT部门进行需求分析、开发、测试、上线，开始进入迭代的项目周期中，可以说每个新系统的上线都代表着一个新的“烟囱”建成。中台的产生背景如图2-3所示。

这种完全基于业务需求建设系统的方式导致企业内部系统“烟囱”众多，给企业后期的互联网建设带来了很多麻烦，主要表现在以下几个方面。

（1）烟囱式系统中存在很多重叠的业务和功能，严重浪费了系统开发和运维等方面的成本。

（2）烟囱式系统构建的独立性使得数据共享变得困难，降低了企业的整体执行力和灵活度。

（3）抑制业务创新。企业在展开新业务、尝试新项目或者开拓新市场时，都要进行大量的重复功能建设和能力建设，试错成本较大，使得企业在决定业务创新之前会十分谨慎地权衡利弊，从而抑制了创新和组织的自我迭代。

（4）难以深入挖掘、沉淀业务。系统在上线之后，功能的完善和业务的升级周期在几个月甚至半年，时间跨度较长，而市场业务的需求是变化且持续的，上线后的系统难以对市场的新需求进行快速响应，可能需要再开一个新的烟囱来响应新需求。长此以往，原来系统的升级改造已不能满足当下的业务发展诉求，需要进行整体升级，而整体升级一般意味着对原有系统的推倒重建，之前的业务服务能力很难被积累、沉淀下来。

阿里巴巴也遇到了“烟囱式”架构带来的问题。为了应对这一问题，阿里巴巴将原来的淘宝技术团队划分出来一部分成立了单独的共享业务事业部。负责团队在共享业务事业部平台中组建了多个业务共享单元，如用户中心单元、商品中心单元、交易中心单元、评价中心单元、店铺中心单元、搜索中心单元等，这些单元是原前端各条电商单元线之间共性的业务需求的整合与沉淀，在平台中以服务资源的形式提供给前台各业务部门使用，避免了前台业务系统之间功能的冗余，使得前台业务能够更好地响应用户需求。

但是，此时的共享业务事业部构建的平台还不算真正意义上的“中台”。因为平台按照前台的业务需求独立地对接业务，为业务方在基础服务上做定制开发。例如，业务方的需求是要引入交易服务，事业部负责交易中心的人员就会依据需求，在基础的交易服务上打造定制化的交易服务和业务方进行对接。此时的共享业务事业部更像一个资源团队，而非一个平台产品团队。阿里巴巴管理人员意识到了仅仅提供资源是不足的，为了更加有效地整合阿里巴巴的基础能力，高效支撑业务创新，阿里巴巴调整了组织架构，提出了中台战略。此时，阿里巴巴的架构真正地开始向“大中台，小前台”转变。

按中台思路来讲，共享业务事业部的所有共享系统单元是一个整体，事业部需要把所有的系统单元（用户、商品、评价、搜索等）打通，集合成一个平台产品、一种服务，为前端业务提供一种业务解决方案。中台在提供基础解决方案之后，业务方根据需要，自主定制开发，来满足自己的业务特性。这种思路使得事业部平台团队免受前台不断的业务需求干扰，自主把控工作节奏，从而有更好的业务思考和规划，为前台业务提供更加完善的基础能力；同时，前台业务能够直接利用中台的基础解决方案，按需定制、组装业务，并对服务进行针对性创新，从而进一步促进中台的完善创新。中台不再是单纯的技术、资源提供者，反而通过其他业务的创新能力“反哺”，形成了新的、更有价值的基础能力，在阿里巴巴集团内，“大中台”成为共创共建、互利互助的平台。

共享服务架构的建设使得阿里巴巴摆脱了因为“烟囱式”系统建设方式所带来的种种发展桎梏，最终成为阿里巴巴业务员中台战略的核心组成。图2-4是阿里巴巴集团的典型企业中台架构，我们可以看到，阿里中台主要是业务中台和数据中台构成的双中台。

业务中台由共享平台发展而来，业务中台的产品也继承了共享平台的会员中心、商品中心、交易中心、订单中心、支付中心等评价中心基础业务服务。总结来说，业务中台将后台资源进行抽象、包装和整合，转化为前台友好的可重用共享的基础服务，实现了从后端业务资源到前台易用能力的转化。这样的业务中台带来的业务价值和作用如下。

（1）服务重用。共享服务架构真正发挥出了SOA （Software-Oriented Architecture，面向服务的架构）理念最核心的价值：服务重用，即松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。通过共享服务架构，企业相关业务领域的业务功能和数据模型被汇聚到一起，就避免了“烟囱式”架构重复功能的建设和维护带来的成本浪费。因为业务和数据已经被统一到了一起，业务系统之间没有进行交互、集成的必要，“烟囱式”架构遇到的第二个问题也迎刃而解了。

（2）服务的可成长性。阿里巴巴共享业务事业部经过多年探索后，沉淀了五大价值定位：开放（实现对内对外的开放）、服务（服务能力不断提升）、滋养（业务滋养）、稳定（专注、专业带来稳定）和数据（线上线下数据产品创新）。其中，“业务滋养”指在业务发展过程中逐步打造服务，通过新业务的介入，让服务成长，使服务变得更加专业和稳定。

（3）赋予业务快速创新和试错能力。共享服务架构为业务的创新打造了一个坚实的中台，降低了业务创新和试错的前期投入成本，避免了“烟囱式”架构的问题。以阿里巴巴的团购业务为例，2010年，市场上团购业务蓬勃发展，阿里巴巴集团也决定构建自己的团购平台，但当时市场上已经有了美团等专业的团购网站，是否应该进军团购业务对阿里巴巴来说也是一个未知。于是当时阿里巴巴投入了十几名员工，进行团购平台的建设，由于阿里巴巴的共享服务体系已正常运转两年，用户中心、商品中心、交易中心等服务能力已经十分成熟且稳定，所以仅仅一个半月后，团购平台就成功上线了。感谢共享服务体系，阿里巴巴上线新项目付出的成本只有其他同类型团购平台建设和上线投入成本的几十分之一。另外，该团购平台上线后，效益十分可观，集团意识到这是一个十分重要的流量入口，将大量的资源投入这一新兴业务，在短短的14个月后，这个仅有十几个人的小团队就发展成为几百人的事业部——“聚划算”团购平台事业部，成为与淘宝、天猫并驾齐驱的三大电商事业部。

（4）更好地适应“大数据”时代。数据对企业十分重要，决定着企业的未来发展。大数据将会是展现企业核心竞争力、挖掘新商业模式，从而改变世界的强大技术推动器。但是在“烟囱式”系统架构下，相关业务领域的数据存储在不同的系统中，数据的模型和标准也不统一，使得企业在实施大数据项目初期要额外进行打通数据层隔断、控制数据权限、转换数据格式、清洗数据等工作，在数据预处理方面要耗费很多的资源。共享服务体系对数据做了很好的统一，使得业务的数据在系统运行中进行了很好的规整和沉淀，极大地简化了数据处理方面的工作，帮助大数据项目更好地开展，使得企业能更好地适应“大数据”时代。

本节之前的阐述，基本围绕中台战略的业务中台展开。实际上，中台并非阿里巴巴发明的，在IT领域具备中台属性的架构早已诞生，从最开始的企业服务总线（ESB）、平台即服务（PaaS）、SOA服务框架到微服务，无一不具备中台思想的潜质。阿里巴巴将中台的概念定义泛化，即中台是一种基础的理念和架构，所有的基础服务都可用中台建设并联通，共同支持上端的业务。由此，根据企业建设目标和战略选择的不同，建设中台还可能包括数据中台、移动中台、技术中台、算法中台和组织中台等平台。如图2-4所示，阿里巴巴集团的中台架构就是典型的“业务+数据”双中台架构。特别是在大数据和云计算逐渐成为新经济时代“石油”和“引擎”的当下，数据中台的重要性可见一斑。本节接下来论述数据中台的组成和采用的技术。

数据中台从后台和业务中台中获取数据，完成海量数据的存储、计算、产品化报装过程，并提供基础的数据处理能力和很多数据产品供业务方使用。数据中台，可以实现数据的分层和水平解耦，具备沉淀公共的数据能力，主要分为三个部分，数据模型、数据服务和数据开发。

数据模型是面向业务支撑的底座能力。数据模型按照复杂度可以分为三层，第一层是基础模型，指将数据标准化和规范化；第二层是融合模型，一般是跨纬度建模，以实现不同关系数据表之间的数据整合；第三层是挖掘模型，偏向应用领域，根据挖掘目标和数据形式有分类与预测、关联规则、聚类分析等模型。阿里巴巴的数据模型构架也是类似的划分，主要包括操作数据（ODS）层、公共维度模型（CDM）层和应用数据（ADS）层。ODS层，也就是刚刚提到的基础模型，是数据接入的同步层，它源于各业务系统，同时面向后续的数据清洗和加工，提供了最初的数据统一接入，涉及离线数据和（准）实时数据。阿里ODS层设计包含了三个特性：其一是数据同步功能，支持结构化数据增量或全量同步到ODPS；其二是实现全结构化数据转换，能够将非结构化数据进行结构化处理后再存储；其三是支持历史数据的积累和清洗，能根据数据业务需求及稽核审计要求保存信息。CDM层以维度模型方法为基础，目的在于提升公共指标的复用性，减少重复的加工。CDM层还会建立一致的数据分析维表，降低数据计算口径不统一的风险。CDM层支持个性化分析与自助取数、支持面向应用的数据同步，可以说是数据仓库核心之能力。ADS层是根据CDM层和ODS层加工而成的，是面向应用和集市的上层能力，它支持个性化指标加工和基于应用的数据组装。

数据服务是指将数据模型按照业务要求进行服务封装，这里的服务概念和业务中台的服务概念类似。图2-4中阿里巴巴集团的数据中台提供的服务就有大数据计算服务、可视化服务、画像分析等。数据服务与基础业务服务一样，首先，要保证数据服务是可重用的，比如用户画像服务，在不同的业务背景下都应该表现良好；其次，数据服务需要被滋养，通过对前台业务需求的不断响应，数据服务应不断成长、扩展，从而更有力地支撑前台业务；再次，数据服务需要稳定，服务必须保证本身功能的稳定性和强大性；最后，数据服务是要开放的。

有时，再好的数据模型和数据服务也无法满足前端业务的个性化需求，这时，数据中台需要提供数据的开发套件。开发套件按照复杂程度也分为三类，一是提供标签库（DMP），用户可以基于标签的组装快速形成营销客户群，一般面向业务人员；二是提供数据开发平台，用户可以基于该平台访问所有的数据并进行可视化开发；三是提供应用环境和组件，让技术人员可以自主打造个性化数据产品，以上层层递进，满足不同层次人员的要求。

前文提到，中台建设不止有业务中台和数据中台，还有移动中台、技术中台、组织中台等。阿里巴巴在数据中台和业务中台之上，为了更加有效地利用中台能力，快速迭代移动产品，沉淀出了移动中台；将各种基础设施使用能力和技术中间件能力，如分布式存储、流失计算、负载均衡等技术进行整合与包装，过滤技术细节，只提供简洁的接口，据此可构建技术中台；将组织结构进行重构，按照共享服务中心的模式建设，可以在企业组织中沉淀出组织中台，组织中台一般是服务支持型部门，如招聘团队、培训团队、市场团队、销售支持团队等。总而言之，中台是一个基础的理念和架构，是为了支持前台业务而沉淀出来的平台，一般适用于业务繁杂的大型企业，企业可以根据需求选择是否建立中台，并选择企业本身需要建设的中台类型。