写点什么

漫谈中台系列:《1 小时带你深入理解中台》学习整理

发布于: 2021 年 01 月 10 日
漫谈中台系列:《1小时带你深入理解中台》学习整理

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

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

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

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


发布于: 2021 年 01 月 10 日阅读数: 102
用户头像

磨炼中成长,痛苦中前行 2017.10.22 加入

微信公众号【程序员架构进阶】。多年项目实践,架构设计经验。曲折中向前,分享经验和教训

评论

发布
暂无评论
漫谈中台系列:《1小时带你深入理解中台》学习整理