大中台小前台的架构设计.docx
- 文档编号:10766597
- 上传时间:2023-02-22
- 格式:DOCX
- 页数:10
- 大小:1.10MB
大中台小前台的架构设计.docx
《大中台小前台的架构设计.docx》由会员分享,可在线阅读,更多相关《大中台小前台的架构设计.docx(10页珍藏版)》请在冰豆网上搜索。
大中台小前台的架构设计
问题一:
什么是平台?
定义:
一种基于外部供应商和顾客之间的价值创造互动的商业模式;它是规则和标准的制定者。
问题二:
平台分为哪几类?
(1)应用平台;
(2)业务平台;
(3)技术平台;
问题三:
平台的价值在哪里?
于他:
为所有参与者创造价值;
于己:
通过积极网络效应吸引用户,利用规模化盈利;
问题四:
什么是中台?
中台,是服务多个产品且具有一定公共业务逻辑的通用共享服务平台,它是人+组织+服务的综合体!
问题五:
中台分为哪几类?
(1)业务中台;
(2)数据中台;
问题六:
中台有什么价值?
毫无疑问,中台能够共享复用,降本增效。
问题七:
中台与平台的差异在哪里?
问题八:
中台架构是如何演进的?
最早,我们的架构就是如此简单。
优势:
系统简单,迭代快速。
不足:
三方对接耦合在业务中,三方系统稳定性影响业务稳定性,三方系统切换改造成本很高。
然后,我们做了基础服务的抽象,把与第三方对接的短信、推送等抽象成基础服务。
随着业务的发展,我们遇到的新的问题。
新业务诞生,烟囱式的系统不断冒出来,数据形成了孤岛,业务之间的流量、产品、系统难以连结,消耗了大量资源去做了重复的事情
很多公司,一般打着“闭环”“高效”的名义,推进烟囱式产品/系统/架构,其实是不作为。
这个时候,类似于XX中心的业务服务诞生了。
如上图所示,除了各个业务公用的,业务无关的基础服务,业务相关的用户中心,订单中心,交易中心,营销中心服务,应运而生。
此时,这类共享服务中心,增加了业务属性。
这些服务,应该归业务研发部门,还是基础服务研发部门呢?
都不是。
此时,业务中台诞生了。
中台,是共性业务的部分。
问题九:
中台,应该做厚还是做薄?
最早,阿里提出了“大中台,小前台”的中台战略。
对此,有不同的看法,中台太厚,势必夹杂个性化业务逻辑,不要让中台成为业务发展的瓶颈,我们提倡“小中台,大前台”,只有足够通用的业务,才适合下沉到中台。
问题十:
如何沉淀与发展通用业务中台呢?
五大步骤实践,分享给大家。
步骤一,成立相关中台部门(产品+研发)。
中台建设,组织是其中不可或缺的一步。
步骤二,服务下沉。
通用基础服务,不断下沉。
步骤三,业务下沉。
通用的基础服务下沉之后,是通用业务的下沉。
步骤四,产品架构与系统架构的升级。
以交易中台为例,通用交易从端(例如:
收银台),到服务,到数据的通用业务中台。
步骤五,不断迭代,不断丰富中台能力。
但务必注意,只有充分通用的业务,才适合沉淀到中台,否则中台只会成为业务发展的瓶颈。
中台负责人不能只想着抢地盘,不属于自己的范围不能大包大揽,要保持克制。
问题十一:
如何评价中台建设是否成功呢?
三个衡量标准:
(1)有没有业务接入使用,有多少接入使用;
(2)接入的成本是否快速简单;
(3)有新的业务需求沉淀是否能快速响应并不影响系统稳定;
问题十二:
什么场景不适合中台建设?
(1)单一业务,单一产品;
(2)主营业务稳定性不足;
(3)团队规模太小;
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 大中台小 前台 架构 设计
![提示](https://static.bdocx.com/images/bang_tan.gif)