搜索 | 会员  
大型科技企业架构:中台模式的爱与恨
来源: 博客园   作者:buptzym  日期:2019-3-21  类别:架构设计  主题:架构设计  编辑:Kennedy
大型企业面对快速变化的市场形势,需要有像创业公司一样快速的反应能力。然而由于复杂的人员和层级关系,大企业做到“拥抱变化”是很困难的。传统以职能部门分治的树状组织架构,若一个底层员工

大型企业面对快速变化的市场形势,需要有像创业公司一样快速的反应能力。然而由于复杂的人员和层级关系,大企业做到“拥抱变化”是很困难的。传统以职能部门分治的树状组织架构,若一个底层员工有个好点子,就不得不自下而上说服管理层,管理层还需发动行政力量推动层层下属,任何一环出了问题就难以进行,其难度可想而知。而各业务线各自有KPI,互相协作非常困难。

(传统的组织架构)

即使说服老大,克服重重困难,从各部门抽调和招兵买马,成立了新的业务部门。然而市场变化非常快,一旦业务受阻,方向转换,花费巨大精力组成的业务线何去何从?此时部门的发展极大地依赖于老大的决策,底层活力不足。

大型组织想出各种方式解决这样的问题,例如阿里在2016年提出了“大中台小前台”的战略,将业务共同的工具和技术予以沉淀,成立专门的中台部门。这样新的项目可以重用中台服务而不用重新设计,避免重复功能建设和维护带来的浪费和山头林立。这样做的不只是企业,美军更是设计了新的战斗方式,每3人一个小组,战斗需要时可随时调集后方火力,信息和后勤支援,灵活而成本低廉。

程序员对这些概念更是熟悉,中台类比到编程领域,就是形成可复用的函数库,抽象共性,减少重复开发,提升迭代效率。中台将人力,技术和服务重新组织,例如,数据中台维护底层数据能力,内容中台将各类资讯汇总整理,供给各业务线丰富的资讯资源;推荐营销中台抽象推荐系统的共性,为各种业务提供营销的快速接入能力。这样也方便统一协调,如数据中台可根据业务优先级管理流量和负载分配,这在各部门独立运营时是不可想象的。当然,中台还有一大好处:分担风险,方便分黑锅,你懂的。

当然,不是所有公司都能实现中台战略,中台要求扁平化的管理模式,没有太多的条条框框。灵活的考勤,没有隔板的工位,统一的基础设施(如数据库和代码库),否则中台就是空中楼阁,实施起来甚为困难。

中台模式的困扰

如果中台模式全部都是好处,这篇文章就应该结束了。中台相比于传统模式虽有优势,但实践和理论的隔阂必然存在。中台该做不该做什么,如何与业务方良好协同,如何评估KPI都成了难题。

我们可以根据中台对业务方的参与度,绘制成下面的一张图。

轴的最左边:仅提供工具库和少量答疑维护,不对业务效果负责。绝大多数开源项目,各种数据库,都可以归于这种极端。
轴的最右边:all-in参与业务方的大部分流程,从运营业务,到数据模型,事无巨细。我们戏称其为“高级外包”。

我们形象地称其为左倾和右倾问题。

越往左走,工具抽象和通用能力强,赋能业务多,雨露均沾,研发人员能专注于技术本身。但越往左越好么?不一定。越左就无法深入业务场景,无法接受业务滋养,很可能故步自封,甚至为了技术而技术,变得学究派,而过于独立的中台变成了纯后台,更重要的是,如何评估业务产出?

在最右面则是另一种极端,其优点非常明显:此时中台完全融入业务,有完整的业务sense,非常理解并能快速应对需求,与业务方打成一片,戏称为“高级外包”。但是,该模式的人力一般只能覆盖单一业务,很难对外辐射。由于精力所限,技术人员过分关注业务,中台的技术深度就会相对较差。

我们要同时警惕这两种极端,但从整体来看,最容易被忽视的反而是右倾。右倾构建了看似美好的中台合作模式,亲密无间的服务,但是人们很容易忽略其问题:由于过分具象和强耦合,中台能力难以沉淀在通用的工具和理论上,当出现其他相关业务时,原有产品并不能支持,应对变化的能力小,一旦业务方向变化就可能前功尽弃。

此时由于中台容量有限,过重的服务模式导致只能覆盖有限的业务。中台不得不评估前台项目的重要程度,甚至拒绝为低优先级的前台提供支持,挑肥拣瘦。那么前台可能会为自己的业绩考虑去自行组团队完成项目,进而导致中台与前台隔阂。相反的,若事无巨细地参与到业务方,侵入性就会很强,人的问题会成为最大的问题:它可能会架空业务方人员,引起猜疑,甚至可能被并入业务方,导致中台骨干流失。

那什么才是合理的中台模式呢?

合理的中台

最好的服务应该像空气一样,不留意就感受不到存在,但不可或缺。

首先,中台必须有对应领域过硬的能力积累,例如算法中台需要有扎实的理论基础,搜索中台在搜索能力的积累更是要达到业务方远达不到的程度。打铁还需自身硬,否则被革命掉只是时间问题。

中台一方面提供服务,另一方面则促进人和人的交流,推动换位思考。原本不同方向的人为了共同的任务在一起工作,能够迅速地学习对方的能力。当任务告一段落后,我们需要关注:业务方是否能维护,改进甚至优化中台的工作和技术;中台是否能产生对业务的通盘理解和技术沉淀。因此,在合作刚开始时,可适当右倾,中台快速熟悉业务,建立共识;随着业务深入,业务方吸收消化,中台逐渐后撤,直到业务方可自行处理大部分问题。

一般来说,在提供相同服务质量的前提下,对业务问题的抽象能力越好,参与度就能越往左。 例如SQL确实是非常伟大的发明,它将数据处理的需求抽象地如此淋漓尽致,技术人员能够专精于性能优化,业务方能灵活操作数据库,完成业务任务。

因此,中台有个重要命题应当考虑:自己的服务和技术应该如何合理抽象,将业务和底层尽可能隔离开来?这套领域特定语言(DSL)应该如何设计,才能让业务方也能看得懂,用得好?  Tensorflow和Keras这类深度学习框架成功的一大部分原因,就是设计了非常良好的深度学习原语。越好的抽象和领域原语,就越能发挥前台人员的业务优势和主观能动性,极大地提升了沟通效率。

同样,业务方也必须能把自己面临的问题予以清晰地描述,参数,环境和目标至少能明白地写在一张纸上。提出模糊的,太过抽象的(比如不管用什么方式,只要能提升KPI),甚至不切实际的目标,就是业务方的懒政和甩锅,中台不是高级外包。在任务层面上,两边应有清晰的分界和明确的问题,大家都精力有限,应做好分内之事。

在沟通上,不仅需要主管之间的密切配合,建立紧密沟通机制,如定期参与前端的业务周会;同时还应有清晰的接口人机制。笔者见过不少例子:多个接口人导致信息冗杂,传播不畅,有时不得不十几个人开大会,导致反复沟通,效率很低。接口人需要明确业务问题,熟悉数据链路,沟通能力强,方能事半功倍。



结语

一切事业都需要由人来推动,大部分问题都是人的问题。组织形式的不同,会导致信息传递效率的极大不同,进而影响事业的成败。“组织架构排名第二的公司,最后在市场上也只能居于老二的位置。”

本文只是笔者作为某大型公司的基层中台工程师,面对业务合作中遇到问题的一些思考,由于视角限制,肯定有以偏概全甚至偏激之处,还请各位读者老爷海涵。为什么要写这篇文章?因为研究如何利用零和博弈,组织一帮聪明人,高效地为了同一个目标奋斗是非常有意思的,组织架构的设计很值得思考。当然由于篇幅所限,还有很多问题没有讨论,比如如何考核中台绩效?

拿着 5000 块的工资,操着 5000 亿富豪的心呐。


德仔网尊重行业规范,每篇文章都注明有明确的作者和来源;德仔网的原创文章,请转载时务必注明文章作者和来源:德仔网;
头条那些事
大家在关注
我们的推荐
也许感兴趣的
干货
了解一下吧