我对中台的定义:企业级能力复用平台

标签: 产品设计 2年 中台 初级 | 发表时间:2019-04-05 15:39 | 作者:思特沃克
出处:http://www.woshipm.com

笔者对中台的定义是“企业级能力复用平台”,本文将针对这九个字进行拆解分析,具体讲述:中台是什么?

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

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

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

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

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

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

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

废话不多说,回到「中台」,如果让我给出一个定义,目前我认为最贴切的应该是: 中台就是「企业级能力复用平台」

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

  • 为什么会有那么多中台,像上文提到业务中台、数据中台、搜索中台、移动中台,哪些才是中台,哪些是蹭热点的?
  • 中台与前台的划分原则是什么?
  • 中台化与平台化的区别是什么?
  • 中台化和服务化的区别是什么?
  • 中台该怎么建设?
  • ……

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

一、企业级

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

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

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

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

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

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

二、能力

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

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

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

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

这个问题比较大,也很难有一个统一的答案。

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

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

三、复用

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

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

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

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

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

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

所以:

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

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

  1. 将更高抽象(例如:业务模式级别)的通用业务逻辑通过抽象后下沉到中台,这样前台就会更轻,学习成本和开发维护成本更低,越能更快的适应业务变化;缺点是:抽象级别越高,越难被复用,需要架构师对于各业务有深入的理解和非常强的抽象能力。
  2. 就是通过对于中台能力的SaaS化包装,减少前台团队发现中台能力和使用中台能力的阻力,甚至通过自助式(Self-Service)的方式快速定位和使用中台能力。目前很多企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。

这里还有一个很有意思的点,相对于「能力复用」其实我们更常用到的词就是「能力共享」,这两个词有些相似。但考虑到「中台」这个概念更加强调对于前台业务的支撑与赋能,除了基本的能力沉淀与共享外,也会更加关注前台的易用性和使用体验,所以我觉得「复用」更能体现出这一点。

四、平台

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

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

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

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

  • 一个是大单体系统的业务响应力有限,缺少「柔性」,当业务发展到一定阶段后,必然产生大量定制化需求,随着内部定制化模块的比例逐渐上升,响应力成指数下降,成为业务的瓶颈点。
  • 另一个则是系统间的打通通常比较困难,容易形成业务孤岛和数据孤岛。

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

五、总结

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

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

有了定义后,如何建中台的思路也就豁然开朗。

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

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

PS:至于有同学给我反馈最近“假大空”说的有点多(虽然我誓死不认……),但还是决定接受反馈开始写一些落地实践之类的内容,敬请期待。

 

作者:ThoughtWorks王健,微信公众号:ThoughtWorks洞见

本文由@ThoughtWorks王健 原创发布于人人都是产品经理,未经允许,禁止转载。

题图来自Unsplash, 基于CC0协议

相关 [中台 定义 企业] 推荐:

我对中台的定义:企业级能力复用平台

- - 人人都是产品经理
笔者对中台的定义是“企业级能力复用平台”,本文将针对这九个字进行拆解分析,具体讲述:中台是什么. 《白话中台战略》已经写了三篇,尤其是第一篇「中台是个什么鬼」收到了很多朋友的反馈. 写“白话”这个系列主要是想通过写文章来驱动自己思考,并借此和更多人一起交流和探讨中台这个话题. 幸运的是,确实有很多朋友在公众号后台给我留言来表达自己的想法,在此摘出来一个具有代表性的:.

不做中台会死吗?企业真的需要做中台吗?

- - 人人都是产品经理
各大互联网企业趋之若鹜地开始了中台建设. 本文的笔者就中台理念、中台建设原则、什么样的企业才适合中台建设等分享了自己的观点. 2010年的中国(深圳)IT领袖峰会上,BAT三家的当家人发表了对于云计算的看法:. 马化腾:云计算需要到“阿凡达”时代才能实现,现在说确实太早了. 马云:如果我们不做云计算,将来会死掉.

W3C完成HTML5.0定义

- - Solidot
W3C宣布公布HTML5和Canvas2D规格的完整定义. 虽然它们还没有成为W3C标准,但特性已经完成,这意味着企业和开发者可以根据目前的规格去实现和开发HTML5 Web应用. W3C称HTML5是开放Web平台的基石,为跨平台应用提供一个完整的编程环境. 根据W3C的发布计划,2012年底发布HTML5.0候选推荐规格,然后着手开发HTML5.1规格草案;2014年发布HTML5.0推荐规格和HTML5.1候选推荐规格.

JSP自定义方法库

- - CSDN博客编程语言推荐文章
如果JSTL的方法库没有满足需要,可以使用自定义方法进行扩展. public static int length(Object obj){ //返回对象的长度. 自定义方法的声明写在 标记里面,格式为.       返回值 方法名(参数1类型,参数2类型……).

Lucene(3.5)自定义QueryParser

- - zzm
//  content: 全国软件专业人才设计与开发大赛  . //  Lucene实战(第二版) Lucene in action  .     private static final Analyzer analyzer = new StandardAnalyzer(version);//和索引时用的分词器一致  .

Android自定义Lint实践

- - 美团点评技术团队
Android Lint是Google提供给Android开发者的静态代码检查工具. 使用Lint对Android工程代码进行扫描和检查,可以发现代码潜在的问题,提醒程序员及早修正. 为保证代码质量,美团在开发流程中加入了代码检查,如果代码检测到问题,则无法合并到正式分支中,这些检查中就包括Lint.

map-reduce自定义分组自定义排序

- - 行业应用 - ITeye博客
1 * @author zm * * 当第一列相同时,求出第二列的最小值---> 由要求分析如下: * 1 必然以 row1来进行分组. * 2 必然也是以 row1,row2作为一个整体来进行比较才能有 当第一列相同时,在比较第二列的状态发生 * 3 mr中,执行流程是 -->-->--> *.

CSS自定义滚动条样式

- 恋上女人香 - 前端观察
相信很多人都遇到过在设计中自定义滚动条样式的情景,之前我都是努力说服设计师接受浏览器自带的滚动条样式,但是这样只能规避还是解决不了问题,最近在项目中遇到了,正好来总结一下. 当然,兼容所有浏览器的滚动条样式目前是不存在的. IE是最早提供滚动条的样式支持,嗯,好多年了,但是其它浏览器一直没有支持,IE独孤求败了.

"官方定义,什么叫邪教"

- diiyoo - KDS Shanghai
我在嘉峪关看到的宣传栏“八招教你辨别鞋教”. 看完总觉得哪里不对劲,特别是如果时光倒流四十年. 我明白了 怎么越看越像 册 那,楼主侬想表达啥. -=此贴发送自[wap]=-. -=此贴发送自[wap]=-. 你应该问 嘉峪关文物局 想表达啥. 我只是转述的 官方给自己的定义   引用:.

Javascript定义类(class)的三种方法

- - 阮一峰的网络日志
将近20年前, Javascript诞生的时候,只是一种简单的网页脚本语言. 如果你忘了填写用户名,它就跳出一个警告. 如今,它变得几乎无所不能,从前端到 后端,有着各种 匪夷所思的用途. 程序员用它完成越来越庞大的项目. Javascript代码的复杂度也直线上升. 单个网页包含10000行Javascript代码,早就司空见惯.