最近在做一些中台的设计和落地，所以一方面梳理现有业务、分析设计方案，另一方面也在不断地学习和吸取其他公司、业务的经验教训。前些天看到下面两份资料，感觉有比较深的感触，所以整理如下。资料地址：
作为前阿里人，来扒一扒中台皇帝的外衣！
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
做好中台的资源投入统计和分析
