1、什么是中台？
中台，在我看来，从业务上来讲，可以说是为了解决系统的复用性的问题而出现的。一个简单的例子，阿里刚刚开始的时候只有淘宝，但是后来出现了天猫，二者尽管顶层业务逻辑有不同，但是他们都是需要一套订单，商品，库存，仓储，物流的各种系统的。如果每次我们想做一个新的业务模块的时候，都要来实现这样一套系统，迭代速度会很慢，而且很容易在做改动的时候因为各个类似功能的系统的改动不一致产生错误。
因此，将这些公用的系统提升，做成–中台，统一来使得各个业务部门重复使用，将需要反复建设的功能和系统进行统一的规划和管理。
主要解决的问题实质上有两类：
-
需要业务需求或者功能需求是高度类似的，通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设、导致复用性很低，效率低，研发资源被浪费，用户体验也不够统一
-
早起业务发展过程当中，为了解决当下的一些业务问题，垂直的个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑非常多，导致了在新业务新市场的拓展过程当中，市场没有办法直接复用，甚至没有办法快速迭代。
中台的领跑者
SuperCell是一家芬兰的手机游戏公司，这个名字或许有些陌生，但是说起下面几款游戏，大家一定会很熟悉：部落冲突、海岛奇兵、皇室战争
SuperCell公司就像是一个高产的游戏孵化器，在几年内开发出了10款以上的游戏，但是大部分用于试错的游戏都在研发过程中被腰斩了，最终呈献给用户的几款游戏都是经典中的经典。
他们开发出的游戏看上去风格迥异，却存在许多共同之处。在业务上，共通的东西包括支付系统、用户系统等等，在技术上，共同的东西包括游戏引擎，内部开发工具等等。而这些共通的资源，都可以由一个强大的“中台”来提供：
2、中台的作用
能力通用化
目前大部分企业实现的中台，主要是将遗留下的后台系统，比如ERP MES CRM的公共部分进行拆解复用，形成类似交易中心，用户中心，订单中心这样的微服务集合供前台调用，从而保证逻辑的一致性同时更快响应前台的变化
Reference 1 当中举了订单服务的演进过程的例子，很值得一看。当平台需要开放多渠道来完成订单的时候，保证用户有着类似的体验是很重要的一项，包括整个系统的的scalability。
在这种情况下，一个数据中台能够使得用户可以看到在各个平台各个渠道自己下的订单。从平台角度来说，有了数据中台，维护成本，发生错误以后的修改成本都会减轻很多。
略微解释下，如果是分开的系统，那么每个系统都会有自己的数据库，我们需要做数据的join操作，然后返回给前端用户需要的正确的信息。当发生了逻辑上的错误以后，我们很有可能需要在分开的几个子系统当中来做修改，很容易出错，修改的整个时间消耗也会很长。而且数据仓库在多个系统的情况下，抽取数据，再进行分析是有比较大的时延的，一般都是加一天的样子，无法看到实时的数据。
快速切入市场
在中台出现之前，我们进入每个行业是比较困难的。在了解业务的基础上需要搭建基础的业务模块。现在不需要了，有了中台策略的加持即使对一些行业不太了解也能够从容应对。
在 BAT 中已经有染指汽车制造，航空航天等专业性很强的行业了，靠的就是中台能力的输出。
3、阿里P9专家对中台的理解
我们网上听到的中台
可以让各业务部门保持相对的独立和分权，保证对业务的敏感性和创新性，另一方面，用一个强大的平台来对这些部门进行总协调和支持平衡集权与分权，并为新业务新部门提供生长的空间，从而大幅降低组织变革的成本。中台部门提炼各业务线的共性需求，最大限度地减组织变革的成本，减少重复造轮子。
实际上中台是这样
- 中台抱大业务的大腿，小业务抱中台的大腿
- 中台并不总是能够提炼共性需求
- 中台的“轮子”会不断变化，业务被动升级
- 中台是某类业务的中台，不是所有业务的中台
- 业务会分优先级，优先满足大业务
- 中台的KPI最终只能通过大业务体现
- 小业务之痛:“你这个需求不通用”
中台并不总是能够提炼共性需求
- 中台和业务方天然存在对共性需求的不同需求
- 单个业务方提出的需求，没有什么标准判断是共性需求
- 大业务的需求更可能是"共性需求"
中台的轮子会不断变化，业务被动升级
- 1、中台系统的领域模型、架构和接口会不断演进，他是会跟随业务演进的，比如大业务发展很快，中台可能会跟着演进，这个时候其他小业务也得跟着对接中台，中台不可能同时维护几个版本的，这样很累，所以小业务只能跟着中台升级。
- 2、先特性再共性，老业务已有功能要进行切换
- 3、所有业务被动升级，频率比自己独立发展要高
中台是某类业务中台
- 业务相似才有共性需求，业务差异越大中台价值越小
- 技术中台 只不过是把 平台 二字替换为 中台