一、火热的中台
2019年，中台这个概念非常热门，由于这种模式有助于提高效率、降低成本、保证质量，一线互联网大厂，如阿里，腾讯，网易，滴滴，纷纷入坑中台。
数据中台、用户中台、搜索中台、电商中台、推荐中台、内容中台、技术中台、算法中台、移动中台……一系列中台不断涌现。
中台其实是一个非常复杂的具有共性能力的组织。一个强大的中台支持众多的小团队研发。让小团队更灵活，降低创新成本，更快更轻地试错和创新。坚实的中台服务让每一个团队不仅可以获得足够的技术支撑，也可以使其他业务团队积累丰富的数据和经验。这也就不难理解中台为何会成为互联网企业未来组织变革的重要趋势了。
中台设计的业务复杂，随着中台成长起来的程序员，对业务有深入的理解，其不可替代性很强。中台程序员，利用后台的技能高效的完成了“前台”的业务，能够以高效率、高产出的方式搭建出一套完整的推荐服务及其周边配套设施，快速实现业务目标，进而提升自己的个人价值。
二、大中台与小前台
2.1 来源
任何一个软件系统都是通过帮助客户解决问题来实现价值的。针对不同的需求会建立不同的软件项目。
这些软件项目包含客户端的应用和后台管理配置的应用。久而久之就形成了固定的“前台”和“后台”系统，而且大家都在乐此不疲地开发着类似的业务系统。
- 用户前台 ：面向用户、直接产生交互，页面注重设计/交互，与服务端产生数据交换引导用户完成业务流程. 比如：
-
管理后台：面向运营人员的配置管理系统，后台为前台提供了一些简单的配置。
用户前台、管理后台、用户之间的关系如下：
传统模式下，项目迭代周期基本以月、季度为单位。长开发周期也意味着需求一旦变动，要么996，要么交付推迟
而且项目之间相对独立，许多项目都在重复发明相同的“轮子”。让项目越来越臃肿的同时，也让开发效率越来越低。
但现实是互联网进入下半场，企业竞争越来越激烈的今天。产品项目不能够快速迭代、低成本试错的后果，就等同让企业处于一定的竞争劣势。
为了解决以上问题，而应运而生的是“中台”概念。
2.2 中台案例
2.2.1 supercell
SuperCell公司就像是一个高产的游戏孵化器，在几年内开发出了10款以上的游戏，但是大部分用于试错的游戏都在研发过程中被腰斩了，最终呈献给用户的几款游戏都是经典中的经典。
是什么让SuperCell公司能够如此高效地试错和迭代呢？他们依靠的是强大的平台资源，支撑起各个游戏开发的小团队。
他们开发出的游戏看上去风格迥异，却存在许多共同之处。在业务上，共通的东西包括支付系统、用户系统等等，在技术上，共同的东西包括游戏引擎，内部开发工具等等。而这些共通的资源，都可以由一个强大的“中台”来提供：
中台的架构思想改变的不只是项目结构，也影响了研发团队的组织形式。SuperCell公司把这种高效的组织形式称为“部落”。
紧随其后，国内互联网公司也纷纷开始了各自的中台战略。
2.2.2 阿里巴巴
图中，阿里巴巴许多产品线的共通业务经过下沉，形成了中台的各种业务中心，而Aliware则是阿里巴巴的技术中间件平台，为各大业务线提供技术支持。
2.3 中台的价值
2.3.1 业务方面的作用
- 快速切入市场
- 专业人员融入系统
- 定义平台规则
2.3.2 技术方面的作用
- 服务重用：中台的初衷就是抽离通用的部分
- 服务进化：技术会跟随业务的进化而进化，每一次进化都是一次技术的沉淀。
- 快速响应
- 数据积累：长年累月的数据积累，特别是对业务数据的积累，能够帮助我们带来商业价值。
- 提高效率
2.4 中台的分类
典型的分类：
- 业务中台
- 技术中台
- 数据中台
- 算法中台
2.4.1 业务中台
业务中台：把各个项目都有可能设计到的公共业务进行下沉，整合成通用的服务：
2.4.2 技术中台
技术平台：为了避免研发人员重复发明轮子，向各个项目提供通用的底层框架、引擎、中间件。
例如，作者本人所在的网易云计算的轻舟微服务产品就是属于该技术中台的范畴，有兴趣可以百度了解一下：
2.4.3 数据中台
数据中台：为各个项目进行各种数据采集和分析：
2.4.4 算法中台
算法中台：为各个项目提供算法能力，比如推荐算法、搜索算法、图像识别、语音识别等等：
2.5 中台模式的适用场景
中台模式特别有利于业务复制尝试和需要大量尝试创新的业务。
例如，当前字节跳动的很多业务就比较适合这种中台模式。
- 从0到1的阶段（初创公司）：没必要建中台。从0到1的创业型公司，首要目的是生存下去，以最快的速度打造出产品，证明自身的市场价值。
- 从1到10的阶段（成长性公司）：可以开始尝试。企业有了一定规模，产品得到市场认可，这时候公司的首要目的不再是活下去，而是活的更好。趁着项目复杂度还不是特别高，考虑把各项目的通用部分下沉，组建中台，方便后续新项目的尝试和旧项目的迭代。
- 从10到N的阶段（高速发展公司）：搭建中台势在必行。当企业已经有了很大的规模，各种产品、服务、部门错综复杂，这时候做架构调整会比较痛苦。但是长痛不如短痛，为了项目的长期发展，还是需要尽早调整架构，实现平台化，以免日后越来越难以维护。
2.6 中台的生命周期
任何事物都有自身的运转规律，中台系统也不例外。首先我们需要满足使用者在某种场景中的需求，通过对需求的转化我们知道需要通过哪些功能或者系统来实现。
这些功能或者系统是否已经在中台系统中存在？如果存在是否需要进行优化或者拆分，如果不存在是否做成可以有通用性的模块？
在定义了以上几点以后，再进行设计，编码调试，集成测试。最后，发布给客户去验证业务的可行性。
如果发现问题再回到需求的原点重新走一次上面的过程，周而复始，直到满足客户的需求为止。
