最近在做一些中台的设计和落地，所以一方面梳理现有业务、分析设计方案，另一方面也在不断地学习和吸取其他公司、业务的经验教训。前些天看到下面两份资料，感觉有比较深的感触，所以整理如下。资料地址：

作为前阿里人，来扒一扒中台皇帝的外衣！

1 小时带你深入理解中台

作者：李云华，前阿里 P9

是骡子是马，拉出来溜溜：2 个接入中台项目经验：电商中台、支付中台，从使用者角度来谈谈中台。

一 中台价值，理想与现实

1、中台的价值，你看到的是这样的

可以让各业务部门保持相对的独立和分权，保证对业务的敏感性和创新性；另一方面，用一个强大的平台来对这些部门进行总协调和支持，平衡集权与分权，并为新业务新部门提供生长的空间，从而大幅降低组织变革的成本。中台部门提炼各业务线的共性需求，最大限度地减少“重复造轮子”。

2、中台的实际价值与问题

2.1 中台抱大业务的大腿，小业务抱中台的大腿

1-1 业务会分优先级，优先满足大业务

1-2 中台的 KPI 最终只能通过大业务体现

前两点有些类似，考虑质量 &效率，中台的最终价值还是通过业务提现，各项业务指标，跟大业务绑定

1-3 小业务之痛：“你这个需求不通用”

中台业务建成后，小业务提新的需求时很可能得到的拒绝理由， 做好心理准备

2.2 中台并不总是能够提炼共性需求

1、中台和业务方天然存在对共性需求的不同诉求

2、单个业务方提出的需求，没有什么标准判断是共性需求

缺乏的是足够客观的标准，很多是与业务未来的发展预期相关的，而对预期的判定往往充斥着主观的理解和决定。

3、大业务的需求更可能是“共性需求”

权重

2.3 中台的“轮子”会不断变化、业务被动升级

1、中台系统的架构和接口会不断演进

2、先特性再共性，老业务已有功能要进行切换

3、所有业务被动升级，频率比自己独立发展要高

2.4 中台是某类业务的中台，不是所有业务的中台

1、业务相似才有共性需求，业务差异越大中台价值越小

2、“技术中台”只不过是把“平台”二字替换为“中台”

数据中台价值：数据打通，分析价值？ 落地很难，提炼新的价值挑战很大

2.5 你有过以下哪些经历？

1、中台抱大业务大腿，我是小业务

2、跟中台撕逼需求和设计，我太难了

（中台也难，什么业务都要放在中台；业务方理解：中台只是包一下接口？良好的 API 设计也没那么容易）

3、中台要我升级，不得不升 （中台不太可能维护多个版本，架构、模型、接口需要统一）

4、中台和平台没什么两样，换个说法而已

二 中台的效果，预期 &实际

1、中台效果的预期

当有大中台思路之后：第一：我们这个体系里有什么样的能力，可以让各业务很清楚的知道，也可以让前台业务方更快的理解、选择和使用中台能力。第二：我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。

2、中台的实际效果

1、没有谁能完整的掌握中台的所有能力

1-1 业务方不能，中台自己也不能

1-2 人海战术：子域/子系统 PD（设计师）、架构师

人员沟通成本、不可能完全通过完整文档提供解决（几百上千页，沟通效率低于人员直接沟通）。

业务方 &中台：业务方描述需求；中台讲解中台能力；定边界，双方分析共性需求、非共性需求；技术投入，设计方案落地

2、30%的定制代码量耗费的人力可能超过 100%

2-1 中台无法设计成类似 netty 的通用框架（技术与业务的区别：业务在变，中台也在变）

2-2 编码工作量小，但讨论和设计工作量巨大

对接成本（学习、适应、改造、维护），天天开会到死。。。

三 中台建设的几个建议

1、勿在浮沙筑高台

优先做好“技术平台”

2、勿做追风的猪

至少有超过 3 个相似的平行业务线才考虑做中台（总监/副总裁级别）

3、步子太大小心扯到蛋

不要一开始就做大而全的中台，先找一个子域试点

4、世上没有万能药

不要试图做一个满足所有业务的中台

5、火车要靠车头带

给中台安排一个和业务线同级别的高层（强有力的领导，PK/撕逼，避免沦为外包）

6、Talk is cheap, show me the data

做好中台的资源投入统计和分析