阿里云「飞天发布时刻」2024来啦!新产品、新特性、新能力、新方案,等你来探~ 了解详情
写点什么

白话中台战略(三):中台的定义

  • 2019-04-16
  • 本文字数:3521 字

    阅读完需:约 12 分钟

白话中台战略(三):中台的定义

《白话中台战略》已经写了三篇,尤其是第一篇“白话中台战略(一):中台是个什么鬼?”收到了很多朋友的反馈。写白话这个系列主要是想通过写文章来驱动自己思考,并希望可以和更多人一起交流和探讨中台这个话题。


幸运的是,确实有很多朋友给我留言来表达自己的想法,我摘出来一个具有代表性的:


“互联网的企业就是爱炒概念。本来很明白的东西,被他们一包装,就变得高深莫测了。我理解中台,就是敏捷响应机制…是一种思维或者理念…企业根据自己的实际情况落实就行。”


对于这位同学的观点我很赞同,中台本身就是一个比较抽象的概念,很多时候我们被那个“中”字困住了,整天在前与中,中与后的具体差别和评判标准上纠结不已。


但是,就像“看板”不是“我们看到的那个板子”一样,“中台”也不一定就是代表“处于中间平台”,这两个字作为一个整体,代表了一种新的思维和理念。在最新一期的 ThoughtWorks 技术雷达讨论阶段,中国区的同学就把“ZhongTai”作为一个独立的技术点提交,并没有做意译,就像“Kanban”一样。


那这种新的思维和理念到底是什么呢?“中台”的背后到底意味着什么?有没有价值?价值何在?这也我一直在不断询问自己的问题。


要想搞清楚这些问题,我认为一个关键点就是看我们是否能够给“中台”这个相对抽象的概念找到一个清晰的定义,因为只有通过定义才能让抽象的概念清晰化,从而明确边界、体现价值。


废话不多说,回到“中台”,如果让我给出一个定义,目前我认为最贴切的应该是:


中台就是“企业级能力复用平台”。


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


为什么会有那么多中台,像上文提到业务中台,数据中台,搜索中台,移动中台,哪些才是中台,哪些是蹭热点的?


中台与前台的划分原则是什么?


中台化与平台化的区别是什么?


中台化和服务化的区别是什么?


中台该怎么建设?


等等……


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

企业级


首先,中台一定是企业级的,这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围,甚至可以是跨企业,例如现在同样火爆的生态的概念。按照徐昊(ThoughtWorks 中国区 CTO)的说法,更贴切的叫法应该是“多前台产品团队”,这里为了简单我还是用企业级来代表。


当做中台建设的时候,一定是跳出单条业务线站在企业整体视角来审视业务全景,寻找可复用的能力进行沉淀,从而希望通过能力的复用一方面消除数据孤岛业务孤岛,一方面支撑企业级规模化创新,助力企业变革,滋生生态。


所以虽然中台的建设过程虽然可以自下而上,以点及面。但驱动力一定是自上而下的,全局视角的,并且需要一定的顶层设计。这也解释了为什么在企业中推动中台建设的往往都是跨业务部门,例如 CIO 级别领导或是企业的战略规划部门,因为只有这些横跨多条业务线的角色和组织,才会去经常反思与推动企业级的能力复用问题。


这一点也引出了中台建设的一个关键难点,就是组织架构的调整和演进以及利益的重新分配,这是技术所不能解决的,也是中台建设的最强阻力,这个我打算在后续的文章里详细阐述。


同时企业级也是区分企业中台化与应用系统服务化的关键点,简而言之中台化是企业级、是全局视角,服务化更多是系统级、是局部视角。


所以从中台的兴起与爆发可以看到一种趋势,就是越来越多的企业无论是由于企业运营效率的原因还是由于创新发展的需要,对于企业全局视角跨业务线的能力沉淀都提高到了前所未有的战略高度。

能力


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


企业的能力可能包含多个维度,常见的例如计算能力,技术能力,业务能力,数据能力,AI 能力,运营能力,研发能力……其中大部分的能力还可以继续细化和二次展开,从而形成一张多维度的企业能力网。


我在上一篇白话中台战略-2 中台到底长啥样?中已经举了一些常见的例子,这里就不赘述了。


可以说,中台就是企业所有可以被“多前台产品团队”复用能力的载体。


这里有一个经常碰到的问题,就是对于某一家企业来讲,你说了有这么多种不同类型的能力,到底哪些能力才是我们企业需要的?哪些是值得中台化的?优先级又怎么划分?


这个问题比较大,也很难有一个统一的答案。我们 ThoughtWorks 现在的做法是通过一系列 Workshop,从业务、数据、技术三个方面切入,通过一系列方法,结合企业愿景,市场定位和数字化现状,跨越多条业务线,试图将企业需要的能力和可复用的能力识别出来,并为落地做好规划和准备。


这些会在后续写到中台如何落地的文章时再详细展开。

复用


讲到这儿,相信大家一定有一个疑惑,无论是说企业级,多前台产品团队,还是讲能力沉淀,都不是什么新话题。很多企业组件化,服务化,平台化搞了好多年,那“中台”到底有哪些新的启发?


我的答案就是对于“复用”的关注被提高到了一个前所未有的高度。


虽然我们一直讲“去重复用”讲了很多年,但仔细想想,大多平台化建设会将重点放在“去重”(消除重复)上,而对于“复用”则没有足够的关注。


很多企业都号称已经建成了各种各样成熟的平台,但是我们问心自问一下,有多少平台是业务驱动的?有多少前台产品团队又是自愿将自己的产品接入到平台上的?有多少平台建设者是在真正关注前台产品团队的平台用户体验?


“去重”讲的更多是向后看,是技术驱动的;“复用”讲的更多是向前看,是业务驱动和用户驱动的。


所以“去重”与“复用”虽然经常一起出现,一起被提及,但是谈论的完全不是一件事情,目的不同,难度也不同,做到“去重”已然非常困难,关注“复用”的就更是寥寥无几,所以:


  • 复用是中台更加关注的目标;

  • 可复用性和易复用性是衡量中台建设好坏的重要指标;

  • 业务响应力和业务满意度也才是考核中台建设进度的重要标准。


而实现更好的复用,常常改进的方向有两个方面:


  • 一方面将更高抽象(例如业务模式级别)的通用业务逻辑通过抽象后下沉到中台,这样前台就会更轻,学习成本和开发维护成本更低,越能更快的适应业务变化;缺点是,抽象级别越高,越难被复用,需要架构师对于各业务有深入的理解和非常强的抽象能力。

  • 另一方面就是通过对于中台能力的 SaaS 化包装,减少前台团队发现中台能力和使用中台能力的阻力,甚至通过自助式(Self-Service)的方式就快速定位和使用中台能力。目前很多企业在尝试的内部 API 集市或是数据商店就是在这方面的努力和尝试。

平台


这里的平台主要是区别于大单体的应用或是系统。


传统的企业数字化规划更多的是围绕业务架构,应用架构和数据架构展开。产出也是一个个基于应用和系统的数字化建设规划,例如要采购或是自建哪些具体的系统,例如 ERP、CRM 等。


当然这个过程并没有什么问题,可以理解此时这些独立的系统就承载了企业的各种能力,由于企业各业务线统一使用一个应用或系统,也自然实现了能力的复用。


但问题常常出现在两个方面:


  • 一个是大单体系统的业务响应力有限,缺少柔性,当业务发展到一定阶段后,必然产生大量定制化需求,随着内部定制化模块的比例逐渐上升,响应力成指数下降,成为业务的瓶颈点。

  • 另一个则是系统间的打通通常比较困难,容易形成业务孤岛和数据孤岛;

  • 所以越来越多的企业开始像互联网学习,以平台化的方式重塑企业 IT 架构,从而对于业务提供足够的柔性,来满足对于业务的快速响应和复用的需求。

总结

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


  • 企业级定义了中台的范围,区分开了单系统的服务化与微服务;

  • 能力定义了中台的主要承载对象,能力的抽象解释了各种各样中台的存在;

  • 复用定义了中台的核心价值,传统的平台化对于易复用性并没有给予足够的关注,中台的提出和兴起,让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上;

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


有了定义后,如何建中台的思路也就豁然开朗:如果说中台是「企业级能力复用平台」的话,那中台化就是「利用平台化手段发现、沉淀与复用企业级能力的过程」,再回头看看这两年做的事情,确实也都在围绕着这些展开。


这就是我对中台的定义,如果你有不同观点或是意见,欢迎留言一起探讨。


原文链接:https://mp.weixin.qq.com/s/4JxgeeZeVaOASXUKjwTflg


推荐文章:


白话中台战略(一):中台是个什么鬼?


白话中台战略(二):中台到底长啥样?


2019-04-16 00:088898
用户头像
王健 ThoughtWorks

发布了 45 篇内容, 共 79677 次阅读, 收获喜欢 70 次。

关注

评论 3 条评论

发布
用户头像
道理我都懂,可是到底什么是中台呢(滑稽脸)
2019-04-26 17:07
回复
人家都说了自己的定义的概念:企业级能力的复用平台。没有实际的企业级能力的就经验,你就是无法理解的。比如开饭馆的,上菜速读比咱们家里快了不少,那厨房里面的备菜和厨师炒菜技能可简单的理解成上菜中台。但是你说啥是上菜中台?你肯定不懂阿,因为你不知备菜要做什么,炒菜技能又是什么,所以会觉得不懂啦。我个人理解,不要喷我阿
2020-01-02 17:39
回复
用户头像
兄弟,看完三篇,感觉技术出身的人不能这么流水账,最后也没说清楚什么是中台,太概念了
2019-04-16 16:43
回复
没有更多了
发现更多内容

来了!8M/S+速度,Pdown复活!

程序员生活志

极客大学架构师训练营第四周学习总结

竹森先生

极客大学 极客大学架构师训练营

如何成为一名合格的 C/C++ 开发者?

张小方

c++ Linux 编程语言 后端 架构设计

一二线城市知名 IT 互联网公司名单(新版)

程序员生活志

互联网 IT 大厂

如何学 Java,我说点不太一样的学习方式

四猿外

学习 程序员 个人成长

大型互联网应用系统使用技术方案和手段

动态规划算法重点在于找上一个的公式,Google Code Review,John 易筋 ARTS 打卡 Week 06

John(易筋)

ARTS 打卡计划

大型互联网架构与集群技术

cxy

嗨,兄弟,别担心,这年头谁还没有一点焦虑!

周果

程序员 管理 成长 个人感想

架构师训练营第 4 周——学习总结

在野

极客大学架构师训练营

我写了一本操作系统词典送给你

cxuan

操作系统 计算机

如何进行高效学习

淡蓝色

深度思考 方法论 感悟 随笔杂谈

奈学:数据湖和数据仓库的区别有哪些?

奈学教育

数据仓库 数据湖

了不起的 TypeScript 入门教程 [1.2 w字]

阿宝哥

Java typescript 大前端 Web

从0开始设计Flutter独立APP | 第二篇: 完整的国际化语言支持

渔子长

flutter 大前端

架构师训练营第四周学习总结

张明森

MySQL 实战 45 讲笔记(2)-查询优化

程序员老王

MySQL

深入理解Kubernetes的Service:回归本源的场景需求

韩超

Kubernetes 微服务 服务

ARTS 打卡 Week 05

teoking

架构师训练营第 4 周作业

在野

极客大学架构师训练营

创新管理体系标准ISO56002介绍

涛哥 数字产品和业务架构

数字化转型 创新

计算机操作系统基础(五)---Linux的进程管理

书旅

php 线程 多线程 操作系统 进程

谈谈架构和微服务<一>

Gabriel

架构 微服务 领域驱动设计 软件设计

架构演化

满山李子

奈学:数据湖和数据仓库的区别有哪些?

古月木易

数据仓库 数据湖

聊一聊程序员如何增加收入

张小方

程序员 互联网 面试 副业赚钱 薪资

架构师训练营第四周课后作业

竹森先生

极客时间 极客大学架构师训练营

SpringBatch系列之Remote-Chunking

稻草鸟人

大数据 Spring Boot SpringBatch 批量任务

第四章总结

MySQL系列 - SQL查询与修改执行过程

俊俊哥

MySQL 性能优化 关系型数据库 存储

实现简单的"纤程"

Near

白话中台战略(三):中台的定义_架构_王健_InfoQ精选文章