到了去年底,阿里巴巴董事长兼CEO张勇在湖畔大学分享时也说:如果一个企业奔着中台做中台,就是死。
其实中台到底 解决了什么问题,怎么落地,都是落地全靠临时发挥了。
大体量的系统,谈中台才有意义!
软件架构,都是逐步演进的,跨度太大,一方面公司没有这方面的财力、人力等你来搞,另一方面技术方面也会存在短板障碍,很容易存在“将就先搞后续完善优化”的思想。
架构演进,静下心来,看看中台真的适合你么?看完下文,你或许心里会更有数。
1、中台源
一、大厂的中台
1、腾讯
All in产业互联网。腾讯的技术委员会,对标的是阿里巴巴的中台事业部,而不是外界所解读的对标阿里“达摩院”。整合带来的最大好处就是技术的标准化,而这一切显然是为其中台战略做铺垫——标准化意味着腾讯可以更高效地把自己的能力交付给客户
2、百度
建立可复用的中台能力。百度中台的技术思路:提供完备的通用能力、定制能力,持续完善领域技术沉淀能力。业务视角, 中台提供了灵活的可定制业务框架, 使得业务可以聚焦业务特有逻辑的开发
3、小米
业务+数据+技术。小米业务中台建设三年战略,包含了持续优化、构建中以及待新建的系统,纵向分为企业战略、业务执行、业务支撑、数据治理四部分。
4、滴滴
构建最合适的业务中台。在对业务和产品进行更好建模的基础上,进行了“五化”:服务化、异步化、配置化、插件化、数据化
5、京东
打造共建、共享、标准化的数据中台。目前京东集团已形成零售、数科、物流、保险、健康等多元化的业务格局,各业务都进入到精细化运营阶段,对于数据精细化运营提出了更高的需求。京东过往十多年业务发展沉淀下来的海量数据,需要通过数据中台的建设形成宝贵的数据资产,以打造强有力的数据智能能力。
6、网易
胖中台、标准中台、平台组织。标准中台组织由各个能力组和工具、规范/流程/方法论组成;当标准中台组织对业务的介入程度不足以支撑中台的实现,就需要更加接近业务的定向组来参与,这就形成了胖中台组织;而能力臻于成熟,工具、流程都实现标准化,标准中台组织也可以退化成平台组织。
7、用友
3+2+1。近两年随着对中台理念、架构及配套研发运营体系的深入理解和落地,用友的iuap平台逐步演变为基于统一中台内核的3+2+1架构,即3大中台,2大服务,1个面向用友所有客户和生态的统一开发平台。
8、知乎
大中台小前台。前台有三个业务团队,分别是社区事业部、商业化事业部以及会员事业部,其中社区事业部被认为是知乎一切事业的根源和基础;商业化团队主要负责知乎的品牌广告、信息流广告,以及相关的商业化活动;会员事业部,就是此前主打知识服务的知乎大学更名而来。技术实行中台制,也就是说知乎所有业务团队共用技术团队。
二、端和台
前后台和前后端是在不同维度的思考。端是在代码层面上的区别,台是展现形式上的区别。
四、各个中台分类
五、中台之坑
1、团队组织的错误
许多团队管理者会认为增加人力是最好的,因为他们认为人员增多会带来效能的提高,但按照敏捷的思想,小团队工作效能更高。
2、业务拆分的问题
业务架构者对业务拆分不够清晰,会导致开发中造成到两混乱信息,是团队的管理和维护成本大大增加。
3、微服务的滥用
中台的建设是从下而上的,中台的需要是从上而下的。微服务不是靠量来取胜,是靠与实际业务的匹配来取胜,设置一个独立的业务单元,单独提供一个系统的微服务。举例来说:某个项目中台设计之初,拆出了 80 个微服务,20 个共同组件,应用服务器 90 台,人员维护的成本极高。优化以后,微服务缩减到 30个,应用服务器只需要 40台。
4、系统的过度设计
大部分微服务架构人们只能看到其结果却看不到其架构过程,但其实不是这样的,它既不是一步到位架构出来的也没有必要这么做,因为架构最基本规律就是解决当前的需求即可,它无需对没有出现的问题负责。
5、前台试错的迷失
小前台快速迭代,快速试错,但是成功必经是少数,试错单位越小,试错的次数越多,越容易被人们忽略,这样的前台可能就被架空了,怎么做呢?完善的管理制度加上前台团队人员得是高精尖人才,类似 supercell 试错后举办聚会(管理制度)和 cell 中成员都是顶级人才(人员选择)解决这一问题,supercell 还有个很大的优势就是公司本身人数就不多,这对管理起到了一定的帮助作用。
6、利益的划分
假使某个中台组件支持了几个不同的前台,结果到最后只有一个前台活了过来,其他都死了,那么每个团队最后的利益该如何分配呢,要知道这几个死了的前台死因可能不仅仅是产品的不合格,更多的可能是具有某种机遇成分。
7、组织架构的调整问题
此处包含组织架构调整太艰难该如何做,还有中台团队前期生存艰难的问题,都在在下面中台插曲中会讲到。
8、不同公司中台架构照搬
这是不可以的!这是因为架构这种东西必须得在公司原有的基础上调整,再一个就是每个公司业务逻辑,部门等都不相同,架构照搬是不实际的。
9、中台团队领导选择问题
该选择什么样的领导来带中台呢?给出一个最佳模板人选:技术出身,并且要十分熟悉公司的业务场景,超强沟通能力和沟通意愿,公司核心员工,在公司内部工作时间长,公司内部人缘广泛。照着这个模板寻找即可。
六、中台建设过程中常见景象
1、中台部门往往前期生存困难
这个问题可以说是组织架构演进过来的,各个公司前期对中台采用试点的方式,往往效果可能是中台部门起初总是在夹缝中求生存,这是因为中台部门既要满足所在公司多个不同前台的需求,指给中台提出了巨大的挑战,可能每次都难以达到前台的要求,再一个就是前台作为战场上直接杀敌的士兵具有更多的话语权,而中台则是后方强有力的补给支援,即使前台和中台权利级别一样,前台可能具备更多的话语权,这对中台的生存更加不利,中台极有可能在初期就流产。
因此初期必须得给中台的发展打一剂强心针,而不是任由中台发展。怎样才能让中台话语权更大?只有让它实实在在成为产品的必经阶段就行了,那如何做呢?公司可以强制规定,前台产品产出必须得经过中台这一阶段,并且放宽初期中台的产出结果,这相当于给中台进行权利的补充。
2、人员变动(包括调岗和辞退)
人员进行部门调整可以理解,但是人员辞退,这是因为比如偏底层的技术人员在垂直业务领域可能不再需要。这几年是互联网的寒冬,今年被大厂“辞退”的员工数量也蛮多,所以我怀疑是有一部分原因是大厂在建设中台,进行组织架构调整的结果,互联网的寒冬可能不是那么“寒”。
3、很多企业会进行数据中台和技术中台的建设
很多企业可能会先进行数据中台和技术中台的建设,然后业务中台可能是留有空缺。这是因为大部分公司对技术层面和数据层面划分较为清晰,做技术平台或者数据平台的团队可以立马拉过来继续做一个技术中台或者数据中台,对组织架构的调整较少,公司做起这两个中台较为容易。而如果要做业务中台就必定是要动组织架构的,动组织架构就意味着动利益分配,这其实就已经卡死很多公司了。再加上有的公司业务复杂的话,这又是一道屏障。
4、中台部门的消亡
中台迈过初期夹缝生存的难关后可能还面临一个凋零消亡的问题,这与各个公司的组织管理有关,如果一个中台部门不与前台部门建立良好关系,又没与后台部门建立良好联系,那么这个中台就危险了,不知那一天就会猝死在突发的利益冲突中。所以项目上可以安排中台和前台和后台专门对接,专门建立联系,这个得看管理者自己的管理策略。
5、中台团队的选人
企业一般开始会从前台调人,其中一定包含了能力极强的业务架构师角色,一部分技术通过招聘方式,还有一部分通过内部培养的形式。
6、先做再调组织还是先条组织再做
组织架构如何调整这一问题为何各大厂没有详细讲明?首先如果要做中台,那么组织架构是必调的,调整组织架构就意味着权利和利益分配的调整,一旦涉及到利益和权利的切分,这个话题就变的有意思了(怎么感觉和美国想禁枪一样),所以企业要是想改组织架构,那得在做每一步选择前都要慎之又慎,这不得不依托管理者能力,以及公司内部全员了解中台的重要性