业务中台化架构

中台的核心是提供封装业务模型的方法。它旨在帮助新型的小型企业提供一流的服务，而无需传统企业基础架构的成本，并使现有组织能够以惊人的速度将创新服务推向市场。中台战略最初是由阿里巴巴提出的，并很快被许多中国的互联网公司所采用，因为它们的商业模式是数字原生的，可以复制到新的市场和领域。如今，越来越多的中国公司将中台作为数字化转型的杠杆。

中台源起

美军的特种部队加航空母舰的策略：10 人以内的一支特种部队在战斗的最前沿侦查，独立决策，一旦发现目标，迅速呼叫强大的中台航母群对其进行毁灭性打击。从汽油车到电动车的转变，汽油车是每台车会内置一个内燃机，而电动车则将分散的内燃机收归到一个大的发电厂，从而降低前端的复杂度。这样发电厂自身的升级改造，譬如从火电到核电或其他更高效清洁的能源，就无须将复杂性透出给终端用户了。

芬兰著名的游戏公司 SuperCell，开发了部落冲突、皇室战争等现象级的手游。整个公司才 200 多号人，就被腾讯以 86 亿美金收购。在 SuperCell 里，一个游戏开发团队平均是 3-7 个人，但有一个强大的游戏中台在做支撑，可以并行开发 50 款游戏，然后通过“内部赛马”产生出一到两款经典。据说马云在带领阿里众多高官参观了 SuperCell 后，回来就在阿里整个集团层面启动了大中台战略。

业务中台、数据中台

进入两千年后，随着互联网应用的快速发展，很多传统企业开始触网，建设自己的互联网电商平台。后来又随着微信和 App 等移动互联应用的兴起，又形成了新一轮的移动应用热潮。这些移动互联应用大多面向个人或者第三方，市场和需求变化快，需要以更敏捷的速度适应市场变化，为了保持快速响应能力和频繁发版的要求，很多时候这些移动互联网应用是独立于传统核心系统建设的，但两者承载的业务大部分又都是同质的，因此很容易出现业务能力重叠的问题。

中台是典型的认知折叠，提升后端的复杂性以降低前端的复杂性。中台源于平台，对其定义也是见仁见智。从笔者的角度来看，中台提供可被集成的能力，不直接构建面向终端用户的应用；平台也是能够允许第三方集成进来，或者直接面向终端用户提供服务。中台的核心本质就是：业务为本、网络连接、数据智能，因此我们常说的中台架构可分为业务中台与《Datawarehousr-Notes/数据中台》，数据中台更多地偏向于中立、统一的数据治理与共享，而本篇专注于业务中台的理念与设计原则。

业务中台，是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少重复造轮子的 KPI 项目。中台不同于平台，不是最终用户能直接使用的，它必须被集成到各个业务场景中。前台要做什么业务，需要什么资源可以直接同公共服务部要。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发，而是在底层不变动的情况下，在更丰富灵活的大中台基础上获取支持，让小前台更加灵活敏捷。

• 核心能力的重复建设。由于销售同质产品，二者在核心业务流程和功能上必然相似，因此在核心业务能力上存在功能重叠是不可避免的。传统核心应用有报价、投保、核保和出单功能，同样在互联网电商平台也有。这就是核心能力的重复建设。

• 通用能力的重复建设。传统核心应用的通用平台大而全，通常会比较重。而互联网电商平台离不开这些通用能力的支撑，但为了保持敏捷性，一般会自己建设缩小版的通用功能，比如用户、客户等。这是通用能力的重复建设。

• 业务职能的分离建设。有一类业务功能，在互联网电商平台中建设了一部分，在传统核心应用中也建设了一部分，二者功能不重叠而且还互补，组合在一起是一个完整的业务职能。比如缴费功能，互联网电商平台主要面向个人客户，于是采用了支付宝和微信支付的方式。而传统核心应用主要是柜台操作，仍在采用移动 POS 机的缴费方式。二者都是缴费，为了保证业务模型的完整性，在构建中台业务模型时，我们可以考虑将这两部分模型重组为一个完整的业务模型。

• 互联网电商平台和传统核心功能前后完全独立建设。传统核心应用主要面向柜台，不需要互联网电商平台的在线客服、话务、订单和购物车等功能。而互联网电商平台主要面向个人客户，它不需要后端比较重的再保、佣金、打印等功能。在构建中台业务模型时，对这种情况应区别对待，将面向后端业务管理的应用沉淀到后台，将前端能力构建为面向互联网渠道的通用中台，比如订单等。

前台，中台，后台

既然讲中台，必然还有前台和后台。前台很好理解，指的是面向 C 端的应用，包括前端 (如 App/ 小程序) 和对应的服务端。至于后台，很多人把它等同于管理后台，比如商品管理后台，负责商品定义 / 上下架等，提供给内部运营人员使用，这可能不够准确。简单来说，对于一个交易系统，前台对应用户能看到的部分，如商品浏览和下单，属于接单的部分；后台对应履单部分，如仓库拣货 / 配送 / 财务结算 / 采购补货等，属于实际干活的，由企业内部人员负责，处于一个交易处理流程的后端。

在传统企业，没有在线的前台，基本是线下手工接单，内部信息管理系统基本都属于履单范畴，例如 ERP、CRM、采购系统、仓库管理系统，财务系统等，这些系统属于一般意义上的后台概念。在互联网企业，因为系统一般是自己开发，管理后台既包含面向前台销售的功能，如商品上下架和促销管理，也包含面向履单部分，比如配送、采购、财务结算，所以互联网企业的管理后台并不简单等同于履单后台。

接单和履单之间还有一系列事情要做，包括生成订单时的优惠计算 / 创建实际的订单 / 支付 / 库存扣减等, 这部分功能属于交易逻辑的核心。在简单场景下，前台应用包含这部分功能，在复杂的场景下，就有必要把这部分独立出来，构成独立的中台，为前台减负。

桌面应用能不能直接操纵底层硬件设备完成功能？理论上是可以的，比如在应用里嵌入汇编语言直接操作硬件，但显然开发效率低，可维护性很差。如果中间加一层操作系统进行转换，向下管理硬件，向上提供简洁的 API，应用开发就非常方便，这里操作系统类似中台的定位。

对于大型传统零售企业 (上图右边部分)，企业经过多年信息化建设，购买了大量的商业套装软件，形成内部 IT 基础设施，现在要往新零售转型，理论上 C 端的应用可以直接调用老系统的 API(如 SAP 产品提供一定的开放能力) 来实现功能打通。但和桌面应用直接控制电脑硬件设备类似，这两者直接对接是低效的，两者的服务对象 (2C 和 2B)/ 数据模型 / 技术栈 / 实时性要求差异很大，而且新的应用进来，又要从头到尾对接一遍，新业务上线，至少需要大半年的时间。

这时如果有个中间层负责桥接和转换，就非常方便。C 端应用可以快速基于这个中间层构建，不用关心底层遗留系统的实现细节。这个中间层就是中台，起到类似操作系统的作用，把旧的基础设施转换成面向互联网的基础平台，而且这个平台非常通用，新业务可以快速对接，短时间搞定上线。传统企业在做全面数字化转型时，这样的一个中台必不可少。

中台与现有服务对比

中台和微服务

中台是微服务的升级，原来只是一个个离散的服务，只负责提供接口功能，如商品服务 / 订单服务 / 权限服务，在中台里，升级为商品中心 / 订单中心，每个中心更强调体系，包括更好的边界划分和业务抽象，更好地监控和系统运营能力 (稳定性 / 故障定位)，更好的业务运营能力 (比如商品中心自带商品管理后台，支持基础商品定义)。每个服务中心围绕核心业务，自成体系，成为一个微内核，这些微内核既相互独立，又形成一个整体，共同构成基础业务平台，也即中台。松散的微服务 ->共享服务体系 ->中台，这是微服务架构和中台的区别和联系。

中台与云

PaaS 提供了一种服务，客户的程序员通过二次开发使用 PaaS 服务，最终完成某个功能给最终用户。PaaS 的通用性需要非常强，这样才能获得足够大的市场，比如 IM、视频云服务等，也因此 PaaS 往往是没有界面的。SaaS 提供的服务不需要客户进行开发，只需要开通服务，在管理后台上配置一下就可以直接使用。但 SaaS 服务往往针对的是一个细分领域，其定制化能力也相对弱很多。即使是像钉钉，钉钉选择 IM 这种企业中最通用化的服务，同时做成企业服务的开放生态，目标客户也主要是覆盖中小企业。定制化需求强的大客户，也往往会需要希望借助 IM PaaS 服务来自主研发内部 IM 工具。

PaaS 和 SaaS 定位在服务外部客户，必须具备很低的使用成本。即使是需要通过技术来接入的 PaaS 服务，接入成本也一定要足够低，接口清晰，文档完善。中台首先是定位在服务公司内部客户，由于这个范围的限定，导致 中台的通用性可以在很多约束条件下来实现，可服务的领域比 SaaS 广。比如即使同样是电商，淘宝、天猫、聚划算、闲鱼、飞猪的站点都是不一样的，而阿里共享事业部就在中台层服务多个业务。此外，由于中台的用户是公司内部的程序员，大家有相似的背景，也可以频繁沟通，所以服务接入的成本可以做得比面向外部客户的 PaaS 要高。