一、什么是中台？

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

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风格进行通信访问。各个微服务间是松耦合的。不同的微服务开发团队理论上可以使用不同的技术栈来实现微服务而无须强求一致。

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

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

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

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

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