6

10个中台9个死?彻底让你搞懂中台系列(1)

 2 years ago
source link: https://www.woshipm.com/pd/5642761.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

中台这一概念,在近几年在国内大热,不少企业接连开始组织架构的调整,意图建设中台。但建设中台,并非这么容易,可能投了不少钱,最后也没有什么水花,那么中台为什么难做?作者在这篇文章中给出了解答,一起来看看吧。

U3IkL0ZTANbe2ylDwP5S.jpg

01 中台到底是什么?

狭义上来讲:我们知道前台是一个个面向用户的可视化操作界面。

后台是包含代码、中间件、数据库等一系列框架代码集。

后台搭建完,前台就会展现出来,一个闭环就形成了。

那什么是中台?顾名思义中台其实就是在夹在前台和后台之间的一个东西。

那为啥前后台已经能形成闭环了还需要中台?

大家一定听过一个被讲了很多次的故事:阿里在发展业务的过程中发现,随着业务线的快速增加,一开始只有一个1688,后来出现了淘宝、阿里妈妈、支付宝、咸鱼、口碑等等大量的内部项目。

每个项目都需要开发一个所谓的前后台闭环,阿里内部100个业务,就得搞至少100个闭环,1个闭环算他50个人的开发测试团队,大业务线还不止,就得5000个员工,这在以人员成本为最大成本的互联网公司,简直是要命。

当然成本还不是最关键的,最关键的是效率,在互联网快速发展的阶段,效率是生命线,你比别人上线晚、迭代晚,可能就玩不过人家了。

所以只能拼命堆人做,与时间赛跑。

虽然这个思路是对的,但是抵不过几个问题啊:

  1. 那会很多项目都是通过市场测出来能不能成的,失败率很高,很可能跑不出来,这样这个团队怎么办,调到其他部门?流动性太高,团队成本也打水漂了
  2. 很多项目的重复性很高,其中的很多模块都可以通用,每次都重新做一遍成本太高了
  3. 如果每次都要从0开发,哪怕堆人搞,其实响应效率也很低,一般一个从0启动的项目打底1个月起上线

于是马云大腿一拍,搞中台,中台能全部解决上面的问题,还能大大降低成本。

怎么搞呢?

就是把一些通用性很高的模块,抽出来,作为公共库的一个个“能力”,然后A业务需要这个了,来拿一下直接用,B业务需要那个了,来拿一下直接用。

大家一定会说,很像开放平台啊!对,本质上其实就是个对内的开放平台。

于是每个新业务就不需要那么多研发人员了,通用的模块就不用重新开发了,在既有的中台能力库上做功能,对业务的响应效率也会高出一个层次。

这么一想,中台简直是一个大杀器啊!

于是阿里就大刀阔斧的开始搞中台建设,花了几年时间,终于陆续建成了。

这期间,随着阿里的如日中天,江湖上吹中台的声音到处都是,管他大公司、小公司、做业务、还是做平台,做全品类,还是做垂直,都是在鼓吹应该要做中台。

不少公司投入了好多钱,也没做出个什么水花来。甚至阻力重重,推到一半就推不下去了。

然而后来阿里又亲自“推倒”了自己的中台计划,把中台的服务能力拆分的更小。

一时间唱衰中台的声音又此起彼伏。

02 中台为什么难做?

归根到底,看似预期很强大的中台建设,存在以下巨大的难点。

1、中台对人的要求太高

搭建中台的产品技术,必须高度了解业务,你想业务A的人只要了解业务A,业务B的人只要了解业务B,中台的人既得了解业务A,也得了解业务B,100条业务线,得了解100条,甚至他要比A更懂A,不然咋抽象对吧

这其中涉及到多个环节:

1)看的准?

你得看的准这个业务是怎么在跑得,他的核心流程是怎么样的,他的功能模块有哪些、具体包含了哪些功能?其中哪些模块适合被抽出来?

随便举个例子,很多东西都会伪装,都会变种,举个最简单的例子,一个盲盒功能,你觉得这个盲盒是什么东西?不会真抽象一个叫盲盒的能力吧?那你就完蛋了

过两天来了一个大转盘需求,你去资源池里找了一圈,发现刚做的盲盒能力根本用不了??

算了,再做一个大转盘吧。

看到这里,大部分小伙伴已经看出来了,盲盒本质上不就是抽奖么,这两个理应是“一样的东西”,大盘转的需求,“盲盒”的能力理应能被使用啊。

本质上它们都等同于“抽奖”。

2)抽的对?

看准后,就要抽的对,抽的对包含几层意思。

i、边界清晰

边界清晰有多重要?不清,是要命的!直接决定了中台的失败。

你到底抽到什么程度?

还是盲盒的例子,盲盒活动的整个业务链路,涉及到了用户、支付、订单、抽奖。

你难道把这些都抽出来了?还是只抽抽奖那部分?

抽的太多,中台就太厚,你让业务干嘛;抽的太少,中台就太薄,失去了意义。

ii、模块的能力合理拆分

既然我们觉得把抽奖 抽出来,那么抽出来,怎么变成一种可灵活调用的能力?

如果拆的好,那么能满足很多额外的场景需求。

哪天来了个新需求是:直接积分兑换奖品。

用抽奖其实是可以满足的,比如你把抽奖分成3块:【抽奖资金获取抽奖资格】、【抽奖核心算法】、【中奖后用中奖券兑换奖品】

那么积分兑换奖品,是不是就可以使用3)的能力?

积分和中奖券,本质上都属于一种虚拟资产,是不是能力就通用了?

iii、如何权衡

中台也面临需求越来越复杂的情况,比如抽奖的时候直接开奖,也有抽奖后某一时间一起开奖;比如算法策略是大家一起开奖,还是部分用户可以优先开奖;比如是必中,还是可不中等等。

这些多样性,在业务的发展中一定会越来越复杂。

和普通产品迭代一样,中台也得不断强化和迭代能力,不然就满足不了业务需求了。

就好比你做了可以直接开奖的能力,结果另一条业务线抛过来一个一起开奖的需求,完犊子了,又满足不了。

所以和普通的业务迭代一样,中台的需求,也面临大量决策问题。

依然需要有效甄别真需求,还是伪需求,需求优先级怎么样,重要或是紧急,最后判断出来该不该做,怎么做,什么时候做,做了价值大不大等等。

2、中台的协同成本很高

中台的协同成本高,这个很好理解,毕竟原来只要前台和后台配合就能完成的事,硬生生的插了一层,变成了3方配合才能完成,难度直接增加50%。配合开发难度PLUS,相应的迭代和找问题的难度也PLUS了

尤其是中台搭建初期能力还不完善的时候,人家根本不想用你,但又碍于公司战略,不得不用你。就变成了一种非市场机制下被迫的行为。

所以中台早期是很难的,中台人也是比较惨的,因为他必须要服务好每个业务线的前后台团队 ,而不是单一的一个需求方。

这种协同复杂度,是几何级的上升,我给你们举个例子:

还是拿抽奖,比如A需要有一起开奖的需要,B要算法是随机中奖算法,C要必中。

而且大家都很急,要求尽快上线,A要求5天后,B要求7天,C要求8天内给到。

这个时候,不单单是判断需求应该先做什么,怎么做的问题了?

还面临着复杂的项目管理问题,资源怎么安排,来保证ABC三方都能满意,结果开发一评估,发现A能在5日内给到,B、C怎么赶时间都不能在7、8天内给到。

于是吭哧吭哧去找B、C商量,能不能缓一缓,结果BC不同意,于是只能考虑优先排BC的需求,再找A去商量,想把A的需求后置,A当然不同意啊,凭什么我要给BC让路,噼里啪啦一顿沟通……大家都不妥协,于是只能向上反馈,要更多的资源。

这其中,也有因为协调不好,有些业务线撇开中台,自己去做了,因为等着误了业务发展,业务始终是第一考虑。

这只是其中一个很小的场景,解决方式也只是举了一个例子,但是管中窥豹,可以看出中台在服务多业务线的过程中,所面临的巨大协作成本和难度。

中台从广义上来讲:从业务中来,又到业务中去。很有点像毛主席的从群众中来,到群众中去的精髓。

做的好的中台对业务一定是有帮助的,但确实因为其难度很大,真正做的好的公司少之又少。

本文由 @ 华叔产品论 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏,鼓励TA抓紧创作!

Recommend

  • 23

    etcd 是云原生架构中重要的基础组件,由 CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册于发现,还可以作为 key-value 存储的中间件。 《彻底搞懂 etcd 系列文章》将会从 etcd 的基本功能实践、API 接口...

  • 26

    etcd 是云原生架构中重要的基础组件,由 CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册与发现,还可以作为 key-value 存储的中间件。 《彻底搞懂 etcd 系列文章》将会从 etcd 的基本功能实践、API 接口、...

  • 35

    etcd 是云原生架构中重要的基础组件,由 CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册与发现,还可以作为 key-value 存储的中间件。 《彻底搞懂 etcd 系列文章》将会从 etcd 的基本功能实践、API 接口...

  • 23

    etcd 是云原生架构中重要的基础组件,由 CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册与发现,还可以作为 key-value 存储的中间件。 《彻底搞懂 etcd 系列文章》将会从 etcd 的基本功能实践、API 接口、...

  • 46

    etcd 是云原生架构中重要的基础组件,由 CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册与发现,还可以作为 key-value 存储的中间件。 《彻底搞懂 etcd 系列文章》将会从 etcd 的基本功能实践、API 接口...

  • 20

    etcd 是云原生架构中重要的基础组件,由 CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册与发现,还可以作为 key-value 存储的中间件。 《彻底搞懂 etcd 系列文章》将会从 etcd 的基本功能实践、API 接口...

  • 2

    10个社群9个死,1万字长文带你社群运营从入门到寂寞 梁山伯伯 2021-09-05 0 评论...

  • 7

    手写一个Redis分布式锁,让你彻底搞懂 作者:指北君 2022-11-11 08:19:03 如果程序运行的极慢(硬件处理慢或者进行了GC),导致30秒已经到了,锁已经失效了,程序还没有运行完成,这时候,就会有另一个线程总想钻...

  • 7

    数据权限是SaaS产品必不可少的功能,明确权限管控的颗粒度,保障数据安全。本文作者对如何SaaS 产品的数据权限该如何设计展开了分析,希望对你有帮助。

  • 1

    手写系列-这一次,彻底搞懂 Promise 首页 / 手写系列-这一次,彻底搞懂 Promise

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK