说透中台上 中台的概念和种类

102 篇文章 10 订阅

开篇词 | 中台,昙花一现还是下一个风口?

讲述:王健

你好,我是王健,是 ThoughtWorks 的首席咨询师,目前专注在企业架构和解决方案的相关方向上。因为近几年沉迷中台无法自拔,同事朋友们也给我起了个花名,叫“台长”,如果你乐意也可以这么叫我,很高兴能在这个专栏与你见面。

我与中台

与中台的第一次邂逅是在 2017 年,当时作为首席咨询师和系统架构师第一次实际参与到了一个大型企业的中台规划和落地项目中。作为一个已经在行业里摸爬滚打了 10 多年的老鸟,并且无论是在分布式系统架构、微服务架构、平台化建设方面都也有了非常多年的经验和积累,面对“中台”这样一个当时在我看来不过是新瓶装旧酒的概念,坦白来讲,一开始我并没有把它放在眼里。

但结果就是被啪啪打脸。整个过程推进得非常困难,从头到尾无论是我对于中台的理解还是我们规划与建设的方法都受到了客户不断的质疑和挑战,项目的范围无论从系统的层面还是从组织的层面也被扩大到几近失控。

但也就是这次过程,才让我开始意识到,中台这个概念跟我之前想象的可能完全不是同一个物种。也自此,我对中台产生了浓厚的兴趣,日思夜想,遍访高人,并将所学所思所想落笔成文,期望与更多人一起探讨。

截止目前,我主导或参与过的中台相关项目大大小小也有 10 多个了,很多疑问和困扰也在这个不断学习、思考与实践的过程中一一解开。同时今年也开始与公司和社区的小伙伴们一起,尝试沉淀一套通用的中台规划与建设方法,来帮助更多企业在中台的规划与建设过程中,少走一些我们走过的弯路。

关于专栏

虽然我对于中台非常痴迷,但当极客时间约我做中台的专栏时,我的心情还是非常复杂的。

首先肯定是非常开心,因为很希望能借助这样一个平台将自己的所想所得分享给更多的人,并且更希望能听到你的观点,你的意见和你对于中台有哪些问题。我们一起努力将这个概念或是工具理解得更加透彻,并最终利用它帮助我们解决实际的问题。

但同时也有一些惶恐,因为中台这个概念不像其他的技术那样成熟和清晰。业界对于这个概念本身也仍然没有一个统一的认识。我相信,这也是今天中台被大家热议的一个原因吧,大家都在关注,但是又很难讲清楚。

还有中台这个概念,无论是从涉及领域的宽度还是从战略到落地的纵深高度来讲,都是非常非常大的,向上可以触及到行业趋势、企业使命愿景战略,向下又可以落地到分布式架构、遗留系统重构、架构演进与守护、质量保证等等各个方面。而且就算是同一个行业,每家企业还都不一样。

想要通过一个专栏,既要把概念讲清楚,又不飘在天上,还可以指导和帮助大家将中台落地,在我看来这几乎是一个不可能完成的任务。

但幸运的是,在极客时间同学专业的支持,以及不断激(催)励(稿)下,经过不断的打磨,这个专栏最终还是跟你见面了,感谢的话留到最后再讲,我先来简单讲讲我是怎么设计这门课程的。

这门课是怎么设计的?

今年 IT 圈中台的概念确实比较火,你可能在朋友圈或是各个媒体渠道上天天都能看到跟中台相关的文章和资讯。

但是大家讲的很多都是各个企业中台建设的结果,一张大大的线框图,对企业带来了怎样怎样的好处。

但中台到底是什么?从哪里来?又会到哪里去?具体又该怎么建设?这几个最基本的问题,谈到的其实并不是特别多,鲜有谈到的观点还都不太一致。

如果再将问题进一步展开,你就会发现有更多的问题仍然模糊不清。你可以跟我一起想一想,以下这些问题你有过同样的疑问吗?

  • 中台与平台 / 微服务 /SaaS 的区别是什么?
  • 中台与前台和后台的边界怎么界定?有了中台那后台是什么?
  • 什么样的企业需要建中台,什么样的企业不需要建中台?对企业到底有哪些好处?
  • 业务中台与数据中台的关系和区别又是什么?
  • 中台建设有什么样的门槛,需要哪些准入条件?
  • 中台该怎么建?分几个阶段?需要什么样的能力?
  • 中台建设的结果好坏如何评估?谁来评估?
  • ……

相信这样的问题还有很多很多。这些问题也曾困扰着我,所以我希望能通过这个专栏,为你一一解答这些困惑,或者至少能给你带来一些启发。

在专栏的课程设计上,我的主要思路是分成三个部分:概念篇、落地篇和最后的答疑篇。

概念篇

在概念篇里,我首先会带你时光穿梭,重走一遍中台的诞生和发展之路,从时间的维度重新梳理一遍中台诞生的背景和几个关键点,看看它究竟从哪里来?之后会通过列举目前市面上常见的中台种类,在空间的维度同样发散,看一看各类五花八门的中台。最终通过收敛和归纳,一起来探究一下中台的本质,即当我们谈论中台时我们到底在谈些什么,给中台下个定义。

落地篇

在落地篇里,我会从概念引申到落地,看看为了避开中台建设过程中的各种坑,在开始中台建设前需要先想清楚哪些问题?需要有什么样的准入条件?中台建设方法论的本质是什么?想清楚了这些问题后,又有哪些方法和套路可以帮我们实现中台的平滑落地。

但是这里有一个前提需要提前声明一下,因为我们之前也提到了,中台的种类太多了,不同企业不同种类的中台,它们的建设方式可能完全不同,但是背后的思想都是相通的。

在落地篇里的后半部分,关于一个中台产品的设计与实施的内容,我会用一个最常见的业务中台建设场景来展开介绍,但是其中提到的方法和工具,对于其他的中台类型也同样适用。

答疑篇

这个专栏的答疑篇是我额外设计的一个小模块。因为中台涉及的范围之广、问题之多、复杂度之高,是很难在几次课程中就完全讲清楚的。我也非常希望在我们一起学习交流的过程中,你可以把对于中台或是我这门课程的问题提出来,我们随时在留言区进行沟通和讨论,同时我也会针对每个人都比较关心的问题,单独在答疑篇里有针对性地统一给你做一些解答。

最后,跟你分享我最近一直在想一个问题。中台到底会不会成为下一个云计算,彻底改变我们思考问题和做事情的方式,还是它只是另一个昙花一现的新概念而已?

老实说,我现在还不能确定。但是通过这两年对于中台的学习和研究,至少对于我来讲,确实受益良多,无论是在视野、产品、架构还是在技术层面上都有了一个质的变化,上了一个台阶。

相信通过你我一起的学习,在了解了中台背后所代表的趋势或是理念之后,无论中台最终是两者中的哪个一个,你也一定都会有所收获。

最后,感谢你的关注。你对中台有哪些了解?又有哪些困惑?你现在已经参与到一个具体的中台建设中了吗?遇到了什么挑战?收获了哪些经验?欢迎写在留言区,我也很想听到你对这门课的期待。

很希望和你在专栏里再次相遇。这次,我们一起来说透中台!

01 | 来龙去脉:中台为什么这么火?

你好,我是王健。

2019 年截至目前,如果说 IT 圈有哪些能称之为热点,那中台一定会占据一席之地,就好像一时间只要跟中台相关的企业或是新闻都会备受瞩目,什么事情如果不跟中台概念沾点儿边,就好似会落后于时代。

中台一时变成了众人关注的焦点之一。

但中台到底是什么?答案仍然扑朔迷离、模模糊糊,甚至还有不少人仍然在思考这个概念是否有其存在的意义,是否又是另一个被炒作的概念,只不过是昙花一现而已。

我整理了一下,2019 年截至目前,大半年的时间,不算看过的,光是我个人收藏的跟中台相关的文章就不下 300 篇。最近,为了这个课程,我又回看了一遍所有的内容,发现在每篇文章里每个作者对于中台都有着自己的角度和观点,直到现在业界仍然无法完全统一,还是众说纷纭,但可喜的是在很多方面的共识已经越来越多,中台这个概念也在慢慢褪去神秘色彩,走到你我面前。

而这也是我动心做这门课的原因,我近几年一直持续专职在做中台相关的工作,有幸作为架构师和产品经理的角色亲身参与到多家大规模集团型企业的中台落地建设项目中。所以希望能够借这个机会,将所见所学整理归纳,尽力为你还原一个中台的全景,帮你理解这个概念和趋势的本质。

我一直遵循着一个观点,想要搞清楚一个概念或是一门技术,就先要回到历史里,回到它诞生的时间,漫步一遍它发展的历程,去探究一下它产生的背景和原因。

正所谓要知其然知其所以然。

今天的内容作为这门课正篇的开篇,我想就带你回到 10 年前,回到中台诞生的起点,我们随着时间的脚步一起重新走一遍中台的诞生和发展之路,来看看中台究竟从哪里来,又将走向何处?

2008~2015 关键词:孕育

中台的兴起,是趋势使然。但中台这个概念,最早被大家关注,一定要算是阿里巴巴提出的中台战略。这不知道你有没有发现,有一个有意思的点,就是为什么我说中台最早被大家关注是因为阿里巴巴,而不直接说中台这个概念就创造于阿里巴巴呢?

既然我们这个专栏叫作“说透中台”,这里可以多说一点,对于中台这个词,很多人认为是阿里巴巴创造的。但截止目前,业界对这个问题还有一些不同的看法和意见,因为在银行里很早就有前台、中台、后台之分,而且有意思的是,阿里巴巴在 2019 年阿里云峰会上海站时,在介绍阿里巴巴双中台的时候,英文翻译也同样使用了银行里中台的翻译,也就是 Middle Office,但是这个概念是否与银行领域的中台概念相关,目前还没有得到任何阿里巴巴的官方信息可以佐证。

但对于你我来讲,中台这个词是阿里巴巴创造的,还是确实引用的是银行业已有概念,我认为,并不是那么的重要,我们可以将关注点更多地放在在 IT 的上下文下,这个概念究竟是什么,究竟又能帮我们些什么。

而对于阿里巴巴的中台战略,现在业界一般都认为是从 2015 年马云走访 Supercell 开始的。但是我通过关注阿里巴巴对外分享的信息,以及实际和多位阿里巴巴的同学了解之后,了解到这次走访的事件只能算是个引子,阿里巴巴的中台化进程,在这之前就已经开始了。所以,要想真正理解阿里巴巴中台产生的背景和原因,需要回到更早的时候,至少要回到 2008 年。

因为在 2008 年,随着阿里巴巴战略的调整,天猫顺势而生。但因为其相较于于淘宝,有其自身的特点,所以当时天猫和淘宝就出现了重复建设的问题,也就是现在大家经常提到的烟囱式系统架构。

烟囱式的系统架构,造成了大量的重复建设和资源浪费,怎么办呢?最自然的想法就是将重复的组织和系统进行整合。正因如此,阿里共享事业部正式诞生,负责将各个前台系统中的公共部分进行平台化改造,经历了一段痛苦的摸索之后,借聚划算爆发的契机,才真正奠定了阿里共享事业部的重要地位,埋下了阿里大中台战略的种子。

2015 关键词:阿里巴巴中台战略诞生

历史就像一列行驶在山脊间的列车,一切都在按照既定的方向不紧不慢地向前推进。

中台这个新物种也正在时间的推进中不断孕育,只在等待一个契机的到来。

2015 年,终于等来了这个契机。

接下来就是大家津津乐道的那个故事:在 2015 年,马云带领阿里众高管一起拜访了位于芬兰、号称是世界上最成功的移动游戏公司 Supercell。说起这家公司,你可能会觉得比较陌生,但是提到这个公司开发的游戏,相信你一定有所耳闻,《部落战争》《海岛奇兵》《卡通农场》等等知名的游戏都出于这家游戏公司之手。

但当时触动马云和阿里高管团队的是,催生了这么多火遍全球游戏的企业,却只有不到 200 名员工。而负责一款游戏的每个团队平均也只有 5 到 7 名团队成员。团队有充分的自由,他们可以自行决定开发什么样的产品,之后就会以最快的速度推出公测版,让市场来评判,来验证产品的好坏。一旦产品不成功,则迅速放弃,此时不但不会有任何惩罚,反而团队会举杯庆祝,之后立即做出调整继续迅速寻找新的方向。

嗯,是的,这就是典型的精益创业的套路。

但要想让这个机制得以正常运转,必须有一个前提,就是产品的构建时间要足够短,试错的成本要足够低,这样才能保证团队在大量的试错中,通过不断从失败中学习,持续迭代调整,尽快找到正确的方向,让创新成功的进度条快速前进。

而背后支撑这个机制得以实现的,就是 Supercell 经过 6 年时间沉淀下来的游戏开发过程中那些公共的、通用的游戏素材和算法。基于这些像乐高积木一样的基础素材和算法,才可以同时支持几个小团队在几周时间内像搭积木一样快速研发出一款新游戏。

这种方式触动了到访的阿里巴巴高管团队,这种理念与阿里巴巴及业界这么多年一直在尝试和构思的“厚平台,薄应用”架构方向不谋而合。就是这次拜访,坚定了阿里巴巴管理层对于组织架构调整的决心,也加速催化了阿里巴巴中台战略的正式诞生。

随后不久,在 2015 年 12 月 7 日,时任阿里巴巴集团 CEO 的张勇通过一封内部信说道:“今天起,我们全面启动阿里巴巴集团 2018 年中台战略,构建符合 DT 时代的更创新灵活的‘大中台、小前台’组织机制和业务机制。”

至此,阿里巴巴中台战略正式诞生,而之前的“厚平台,薄应用”也顺势变成了“大中台,小前台”。

但有意思的是,在 2015 年阿里巴巴中台战略刚刚被提出的时候,印象中并没有掀起多大的波澜。当时大家谈论的还是花千骨和《我的滑板鞋》,而互联网圈聊的更多的也是互联网 + 和 O2O。熟不知,一场新的战场已经开始孕育,种子已经种下。

2017 关键词:横空出世

随着 2015 年中台概念的诞生,经过了默默无声但暗流涌动的 2016 年,在 2017 年我们逐渐开始在社区里听到了越来越多关于中台的声音,阿里巴巴和滴滴出行不约而同地开始分享各自中台建设的经验,而与中台相关的书籍也出现在了市面上。

互联网大厂的集体发声,让中台这个概念时隔了两年之后又重新回到了大家的视野当中。

据我了解,很多企业无论是互联网大厂,还是一些比较有战略眼光的企业,也都是在这个时间点开始重新审视并重视这个已经出现苗头的新概念。

最早一批开始动手的企业大多也是在这个时间开始了自己的中台整体规划与建设,而我也是在那个时候开始与中台结缘,关注并研究中台,实际参与到一个个客户的实际中台项目中的。

但当时大家面对的问题和困难也很多,像阿里巴巴或是滴滴出行这类的企业,在分享中台的时候,更多的是以自己发展历程的角度和自己的问题出发。这也毋容置疑,但是大家回头来审视自己企业的中台建设时,每家的情况都不一样,每家的问题也不同,自己的中台到底应该是什么样子?怎么建设?这些问题很多都是在书中、在分享中找不到直接的答案,只能靠自己一点一点摸索。

至此,一些勇敢的先行者们就开始了各自的中台探索之旅,虽然这注定是一条布满荆棘的道路。

现在回头再看,有些当时的探索最终失败了,有些探索仍在继续。但无论如何,这些先行者们的探索和经验得失,为我们现在理解和建设中台扫清了很多障碍,没有这些探索和思考,也不会有现在的这些经验与共识。

2018 关键词:全面爆发

2018 年年中,中台蓄势已久,终于迎来了全面爆发。

这点我算是有亲身体验的。记得非常清楚,那应该是在 2018 年 9 月 9 日的中午,在同事们都趴在桌子上睡午觉的时候,我终于借午休的时间,把憋了 3 个多月才写完的一篇文章像往常一样发到公众号。这篇文章写的是自己这一年多来关于中台的一些思考,在我看来是篇再普通不过的文章。

之后发生的事情却远远超出了我的想象,我的文章一下午的时间被各种社区大号转发,阅读量迅速突破了一万、两万、三万、四万……这对于平时写文章最多只有几百阅读量的我来说,有点一时不知所措。那时的感觉就是所有的朋友、朋友的朋友、朋友的朋友的朋友,都在转发这篇中台的文章。

那也是我第一次感受到了中台的热度,它蓄势已久,终于迎来了属于自己的一次爆发。

但只有这一次大讨论,还不足够。随后发生的事,你也许也还记得。来,我带你一起快速回顾一下:

  • 2018 年 9 月 30 日,腾讯宣布了 7 年来最大规模的组织变革,新成立了云与智慧产业事业群(CSIG)。同时,腾讯新成立了技术委员会,宣布未来将打造技术中台。
  • 2018 年 11 月 26 日,阿里宣布进行组织升级,阿里云事业群升级为阿里云智能事业群,将中台智能化与阿里云全面结合。
  • 2018 年 12 月 21 日,京东集团人力资源部发布关于京东商城组织架构调整的公告,公告内容称:“在新的组织架构下,京东商城将围绕以客户为中心,划分为前中后台。中台为前台业务运营和创新提供专业能力的共享平台职能。”
  • ……

也正是这一波互联网大厂眼花缭乱的集体操作,纷纷为中台接力发声站台,才正式把中台推上了舞台,迎来了全面爆发。

2019 迷雾仍然存在

中台的热度经过 2018 年底的爆发,延续到 2019 年,并没有消退的迹象,反而越发高涨。

但爆发归爆发,不代表之前的问题都已经被解决,问题和困惑依然存在,丝毫没有因为概念的火爆而变得清晰,反而随着跟进的企业越来越多,问题不降反增,变得越来越多:

  • 中台与平台的区别到底是什么?
  • 中台到底有多少种?哪些是哪些不是?有建设顺序么?
  • 中台到底怎么建?从哪开始?怎么算结束?
  • 中台需要组织调整么?怎么调整?
  • 中台如何验证建设效果?
  • ……

而这些问题这几年也一直困扰着我。如今,经过了这么长时间的探索、研究以及向前辈们取经,我也有了一些自己的思考和总结。现在,我把这些内容分享给你,跟你一起探讨这些问题的答案,帮你在自己的中台建设中扫清一些障碍。

总结思考

今天,我带你回顾了中台的发展过程。最后,我们来看看是不是可以回答开篇的那个问题了:中台到底为什么会这么火?

就像很多趋势不是一股力量形成的,我认为中台的火爆至少是因为以下这四个方面的契机凑在了一起。

\1. 互联网企业的样板效应。这个毋容置疑,在当下,互联网公司,尤其是各个大厂的样板和标杆效应还是非常强的。更何况对于中台这件事情上,互联网企业们的态度又是这么的高度一致,在以往也是很少见的,而建设效果也实实在在被大家看在眼里,让人羡慕不已。

\2. 那互联网企业为什么会这么一致地推动中台呢?背后还有一个更深层次的原因就是今年火爆的产业互联网,在消费互联网阶段的中后期,消费侧的战场日益白热化。互联网企业为了追求持续增长,纷纷将目光转向了供给侧,这就是今年 ToB 也异常火爆的原因。而云和中台战略正是互联网企业进入传统行业的一个非常好的切入点,所以我们看到越来越多的互联网企业参与进传统企业上云和企业数字化转型过程中,把自己的技术和实践带到传统行业,在整个过程中,中台确实是一个很好的抓手和利器。

\3. 正所谓一个巴掌拍不响,这个时间点确实也正好匹配到了一些行业从系统化向平台化转型的节点。通过这些年的信息化建设和积累,企业内信息化系统该建的也都建了,什么 ERP、CRM 等,该有的也都有了。信息化建设启动早一些的企业,内部的各个系统也开始出现前面提到的烟囱林立、数据孤岛等痛点。而信息化建设相对晚一些的企业,也正好想通过这波中台浪潮来个弯道超车,一步到位。此时再赶上一阵中台旋风袭来,家家企业都觉得自己有做中台的需求和痛点,开始了自己的中台规划与建设。

\4. 最后,我认为还有一点也非常重要,也是底层的原因,就是这两年整体的经济大势并不太好,不确定性和不可预测性正在不断地冲击着各个企业甚至行业,而企业的管理者们对于企业未来发展的恐惧与焦虑倍增。这时候,互联网企业通过中台战略,把能力进行沉淀与复用,用确定性来应对不确定性,拥有快速试错、快速创新的能力和思路,这让传统企业看到了一个突围的方向。经济形势好的时候,大家要么都在忙着快速拓展业务,兵贵神速,怎么快怎么来;要么就是守在自己的成熟业务上,到点收成,也没有很强的动力改变。但经济形势严峻了,压力与恐惧越来越严重了,为了能保持企业未来的生存和可持续发展,或者为下次形势转好继续冲刺做好准备。所以,效仿互联网行业,中台战略也成了越来越多传统企业和行业的选择。

总之所谓天时地利人和,多方的因素聚集在一起也就催生了这波中台热点。而中台的火热到底只是昙花一现?还是像云计算和微服务一样会成为 IT 发展的又一次重要的里程碑?目前仍未成定论,但我个人更相信后者会有非常大的可能性。

最后,我也很想知道你为什么对中台感兴趣?你觉得中台为什么这么火呢?对于中台你现在最关心的问题是什么?

期待跟你一起在专栏里充分讨论。也欢迎你把今天的内容分享给自己的朋友,我们下一讲见!

02 | 中台种类:你听说的中台真的是中台吗?

你好,我是王健。

上一讲我带着你一起重走了近十年的中台发展之路,从时间的维度了解了中台发展的背景,也帮你分析了中台兴起背后的一些原因。

不过最后的时候我们聊到,直到目前,中台的概念仍然存在着很多迷雾,中台到底是什么?中台到底该长什么样子?有哪些种类?对企业到底有什么价值?我需不需要建中台?这些问题在你心中可能仍然没有确切的答案。

今天我就带你一起看一看,截至目前出现过的一些不同种类的中台,看看从这些看似不同种类的中台背后,我们能不能找到一些共同的特点。下一讲我会带你一起来探寻中台的本质,来解答你心中的疑惑。

至于中台的分类,我把目前出现的这些中台分为“主流”和“非主流”两类,下面就带你一一来看。

主流代表:业务数据双中台

业务中台

业务这个词,其实是有些宽泛的,我听到很多人口中说的业务都不是一个概念。为此,我还特地做了一些功课。业务,更白话一些来说,就是为了售出产品、换取利润,各行业中需要处理的商业上的相关事务。所以在早期我们通常会把于销售叫作业务员。

网易副总裁汪源就曾在网易云创峰会上提到过:“所有的中台都是业务中台”。对于这个提法,我也是认同的,因为从广义上来看所有的中台,不论是业务中台还是数据中台,亦或其他,都是为业务,为企业可以更好地以更低的成本、更高的质量、更快的响应速度售出产品、换取利润服务的。

换个角度看,从企业架构的层面看,应用架构、技术架构、数据架构都是要匹配公司的业务架构的,因为“业务”,即售出产品、换取利润是企业的核心目标。

好,既然所有的中台都是业务中台,那我们经常提到的业务数据双中台中的业务中台,这里的究竟代表的是什么呢?依我来看,我们常提到的业务中台,是狭义层面的业务概念,业务中台需要具体承载支撑业务开展的必要业务元素,封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案

这么说可能会比较空,我有一个技巧,当我思考业务中台时,我会不断地问自己一个问题:企业的业务能够顺利开展,需要解决哪些核心问题?

比如电商的场景,如果我是一家电商企业,我业务要顺利开展,即把我的产品卖给用户,换取利润,一般要解决的核心问题无非包含:

  • 我的用户是谁?从哪里来?
  • 我卖的产品是什么?从哪里来?
  • 怎么让用户知道我卖的产品?
  • 用户为什么会买我卖的产品?
  • 用户怎么买?
  • 货怎么送?
  • 用户怎么退换货?
  • 怎么才能让用户不断地买?

这些就是一个电商业务能够正常开展所需要解决的最基本最核心的问题,在 DDD(领域驱动设计)中,对于这些企业业务开展需要关注的核心问题空间有个专有名词,就是问题域。大家常说的用户域、订单域等等的叫法也来源于此。

而对于一家电商企业的不同业务线,大多是因为卖的产品不同,或是卖的区域不同,用户群体不同,但是这些问题也都是要解决的,大多数情况下解决的方法也是相通和类似的。这就是业务中台之所以能够存在的原因。

所以,我们常提到的业务中台,可以理解成狭义的业务中台,通过将不同业务线解决相同问题域的解决方案进行抽象与封装,通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求,实现对于不同业务线的业务支撑。

数据中台

讲完了业务中台,我们再来看目前热度最高的数据中台。数据中台为什么这么火热?我总结下来主要是这么几个原因。

  1. 见效快。目前大部分传统企业的问题还在于数据不通,“数据孤岛”现象比较严重,数据中台的建设对于痛点的解决直接,驱动力强。
  2. 组织调整负担小。一般来说,有一定规模的企业都已经有了大数据团队或是 BI 团队,这个团队自然就承载着相关的职能,不需要再做大的组织调整。
  3. 有一定技术基础储备。大部分企业都进行了多年的数据仓库建设,或是随着前几年大数据的浪潮,已经构建了多年的大数据技术平台。
  4. 大势所趋。大家都在讲 DT(Data Technology)时代,对于数据的价值,企业的认识也越来越深刻,大家已经意识到数据不再只是一种运营辅助分析的工具,而逐渐成为企业的核心资产和竞争力。

组织变动小,技术也有了基础,痛点明显,成本低,见效快,又是大势所趋,那么数据中台成为人们关注的热点也就不为怪了。

但是,既然现在都在提业务数据化,数据业务化,既然两个概念也在相互转化和融合,那数据中台与业务中台之间又是什么关系呢?究竟什么才是数据中台?跟过去建设的数据仓库和大数据平台又有什么区别和联系呢?

相信,这些也是很多关注数据中台的同学特别在意的问题。

关于业务中台与数据中台的关系,我比较赞同阿里巴巴技术方案总监谢纯良在一次 InfoQ 采访中提到的观点:“业务中台就是在产生数据,数据中台是做数据的二次加工,并将结果再服务于业务,为业务进行数据和智能的赋能。

而对于数据中台与传统数仓和数据平台的区别,关键在于数据中台相对于数仓、大数据平台,向前台、向业务又迈出了一步,不再只是关心技术层面大数据底座的打造,同时开始更多地关注企业层面的数据治理以及数据资产化的内容:包括但不限于数据的资产化管理(质量、成本、安全),数据服务的构建,数据的体系化建设(统一模型和指标)等。

为了方便理解,在 ThoughtWorks 我们经常把数据中台比喻成一个数据工厂,通过收集到原材料仓库,经过厂房流水线的数据加工,最终作为数据产品进入到产品仓库,通过数据商店,以各种方式(例如数据 API 的方式)对于前台或是业务中台赋能,整个过程通过控制中心进行协调调度。

这个比喻形象生动地体现了数据中台对于数据的二次加工的过程,同时还描述了通过数据实验室承载为数据赋予智能,通过办公室完成数据的治理与资产化的相关处理。

介绍完了我们最常见的业务数据双中台,这里做个小结。

业务中台与数据中台相辅相成,互相支撑,互为输入输出。业务中台承载了企业的通用业务能力,为多业务线赋能;数据中台通过对于业务数据的二次加工,并反馈回业务中台,为业务进行数据和智能方面的赋能。两者的紧密配合一起为企业构建起了商业战场强大的后方炮火群,这也就构成了最著名的业务数据双中台模式。

非主流系列

在业务数据双中台之外,还出现过各式各样的中台,而这些中台的出现也让原本还比较清晰的中台概念变得有些模糊。那接下来我就快速为你介绍一些这几年我所接触过的中台,在我讲述的过程中,你也可以思考一下,这些中台中哪些是李逵,而哪些是李鬼,谁才真正配得上中台的称号,谁又是来蹭流量的。

技术中台

除了业务数据双中台,最常被提到,在我看来介于主流和非主流之间的就得属技术中台了。技术中台相比业务中台和数据中台,边界也会更加清晰,简单来讲就是在 CloudNative 下将使用云或其他基础设施的能力、各种技术中间件的能力进行整合和包装。过滤掉技术细节,提供简单一致、易于使用的应用技术基础设施的能力接口,助力前台和业务中台、数据中台的快速建设。不过业界也有说法,认为技术中台没有很强的业务属性,只是一些中间件的集合,顶多算是个中间件平台而已,称不上中台,你怎么看呢?

研发中台

软件开发是一项工程,涉及到管理、流程、测试、团队协作等等方面。如何将企业的开发流程、最佳实践沉淀成可重用的“能力”,从而助力创新性应用的快速开发迭代,也是我们看到的很多企业正在做的事情,我们可以管这种关注开发效能管理的平台叫作研发中台。

移动中台

在移动互联网时代,移动优先的原则已经成为不争的事实,将 App 开发过程中的通用技术组件进行封装沉淀到移动中台中,就可以在构建新的 App 时大量复用已有组件和能力,快速构建和响应。

管理中台

最近很多企业开始尝试把中台思维应用到企业内部,重新对“人”“事”“流程”“企业运营”进行平台化 / 中台化改造。试图通过中台化建设,加速企业管理标准化和提升运营能力。

组织中台

在穆胜老师的书《释放潜能:平台型组织的进化路线图》中,通过分析了海尔平台化组织的演进过程,他提出了组织中台的概念。组织中台很像企业中的内部风投和创新孵化机构,为前台组织和团队构建创新型前台应用提供类似于投资评估(项目甄别)、投资管理、投后管理(孵化与风控),真正从组织和制度上支撑前台组织和应用的快速迭代和规模化创新。

好了,非主流系列我们就介绍到这里。其实远远不止这些,其他还有像财务中台、采购中台、供应链中台、AI 中台、运营中台、安全中台、管理中台等等,也曾出现在我们的视野里,今天就不一一展开了。

总结思考

最后来做个总结。这一讲我带着你一起纵览了一下现在市面上比较常见的中台种类,此时的你可能比之前感觉更蒙了,原来还有这么多不同种类的中台存在,到底哪个是李逵那个李鬼,也傻傻分不清楚。而中台到底是什么这个终极问题,此时也一定还缠绕在你的脑海里。

不用担心,通过前两讲的发散,我想让你和我一样,先把视野打开,从时间的维度和空间的维度先建立起一个全局观,下一讲我们就将做第一次收敛,来探究中台的本质。

最后,给你留几个思考题:

  • 你自己企业有中台吗?是哪种类型?
  • 对于以上提到的这些中台,你是否也有不同的理解?
  • 除了我们今天讲到的,你还见过哪些种类的中台?
  • 你自己是否有一个标准来判断哪些是中台?

欢迎你在留言区发表自己的观点,期待和你一起讨论。也欢迎你把今天的内容分享给自己的朋友,我们下一讲见!

03 | 中台定义:当我们谈中台时到底在谈些什么?

你好,我是王健。

前面两讲,我带你从时间维度重新走了一遍中台的发展历程,又在空间维度为你介绍了目前市面上出现过的各类中台。

估计你现在一定被这么多种类的中台搞的有点晕头转向了,这些中台都称的上是中台么?感觉和之前一直在做的平台也没有什么两样啊?

这也是我过去几年一直在内心不断问自己的问题。这一讲作为概念篇的最后一篇,我就试着带你跳出时间与空间的维度,来分析一下企业为什么要建中台?当我们谈中台时,我们到底在谈些什么?

企业为什么要建中台?

我们先来看企业为什么要建中台?想要回答这个问题,咱得先解决另一个问题,那就是企业为什么需要平台化?

企业为什么需要平台化呢?先给我的答案:

因为在当今这样一个互联网时代,用户才是商业战场的中心,为了快速响应用户的需求,借助平台化的力量可以事半功倍。

这背后的逻辑很简单,不断地快速响应、探索、挖掘、引领用户的需求,才是企业得以生存和持续发展的关键因素。

那些真正尊重用户,甚至不惜调整自己、颠覆自己来响应用户的企业,将在这场以用户为中心的商业战争中得以生存和发展。反之,那些在过去的成就上故步自封,存在侥幸心理希望用户会像之前一样继续追随自己的企业,则会被用户淘汰。

很残酷,但这就是这个时代最基本的的企业生存法则

而平台化之所以重要,就是因为在这场以用户为中心的现代商业战争中,它赋予或加强了企业最核心的能力:用户响应力。平台化思想(Platform Thinking)恰好鼓励企业不断抽象沉淀自己核心的底层能力,通过平台化包装,得以更好地赋能前台业务,用底层的确定性来帮助企业应对前台业务以及最终用户需求的不确定性。

从结果来看,在不确定性当道的当今商业战场,真正的弄潮儿也大多是那些具备平台化思维并很早就开始发力平台建设的企业,这也在一定层面上佐证了平台化对于一家企业的重要性。

好,现在我们想明白了第一个问题,企业为什么需要平台化。但是平台化并不是一个新概念,很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起?对于企业来讲,传统的“前台 + 后台(或是平台)”的平台化架构为什么不能满足企业的要求呢?

这就引出了我们的核心问题:企业为什么要建中台?

同样,先给我的答案:

中台化是平台化的下一站,是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能,真正为前台而生。

为了能够更清楚地讲解我的观点,这里需要先定义一下,在今天我们讨论的上下文下,前台和后台分别指什么。

  • 前台:由各类前台系统组成的前端业务平台。每个前台系统都是一个用户触点,大多是企业最终用户直接使用的系统,是企业与最终用户的交点。例如用户直接使用的网站、手机 App、微信公众号、小程序等都属于前台范畴。
  • 后台:由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源(数据 + 计算),例如财务系统、产品系统、客户管理系统、仓库物流管理系统等,这类系统构成了企业的后台。(在和很多互联网的朋友聊过之后,在互联网企业很多并没有后台的概念,更多直接使用平台的概念,例如分为前台层和平台层,但位置和作用与传统企业里的后台相似,我这里直接统一使用后台这个概念来代表。)

定义了前台和后台,我们再回过头来看企业为什么要建中台这个问题。

我们看到很多企业的后台,在创建之初的目标,并不是主要服务于前台系统的业务创新,而更多的是为了实现后端资源的电子化管理,解决企业管理的效率问题。这类系统要不就是当年花大价钱采购的套装软件,需要每年支付大量的服务费,并且版本有的也已经非常老旧了,定制化困难;要不就是花大价钱自建,年久失修,一身的补丁,同样变更困难,基本改不动了,也是企业所谓的“遗留系统”的重灾区。

可以这么说,大多数企业已有的后台,要么前台根本就用不了,要么不好用,要么变更速度就根本跟不上前台业务发展的节奏。总结下来就两个字“慢”和“贵”,对业务的响应慢,动不动改个小功能就还要花一大笔钱。

有人会说了,你不能拿遗留系统说事儿啊,我们可以新建后台系统啊,整个 2.0,问题不就解决了?

这是一种解决问题的思路,不过就算是新建的后台系统,因为后台管理的往往是企业的关键核心数据,考虑到企业安全、审计、合规、法律等限制,这样的系统也往往⽆法被前台系统直接使用,或是受到各类限制⽆法快速变化,不能⽀持前台快速的业务创新需求。

此时的前台和后台就像是两个不同转速的齿轮,前台由于要快速响应前端用户的需求,讲究的是快速迭代创新,所以要求转速越快越好;而后台由于面对的是相对稳定的企业核心后端资源,而且往往系统陈旧复杂,甚至还受到法律法规、审计等相关合规约束,一般是追求稳定至上,越稳定越好, 转速也自然是越慢越安全。

所以,随着企业业务的不断发展,这种“前台 + 后台”的齿轮速率“匹配失衡”的问题就逐步显现出来了。

企业业务不断发展壮大,后台修改的成本和风险越来越⾼,这就驱使我们尽量保持后台系统的稳定性,但同时还要响应用户持续不断的需求,怎么办?最自然的就是将大量的业务逻辑(业务能力)直接塞到前台系统中,因为前台离用户近,响应也相对快。

但是这样也是有代价的,这样的后果就是引入重复,同时还导致前台系统不断膨胀,变得臃肿,形成了一个个大泥球的“烟囱式单体应用”。这个局面的结果就是,前台系统的“用户响应力”被渐渐拖垮,用户满意度逐渐降低,企业竞争力也随之不断下降。

对于这样的问题,Gatner 在 2016 年发布了一份报告 Pace-Layered Application Strategy。报告中给出了一种解决方案,即按照“步速”将企业的应用系统划分为三个层次(正好契合前中后台的三个层次),不同的层次采用完全不同的策略。

而 Pace-Layered Application Strategy 也为“中台”产生的必然性,提供了理论上的支撑。

在这份报告中,Gatner 提出,企业构建的系统从 Pace-Layered 的角度来看可以划分为三类:SOR(Systems of record ),SOD(Systems of differentiation)和 SOI(Systems of innovation)。每一类的系统都有着不同的变化速率,因此也会有不同的生命周期,适合不同的技术架构和不同的开发过程,甚至是采用不同的投资模式。

回到之前说的后台与前台的两层架构,如果映射到这个模型上其实就是只有 SOR(后台)与 SOI(前台)的两层应用架构。这样的情况下,我们又要尽力保持后台(SOR)系统的稳定可靠,⼜要前台系统(SOI)能够⼩而美,快速迭代。因此就自然出现了上文提到的“齿轮匹配失衡”的问题,感觉鱼与熊掌不可兼得。

怎么办?Pace-Layered 中的 SOD 就是答案,它提供了比前台(SOI)更强的稳定性,以及比后台(SOR)更高的灵活性,在稳定与灵活之间寻找到了⼀种美妙的平衡。

中台就是 SOD。有了这层“中台”,我们既可以将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层,为前台减肥,恢复前台的响应力;又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层,赋予这些业务能力更强的灵活度和更低的变更成本;或者干脆直接对于后台进行中台化改造,通过配置化、自助化、白屏化等形式为后台加速,从而为前台提供更强大、更迅捷、更易用的“能力炮火”支援。

中台就像是在前台与后台之间添加的⼀组“变速齿轮”,将前台与后台的速率进行匹配,是前台与后台的桥梁和润滑剂。它为前台而生,易于前台使用,将后台资源顺滑地通过前台导流向用户,支撑企业更好地响应用户。

好了,现在我们可以小结一下,回答企业为什么需要建中台这个问题了。很简单,企业在平台化的过程中,为了能不断地给前台业务提供更好的服务,来支撑企业对于用户的持续响应,增加企业的用户响应力,企业需要构建自己的中台。

给中台下个定义

讲了这么关于中台的来龙去脉,以及种种表现形式,也讲了我对于企业平台化与中台化的理解,但你可能仍然会觉得比较抽象,所以我想,一定要试着给中台下个定义。

为什么需要一个定义呢?倒不是因为别的原因,我是觉得需要给自己一把简单的尺子,让我能轻易记住中台的特性,并能用它来快速判断一个所谓的中台是不是满足我对于中台的理解,所以我给中台的定义就是:

企业级能力复用平台。

很简单,是不是有点失望?但是为了找到一个我觉得还靠谱的定义,我几乎花了快两年的时间,期间有各种各样的定义曾浮现出来,但至少到目前为止,我觉得只有这个定义最贴切、最简单、也最准确,它能解释几乎所有我碰到的关于中台的问题,例如:

  • 为什么会有那么多中台?
  • 中台化与平台化的区别是什么?
  • 中台化和服务化的区别是什么?
  • 中台该怎么建设?
  • ……

这 9 个字看起来简单,重要的是其背后对“中台”价值的阐释,下面就让我为你一一拆解来看。

1. 企业级

企业级定义了中台的范围。不是说一个企业只能有一个中台,也不代表一个中台就是只能包含一家企业,企业级更多代表的是中台处理的问题在企业级别,即至少包含多条业务线或服务多个前台产品(团队),如果一个中台只为了支持一条业务线或产品线,那就不是中台,即使它用了服务化或是大数据等技术。

企业级这一点非常非常重要。它让我想清楚了,中台建设的事情并不是一个技术问题,而是一个要上升到企业架构的问题。做中台建设的时候,一定是跳出单条业务线、站在企业整体视角来审视业务全景。

想清楚了这一点,我对中台的理解就有了一次质的变化,也终于知道为什么一开始用做系统服务化的方式做中台会面临那么多的问题,比如最常见的组织和干系方以及利益再分配的问题。

从中台的兴起与爆发我们也能看到一个趋势,就是越来越多的企业,无论是想提升自身的运营效率,还是出于业务创新发展的需求,都已经把企业全局视角、跨业务线的能力沉淀,提到了前所未有的战略高度。

2. 能力

提到中台,最常听到的一个词就是“能力”。可能是因为能力这个词足够简单,又有着足够的包容度与宽度。

能力定义了中台主要承载的对象。

能力的抽象解释了为什么会有那么多种类中台的存在,也能解释为什么每家企业的中台都不一样,因为不同的企业之所以能够同时存在,就是因为其核心能力不同,可以满足用户不同层面的需求,也就是我们常说的差异化竞争力。

3. 复用

复用定义了中台的核心价值,也承载了上面讲到的从平台化到中台化的演进过程。传统的平台化对于“可复用性”和“易复用性”并没有给予足够的关注,更多关注的是如何消除掉重复的能力建设,既所谓的“去重”。

但中台的提出和兴起,体现出一种对于前台业务的使用体验更加关注的趋势。让人们通过对于“可复用性”和“易复用性”的关注,将目光更多地从平台内部的建设转换到平台对于前台业务的支撑上。这里有一个从治理到赋能的视角转换,既从“去重”到“复用”的关注上。

“去重”与“复用”虽然经常一起出现,一起被提及,但是谈论的完全不是一件事情,目的不同,难度也不同。“去重”讲的更多是向后看,是技术驱动的;“复用”讲的更多是向前看,是业务驱动和用户驱动的。而正这个视角的转变,我认为是理解中台概念的关键,所以

  • “复用”是中台更加关注的目标;
  • “可复用性”和“易复用性”是衡量中台建设好坏的重要指标;
  • “业务响应力”和“业务满意度”是考核中台建设进度的重要标准。

这也能解释为什么很多互联网企业,将对于平台的治理,通过业务抽象以及可配置化和白屏化的改造升级,把这个过程称之为对于平台的中台化改造过程。

4. 平台

平台定义了中台的主要形式。区别于传统应用系统拼凑的方式,中台通过对于更细粒度能力的识别与平台化沉淀,实现企业能力的柔性复用,更好地支撑前台业务,来满足对于业务的快速响应和复用的需求。

企业级能力复用平台”这个定义虽然看起来简单,但经过这么长时间对于中台的实践与思考,我觉得这个定义背后所代表的意义是目前对中台价值的最贴切的阐释。

  • 企业级”定义了中台的范围,区分开了单系统的服务化与微服务;
  • 能力”定义了中台的主要承载对象,能力的抽象解释了各种各样中台的存在;
  • 复用”定义了中台的核心价值,传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注,中台的提出和兴起,让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上;
  • 平台”定义了中台的主要形式,区别于传统的应用系统拼凑的方式,通过对于更细粒度能力的识别与平台化沉淀,实现企业能力的柔性复用,更好地支撑前台业务。

总结思考

今天我们从企业为什么需要平台化入手,讨论了企业又为什么需要建中台。结合前两讲的内容给出了我的观点,不知道对你有没有启发,让我最后再来总结一下。

以用户为中心的持续规模化创新,是中台建设的核心目标。企业的用户响应能力和规模化创新能力,是互联网时代企业综合竞争力的核心体现。平台化包括中台化只是帮助企业达到这个目标的手段,并不是目标本身。

中台(⽆论是技术中台、业务中台还是组织中台)的建设,根本上是为了解决企业响应力困境, 弥补创新驱动需要快速变化的前台和稳定可靠驱动需要变化周期相对较慢的后台之间的矛盾,提供⼀个中间层来适配前台与后台的配速问题,打通并顺滑链接前台需求与后台资源,帮助企业从整体上不断提升用户响应力。

所以,中台到底是什么根本不重要,如何想方设法持续提高企业对于用户的响应力才是最重要的。而平台化或是中台化,只是恰巧走在了这条正确的大道上。

最后我们给中台下了一个定义,既“企业级能力复用平台”。有了这个定义后,我们不仅可以把它当作一把尺子来丈量一个中台是否货真价实,对于如何建中台的思路也能豁然开朗。

因为如果说“中台就是企业级能力复用平台”的话,那“中台化”也就是“利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程”。

好了,从下一讲开始我们就正式进入落地篇,一起来看看我们是如何规划与落地实施中台的。

最后,给你留几个思考题:

  • 你的企业真的需要中台吗?
  • 如果让你用一句话来给中台下个定义,你会怎么讲?
  • 在你所在的企业,中台是解决方案还是问题本身?

中台还是组织中台)的建设,根本上是为了解决企业响应力困境, 弥补创新驱动需要快速变化的前台和稳定可靠驱动需要变化周期相对较慢的后台之间的矛盾,提供⼀个中间层来适配前台与后台的配速问题,打通并顺滑链接前台需求与后台资源,帮助企业从整体上不断提升用户响应力。

所以,中台到底是什么根本不重要,如何想方设法持续提高企业对于用户的响应力才是最重要的。而平台化或是中台化,只是恰巧走在了这条正确的大道上。

最后我们给中台下了一个定义,既“企业级能力复用平台”。有了这个定义后,我们不仅可以把它当作一把尺子来丈量一个中台是否货真价实,对于如何建中台的思路也能豁然开朗。

因为如果说“中台就是企业级能力复用平台”的话,那“中台化”也就是“利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程”。

好了,从下一讲开始我们就正式进入落地篇,一起来看看我们是如何规划与落地实施中台的。

最后,给你留几个思考题:

  • 你的企业真的需要中台吗?
  • 如果让你用一句话来给中台下个定义,你会怎么讲?
  • 在你所在的企业,中台是解决方案还是问题本身?

期待你在留言区分享自己的想法,也欢迎你把今天的内容分享给朋友,和他一起学习讨论。我们下一讲见!

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

办公模板库 素材蛙

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值