全面解读中台
中台，通过对业务、数据和技术的抽象，对服务能力进行复用，构建了企业级的服务能力，消除了企业内部各业务部门、各分子公司间的壁垒，适应了企业，特别是大型企业集团业务多元化的发展战略。基于中台，可快速构建面向最终消费者和客户的前台应用，从而满足各种个性化特征的前台需求，为企业的数字化转型提供明确的道路。
3.1 什么是中台
那么中台到底是什么？中台是一个新的概念，但却是一个旧有的名词，在新时期我们赋予其新的内涵。本节介绍中台的历史起源，以及数字化时代中台在企业信息化建设中的表现和作用。
3.1.1 中台的源起
在中国古代东汉时期，尚书台成为*的中枢，号称中台。唐朝所完善的三省六部制，以门下省为西台，中书省为东台，也将尚书省称为中台。尚书省作为执行机构，辖吏、户、礼、兵、刑、工六部，如图3-1所示。
图3-1 中国古代官场的“中台”架构
在一个投资银行的组织结构中，前台（Front Office）是与客户（无论是个人客户还是公司客户）直接互动的岗位，诸如大堂经理、客户经理、柜员等。中台（Middle Office）是指直接支援前台工作的所有人员，使用前台或后台的资源，为前台提供专业性的管理和指导，并进行风险控制，比如风险管理、合规应对、财务管控以及IT服务等。后台（Back Office）指幕后的职能岗位，行使管理职能，比如结算、清算、会计、人力资源等。
位于芬兰的著名移动游戏公司Supercell以小前台的方式组织了若干个开发团队。每个团队包含了开发一款游戏所需的各种角色。这样各个团队可以快速决策、快速开发。而基础设施、游戏引擎、内部开发工具和平台则由类似“部落”的部门提供。“部落”可以根据需要扩展为多个小分队，但各个小分队都保持共同的目标。“部落”本身并不提供游戏给消费者。
2015年的阿里巴巴已拥有规模庞大的个人会员和企业会员，业务种类纷繁复杂，业务之间交叉依赖，业务团队众多，不能及时响应业务的要求。因此当年12月，时任阿里巴巴集团CEO的张勇通过内部邮件宣布启动阿里巴巴2018年中台战略，构建符合DT时代的更具创新性和灵活性的“大中台，小前台”的组织机制和业务机制，实现管理模式创新。即将产品技术力量和数据运营能力从前台剥离，成为独立的中台，包括搜索事业部、共享业务事业部、数据平台事业部等，为前台即零售电商事业群提供服务。从而前台得到精简，保持足够的敏捷度，更好地满足业务发展和创新需求。
2017年5月出版的《企业IT架构转型之道：阿里巴巴中台战略思想和架构实战》详细阐述了业务中台是介于前台与后台之间的。其采用共享的方式建设，解决了以往烟囱式和单体式架构设计的重复开发、数据分散、试错成本高等问题。书中列举了建设业务中台的一些原则：高内聚低耦合、数据完整性、可运营性、渐进性等。此书的出版推动了中台思想的发展和中台的建设。
之后，很多互联网公司快速跟进中台。滴滴出行在2017年12月分享了《如何构建滴滴出行业务中台》。滴滴出行在前端业务上形成了出租车、快车、专车、代驾等多业务共同发展的业态。虽然各业务的应用场景不同，但所有业务本质都是出行，交易流程是相同的。如果各业务独立发展，则业务间缺少协同性。
京东在2018年12月宣布采用前台、中台和后台的组织架构。前台职能是理解和洞察客户需求和行为，通过产品创新和精细化运营服务客户，最终实现和提升客户价值。中台通过沉淀、迭代和组件化地输出服务于前台不同场景的通用能力，作为为前台业务运营和创新提供专业能力的共享平台。后台职能则提供基础设施建设、服务支持与风险管控，为中、前台提供保障。
3.1.2 从组织管理和技术系统角度看中台
中台可以作为一种企业组织管理模式和理念（Middle Office）。不过从技术系统角度看，中台也可以作为一种新型的企业IT设施架构（Middle Platform）。此外，为建设中台系统，有些企业会成立专门的中台技术团队来整体负责、实现和运营。因此作为组织管理模式的中台和中台系统这两者并不是完全分开的。
中台化的组织方式就是在公司内部构建统一的协同平台。一方面，可以让各业务部门保持相对的独立和分权，保证对业务的敏感性和创新性；另一方面，用一个强大的平台来对这些部门进行总协调和支持，平衡集权与分权，并为新业务、新部门提供生长空间，从而大幅降低组织变革的成本。中台部门提炼各业务线的共性需求，最大程度减少重复“造*”。
从技术系统层面看，中台是企业级共享服务平台。传统的IT系统或套件没有太多关注系统能力的复用和共享，因此企业在多年的信息化过程中引入和建设了多套具有重复功能的烟囱型系统。而中台则要求对能力进行细粒度分析，识别共享能力，并将共享能力建设成为统一的平台。因此中台不是单系统的服务化。
综上所述，中台是能力的枢纽和对能力的共享。中台是在集中的基础上建设分权的业务，进行联通，并为各业务提供统一的服务。因此一切将企业的各式各样的资源转化为易于前台使用的能力，为企业进行“以用户为中心”的数字化转型服务的平台，都是中台。但要注意，与此思想相匹配所建设的中台团队并不能当作资源共享团队。中台团队关注的是如何形成基础服务，为前台团队建设业务应用提供便利。因此中台要实现平台逻辑与业务逻辑的分离，并隔离不同前台业务。
另外，中台不是微服务，因为中台不仅是一种技术架构，还是企业进行数字化转型的整体参考架构。不过从技术角度，可以认为微服务是建设中台的最佳实践。微服务是将J2EE时代的单体架构拆分为多个提供微服务的技术架构。微服务将相关联的业务逻辑及数据放在一起形成独立的边界。各个微服务之间通过标准的协议，比如HTTP RESTful风格进行通信访问。各个微服务间是松耦合的。不同的微服务开发团队理论上可以使用不同的技术栈来实现微服务而无须强求一致。另外，微服务所需的数据存储一般都由单独的数据库实例或数据库模式隔离，数据的交互只能通过接口或消息实现，而不能在数据库层直接访问另一个微服务的数据。微服务强调接口的隔离原则，通过接口封装。由于微服务可单独部署，因此可根据需要对所需的微服务进行扩缩容，无须针对整个系统，从而使系统的伸缩性更灵活，更能应对大流量并发场景，比如秒杀。微服务拥有与生俱来的独立开发、独立部署、独立发布特性，支持高并发高可用，以及去中心化管理等优点。但由于微服务是分布式编程，提高了开发、调试、部署、运维等的难度，增加了服务管理的复杂度，且需要重新设计原先由单一数据库保证的原子性等。虽然微服务对开发团队提出了更高的要求，但是它促进了研发团队的一体化运维能力，从而改变了企业的研发组织架构。
3.2 中台系统及其展现形式
中台是数字化转型下重构企业IT基础设施的最佳实践。那么，怎么理解中台是企业级共享服务平台？我们先来看看中台的起源地—阿里巴巴建设中台的驱动力和成果。
2008年的阿里巴巴集团由于内部部门之间的隔离、业务目标相对不一致，淘宝和淘宝商城（即现今的天猫）是作为两套独立的系统分别建设的，即是两套独立的烟囱型系统。但二者的基础业务都是电商交易，因此基本功能是类似的，包括商品、交易、支付、评价、物流、积分、论坛等功能。由于系统间的隔离，虽然商城的流量和交易持续走低，却无法将淘宝的流量引流到淘宝商城。因此，两个业务部门商量如何打通两个电商平台，从而成立了共享业务事业部，着手进行内部称为“五彩石”的项目。“五彩石”项目的成果，即现在称为“中台”的各共享业务服务中心，这为后续天猫的快速发展奠定了坚实的基础。中台整合了阿里巴巴集团的产品技术能力和运营数据能力，对各前台业务形成了强有力的支撑。后续上线的聚划算、1688等均得益于中台的建设。
由此可以看到，企业在信息化建设过程中，不同业务部门基于本部门的业务需求提出了相对独立的方案。IT部门为满足不同业务部门的不同业务需求（有时甚至是相互冲突的），搭建了纷繁复杂且部分功能重复的烟囱式系统。烟囱式系统的建设不仅带来了功能的重复建设，还带来了重复维护，导致企业的重复投资。此外，为了打通烟囱式系统，还需要专门设计第三方集成方案或引入企业服务总线（ESB）的概念，集成和协作成本高昂。因此，在建设和引入新的系统时，虽然各部门根据自己的业务需求构建了定制化的最优解决方案，但这些方案可能只是局部最优；如果从公司整体来看，不一定是全局最佳的解决方案。所以，构建系统如果不从全局出发，不进行现有系统的改造升级、重复利用，那么只能是在旧有的复杂性上再次引入新的复杂性，导致系统越建越复杂，而效率却越来越低。
既然我们强调中台是能力的复用，那么在建设新系统或业务应用时，可复用的能力具体是以什么样的形式提供的呢？在程序设计中，函数是将一段经常使用的代码封装起来，然后在需要使用时直接调用。使用函数体现了程序设计模块化的指导思想，即将大问题分解为小问题，通过解决小问题来解决大问题。其次，函数的使用大大减少了重复编写程序段的工作量。相关的通用函数集，可以编译成动态链接库及类库，这再次提升了复用的可能。既然我们可以使用函数、类库的方式将一些可复用的功能封装起来，那是不是也可以将可复用的功能作为服务提供？以服务的方式提供共享能力的平台就是中台。中台是比函数和类库更高一层次的复用封装（见图3-2），从而更好地服务于业务。
图3-2 共享的三个层次
3.3 中台的作用
中台应该包含哪些内容呢？什么应该包括在中台里？什么不应该放在中台里？中台与企业现有的ERP、CRM是什么关系？如果建设了中台，中台应当如何发挥作用，而不是又让企业陷入建设另一套IT系统的老路？
3.3.1 中台的分类
中台是从多个相似的前台业务应用共享的需求中产生的，因此最先提出的中台是业务中台。数据是从业务系统产生的，而业务系统也需要数据分析的结果，那么是否可以把业务系统的数据存储和计算能力抽离，由单独的数据处理平台提供存储和计算能力？这样不仅可以简化业务系统的复杂性，还可以让各个系统采用更合适的技术，专注做本身擅长的事。这个专用的数据处理平台即数据中台。
3.3.2 业务中台定义及建设内容
业务中台是阿里巴巴首先提出的企业IT架构的转型之道。站在阿里巴巴集团全局的角度看，业务中台是从整体战略、业务支撑、连接消费者和业务创新等方面进行统筹规划的。因此业务中台内含了阿里巴巴电商交易的主营业务。业务中台更多关注的是如何支撑在线业务。阿里巴巴一开始将淘宝作为平台方连接商家和消费者，进行电商交易活动，随之发展出淘宝商城，即后来的天猫。天猫本质上还是电商交易平台。既然都是电商交易平台，就都涉及售前、售中和售后的业务流程。
业务中台围绕以交易为核心关联的领域组成。交易的对象是商品，商品通过店铺售卖给会员，交易的凭证是订单，在线交易需要支付，成单后需要货品出库和物流派送等，售前需要营销促销活动吸引流量并加强转化，售后用户会对店铺、商品进行评价等。由此可见，典型的业务中台由多个业务服务中心组成，如
图3-3所示。
会员中心服务于用户的消费全生命周期，为用户提供特定的权益和服务，企业可以通过会员中心与用户进行互动，培养用户忠诚度。其主要能力包括：
- 会员运营管理：包括会员注册、个人信息维护、会员注销、会员卡办理等相关能力。
- 会员体系管理：包括会员体系的创建、积分规则、成长值规则、等级、权益等相关能力。
- 客户服务管理：包括客户的新增、导入、查询等相关能力。
- 积分交易管理：包括积分获取、核销、清零、冻结、兑换等相关能力。
图3-3 一个典型的由服务中心组成的业务中台
商品中心提供管理商品核心数据的能力，围绕商品构建商品关联数据，诸如商品版本信息、商品品牌、商品属性、商品类目等。其主要能力有：
- 品牌、类目、属性管理：包括对商品品牌的维护、查询，前后端类目的维护，属性及属性组管理等相关能力。
- 产品数据管理：包括对产品模板的创建、编辑、查询、禁用等相关能力。
- 商品数据管理：包括商品创建、修改、查询等相关能力。
- 商品发布管理：包括商品发布、上下架（即时+定时）等相关能力。
交易中心负责企业业务交易订单的整体生命周期管理，包括加入购物车→订单生成→合并分拆→流转→支付→发货→退换货→完成。所有电商业务的核心系统都是围绕交易订单进行构建的。其主要能力包括： - 购物车管理：包括购物车商品添加、编辑、查询、校验等相关能力。
- 正向交易管理：包括交易订单生成、发起支付交易订单、商品发货管理、上门自提及核销等相关能力。
- 逆向交易管理：包括换货、退货、退款等相关能力。
- 订单数据管理：包括交易订单、支付记录、发货记录、换货记录、退款记录等数据管理能力。
- 交易流程编排：支持交易流程节点的配置化，便于根据业务场景的不同设置与之匹配的流程。
评价中心提供对评价主体对象、评价规则/等级、评价内容、评价操作的管理能力，从而满足不同角色的评价用户对评价内容的发布、追加、平台审核、平台申诉等需求。主要能力包括： - 评价内容管理：包括管理评价的主体对象、评价规则配置、评价等级、评价标签配置等相关能力。
- 评价操作能力：包括评价的发布、修改、追加、回复、申诉等相关能力。
- 评价监管能力：包括评价发布审核、申诉审核、评价屏蔽等监管相关能力。
店铺中心提供企业店铺主体管理、店铺管理、类型管理、经营对象管理等能力以支持企业为商户提供线上门店，同时也支持商户管理、店铺会员、店铺会员等级管理、店铺装修等。其主要能力包括： - 商户管理：包括商户单个、批量开通，商户审核，商户基本信息维护等相关能力。
- 店铺管理：包括店铺开通、店铺基本信息维护、店铺审核、店铺会员等相关能力。
支付中心给下游商户输出标准的支付服务，提供代付代收、财务对账等服务。通过对接多个主流渠道，稳定输出微信、支付宝、银联等支付能力。其主要能力包括： - 支付能力：包括创建支付订单、接收渠道通知、查询渠道订单等基本支付能力。
- 支付路由：包括支付渠道管理、支付方式管理、支付商户和应用开通管理等相关能力。
- 资金账户：包括资金账户管理、充值维护、提现等相关能力。
营销中心提供商家的活动计划、申报、审批、执行、核销的全链路管理，也提供基本的促销能力，如优惠券活动、满减买赠等。其主要能力包括： - 活动模板管理：包括提供营销活动的策略模板、规则配置、条件、动作模板等相关能力。
- 活动管理：包括提供具体活动的基本信息配置、人群圈选、商品管理、触发条件等相关能力。
- 优惠券管理：包括优惠券的发放、领取、查询、使用核销等相关能力。
- 赠品管理：对于满赠、买赠活动，提供赠品维护、查询、启用、禁用等相关能力。
库存中心提供仓库、库存、货品、单据（入库单/出库单/
盘点单/盘点盈亏单）、审核（调拨/盘点）、包裹、货品运费、物流运输、接入第三方物流公司的服务能力。其主要能力包括：
- 仓库管理：包括服务区、仓库、仓位及其关联管理等相关能力。
- 货品管理：包括货品进货入库、销售出库、调拨入库、调拨出库、调拨审核等相关能力。
- 货品盘点：包括盘点单生成、审核、查询等相关能力。
- 履约管理：包括库存检查、发货单创建及查询、包裹物流查询、运费管理、物流状态跟踪等相关能力。
建设一套中台系统，可同时运用在多个电商平台的开发设计和服务中。因此，中台可以为同时建设、运营多套电商平台的互联网企业节省系统建设和运营成本。因为中台既可以避免功能重复建设，又可以通过全渠道打通会员系统来增加流量、互相促进，还可以减少运营成本和人员。有了中台，再发展电商相关应用就会变得更加容易，比如，阿里巴巴发展出的聚划算。
如果使用传统的系统思维来设计业务中台，很有可能只是将原先隔离的各业务系统通过微服务的方式，强行集成在一起，如图3-4所示。这种方式构建的微服务不是纯粹基于领域进行建设，而是从一个系统的粒度层次进行建设。比如PMS会涉及用户和订单，OMS也需要关注会员和订单，CRM同样涉及会员。因此，按此方式建设的所谓中台，它的各组成部分还是互相交叉重叠的，并不能体现中台是能力共享平台的核心理念。所以，只对企业业务系统做一个大一统的集成，并不是中台。
图3-4 传统思维下所建设的“业务中台”
3.3.3 数据中台定义及建设内容
数据中台是什么？
数据中台与数据仓库有什么区别？
数据中台到底怎么与业务中台融合？
这三个问题一直以来是人们问得最多的问题。本节将试着对这三大问题进行一一解读。
在回答数据中台是什么这个问题之前，先了解一下大家比较熟悉的数据仓库。在以BAT为首的互联网公司蓬勃发展起来之前，国内三大电信运营商对于数据仓库的建设走在其他行业的前面。早在2011年的时候，中国移动集团公司就组织编写了指导各省公司建设数据仓库的纲领性文件《中国移动NG2-BASS3.0建设规范》。在文件中明确将中国移动的业务分成了7大业务板块，按照功能将数据资产划分为三层：数据层、功能层、应用层。这是很典型的数据仓库建设的分层模式，如今的数据中台数据分层建设模式也延续了数据仓库的分层建设规范，后面会详细讲到。
图3-5所示是某电信运营商数据仓库的应用层规划内容，详细规划了每个应用领域的数据应用。但是仔细研究可以发现，这些数据应用几乎全是“分析”，也就是解决了事后“看数据”的问题。
再来看看图3-6所示的阿里巴巴的数据中台支撑的数据应用层，除了通用的数据分析以外，还包含“个性化推荐”“风险评估”“预警监控”等与业务紧密结合的数据赋能业务的应用。而这些丰富的赋能业务的数据应用必须依赖数据中台提供的强大的数据服务来支撑。
图3-5 某电信运营商数据仓库分层模型
图3-6 阿里巴巴数据中台总体架构图
通过上面的对比不难看出，数据中台与数据仓库最大的区别就是数据中台更加贴近业务，不只提供分析功能，更重要的是为业务提供服务，与业务中台或者业务系统（老旧系统）连接更加紧密了。就拿大家比较熟悉的“千人千面”案例来说，除了要整合业务系统产生的用户基础属性、订单、评价、加入购物车等行为数据，还要通过埋点的方式实时获取用户偏好浏览、搜索、分享商品等行为数据，经过数据中台对一系列的数据进行加工处理（见图3-7），最终以微服务的形式提供支持。在业务系统中，每个需要呈现商品给目标用户的数据服务，已不是简单地、一成不变地去商品库查询数据，而是调用数据中台提供的商品推荐接口，以此来根据不同的人群偏好、浏览历史、商品相似度等数据来为每个人推荐他最感兴趣的商品。试问这种业务、数据紧密联动的场景在数据仓库时代又如何能做到呢？
图3-7 数据中台与外部系统交互
在介绍完数据中台与数据仓库的区别之后，我们再回过头谈谈数据中台到底是什么。首先说说数据中台不是什么。
第一，数据中台不等于大数据。近些年来，“大数据”这个名词可能是被提及最多的词汇之一，大数据甚至成为国家战略。同时，“数据中台”也正是在大数据概念兴起之后应运而生的。因此，相当一部分人把数据中台和大数据划等号，一提到数据中台，就想起Hadoop、Spark等大数据处理技术，这样的想法是不对的，这些大数据处理技术只是数据中台的基础设施提供者。大数据技术大行其道，加速了数据中台战略成熟。
第二，数据中台也不是一个研发工具。最近一段时间，在市面上流行着一种说法，说某某公司有一个数据中台产品，可以直接卖给某某客户。这种说法是在忽悠客户。实际提供给客户的仅仅是一个可视化的研发工具而已。数据中台一定是整合了企业自身数据并经过加工、治理后形成企业自身的数据资产的平台。试问，根本还没了解客户到底有什么数据的情况下，如何能说自己有一个数据中台产品呢？
那么如何定义数据中台呢？我们也曾尝试在网上找到一个标准答案，也曾找过首倡“数据中台”概念的阿里大咖们寻求标准答案。最近网络媒体上各种数据中台分享、峰会纷纷扰扰，各种解读真是乱花渐欲迷人眼，但都没有得到一个很精炼、标准的关于数据中台的定义。但越是没有标准，越是被人问得多，这就是为什么开篇提到的第一个问题就是“什么是数据中台”。
经过这些年来对数据中台的一腔热血，我们也曾经为此翻阅大量资料，力求言简意赅，力求精准定义。我们认为：数据中台是一个用技术连接大数据计算存储能力，用业务连接数据应用场景能力的平台。
“连接能力”是数据中台的精髓。作为一个处在中间层的能力平台，“连接”是其根本任务。在业务层面需要尽可能连接各种数据源作为其生产资料；同时，由于生产数据的场景越来越多，覆盖了线上、线下等多渠道，各数据生产资料之间也需要进行连接，才能形成全域的数据；数据在数据中台这个平台上按照标准的模型进行规范加工处理后需要服务于多种场景，同样需要我们提供标准的数据服务接口将数据与应用场景连接起来。因此，连接是数据中台的根本能力，也是数据中台的价值所在。
3.3.4 业务中台和数据中台的关系
无论是业务中台还是数据中台，都是在企业IT系统架构演进过程中形成的，并从企业自身IT系统规划、建设、运营、运维等多年的经验中提炼出来的共性能力。业务中台和数据中台作为两个*并肩构建了数字中台，支撑前台对会员提供从营销推广、转化交易到智能服务业务的闭环服务，促进企业业务的提升和发展，如图3-8所示。数字中台对内连接企业的后台系统，诸如ERP、人力资源、协同办公、财务管理等。
业务中台抽象、包装和整合后台资源，转化为便于前台使用的可重用、可共享的核心能力，实现了后端业务资源到前台易用能力的转化，为前台应用提供了强大的“炮火支援”能力，且随叫随到。业务中台的共享服务中心提供了统一、标准的数据，减少了系统间的交互和团队间的协作成本。
图3-8 业务中台与数据中台双轮驱动的数字中台支撑前台业务
数据中台接入业务中台、后台和其他第三方数据，完成海量数据的存储、清洗、计算、汇总等，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。可以认为，数据中台为前台战场提供了强大的“雷达监测”能力，实时掌控战场情况，料敌先机。不过数据中台所提供的数据处理能力和在之上建设的数据分析产品，也不局限于服务业务中台。数据中台的能力可以开放给所有业务方使用。
从前台应用的角度看，业务中台所提供的“炮火支援”能力和数据中台所提供的“雷达监测”能力是一体的，并不是相互独立的。业务中台与数据中台相辅相成，互相支撑。对于业务方来说，自己产生数据，并同时消费自己的数据，在消费自己的数据时又在继续产生数据，从而形成数据闭环。打个比方，业务沉淀数据是产矿，将数据导入数据中台是探矿和挖矿，数据中台对数据进行建模等加工处理是对矿物的加工提纯，通过数据服务指导业务的开展是矿产再生的过程。业务中台和数据中台只是技术实现方式不同，它们一起组成了支撑业务创新的两个“*”，缺一不可。
3.4 中台的发展与进化
中台的存在价值是为它的客户服务，比如业务中台和数据中台要快速响应前台应用的需求。但如果中台同时服务于多个前台应用，在资源有限的情况下，必然涉及对来自不同应用的需求的优先级排序和取舍。如果前台应用急需某一能力，但中台又不能及时提供，是否允许前台先实现，等中台有时间再来沉淀？由此可以看出，大中台立足于横向的、全局的长远考虑，而小前台则注重于解决纵向的业务应用的当前问题。大中台的发展必然涉及权衡，但如何做取舍没有标准答案，需要结合实际情况进行。
3.4.1 中台的演变
中台的催生基石是能力共享。如果中台所提供的能力无法被共享，那就不是中台能力。如果中台只服务于一个前端应用，那就不是中台。那么哪些能力比较通用且是多个前台系统的共性需求？要回答这个问题，可从系统的组成开始分析，如图3-9所示。一个应用系统首先是为用户服务的，因此最先离不开的是系统的角色和用户。因此，建设中台的一个起步点就是先将角色和用户这些资源管理起来，形成用户共享中心。统一用户、统一权限、统一登录，可以看作是中台的雏形，但如果仅仅停留在此阶段，就退化成了单点登录。在此基础上，再发展与人相关的会员系统，比如会员的积分、积分的变动、会员的等级等就形成了会员中心。再者，用户是通过商品、订单与系统进行交互的，因此，商品的管理、订单的集中处理也是可以一起共享的。这些资源的统一集中管理后，相关的用户、会员、积分、订单等数据被存储在一起，方便全局管控。进行集中管理的资源越多，建设中台所取得的成果就会越大，就越能体现中台对前台应用的支撑作用。
图3-9 中台建设的三个步骤
在资源集中管理的基础上，更重要的是抽象出系统能力。抽象是指在考虑目标事物时，去除表象的、次要的方面，而抽取相同的、主要的方面，从而做到从个别中把握一般规律。通俗一些的说法就是将目标事物模型化。只有通过抽象，设计出来的能力才能应用到类似的需求中。
中台是为前台业务服务的，因此当前台业务有所更改时，中台要随需而变。这就要求中台具有很好的灵活性来支撑业务的开拓和发展：
1）数据模型需要根据前台业务要求实现可扩展性。
2）业务流程可根据场景和需求重新定义和编排，并可通过插件机制进行定制。
3）中台环境需要支持多环境可部署。比如不同的基础设施环境，包括公有云、私有云及容器云等；再比如不同的微服务框架，如阿里云的EDAS、开源的SpringCloud、Dubbo等。
中台的建设不是从零起步，但是中台是为业务服务的，是需要根据企业业务演进逐渐积累而成的。因此中台的建设不是一蹴而就的。
3.4.2 中台生态的形成
中台是企业级共享能力平台，因此除了最开始提出的业务中台和数据中台，还会逐步发展出技术中台、研发中台、移动中台、AI中台、算法中台、组织中台等其他中台。
技术中台整合和包装了云基础设施，以及在其上建设的各种技术中间件，比如微服务、分布式缓存、消息队列、搜索引擎、分布式数据库等，并在此基础上建设和封装了简单易用的能力接口，如图3-10所示。技术中台的建设标准是参考在一个只提供虚拟机或容器的私有云上，建设一个业务中台或数据中台所需但私有云没有提供的技术相关组件。技术中台作为工具和组件，为建设前台应用和业务中台提供了基础设施重用的能力，大大缩短了它们的建设周期。如果数字中台（即业务中台+
数据中台）是强大的中台炮火群，则技术中台提供的是如何根据需要快速搭建中台炮火阵地（即创建和部署不同环境下的中台）。
如何让阵地建设得更加可靠、简捷易用（通过技术中台提供资源的动态扩展能力等）？隔离数字中台对基础设施的依赖。比如业务中台的每个业务服务中心都需要关系型数据库。关系型数据库要提供一主一备和自动切换功能，以及读写分离和只读库创建的能力。为了快速访问大数据量的表，一般需要使用分布式数据库对其进行分库分表操作。分布式缓存是提高访问效率的一个必不可少的组件。通过消息队列实现异步解耦和大流量削峰填谷，这大大增强了前台应用应对大用户并发的能力。使用CDN加速的对象存储，可极大提高前端访问的性能。数字中台是在技术中台的基础上开发、运行的，但又不能与技术中台绑定。因为数字中台关心的是如何满足业务要求，而技术中台提供基础设施底层的能力，两者相互促进但又相互隔离。
图3-10 技术中台
研发中台是关注应用开发效率的管理平台，如图3-11所示。软件开发和系统建设是一项工程，涉及项目管理、团队协作、流程、测试、部署、运营、监控等方面。如何将在企业应用开发过程中的最佳实践沉淀为可重用的能力，从而更好地快速迭代开发创新型的应用，也是很多企业目前的一个关注点。这个关注点也是企业能力的体现，即研发中台。研发中台为应用开发提供了流程和持续交付的能力，包括敏捷开发管理、开发流水线、部署流水线、持续交付。敏捷管理一般由问题、迭代、实施等组成，并管理研发人员的日常工作和任务。开发流水线则涉及源代码的版本管理、分支的创建、合并和提交，半成品的构建、存储和使用以及产成品的构建。将产成品部署到指定环境并上线运行是部署流水线的职责。线上的应用需要监控，包括基础设施监控、应用监控、日志洞察、浏览器监控、链路分析和追踪等功能。研发中台为应用的开发提供了流程、质量管控和持续交付的能力。
图3-11 研发中台
消费者接触得最多的企业前台触点在移动端。如何保障移动端的迭代效率和稳定性也是企业需要着重考虑的。一个电商业务一开始可能只是一个工具型的App，完成对商品全生命周期的闭环支持。随着在业务中台基础上发展出相似业务，需要平台级的移动端开发支持。继续深化发展可能还需要支持多业态。因此为快速开发移动App、H5和小程序以支撑前台业务发展所进行的最佳实践就逐渐沉淀为移动中台，如图3-12所示。
1）移动App与其他前端技术比较，有其特殊性。比如移动App作为一个C/S架构，其发版模式需要通用应用市场的审核，而其客户端的更新是使用者控制的，提供远程配置、动态更新有助于控制App端。
2）移动业务是在线业务，对网络存在强依赖，而移动链路本身的稳定性和连通率等相比有线网络有一定的不足，因此消息推送的实现需要考虑网络因素。
3）因移动端质量相关问题，需要提供热修复等功能。
4）对移动App本身的安全扫描和加固也是一个需要着重考虑的因素。由于前端有不同的实现技术，如果完全使用不同的开发方式，对于企业来说是重复投入，且资源和技术不能共享。因此，使用Hybrid混合开发的方式，既可以支持移动App，又可以支持H5，甚至小程序，这也是移动中台需要研究的一部分。因此，尽可能将前端组件化，比如UI组件和图表组件，在此之上组装成业务组件，能大大提高移动端开发效率和质量。
图3-12 移动中台
前面所提的业务中台、数据中台等都是从技术系统层面展开的中台演变。企业在进行中台建设时，容易着手的也是对技术体系的改进。但要发挥中台的能力，让中台战略实际落地到企业，并为企业的业务目标服务，需要有与中台技术架构相匹配的组织架构。从Supercell 的“部落”，比如阿里巴巴的共享业务事业部、数据平台事业部，京东的前、中、后台，大家都可以看到建设中台需要两手抓，两条路线相匹配，齐头并进。如果将业务中台、数据中台等称为“战斗部队”，那么为企业提供的项目投资管理、风险管理、资源调度等的组织中台则是“战场指挥部”，指挥前线，调度后方。
“大中台，小前台”这种组织形式，并不是什么新鲜事物，实际上它是一种理想化的支撑模式。前台业务足够灵活，配套支撑足够快捷，资源还能够高效复用。不过要让中台模式在企业中发挥作用，对企业本身也是有一定要求的，比如企业有一定规模，业务比较丰富，值得去提炼共性元素形成共享能力。如果同时开展多种相类似的业务，那么从业务A提炼出来的能力可能提供给业务B使用；或者虽然业务单一，但同一业务在不同地域有不同的模式，也能沉淀出很多共享能力。
数据中台提供了数据分析报表来响应运营，并在此基础上提供数据能力直接服务于业务。那能不能更进一步，提供诸如个性化服务等与智能相关的能力？答案是肯定的，通过AI中台就可实现。AI中台借助数据中台的能力，尝试解决模型的训练、发布，智能服务的构建自动化，统一的元数据管理体系，模型的全生命周期管理等问题，通过AI能力平台化，降低对人员能力的要求。与数据中台利用CPU级别的资源不同，AI中台需要扩展对GPU资源管理和整合能力，为算法模型的开发者、训练者、标注管理者、数据管理者等构建智能服务的人员服务，并最终为业务人员提供智能化的服务。
3.4.3 中台与前台的博弈
中台通过提供基础服务和解决方案为前台业务应用提供服务。中台的职责是不断提升整体平台的服务能力基线。根据中台对前台业务的支持与参与度不同（见图3-13），会产生不同的中台建设路径。
图3-13 中台对业务的参与度
一个极端理解是中台是工具，即将中台作为工具平台来建设。由于工具的通用能力强，抽象层度高，所以工具可适应各行各业的企业。如此，中台的研发人员可只专注技术相关的问题，而无须关注和了解企业本身的业务。但是正由于工具无法深入业务场景，也不内含业务能力，导致中台不能沉淀业务，从而使中台开发人员与业务方沟通不顺畅，中台方无法直接为业务赋能。为了解这个问题，需要一个长期的业务理解和系统建设过程。
另一极端是中台完全为业务服务。中台方能快速理解业务需求，参与业务方的数据模型讨论、流程设计等，并将其变成系统实现。中台研发人员参与业务建设，符合中台为业务服务的目的，而且中台的能力也是通过业务沉淀下来的。但是过分关注业务，过分与业务团队耦合，会受限于时间和团队的能力，不仅中台可能会没有考虑通用的业务能力，也会导致无法更专注于对中台技术的深入研究。中台如果不从抽象度、适配性等角度出发，投入建设机制性的工作，很有可能局限于某单一业务，导致中台无法很好地适应其他相关业务的要求，从而不能很好地应对业务的变化。
目前很多宣传中描述的数据中台走到了图3-13所示的最左侧：把数据建设的工具称为数据中台，或把数据治理、数据建模等工具宣称为数据中台（其实只是片面地在理解数据中台）。中台最主要的能力是提供业务方可重复使用的并与业务相关的能力。数据工具的能力太泛化，会导致与业务方的距离太远，从而不能很好地为业务方赋能。
从历史发展来看，一开始企业建设了一个前台应用A（如
图3-14所示）。随着业务的发展，扩展到类似的业务，由于业务快速发展的需要，很有可能重新开发另一个前台应用B。但随着应用B的建设，发现应用A和应用B的很多功能和能力是重复或相似的，因此考虑是不是可以通过建设公共的部分，避免重复投入和建设。由不同前台应用抽取出来的公共部分即为中台。但是中台建设是一个新的命题，需要更强有力的团队，需要不断探索。如果中台研发团队的研发能力和时间进度无法跟上前台业务的需求变化，那么中台就只能满足部分前台业务的需求。再者，如果中台的抽象程度低、扩展性差，则会导致中台无法满足前台业务需求。这时前台应用又因为业务本身的发展目标和压力不得不自行组织团队完成这部分功能，由此可能发生本应由中台提供的能力却最终实现在业务应用中。中台越做越小，前台应用越做越大。这样一来，进一步压缩了中台的生存空间。
图3-14 中台与前台应用的关系
因此，中台既需要满足业务的需求，但又不能过度参与业务。中台能力的建设首先要保证投入到中台的资源不能成为业务建设的瓶颈。中台提供的能力要具有灵活性和可定制性，便于业务方根据规范自主完成，减少沟通成本，提升效率。
“大中台，小前台”，并不意味着前台不重要。相反，建设大中台就是为了更好地服务于小前台。大中台要想发挥作用，体现出自己的价值，必须通过小前台的引导。因此，判断中台建设是否成功的指标应包括：前台有没有使用中台，前台从使用中台中获得了哪些好处，中台好不好用，愿不愿意继续使用中台。
3.4.4 中台的进化策略
虽然中台概念的提出到现在仅几年时间，但中台已经在这几年中走出了自己的路径。根据中台的进化和演变的历史及可能的方向，目前可以看到共有广度和深度两种途径，如图3-15所示。
图3-15 中台的广度和深度两种进化策略
广度是指中台所涉及的内容会越来越多，即可以认为各种中台的不断出现，也可以认为是一个中台内部的共享服务中心会不断横向扩展，从一开始所提的业务中台、数据中台，逐步演化到AI中台、技术中台、研发中台等。另一方面，一个中台范围内的共享能力也在扩展，从用户中心、交易中心、营销中心等扩展到内容中心、工单中心、成长中心等。中台团队如发现某一前台业务模式很好，则将其沉淀为共享服务，从而提供更多的业务，这也是在建设和加强中台。由于中台作为中枢点同时支撑多个前台业务，因此中台成为打通前台业务的最好着力点，让不同的前台业务可以互相借力和引流，互相促进发展。
中台所沉淀的共享服务能力并不要求支撑所有前台业务，只要有多于一个前台业务需要某一种能力，此能力即可沉淀为中台能力，因此我们不能大而全地建设中台。如果企业认为现在企业各系统的用户管理能力需要统一，那就可以着手进行用户中心的建设。在此基础上，如果企业发现会员需要统一管理，订单需要全局视图，那么就构建会员中心和订单中心。因此，中台的建设是可以分阶段逐步实施的，无须将所有重构全部一起推动，而后者既会增加复杂性，又会提高风险，还不能及时得到反馈。
中台的成长离不开前台业务的创新。只有不断进行业务迭代和更新试错，对中台提出新的挑战和沉淀，才会让中台做得更好。另一方面，中台团队也需要有自己的产品化、平台化建设思考，并作为新业务的孵化器。
中台还需要建设成为开放的体系。开放不仅仅是对企业内部开放，也要对企业外部开放。通过中台建设，企业可以将自有的系统变为开放式平台，从而为其他企业充分提供第三方的数据和服务。再者，中台本身通过开放也可以充分利用其他第三方数据和服务。开放可以接口的方式，通过开放API，开创新的商业机会和应用模式。
中台的开放也意味着中台需要支持个性化需求。通过抽象能沉淀共性的流程、数据模型等。但不同业务总有不同点，这些不同的需求就需要个性化的支撑。中台和前台一般是由不同团队负责的。因此为了提高效率，中台必须留出足够灵活的扩展点，以便不同前台业务根据其需求进行定制化扩展。
中台作为平台，必然需要考虑拆分整体应用形成业务组件，通过业务抽象建模，解决共性的问题，从而更好地为业务服务。对业务问题的抽象程度越高，中台对业务的适配度就越高，需要对具体业务参与度就越低，从而更能发挥中台及中台团队的价值。因为越好的抽象越能发挥业务应用开发的创造性。在考虑拆分的同时，必须设计整体框架和组装策略，即组件间的协作机制。通过协作机制，才能让各业务组件协同实现业务场景以达到业务目标。
中台作为一个平台，其本身的运营也需要数据支撑。比如需要统计和观察中台以API形式提供的共享能力，从而了解中台哪些能力被业务引用及引用的频率，所使用的参数模式等；哪些设计的接口能力没有用处等。有了实际的数据，可更好地迭代中台。
中台建设是一个综合性的系统工程，因此需要有效的方法论的指导。中台建设方法论会在后续章节专门讨论。