不做中台,那就等着死吗?!

王晔倞 2019-08-02 10:40:15
在技术圈,每年总有那么一拨人,喜欢把 “某某岗位要不要写代码” 这样的话题拿出来讨论一番。

 

比如,前年的话题是CTO要不要写代码,去年的话题是架构师要不要写代码,今年的话题是技术总监要不要写代码……按这逻辑,明年的话题是不是要讨论工程师要不要写代码?

 

说实话,我并不喜欢讨论这类话题,因为每家公司的客观环境与人文价值观都不相同,聊这些,除了引发争吵,不会从中得到更多。

 

相比之下,我更愿意参与一些技术话题的讨论,因为大家面对的场景相似,采用的技术也相似,这样能更容易产生共鸣,更容易擦出 “爱” 的火花。

 

就在刚过去的半年里,「中台」成了技术圈内讨论的热门词汇,就连一些名不见经传的小公司,也都纷纷喊出了「要向中台转型!」的口号,甚至有人说「不做中台,那就等着死吧!」

 

如果我没有记错,「中台」思想源自于2015年,马云参观一个著名的游戏公司Supercell之后提出了这个概念,简言之就是“小前台、大中台”,随即阿里就成立中台事业群,并取得了很好的成效。随后,美团点评也开始走中台策略,腾讯在去年的组织架构调整中,也提出建设具有 “腾讯特色的技术中台”。

 

一、技术中台的作用是什么

 

要搞明白这点,你需要先搞清楚「技术前台」、「技术中台」与 「技术后台」 之间的关系,以及他们各自扮演的角色与作用。

 

先来说说我们的「技术前台」。

 

「技术前台」,说白了就是为业务部门开发功能的技术团队,如果是ToC的业务,交付物必须贴近终端用户,如果是ToB的业务,交付物需要满足商家的需求。脑海中必须时刻牢记 “小步快跑,快速试错” 的理念,业务说啥,就是啥,业务要怎么做,你就怎么做。

 

另外,研发资源的投入基本和业务对等,业务需求多,人数增加,业务需求少,人数相应减少,而且团队组织也基本按功能线来划分。

 

 

运用的技术栈也相对单一,以Java语言为例,通常 “1个NG + 1个War/N个Jar + 1个数据库” 就搞定了,而其余的技术服务都将由「技术中台」提供。

 

 

「技术前台」的核心价值体现在对业务逻辑的理解与实现上,是技术向业务传递价值的阶梯。

 

我觉得在这点上,与线下销售团队的前台营销有一些类似。

 

再来说说我们的「技术中台」。

 

「技术中台」,说白了就是强调资源整合、能力沉淀的平台体系,当「技术前台」实现业务功能时,为他们提供底层的技术、数据等资源和能力的支持。

 

这怎么理解?

 

 

从这张图中可以看到,「技术中台」有点像编程时的适配层,起到承上启下的作用,将整个公司的技术能力与业务能力分离,并以产品化方式向前台提供技术赋能,形成强力支撑。

 

二、什么情况下有必要做技术中台

 

俗话说 “知己知彼,百战不殆”,在我看来,面对技术问题时,“知己” 比 “知彼” 更为重要。

 

在实施「技术中台」之前,我们是否要静下心来对自己进行 “灵魂拷问”?比如说,当前的时机是否已经成熟?或者怎么才叫成熟?

 

在我看来,要想做「技术中台」,客观环境需先满足两个前提:技术组织结构垂直化、业务线又多又复杂。

 

否则,「技术中台」的结果只会是两种:一场闹剧或者一笔赔钱的买卖。

 

1、技术组织结构垂直化
 

 

曾经有朋友说过,每家公司的组织结构演进都是一部心酸血泪史。我很费解,问为什么?

 

他说,因为这中间掺杂着太多的主观判断与情感纠葛。

 

比如,某员工认为公司管理混乱,组织架构来回调整,今天拆这个团队,明天合那个团队,纯属病急乱投医,高管都是些横行霸道,滥用资源的傻逼货,借机搞人,这公司,没救了。但高管们大呼冤枉,觉得组织架构调整的目的是为了提高产出和人效,如果你干得不爽可以离开,这种事情,本来就不可能让每个人都满意,既得利益者肯定大加赞赏,而失去利益者肯定狂喷不止,不用理会。

 

的确,这种 “自我革命式” 的调整,基本不可能一步到位,需要一个过程慢慢演化,而在这个过程里,自然会遭遇很多的阻力或质疑。

 

 

瞧瞧这结构,经典的职能分工模式,有什么问题吗?我不但说不出问题,甚至能找出一万个理由说明这种模式的好处。开发按业务线分开,测试与运维形成上下层关系,谁也不想管对方,两边的老大也是评级的,相安无事。

 

那什么情况下才会觉得这种模式有问题呢?

 

客观的说,职能分工模式更适合瀑布式开发模式。先谈需求,再谈工期,随后按部就班地往下做,但当用户的需求开始变的多种多样,业务方时不时的就要上一个新功能,做一个新系统的时候,你会发现开发出来的系统很难变更,至少很难快速变更。

 

于是,你把开发按系统功能进行重组,每个团队都围绕 “交付速度” 开展工作,但这样又遇到了两个新的问题:

 

  • 多种多样的中间件,每个团队独立选型中间件,没有统一的维护,没有统一的知识积累,无法统一保障SLA;

  • 开发与测试、运维之间目标不一致(比如测试A君,开发要求你只做功能测试,快上线,但测试老大却要求你做非功能测试,保障质量,避免背锅……到底听谁的?),陷入永无休止的扯皮与争吵。

     

 

面对这两个新的问题,我们做出了调整:

 

  • 成立平台架构组,负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护;

  • 把质量管理部中的测试团队,与系统运维部中的应用运维团队,按照系统功能拆分至各开发团队,由原开发经理负责,形成各自独立的Feature Team。

     

 

 

到这个时候,虽然整个组织结构还未完全实现垂直化分工,但已基本能够达到 “快速试错,小步快跑” 的目标。

 

另外,这更像平台化的另一种雏形,就是逐渐把一些公共、底层的技术能力抽象出来,与业务逻辑分离,并形成各种接入式基础服务,同时可以为多个业务线提供服务。

 

也就是说,打造「技术中台」的前提是平台化,而平台化的先决条件是「组织结构垂直化,技术工具公共化」。

 

如果没有这样的前提,就失去了打造「技术中台」的立身之基。

 

2、业务线又多又复杂
 

 

曾经有朋友问我,技术的核心价值是什么?我的答案是 “改变世界”。

 

他说,别扯淡,好好说话。

 

他说,对业务驱动型的公司来说,技术的核心价值是 “降低成本,提升效率”,而单从架构设计的角度来看,想达成这项目标的两个手段是「通用性」与「复用性」。

 

现在想想,这句话可以完美的衔接到「技术中台」上去。

 

回顾几年前,我们的业务逻辑也曾非常单一,要么用你的银行卡买卖基金,要么用你的电子钱包买卖基金,方便,快捷。

 

 

渐渐地,随着业务创新业务增多,需要前后台系统定制开发,逻辑兼容难度增加。

 

 

在这样的局势下,为满足企业规模扩大和多样化经营对组织机构的要求,公司开始转向事业部制,按产品、地区或市场(顾客) 划分经营单位。

 

 

为了应对业务方的这次调整,我们开始将业务开发中的一些共享服务分离出来,成立了业务中台组(由于本文以技术中台为主,业务中台的内容将不进行展开说明),将可以复用的服务和代码,交由这几个组开发出服务来,给业务组使用,这样数据模型会统一,业务开发的时候,首先先看看有哪些现成的服务可以使用,不用全部从零开发,也会提高开发效率。

 

与「业务中台」相呼应,「技术中台」就像一个工具大仓库,里面放满了各式各样的技术工具,无论是哪个团队,哪个人,快速找到自己的工具,拿来就用就行了。

 

而维护工具的这群人,不用贴近业务开发,每天的任务就是研究如何使用这些工具,如何调优,遇到问题如何Debug,形成知识积累。有了这么一群专职的人,就可以根据自身的情况,选择有限几个技术栈集中研究,限定业务组只使用这些工具,可保证选型的一致性。

 

如果你只有一条业务线,那就别搞「技术中台」了,把人凑在一堆,又省钱,又省力。

 

三、有了技术中台,是不是就能上天

 

理论上讲,当业务线变多且越来越复杂,前台与后台之间的“技术债”会随之变多,重复造轮子与沟通成本太高的现象会增多,通过技术中台可以一定程度上来解决这个问题。

 

这种理论看似完美,但在实际执行上却困难重重。

 

设想下,如果「技术中台」做得太多,资源投入就会很大,无法形成正向的利益传导,如果「技术中台」做得太少,又无法深入理解业务,导致适配方案落地性变差,渐渐失去价值。

 

这句话怎么理解?

 

十年前,我在某金融软件公司工作,随着客户数的增多,成本与效率/质量的矛盾日益凸显。

 

设想下,从一波人维护一套代码,渐渐变成一波人维护几套代码,这样一来,Bug增多,效率下降,抱怨也随之变多,再加上甲方挖人,最后人员离职,团队土崩瓦解,Game Over……

 

在这种情况下,一般公司会采取三种应对措施:

 

  • 一对一服务 - 项目制:多个团队,多套代码,多套标准,服务多家客户,但这样一来成本又难以承受,时间一长,肯定资不抵债;

  • 一对多服务 - 标准化:一个团队,一套代码,一套标准,服务多家客户,但客户不买账,客户说我的需求都是个性化的,你别来某某标准来引导我,叫你咋做,你就咋做,不愿意?那您走,我找别人家做;

  • 一对多服务 - 产品化:一个团队,一套代码,多套标准,服务多家客户,通过技术与配置化的手段,利用SOA思想,打造自己的产品化平台,但对技术投入要求较高,尤其是核心人才的依赖较大,中小型企业一般都很难留住这些人,只要他们一走,公司基本完蛋。

     

 

回想下,当年那些叱诧风云的软件公司,又有几家活下来了?以金融业为例,恒生算是在第二条路上走的比较成功的,而我们当年却死在了第三条路上。

 

在我看来,我们的「技术中台」就是一家 “乙方服务公司”,而我们的「技术前台」更像是一家 “甲方电商公司”。

 

不可否认,有了这家 “乙方服务公司” 之后,在面对大型项目及快速多变的业务时,技术的投入与主动权更强了,但由于理念、职责、节奏与使命不同,外加 “屁股决定脑袋” 的立场,前台与中台之间很容易引发矛盾。

 

从职责角度来说,前台是 “快速应对业务变化”,中台是 “稳定高效提供服务”。

 

一个追求效率,一个追求质量,这矛盾是天然存在的。

 

怎么理解?我来举个小例子说明下。

 

前台部门的A团队和B团队,由于业务需要同时向「技术中台」提出要接入缓存服务的需求,「技术中台」的中间件产品线中有一套基于Proxy的自研分布式缓存系统,已在其他业务线运行多年,但由于A团队与B团队的技术债都各不相同,必须通过增加适配器才能完成接入,而此时人手又不够,按重要程度排序,只能先接A团队,但B团队也有需求,又等不及,怎么办呢?就先给他来个Redis接着玩玩吧,等A团队接好了再来接你的。

 

一个月后,等A团队接完了,找到B团队,这时痛点已不存在,团队的激情自然不高,毕竟没有收益,就不了了之了。

 

几个月后,安全团队提出要对Redis集群进行改密,由于A团队接入的是「技术中台」的缓存中间件产品,采用代理模式,并通过控制台操作,既方便,又快捷,找个晚上,5分钟内,全部搞定。

 

但B团队用的是直连Redis的模式,密码嵌入在SDK中,不仅在改密过程中需要前台与中台联动,而且还需要在改密后重启应用服务,这样一来,只有配合应用发布的周期才能干这件事。

 

最终,原本五分钟可以搞定的事,整整搞了三周才搞定,「技术中台」的运维同学更是陪熬了多次通宵,还因为人为疏忽引发了一次事故。

 

就在这件事过去的一年时间里,由于B团队系统的业务规模逐渐增大,Redis数量也逐渐增多,「技术中台」的运维成本与风险也随之上涨。

 

这期间,中台曾多次与前台交涉,希望能够通过适配的方式将A团队接入缓存中间件,但始终未能达成。

 

在「技术中台」看来,“你们只顾自己,不管别人,功劳你们拿,黑锅我们背?”

 

在「技术前台」看来,“你TM懂个屁!我们都快被业务逼疯了,你们不就多费点人工吗?多加点班会死吗?总扯一些理念干嘛?对你没收益的事,你干嘛?”

 

因为这样的分工模式,导致这种矛盾在工作中很多,而且似乎并没有更好的方法彻底解决。

 

有人说,要解决很简单,要么强压,要么加大投入,下下狠心就得了。

 

先来说说强压,似乎能够在短时间内达到目的,但纯属 “杀敌一千自损八百” 的招数,难道要业务研发团队停下手上的活,倾巢而出一起搞技术改造吗?更何况,前台承受的压力,是中后台团队无法想象的。

 

退一步说,抛开 “互相理解” 这个话题,强压的套路等同于 “攻城为上,攻心为下”,对今后的管理与团队氛围都会带来诸多的麻烦。

 

再来说说加大投入,看看我上面提到的 “死在路上的软件公司们”,还想加大中后台的投入吗?

 

如果你不是大厂,还是算了吧。

 

那句话怎么说来着?最悲惨的结局是,你的技术中后台越发强大,但你的业务规模却在逐渐萎缩。

 

可悲,可叹。

 

在互联网时代,技术圈似乎从来不缺少热议话题,但有质量,有深度,且能解决实际问题的却少之又少。

 

现在人人都在讨论「中台」,今天「产品中台」,明天「数据中台」,这个说能提高效率,那个说能排除万难,聊得不亦乐乎。

 

对于企业来说,话题热不热并不重点,方案牛不牛逼也不重要,关键是能帮助用户找到效率、质量与成本的平衡点,或许才算是一个合格的「技术中台」。

 

 

 

作者:王晔倞

来源:吃草的罗汉订阅号(ID:kidd_wyl)

dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

活动预告