一、什么是中台？

本节介绍中台的历史起源，以及数字化时代中台在企业信息化建设中的展现和作用。

1、中台的源起

中台不是一个新名词。在一个投资银行的组织结构中：

前台（Front office）是与客户和顾客（无论是个人客户还是公司客户）直接互动的岗位，诸如大堂经理、客户经理、柜员等。

中台（Middle office）是指直接支援前台工作的所有人员，使用前台或后台的资源，为前台提供专业性的管理和指导，并进行风险控制，比如风险管理、合规、财务管控以及IT服务等。

后台（Back office）指幕后的职能岗位，行使管理职能，比如结算、清算、会计、人力资源等。

位于芬兰的著名移动游戏公司Supercell以小前台的方式组织了若干个开发团队。每个团队包含了开发一款游戏所需的各种角色。

这样，各个团队可以快速决策、快速开发。而基础设施、游戏引擎、内部开发工具和平台则由类似“部落”的部门提供。

“部落”可以根据需要扩展为多个小分队，但各个小分队都保持共同的目标。“部落”本身并不提供游戏给消费者。

2、国内大厂中台建设概况

1）阿里巴巴

2015年的阿里巴巴已拥有规模庞大的个人会员和企业会员，业务种类纷繁复杂，业务之间交叉依赖，业务团队众多，不能及时响应业务的要求。

因此当年12月，时任阿里巴巴集团CEO的张勇通过内部邮件宣布启动阿里巴巴2018年中台战略，构建符合DT时代的更创新灵活的“大中台、小前台”的组织机制和业务机制，实现管理模式创新。

即将产品技术力量和数据运营能力从前台剥离，成为独立的中台，包括搜索事业部、共享业务事业部、数据平台事业部等，为前台即零售电商事业群提供服务。从而前台得到精简，保持足够的敏捷度，更好地满足业务发展和创新。

2017年5月出版的《企业IT架构转型之道：阿里巴巴中台战略思想和架构实战》详细阐述了业务中台是介于前台与后台之间的。

采用共享式的方式建设解决了以往烟囱式和单体式架构设计的重复开发、数据分散、试错成本高等问题。列举了建设业务中台的一些原则：高内聚低耦合、数据完整性、可运营性、渐进性等。此书的出版推动了中台思想和建设。

2）滴滴

之后，很多互联网公司也在快速跟进中台。滴滴出行在2017年12月分享了《如何构建滴滴出行业务中台》。滴滴出行在前端业务上形成了出租车、快车、专车、代驾等多业务共同发展的业态。

虽然各业务的应用场景不同，但所有业务本质都是出行，交易流程是相同的。如果各业务独立发展，则业务间缺少协同性。

3）京东

京东在2018年12月宣布采用前台、中台和后台的组织架构。

前台职能是理解和洞察客户需求和行为，通过产品创新和精细化运营服务客户，最终实现和提升客户价值。

中台通过沉淀、迭代和组件化地输出服务于前台不同场景的通用能力，作为为前台业务运营和创新提供专业能力的共享平台。

后台职能则提供基础设施建设、服务支持与风险管控，为中、前台提供保障。

3、从组织管理和技术系统角度看中台

中台可以作为一种企业组织管理模式和理念。不过从技术系统角度，中台也可以作为一种新型的企业IT设施架构。

此外，为建设中台系统，有些企业会成立专门的中台技术团队来整体负责、实现和运营。因此作为组织管理模式的中台和中台系统这两者并不是截然分开的。

中台化的组织方式就是在公司内部构建统一的协同平台。

一方面，可以让各业务部门保持相对的独立和分权，保证对业务的敏感性和创新性；

另一方面，用一个强大的平台来对这些部门进行总协调和支持，平衡集权与分权，并为新业务新部门提供生长的空间，从而大幅降低组织变革的成本。

中台部门提炼各业务线的共性需求，最大限度地减少“重复造轮子”。

从技术系统层面，中台是企业级共享服务平台。传统的IT系统或套件没有太多关注系统能力的复用和共享，因此企业在多年的信息化过程中引入和建设了多套具有重复功能的烟囱型系统。

而中台则要求对能力进行细粒度的分析，识别共享的能力，并将共享的能力建设成为统一的平台。因此中台不是单系统的服务化。

综上所述，中台的核心思想是能力的枢纽和共享。中台是在集中的基础上建设分权的业务，进行联通，并为各业务提供统一的服务。

因此一切将企业的各式各样的资源转化为易于前台使用的能力，为企业进行“以用户为中心”的数字化转型服务的平台，都是中台。

但要注意，与此思想相匹配所建设的中台团队并不能当作是资源共享的团队。

中台团队关注的是如何形成基础服务，为前台团队建设业务应用提供便利。因此中台要实现平台逻辑与业务逻辑的分离，并且隔离不同前台业务。

另外，中台不是微服务，因为中台不仅仅是一种技术架构，中台还是企业进行数字化转型的整体参考架构。不过从技术角度，可以认为微服务是建设中台的最佳实践。

微服务是一种将J2EE时代的单体架构拆分为多个微服务的技术架构。微服务将相关联的业务逻辑及数据放在一起形成独立的边界。

各个微服务之间通过标准的协议，比如HTTP RESTful风格进行通信访问。各个微服务间是松耦合的。不同的微服务开发团队理论上可以使用不同的技术栈来实现微服务而无须强求一致。

另外，微服务所需的数据存储一般都由单独的数据库实例或数据库模式隔离，数据的交互只能通过接口或消息，而不能在数据库层直接访问另一微服务的数据。微服务强调接口的隔离原则，通过接口封装。

由于微服务可单独部署，因此可根据需要对所需的微服务进行扩缩容，无需针对整个系统，从而系统的伸缩性更灵活，更能应对大流量并发场景，比如秒杀。

微服务拥有与生俱来的独立开发、独立部署、独立发布，支持高并发高可用，以及去中心化管理的优点。

但由于微服务是分布式编程，提高了开发、调试、部署、运维等的难度，增加了服务管理的复杂度，且需要重新设计比如原先由单一数据库所保证的原子性等等。

虽然微服务对开发团队提出了更高的要求，但是它促进了研发团队的一体化运维能力，从而改变了企业的研发组织架构。

二、中台系统及展现形式

中台是数字化转型下重构企业IT基础设施的最佳实践。那么，怎么理解中台是企业级共享服务平台？我们先来看看中台的起源地阿里巴巴建设中台的驱动力和成果。

2008年的阿里巴巴集团由于企业内部部门之间的隔离、业务目标相对不一致，淘宝和淘宝商城（即现今的天猫）是作为两套独立的系统分别建设的，即是两套独立的烟囱型系统。

但二者的基础业务都是电商交易，因此基本功能是类似的，比如包括商品、交易、支付、评价、物流、积分、论坛等。

由于系统间的隔离，虽然商城的流量和交易持续走低，却无法将淘宝的流量引流到淘宝商城。因此，两个业务部门商量规划如何打通两个电商平台，从而成立共享业务事业部，着手进行内部称为“五彩石”的项目。

“五彩石”项目的成果，即现在称为“中台”的各共享业务服务中心，为后续天猫的快速发展奠定了坚实的基础。中台整合了阿里巴巴集团的产品技术能力和运营数据能力，对各前台业务形成了强有力的支撑。后续上线的聚划算、1688等均得益于中台的建设。

由此可以看到，企业在信息化建设过程中，不同业务部门基于本部门的业务需求提出了相对独立的方案。

IT部门为满足不同业务部门的不同业务需求（有时甚至是相互冲突的）搭建了纷繁复杂且部分功能重复的烟囱式系统。烟囱式的系统建设不仅带来了功能的重复建设，还带来了重复维护，导致企业的重复投资。

此外，为了打通烟囱式系统，还需要专门设计第三方集成方案或引入企业服务总线ESB的概念，集成和协作成本高昂。因此，在建设和引入新的系统时，虽然各部门根据自己的业务需求构建了定制化的最优解决方案，但这些方案可能只是局部最优；如果从公司整体来看，不一定是全局最佳的解决方案。

所以，构建系统如果不从全局出发，不进行现有系统的改造升级、重复利用，那么只能是在旧有的复杂性上再次引入新的复杂性，导致系统越建越复杂，而效率却越来越低。

既然我们强调中台是能力的复用，那么在建设新系统或业务应用时，可复用的能力具体是以什么样的形式提供的呢？

在程序设计中，函数是将一段经常使用的代码封装起来，然后在需要使用时可直接调用。使用函数体现了程序设计模块化的指导思想，将大问题分解为小问题，通过解决小问题来解决大问题。其次，函数的使用大大减少了重复编写程序段的工作量。

相关的通用的函数集，可以编译成为动态链接库及类库，再次提升了复用的可能。

既然我们可以使用函数、类库的方式将一些可复用的功能封装起来，那是不是也可以将可复用的功能作为服务提供？以服务的方式提供的共享能力平台就是中台。中台是比函数和类库更高一层次的复用封装，从而更好地服务于业务。