中台亡了,问题到底出在哪里?

曾几何时 , 中台一度被当做“变革灵药” , 嫁接在“前台作战单元”和“后台资源部门”之间 , 实现企业各业务线的“打通”和全域业务能力集成,提高开发和服务效率 。但在中台如火如荼之际 , 我们可以发现各大企业又在反其道而行,纷纷不断进行“拆中台”,那么中台对于企业而言,究竟发挥了哪些作用,当前又出现了哪些问题?今天,我们特邀了高级研发管理专家、腾讯云 TVP 程超老师 , 他将从搭中台到拆中台的风向转变,探讨企业软件架构的底层逻辑 。
【中台亡了,问题到底出在哪里?】目录
一、四大层面解读中台备受追捧原因
二、拆分中台并非全盘否定中台
三、企业应该因地制宜选择是否需要中台
中台都在忽悠吗?都被忽悠瘸了?我们都在悄悄淘汰中台,你们还在建?最近网上充斥大量文章和观点,都在说中台过时 。为什么会这样说?是因为成本与复杂性?技术限制与业务变化?还是因为组织变化?为什么会这样呢?且听我一一分析 。
众所周知,中台是指企业内部的中间层平台,负责连接上下游系统,提供数据和功能服务 。而在过去几年中台概念曾经风靡一时,甚至被认为是企业数字化转型的关键 。然而,近年来,一些企业确实出现了对中台战略的重新评估,不再像之前那样盲目地追求中台建设 。
其实,中台的概念兴起于企业数字化转型的浪潮中,企业开始意识到传统的前台系统(如客户端应用)与后台系统(如企业资源规划系统)之间的断层,而中台则被认为是弥合这种断层的理想方式 。
值得一提的是,关于中台的定义,业内大佬也曾经发表过一些观点:
提炼各个业务条线的共性需求,并将这些打造成组件化的资源/能力包,然后以接口的形式提供给前台各业务部门使用,这样就可以最大限度地避免“重复造轮子”的问题 , 也让每一个新的前台业务创新能够真正意义上“站在巨人的肩膀上”,而不用每次开辟一个新业务都像新建一家创业公司那么艰难 , 甚或更为艰难 。
——某企业资深架构师 钟华

中台亡了,问题到底出在哪里?

文章插图
总结而言 , 中台的核心点主要有以下三个:
  • 中台是为前台而生 。
  • 提炼各业务条线的共性需求 。
  • 减少“重复造轮子”的时间与资源浪费 。
一、四大层面解读中台备受追捧原因
2015年,业界首次提出“大中台、小前台”战略 , 是想打造统一技术架构、产品支撑体系、数据共享平台、安全体系等等,把整个组织“横”过来 , 支撑多种多样的业务形态 。中台似乎已经成为行业标配 , 稍有规模的公司都建设了自己的中台 , 掀起了一股强劲的中台风 。
中台能够解决哪些问题呢?在我看来,主要有以下四种:
  • 项目重复造轮子严重,无法形成抽象共用
中台提供了一种在企业内部建立统一的技术平台或者服务平台的模式 。这个平台可以被不同部门或者项目共享和复用,从而减少了重复开发的情况 。随着新业务的不断接入,共享服务也从仅能提供单一的业务功能,不断的自我进化成更健壮更强大的服务,不断适应各种业务线的新需求 。同时在数据积累方面,通过数据中台将各业务的数据都沉淀下来,不断地积累数据,发挥数据的最大威力 。
  • 业务变化快,缓慢的研发流程难以迅速响应
很多企业开发响应慢,其实大部分都是因为数据问题,没有做到实时、准确和统一 。比如一家公司的订单 , 分为 C 端订单,B 端订单,共享单车订单等等,这些订单分管在不同部门中,想要做订单统计、预测等就比较困难,各类型订单彼此割裂,而如果企业只有一个订单中心的话 , 数据就能够在不同场景下感知到业务的变化和联动 。
  • 提高资源利用率和研发效率

中台亡了,问题到底出在哪里?

文章插图
说起如何提高资源利用率和研发效率 , 我总结为中台建设五步法:插件化、服务化、配置化、异步化和数据化 。这五步环环相扣,其中插件化就是提高研发效率的关键点,我们将对核心交易流程进行抽象建模设计,并通过流程引擎的改造,实现增加多个插件和扩展点 。这样 , 不同的业务场景可以根据需求自定义其个性化逻辑 , 将整个交易环节抽象为一个流程框架,并在其基础上引入一系列业务扩展 。这种设计使得各业务间互不干扰,更灵活地满足各自需求 。


推荐阅读