中台——为前台而生

一、没有中台的时代——传统项目

在传统项目中，项目的物理结构是什么？

无论内部结构如何复杂，都可以分为“前台（用户）”和“后台（管理）”两部分。

什么是前台？

先声明“前台”和“前端”并不是一回事！！！

所谓前台即包括各种和用户直接交互的界面，比如web页面，手机app；也包括服务端各种实时响应用户请求的业务逻辑，比如商品查询、订单系统等等。

什么是后台？

后台并不直接面向用户，而是面向运营人员的配置管理系统，比如商品管理、物流管理、结算管理。后台为前台提供了一些简单的配置。

前台、后台、用户之间的关系

传统项目存在的问题：

在传统的前台-后台架构中，各个项目相对独立，许多项目都在重复发明同样的轮子，即让项目本身越来越臃肿，也让开发效率越来越低。

结果：

（1）人手不够

（2）重复建设问题

二、中台的出现背景

（1）国外（最先）

中台的引出者—— SuperCell（一家芬兰的手机游戏公司 ）

海岛奇兵：

部路冲突：

皇室战争：

是什么让SuperCell公司能够如此高效地试错和迭代呢？

​ 他们依靠的是强大的平台资源，支撑起各个游戏开发的小团队。

容忍失败，甚至为失败喝彩

Supercell，失败从来不是可耻的记录，而反倒是一种进步的动力。一款游戏推出遭到失败后。其管理者的反应是“太好了，这款游戏失败了，证明了我们剔除一条错误的道路”。独特的“庆祝失败”根植于其企业文化之中，潘纳宁认为：“我们是在从失败中吸取教训的基础上建立了这家公司。失败得越快，我们学习得越快，也会变得越好”。

他们开发出的游戏看上去风格迥异，却存在许多共同之处。在业务上，共通的东西包括支付系统、用户系统等等，在技术上，共同的东西包括游戏引擎，内部开发工具等等。而这些共通的资源，都可以由一个强大的“中台”来提供：

好处：

（1）深度利用云计算/微服务等技术，升级单个员工价值

（2）小而精的团队

（3）信息共享

（2）国内（部分）

A. 阿里巴巴

阿里巴巴2015年提出了“大中台，小前台”的战略：

图中，阿里巴巴许多产品线的共通业务经过下沉，形成了中台的各种业务中心，而Aliware则是阿里巴巴的技术中间件平台，为各大业务线提供技术支持。

B. 华为

华为提出了“平台炮火支撑精兵作战”的战略：

华为把作战小分队比喻为前台项目团队，把中台比喻成战地指挥部。在这个比喻当中，中台的作用就是提供资源支持：要数据给数据、要技术给技术。

三、什么是中台

阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含了用户中心、商品中心、交易中心、评价中心等十几个中心，而共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。钟华. 《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》

中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。

中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。

中台作为变速齿轮，链接了用户与企业核心资源，并解决了配速问题

中台的定义：

中台就是“企业级能力复用平台”

（1）企业级

定义中台的范围，区分开了单系统的服务化与微服务

（2）能力

定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在

（3）复用

定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上

（4）平台

定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业力的柔性复用，对于前台业务更好的支撑。

四、为什么要做中台

其实和把程序内的公用逻辑封装为 library 差不多，就是尽量避免重复造轮子。一个轮子造 100 遍，对部门是没有任何好处的。一个系统造 100 遍，对企业自然是没什么帮助的。

早期的企业经常借鉴腾讯经验，鼓励内部竞争。但内部竞争的度往往不好把握，经常会出现“所有部门都在造差不多的系统”的现象。

中台从公司战略角度，将这些行为进行了规范化，公共的部分交给公共系统部门去做。

总结：

为了规范化、快速化开发，为了更有效的管理公司！

五、前中后台三者之间的关系

前台:由各类前台系统组成的前端平台。

每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。

后台:由后台系统组成的后端平台。

每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。

前台作为用户触点，直接和用户进行交互由于通过提升用户体验感吸引流量，已经成为产品营销、推广的基本手段之一。因此，前台的变化更快，需要不断创新，随着业务的发展，要有试错能力。

后台更多解决的是企业资源及管理效率问题，通常是稳定至上。所以，后台对业务的响应是比较慢的，并且改动成本非常大。因此，两者之间产生了巨大矛盾，这也就是为什么在很多企业里，前台部门和后台部门彼此经常抱怨的原因所在。

中台:就像在快慢两个齿轮之间，加入一组“变速齿轮”，将前台与后台的速率进行匹配，一方面，支撑前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。另一方面，又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本。

一句话总结：

​ 中台比前台更稳定，比后台更灵活，在稳定与灵活之间找到了一种平衡。

说到这里，有人又提出了疑问：

（1）这不就是以前业务平台要解决的事情吗？

（2）业务功能独立封装，通过业务总线，实现业务流，本质还不是平台的概念？

（3）平台和中台之间，真的是换汤不换药吗？

中台和平台之间的差异：

​ 中台是由平台自然演化而来的。

​ 两者之间在功能上有相同之处，这很正常，但是其差别也是很大的。先看下网上的两个例子：

（平台化协作）

这是一个电商平台中，客户的购买场景，粗略的可以划分为6个小的场景：选择产品准备购买->收银台->输入、校验->首次支付、签约->触发风控规则->求助客服。一般情况下，针对对外的客服，我们会建立一个统一的知识库。一旦中间某个环节出了问题，有客户咨询，客服会在第一时间查询知识库，然后在对客户进行回复。但知识库的更新往往是滞后的，如果知识库中没有该类问题，就需要线下协调了。比如：风控环节出了问题，那么协调人员需要找产品，产品找研发，研发找安全团队的产品或研发，进行一系列的讨论之后，给出最终答案。所以我们在网上购物中常会遇到这种情况，中间环节出了问题我们打电话给客服，客服开始给我们解释流程或说明其内部组织各环节处理进度，但是作为消费者，我们根本不关心流程，更不关心对方的组织架构，我们只关心如何快速、准确的告诉我，我该怎么做。

（中台化协作）

在来看中台运作模式，中台先做功能抽象，按照服务客户或服务场景进行抽象，通俗来讲，就是哪些功能是面向直接客户的，可以抽象成服务中台，哪些功能是几个业务场景通用的，可以抽象成业务共享中台，哪些业务是可以解决一类问题或是一个业务场景的，可以抽象成相关的针对性业务中台。中台与中台之间相互协作，该独立就独立，该对接就对接。每个小中台内部，从产品设计到研发甚至到运营，高度自主独立。小中台组成大中台，形成炮火支撑群。并且，一个小中台环节出了问题，该怎么做，内部都能给出解释，并且信息直接同步给问题回馈部门。

对比两种模式，我们可以发现，知识库和中间多余的沟通环节省略了。知识的积累由小中台内部自行沉淀，更聚焦。

中台和平台的差异化：

1.组织模式不同

平台和中台在组织模式上，存在横向和纵向的差异化。从一个业务场景的实现上，平台贯穿了需求调研、产品设计、产品研发以及后续的运营等部门。通常是把架构师、开发、测试、产品搞在一起协同、排期、研发、上线。而中台，则采用“承包制”，一个业务，从需求调研到后续运维，全流程服务。

2.聚焦程度不同

前面提到过，当今的商业斗争比拼的是响应力，用户是商业战场的中心。中台模式，聚焦了业务场景或用户本身，避免了服务的断档，可以促使中台内部人员进行客户需求的深度挖掘。同时，利于公司培养出复合型人才。

3.最终目的不同

无论平台还是中台，在高内聚低耦合上，都是一样的。横向模式的平台，职责边界划分清晰，便于集成，适合项目或产品的交付。而纵向模式的中台，在数据的完整性和业务可运营层面上，更具操作性，适合精细化服务和创新。

六、中台的分类

（1）业务中台

业务中台在前文中反复提及，就是把各个项目的共通业务进行下沉，整合成通用的服务平台：

（2）技术中台

技术平台，为了避免研发人员重复发明轮子，向各个项目提供通用的底层框架、引擎、中间件：

（3）数据中台

数据中台，为各个项目进行各种数据采集和分析：

（4）算法中台

算法中台，为各个项目提供算法能力，比如推荐算法、搜索算法、图像识别、语音识别等等：

七、什么样的公司适合中台

（1）公司具有一定的规模，产品得到了市场的认可

这时候公司的首要目的不再是活下去，而是活的更好。这个时候，趁着项目复杂度还不是特别高，可以考虑把各项目的通用部分下沉，组建中台，以方便后续新项目的尝试和旧项目的迭代。

（2）当企业已经有了很大的规模，各种产品、服务、部门错综复杂

这时候做架构调整会比较痛苦。但是长痛不如短痛，为了项目的长期发展，还是需要尽早调整架构，实现平台化，以免日后越来越难以维护。

八、中台给企业带来的收益

工程方面

就像上面提到的，首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置，并在公共服务上快速高效迭代出新的业务。

数据方面

有了统一的用户、订单系统，就不会再有各种恶心的数据打通问题，不会有跨部门的数据墙。

有了统一的中台，也就有了统一的数据规范。

对于大数据相关的需求，可以从相对唯一的数据出口进行业务迭代，不需要为每一个部门进行定制开发，浪费人力。

创新方面

这一项目也很好地诠释了之前所说的“点、线、面”的理论，在“点”上根本感知不到的问题，在“线”和“面”的平台上，更容易发现这些问题的本质，通过专业的技能解决这些问题，为企业带来实实在在的业务价值，这就是很好的创新！钟华. 《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》

有了公共的中台，意味着有了相对全局的视角，更能发现单点观察难以发现的问题。在更大的业务层面进行一定的创新。

九、总结

（1）中台解决的问题

1. 技术层面

   中台解决的问题是 —— 多项目 且 项目相对独立，导致需要重复造轮子。

   如：文件上传 / 订单模块 / 支付模块 / 搜索模块…引起的研发周期长，程序员996了都不能灵活应对业务变化 的情况

2. 业务层面

   中台解决的问题是 ——因为项目相对独立，技术重复造引起的 研发周期长 / 面对市场需求总是慢半拍(不灵活) / 试错成本高 / 不利于创新

（2）中台解决的方式

• 通过 统一的公共技术模块 抽离形成服务。再次需要该服务时通过接口调用完成，避免重复造轮子，避免研发周期拉长
• 明确业务流程，封装成公共业务流程模块。当下次走同样业务流程时直接复用。降低试错成本，有利创新
• 到时候技术研发的就不是项目，而是这些 “公共模块” 形成的 服务，形成的 中台

一句话：企业级能力复用平台！

（3）个人感受

“中台概念”往小地说，就是“微服务”。但中台需要使用 产品管理 的方式来对待。因为中台对外提供的服务需要 不停的迭代，适应业务的需求，而不是等业务来提需求。对，技术人员也要懂业务。