当前位置: 首页 >  网络营销

中台的末路

发布日期:2019-10-18

中台的概念不绝于耳,众多公司忙⊥着搭建中台,这些中台背后的问题,你了解吗?

从2015年开始,到2019年现在为止。各大公司都在吹捧中台理念。仿佛中台是业务复杂性的救世主,是某些架构师和PM的新出路,各种割韭菜的讲中台的课程层出不穷。

当然,吹牛逼的时候大家都是拣好的说,苦逼的东西就只有内部人士知道。中台到底靠谱还是不靠谱,只凭各路英雄的演讲内容,那看起来是靠谱的。

先来看看这些公开的观点,再以我的视角还原“中台”的真相。

按照惯例,手动贴上文章的目录:

一、公开的观点

1.1 中台是什么

阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事≡业部,包含了用户中心、商品中心、交易中╥心、评价中心等十几个中心,而共享业务事业部正是“厚平台”的真实体现,为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务∪服务。

——钟华,《企业иIT架构转型之道:阿里巴巴中台战略思想与架构实战》

中台实际上是通用业务的下沉。

企业在一个行业耕耘多年之۞۞后,一般都会形成一些公用的业务,而这些业务是可以像中间件那样进行下沉共享的。

再往前推一些,也就是比较早期人们常说的偏业务的基础服务,在概念上并不┍是创新。

1.2 为什么要做中台

中台解决了什么问题?

其实和把程序内的公用逻辑封装为Library差不多,就是尽量避免重复造轮子。一个轮子造100遍,对部门是没有任何好处的;一个系统造100遍,对企业自然是没什么帮助的。

早期的企业经常借鉴腾讯经验,鼓励内部竞争。但内部竞争的度往往不好把握,经常会出▇█现“所有部门都在造差不多的系统”的现象。

中台从公司战略角度,将这些行为进行了规范化,公共的部分交给公共系统部门去做。

1.3 ↔中台给企业带来的收益

1)工程方面

就像上面提到的,首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置,并在公共№服务上快速高效迭代出新的业务。

2)数据方面

有了统一的用户、订单系统,就不会再有各种恶心的数据打通问题,不会有跨部门的数据墙。

有了统一的中台,也就有了统一的数据规Ω范。

对于大数据相关的需求,可以从相对唯一的数据出口进行业务迭代,不需要为每一个部门进行定制开发,浪费人力。

3)创新方面

这一项目也很好地诠释了之前所说的“点、线、面”的理论,在“点”上根本感知不到的问题,在“线”和“面”的平台上,更容易发现这些问题的本质,通过专业的技能〢解决这些问题,为企业带来实实在在的业务价值,这就是很好的创新!

——钟华,《企业IT架构转型之道:╪阿里巴巴中台战略思想与架构实战》

有了公共的中台,意味着有了相对全局的视角,更能发现单点观察难以发现的问题,在更大的业务层面进行一定的创新——听着很有道理。

二、真相

中台能解决问题么?是能解决的。

中台能解决所有问题么?那显然是不能的。

就像微服务架构一样,架构师吹牛的时候天花乱坠,你做起ч来却发现这条路上全都是坑。

2.1▣▤▥ 技术方面

公用业务下沉,这个理念其实很朴素。

所有程序员都知道我们』公用的逻辑要进行封装、抽象,变成Library。中台的本质其实就是把这种朴素的思想进行了一定程度▪的推广。

1)难以应对 Cross cutting concern

根据中台进行系统拆分和部门调整之后,还是会遇到 cross cutting■ concern,什么是 cross cutting concern:

The crosscutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which arЁe needed in almost every module of an application, hence they are cross-cutting concerns.

有些需求难以避免地会影响整个流程中的所有系统:

比如,从技术范畴进行的一些改造(如为了完成tracing,所有系统增加trace id,并在log中默认携带)。

比如,从业务范畴进行的i18n改造(注:i18n是国际化的意思,Internationalization去掉头尾的i和n刚好还剩下18个字符,程序员的智慧)。

这些改造需求一般天生就是跨系统、跨组、跨部门的,事情一带上“跨”的字眼,就不好搞了。

举▲一个典型的例子,某巨型互联网公司员工抱怨,在当前的微服务和中台架构前提下,做一个需求经常要改20+个模块,苦不堪言,连上线顺序都不一定搞得清楚。

当这20+个模块又是跨部门的时候,就更难了。想要推动其它部门做一些短期看起来没啥收益的事,太难了。

2)稳定性和灵活性的矛盾

对于一个系统来说,追求稳定性,那么必然会在修改和升级上较为消极;追求灵活性,那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一,在一定程度上就得放弃另一方面。

就像网友经常讲的不作死就不会死,没有代码才是真正的稳定之⇔道。

Google程序员在Github上发起的行为艺术项目:nocode,没有 code,就没有bug——可谓弃疗的典范。

有很多中台系统被剥离之后,因为用户众多,一旦出现技术上的问题,影响面巨大。

从我的实际观察来看,中台部▕门的系统虽然初始立项的时候声势浩大,但基本也没什么人关注这些公共系统的代码质量或者测试质量。最终只不过是大家公用了一堆“垃圾”,“垃圾”在转过几手之后,后来的人基本就不太想对原来的代码进行修改了。

可能有人会讲你可以重构啊。

嗯,重构的前提是系统有完善的测试用例和可以跑的测试。事实上一般都没有!在没有测试的情况下,我们可以根据过往的系统需求文档和 PRD来还原当时的业务场景,并进行测试补充。

但你又发现,中台的性质(大多偏技术项目,基本没什么PM把关或者出文档)使其基本没有什么靠谱的、详尽的文档。写的复杂的中台,连业务流程都理不清楚,还想︴写测试,别做梦了哦。

3)中台与前台的模糊╦╧业务边界、距离

在实际实践时,中台与FT←的边界往往划得不清不楚。比如,用户服务、用户权益、用户在各种子系统中的状态,这些内容可能并不是用户❤服务本身关心的内容。

但往往需求也会提给用户服务,这时候用户服务就只是进行字段存储,而状态机变化则完全在外部。

如果对系统内的个别数据不进行管理,那么有其它接入方接入时,就无法解释清楚字段的含义和使用场景。

如果不接受这些不相干的数据接入,那么前台流程系统可能会在自己内部重新建立自己的数据系统,这部分系统又极有可能和中台有功能上的重叠。

如果想要把这些数据接管过来,那么中台又需要梳理所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部,这往往又会产生与中台与前台业务边界的冲突。

难以给出有效的边界,就意味着无穷无尽的撕逼。这便是很多中台的两难:我接不是,不接也不是。

如果去问那些中台业务部门的系统开发负责人:某些业务要不要你们来做,连这些人自己都说不清楚。

2.2 人方面

如果要ↇ做中台,那往往需要将业务部门的一部分系统进行下沉。

下沉并不仅仅是一个技术问题。

如果要把系统从一个部门变到另一个部门,这一定会带来人员的调动。从情感上来讲,人们都是讨厌这种部门变动的。因为“领导”会在部门调整中发生变化,同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。

也有些公司在调整中进行粗暴的系统交接,如果系统需要下沉,那我直接从原来的维护团队手里夺过来,交给中台部门来管理。

这一样会引起双方的反感:

交接方:这是我们加班加点,辛辛苦苦开发出来的系统,凭什么交给别人?奋斗了半年难道就是为了给别人摘桃子? 被交接方:这个系统原来的维护团队水平极低,代码就是一堆“垃圾”,他们不想搞了就随便扔给我们?凭什么啊?我们又不是接盘侠。

即使贵司运气好,在系统交接过程中没有出现问题,那交接后也不好说。被交▂▃▅▆█接的系统在交接后往往陷入消极维护状态,这时候前台业务╨接入中台会比以往更加困难,这种困难使前台业务的不满积累到一定程度之后,会再次催生前台部门重新造一套新的自己的中台,而部分或全部放弃原来的中台。这样,原来的中台部门便会陷入尴尬的境地。

生存空间被挤压,人也自然很难待得下去,各公司的中台部门,人跑的比香港记者都快。

2.3 部门、公司、组织架构方面

1)跨部门沟通障碍、跨部门目标差异

进行部门划分之后,每个业务部门会有自己的一套目标体系。部门与部门的目标(KPI)一般是不相同的,如果相同的话,那也就没必要分多个部门了。

而部门与部门之间的目标在某种程度上甚至可能有冲突。

例如,A部门Feature Team较多,主要负责业务功能迭代,需要更强的灵活性;而B部门负责中台数据,主要关心系统稳定性,也就是前文提到的灵活性和稳定性的矛盾。

若此时出现cross cutting concern,两个部门需要在矛盾上取得一定程度的平衡,这种平衡在个别情况下是不可得的。

例如在一段时间内,中台部门的目标是提高某个商业指标,让公司更赚钱/省钱。这时候前台业★务提来了新的需求,这种需求是能使流程开发更加灵活的,但与中台部门的KPI不在一个航道上。

中台部门显然要把需求排排优先级,把任务排排主▊次。前台部门又会觉得中台支持个』需求怎么这么龟速又唧唧歪歪,不如自己实现了。

前台业务也有自己的理由:“自闭环”嘛,这词真是好用。

2)公司利益分配

毫无疑问,距离业务近的地方比距离业务远的地方能分到更多公司增长的成果。

中台看起来是业务,但又是公共业务,既然是公共业务,那基本上没办法分享到任一单一业务成功的红利。纵使其成功的原因中,中台的强大、便捷是重要в原因。

这会导致什么问题呢?

没有人愿意接手中台项目,中台项目变成烫手的山芋。大佬无法在中台项目上获得红利,小弟们没法在中台项目上获得利益。中台功能确定以后,只有出事故的时候大家才想起你来。稳定运行是应该的,出事就是你的锅!

3)利润中心?其实是成本中心

最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能,转变为基于企业核心业务和数据进行运营的团队,这个团队会更快、更好地支持业务发展的同时,逐渐掌握企业最核心的业务和数据,逐步培养出企业最稀缺的“既精通∈业务,又熟悉技术”的复合型人才。

在接下来整个社会进入开放共享的时代,企业最大的价值将会是基于这些核心业务和数据进行对外开放的运じ营,到那个时候,这个部门将成为企业最为宝贵的资产。

——钟华,《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》

在大多数公司,中台部门和基础架构一样,会被当成是包袱而不是财富。▷可能有些人读到这里会不太爽。

我们来看看,科技公司是怎么看待员工的呢?

在DDD相关的书里提到两个概念:成本中心、利润中心。

技术对业务参与不强的情况下,技术部门基本上都会被当作是成本中心。也就是老板要达成自己的目标,必须不情不愿地花钱去养你◀们这些技术团队。

对应业务侧开发来说,想要改变老板的这种看法,需要让业务系统和业ⓛ务人员之间进行强联动,将一部分业务人员变成系统人员架构中的业务专家角色,或者是研发人员自己变成一个业务领域专家,就是有些人常说的你得跟老板穿一条裤子。

从这方面来讲,ì大多公司的基础架构角色就比较尴尬。业务驱动的公司,@基础♀架构并不是其致胜¤要素。所以不管你做的再好,只要公│┃司没有用技术赚钱,那么这部分的支出就只能被当作单纯的成本。

当然了很多做基础的大佬也根本不在乎,公司只是个练兵场,练成了带小弟们跳槽就好。

中台也是一样的,从业务一线剥离到后方之后。中台离业务的距离越来越远。公司高层渐渐看不到继续对中台进行投入的价值,中台便渐渐变成了他们眼中纯粹的成本中心,是公司财务的包袱而不是财富。

2.4 行业方面

中台建设一般要考虑公司的实际情况,这样建设出来的系统可以应对一段时间内的公司业务变化。然而公司的压力有时并不来自于自己的业务方向,可能来自于行业内其它公司的模式挑战。

理论上来说,只要一个公司的业务系统架构建设完成了,便已经完成了一种架构上的固化。这时行业内如果有新的模式获得了成功,公司肯定要进行跟进,但是新的模式一定意味着对原有系统、架构的挑战。

试想,原来系统架构是针对线上交易设计的,突然有一天,O2O模式被证明有利可图,大多数公司都开始转向线下。原有的流程、模式当然想要复用,但是这л时候复用的成本很可能比重新开发还要高。

眼睁睁看着竞争对手们甩掉包袱,轻装上阵,以更低的成本更短的时间攻城略地,挤压自己的生存空间。

这时候怎么办呢?

大多数公司给出的方案是成立新的业务部门,在新趋势新阵地冲锋⊙陷阵。新部门肯定也要用到原来公司的老服务,又碰到了我们的老问题:跨部门合作,新部门的成功并不会让老部门多得到多少好处,配合自然不会太积极。

如果新部门的尝试获得了初步成功,得到了公司资源的倾斜,获⊙得了有效的人力资源补充。之后又会带来新一轮重复造轮子,互相不合作,互相撕逼的腥风血雨。

——简直是一个轮回。

三、结语

经常有小伙伴说,国内某公司中台非常好,大家都在学。

嗯,我倒是想问问了,如果真的做的好,某公司旗下的金融公司和电商公司还会需要两套完全一样的基础架构,和好г几朵云?

作为一个技术人员,在各种乌七八糟、花里胡哨的概念“轰炸”下,应该能够保持理智,不要被各种人带节奏。

最后,把曹大博客的slogan分享给大家:

If you don’t k⿲eep moving, you’ll quickl*y fall behind.

第一次读到的时候,振聋发聩,和大家共勉!

 

作者:曹春晖;公众号:码农桃花源(ID:CoderPark)

来源:https://mp.weixin.qq.com/s/OSTMAMal_XLV0feMERamBA

本文由 @码农桃花源 授权发布于人人都是产品№经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

  • 速途研究院:六成网友表示...

    “某快餐品牌的六翅怪鸡你还敢吃吗?”“我们支持贩卖儿童判死刑”“急!高考准考证丢失请联系此号码”……这些谣言正在无时无刻地侵蚀着网络空间。速途研 究院近日发布的《2015年上半年网络谣言调查报告》显示,有六成网友表示参与过谣言的转发分享。尽管其中有21%的人表示坚决抵制网络谣言,但真正举报 过谣言的人却仅占到了7.4%。 近半人“...

  • Google:2016年...

    在谷歌最新发布的安卓系统使用率月度报告中,该报告显示安卓不同版本的用户使用率情况,在本月的报告中Android 6.0 Marshmallow成为了唯一的用户使用率增长的安卓版本。统计数据来自为期一周(4月25日-5月2日)的谷歌Play商城用户的数据统 计,Froyo 2.2版本之前的系统并不被计入统计。安卓6.0 Marshmall...

  • 【怎样做好网络营销】网页...

        虽然SEO规矩不断在改变,技能发展和查找引擎优化肯定是严密相关的,可是有些底子的东西一向没有改变,例如进步网站加载速度,添加用户体会,这些是北京SEO公司一向特别注意的问题,也是北京SEO公司以为最根底的问题。         网页缓存...

  • 网站关键词布局有哪些策略

        这里是获客学社,每天与你分享获客之道,让获客更简单做SEO优化的各位,是否经常都在为关键词布局而烦恼?相信刚接触SEO的应该都遇到这种情况。其实很多SEO都是以自己的主观思想来选择关键词,也不重视关键词分析,要么是选择的都是广泛的、竞争力大的关键词,所以,后导致网站出现这样的问题。   ...

  • 全家出游都靠它!盘点4款...

    春天是踏青赏花的好时节,体验大自然美景的同时,也是促进家人感情的好时机,如此时刻怎么能缺少一台续航能力强的拍照手机? 1、华为Mate10 Pro 华为Mate10 Pro是打破了以往商务机的拘束感,采用考究的四曲面玻璃设计,让光影在机身流转变幻,给18:9修长的机身带来流光溢彩的美感。   配置方面,华为Mate 10 Pro搭载麒麟970芯片,具备IP67防溅抗水等级,共有宝...

  • SensorTower:...

    Sensor Tower 商店情报数据显示,短视频社交平台 抖音及其海外版TikTok 在刚刚过去的第一季度新增用户量达到1.88亿,较2018年第一季度1.1亿的新增用户数增长70%。 实现快速增长的主要动力来自印度市场,上季度首次安装TikTok的印度用户预估达到8860万人,是去年同期的8.2倍,其中99%的安装量来自Google...

  • RESTful API ...

    网络应用程序,分为前端和后端两个部分。当前的发展趋势,就是前端设备层出不穷(手机、平板、桌面电脑、其他专用设备......)。 ...

  • 微软将数据保存在玻璃中 ...

    微软研究团队正在进行Project Silica二氧化硅项目,将信息编码在一块超强的玻璃上,为了证明它的有效性,他们在玻璃上存储了一部经典电影。微软与华纳兄弟公司合作,在玻璃上存储了“超人”电影拷贝,并且很重要的是,成功地读取数据。这部 1978年电影保存在一块75 x 75 x 2mm的石英玻璃上。微软认为,随着世界数据量增长,档案存储成为一个大问题。现有系统,无论它们是依靠磁带,固态驱动器还是...

  • 德勤咨询:2016年境外...

    报告下载:添加199IT官方微信【i199it】,回复关键词【2016年境外TMT标杆企业高管薪酬与激励调研报告】即可 TMT(Technology, Media, Telecom)是指以信息技术为基础,以互联网科技、新媒体和通信为代表的新兴产业。伴随国内经济结构转型步伐加快,以TMT产业为代表的“新经济”及其引领的创新力量无疑迎来了更广...

  • 中国铁路发布12306积...

      【环球网科技综合报道】3月1日,中国铁路在其官方微博发布《真的能省钱!积分换火车票攻略来了》文章表示:“真的能省钱,千万别错过!” 资料图   文中特别提示:1.积分在会员本人实际乘车到站后5日内自动进入会员本人账户,不能转让。2.积分自进入账户当日起连续12个月有效,在有效期内可进行兑换,到期未兑换积分自动作废。3.会...

  • 百度seo:带你了解百度...

      大家都知道百度又要推出新的算法了,seo又将迎来场新的变革,那么新出的细雨算法都有什么呢,百度seo的小编来和大家起来了解下,说说百度新出的细雨算法都有什么,有哪些需要各位站长注意的,下面随百度seo的小编起来看下吧!!   “为保证搜索用户体验,促进供求黄页类B2B站点生态健康发展,百度搜索将于7月中旬推...

  • SEO外链建设的新趋势

      当下做SEO链接,怎么做效果好?答案是需求型链接传递权重效果好。什么是需求型链接。以百度百科为例:咱们看到,百科句子里加了许多锚链接,这些链接让用户在阅览时,如对某个词不明白或不了解时,他能够点击链接进入到这个词的专门解说页面。这种咱们叫需求型链接中的解说型链接。       链...