从阿里提出的拆中台,聊聊中台战略是否过时(201226)

标签: 微服务架构 | 发表时间:2020-12-26 09:06 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
从阿里提出的拆中台,聊聊中台战略是否过时?

 

最近一段时间有个热点经常被大家转发,就是阿里拆中台。起因是阿里张勇在内网发文谈到中台太厚,反而影响到了阿里业务发展和敏捷响应能力。从15年张勇提出大中台,小前台战略,到今天又自我否定提出了拆中台,那么是否真正中台战略思想已经过时?

如何理解拆中台这个概念?

对于这里的拆实际应该从两个方面理解。

其一是分拆,即原来的中台太大了需要进行分拆,从谈到最多的业务中台和数据中台,包括业务中台能力也进一步分拆为独立的中台,比如人力服务中台,供应链中台,知识和搜索中台。而对于数据中台独立分拆AI中台等。

这个实际和我前面谈到的中台构建中本身即微服务化思路是一致的。中台能力本身就是多个微服务中心或能力中心去支撑的,而不可能说构建在一个大系统里面。

既然原来已经微服务拆分,那么为何还存在分拆的概念?

简单来说就是中台大了后,不同业务域的中台服务能力本身,在向前台提供服务能力支撑,服务运营的时候是存在差异化的,包括后期的服务治理。因此你会看到不同类型的中台,中台业务团队,运营团队,服务团队都需要进一步进行拆分,才能够更好的满足前台应用需求。

从阿里提出的拆中台,聊聊中台战略是否过时?

 

其二是抛弃中台,这里主要是指进行全新业务域IT能力建设的时候,一开始往往并不是以中台+服务+应用的思路去规划。而仍然是传统纵向模式,这和网上谈到的中台基因更多是应对组合式创新,而不是颠覆式创新类似。

这里可以参考网上的一段论述如下:

为什么这么说呢?因为,组合式创新,是把现有几个能力进行组合,形成新的能力,它强调能力的标准化,这个恰恰是中台所擅长的。以“盒马鲜生”为例,它复用了中台的商品、库存、用户、支付、AI、安全等多个服务能力,经过重新组合,形成了“零售新物种”。但是,颠覆式创新,是从根上做创新,它要打烂前台、中台、后台,颠覆现有模式和能力。比如智能制造颠覆传统制造、智能手机颠覆传统手机,你没法在现有生产线上去创造,只有打破原有模式。所以,中台不支持颠覆式创新,这是中台的基因所决定的。

再简单来说,拿腾讯来说,腾讯可能已经构建了自己的游戏中台能力,但是自己又有为微众银行,那么微众银行要借鉴和使用游戏中台能力显然是不可能。

那么微众银行在业务和IT构建的时候是否就一定按中台思路构建呢?

一般来说往往并不会,即当面对一个新的业务领域和颠覆式创新场景的时候,实际上你并不清楚你应该有哪些可复用能力沉淀到中台,因此自然也谈不上按中台+服务+前台应用思路来构建IT。

这也是我原来强调过的一个关键点,即:

中台是企业信息化建设中逐步演进和演变出来的,而不是规划出来的。

中台是否过时?

从阿里提出的拆中台,聊聊中台战略是否过时?

 

当接触到中台和微服务概念的时候,我们经常就听到的是SOA思想过时,组件化思想过时。而实际上你可以看到中台和微服务正是原来SOA架构思想,组件化思想的演进和发展。

中台这个词炒作的太多,可能大家都不再愿意提中台概念。但是SOA架构思想,微服务思想不存在过时的说法。可能以后还会冒出新词汇,但是这些思想本身都是一样的。

传统企业信息化和互联网信息化基因是不同的。

在前面我就谈到互联网企业信息化和传统企业信息化很多规划思路,系统建设思路,业务系统的复杂度,面对的用户受众各个方面都有差别。

如果简单的照搬互联网构建中台的思路来建设企业内中台,基本都是死路。

大部分企业更多的应该是基于当前遗留IT架构和IT系统能力,采用逐步演进的思路来构建自己的中台。这个中台也不一定一开始就要微服务化,要独立构建。而是以能够提供共享服务能力给上层应用使用为核心指导原则。

中台核心是共性业务能力的抽象下沉,并统一对外提供。

很多企业没有大张旗鼓的去规划构建中台,但是经过多年建设形成了自己的服务共享平台和服务资产库,这个服务资产有效的支撑了新的业务应用的开发,那么这个服务共享平台就是对企业有价值的中台。

这个服务共享平台可能仍然大量适配和接入了遗留IT系统的可复用能力,而不是全新构建新能力,但是这恰好是企业中台构建和平滑演进中的最佳方式。

简单来说很多企业连服务共享平台都做不好,如何有能力做好中台?我们实施了大量的SOA和ESB服务总线项目,大量的企业仍然将ESB作为一个接口集成平台在使用,在这种管控治理水平下,实际上是很难去规划建设中台的。

传统企业什么时候需要构建中台?

大家可以看下,除了互联网企业外,中台规划建设实践最多的是哪些企业?

简单来说主要包括了金融服务,电信行业,快消品行业等。这些企业中台实践的多最大的原因就是本身的商业模式变化,互联网转型需求,即在直接面对C端消费者的时候,需要能够更加敏捷的为客户提供各种服务能力,能够快速的衍生新的商业或服务模式。

而对于其它大部分传统企业来说,实际上并没有这种需求。比如很多下游的制造类企业,往往并不直接面对C端客户。这类企业的信息化和IT系统建设,更多的是为了满足内部业务高效运作,满足内部员工的使用需求。

基于这类企业信息化建设的供应链,财务,ERP等业务系统,绝对是很少出现类似互联网企业应用一样天天都在变更,都在发布版本,随时都在衍生新的APP应用等场景。

从阿里提出的拆中台,聊聊中台战略是否过时?

 

简单来讲:对于本身就是做C端消费类产品的企业,本身又希望实现对终端用户的端到端触达能力,同时营销价值链本身又是完全自建的情况。这种企业往往对中台建设的需求最强烈。

我们也看到当前很多上中台的企业更多就是属于上面场景的企业,而且中台的构建更多的是面向自己的电商平台,CRM营销网络,面向C端的前台应用需求。

在这种情况下,企业需要去构建一个中台来满足前台应用敏捷化的需求。

也就是说这个企业中台已经不再是简单的满足内部业务系统,内部用户的使用,而是更多的打破了企业边界,面向外部的消费者用户,或者产业链上的生态合作伙伴的需求。

在这种场景下,我们就需要对企业内部已有的业务能力进一步包装和抽取共性,然后将共性能力以API接口服务的方式提供给前台应用。

从阿里提出的拆中台,聊聊中台战略是否过时?

 

其次,就是一个大的集团性企业,本身在进行业务重组,将共性业务能力形成共享中心的方式进行统一的情况下,需要去构建一个中台。这个也和我们中台产生背景思路一致。

比如前面谈到的,一个生产制造企业,本身有很多子公司或工厂,但是你可以看到企业的供应链能力,营销服务能力,售后服务能力完全是可以共享和复用的,这些业务能力应该进行整合和统一。真正差异化的仅仅是制造各类产品不同的制造单元。

在这种明确的业务驱动和业务整合背景下,往往也是最佳的构建中台场景。

其次,对于中台适用场景网上一个说法也可参考:

https://www.sohu.com/a/440065246_355140

从阿里提出的拆中台,聊聊中台战略是否过时?

 

如上的四象限图。这四个象限的横轴代表技术演化稳定性,竖轴代表功能的通用性。中台的优势领域在第三象限,这个象限技术具有高确定性,业务功能通用。第二象限属于比较稳定但是不通用的小众行业。第四象限属于普遍流行但是高速变化的领域,比如说内容和服饰或者端上的交互。而第一象限属于创新业务,不但定制化程度高且快速演化,比如说面向垂直行业或者初创技术。

也就是说: 中台的使用范围是有限的,仅仅限于技术演化相对慢且功能通用性高的场景中。这是我们得出的第一个结论。

过往中台的失败案例也往往集中在把中台强推到创新业务中的情况。

中台为何笨重?

在这里我还是想展开谈下中台为何会越来越笨重。假设一个企业的中台已经是按照微服务架构思想拆分为了多个能力中心进行构建,比如订单中心,商品中心,支付中心等。在这种构建模式下各个中心都可以对应到独立的开发团队进行独立自治的设计,开发,实现和能力交付工作。

新需求响应难度增加

当在构建一个新的前台应用的时候,如果当前中台提供的API接口服务能力有现成可用的,那么通过快速复用自然是可以加快前端应用构建速度。

但是如果前台需要支付中心提供一个能力接口,这个接口原来支付中心并没有。

在这种场景下支付中心就需要全新去实现一个接口,并将接口暴露给前台使用。在规划设计这个接口的时候,整个过程实际是变复杂了。

即支付中心在实现这个接口的时候,还需要分析和考虑如何将接口做到通用化和标准化,后续还可能存在哪些业务场景同样需要使用类似的API接口。即接口虽然是前台A应用提出的需求,但是中台去设计实现的时候必须考虑通用性,可复用度,接口治理管控多方面的内容。这些都考虑清楚了才能够去实现。

其次,如果是由前台自己去实现这个接口,那么这属于前台模块内部的接口集成,相对来说更加容易进行集成和联调测试。但是接口转到由中台提供的时候,这个原来内部的集成变成了跨团队,跨应用的外部集成,整个集成度本身也提高。

因此当需要中台新增能力的时候,实际对业务响应的敏捷度是下降的。

但是好处就是,如果后续还有新应用也需要这个可复用能力,那么敏捷度就能提升。

当我们在谈中台敏捷性的时候,往往都在说中台能力已经足够完整,前台应用构建需要的东西都能够从中台找到。但是却忽视了存在新的需求需要不断下沉到中台的场景。如果这个场景存在,那么敏捷度是降低的。

但是如果后续新可复用能力不沉淀,那么中台本身就失去了价值和活性。

企业一开始规划建设的中台很好,但是运行一段时间你会发现又出现大量可复用能力没有下沉到中台,仍然是在前台来实现。本来希望前台越做越薄,但是实际情况往往是前台应用越来越厚。前台对中台依赖逐渐变小,那么中台本身价值也逐步丧失。

集成复杂度增加

在传统的业务系统和应用开发中,往往所有业务功能和逻辑都在自己内部实现,虽然存在重复,但是好处就是完全属于内部可控,协同和集成难度也小。

但是当采用中台分层架构思路后,一个前台应用往往会依赖多个中台能力提供中心的能力,一个前台应用要跑通设计到多个接口集成和联调,需要协同多个研发团队,出现了问题后又需要等待中台研发团队变更和修复。

即虽然用现成可复用接口服务提升了效率,但大量的接口集成或变更依赖往往降低效率。

本来自己一个项目组能搞定的事情,发现中台化后需要协同和依赖3个项目组,整体交付进度和质量反而完全不受自己控制。

再举个例子:一个本身很小的业务系统设计开发,实施了微服务架构和前后端分离,后端人员不会前端技术,前端人员本身不care业务,导致一个简单系统实现都要多人协同和集成才完成,而且质量难以稳定。对于这类小业务系统开发,个人是强烈反对微服务化和前后端分离。

可复用带来实现复杂度增加

共性业务能力下沉实际包括两个方面。其一是完全相同的接口服务能力,其二是需要进行业务需求差异后抽象和参数化,在抽象化后才能够提取共性的服务能力。

当中台能力构建出现第二种情况的时候,你会发现中台能力的设计和实现复杂度一定增加,正如我们在软件开发时候,如果数据库只支持mysql,跟需要支持多数据库,在实现复杂度上完全是两个层面。多数据库支持不仅仅提升了实现复杂度,同时还降低了接口服务能力的性能。

同时当后续中台某个接口服务能力进行变更的时候,同样出现大量前台应用依赖,一变动往往上层应用也要配套变更的情况。如果不变动,再新增加新的服务能力接口,那么后续中台提供过的接口服务本身的版本管理,服务本身的生命周期管控又出现问题。

当一个企业原来IT建设以及相对完善,但是企业战略调整需要逐步对外上下游协同,或者直接触达C端客户的时候,这个时候构建中台相对容易。即基于已有的IT系统建设经验,已经足够提取出一套稳定的中台能力服务层,同时这些能力接口相对稳定。

但是一开始你按中台思路去构建,没有足够的业务沉淀和业务场景覆盖,那么后续中台就出现大量的能力新增和变更,这种不稳定的中台对前台构建往往才是大灾难。

中台服务治理管控能力跟不上

中台建设完成后,API接口服务能力提供给上层使用,这些API接口如何使用,应该遵循什么样的规范流程,如何进行接口订购消费,如何监控接口运行,接口变更时候如何处理?

这些都是很现实的服务治理管控问题。

这些治理规范和管控流程没有跟上,那么中台能力的使用就处于一种混乱和不可控的状态,中台提供能力被前台大量随意使用不仅仅是数据安全的问题,更大的问题是前台和中台之间耦合性逐渐增强,任何变更牵一发而动全身。

我们希望引入中台和服务去实现解耦,但是发现接口乱使用反而更加耦合。

中台首先是一个业务概念

从阿里提出的拆中台,聊聊中台战略是否过时?

 

在谈中台的时候我始终强调中台是一个业务概念,首先要做的是共性业务能力整合。

这个实际在中台概念出来前,很多企业就在做这个事,比如构建的统一财务共享中心,人力资源中心,供应链采购中心,售后服务中心等。也就是说在中台能力没有出路前,很多大企业已经在构建自己面向不同业务域的共享服务中心,实现共性业务能力的整合。

共性业务能力整合后,自然就有配套的中台IT能力中心实现,这个过程本身是很顺的。是业务推动了IT,而不是IT去构建中台中心反向推动业务变化。

中台首先是一个业务概念,其次才是为之配套的IT技术实现。

中台本身就是需要很好的衔接业务和IT,才能够真正规划和建设成功。如果业务组织和团队本身没有变化,业务构建方式没有变化,仅仅是期望IT系统中台化后来支撑业务,显然是不现实的。这也是很多企业最终中台建设失败的一个关键原因。

中台价值始终体现在对业务的敏捷和快速响应能力上,如果这个关键的KPI指标都没有达到,就脱离了中台建设的初衷。

包括现在的中台建设和IT解决方案厂商也是同样道理,能够提供技术解决方案的很多,而真正垂直在一个业务领域,能够提供完整的业务梳理,中台规划的少之又少。这也是导致最终的中台类系统无法匹配业务目标实现的一个关键原因。

中台思想本身没有错,关键点还是在于业务如何变革,业务和IT如何协同去推动中台规划和建设。如果这个没有想清楚,完全没有上中台的必要。

业务和中台去中心化

从阿里提出的拆中台,聊聊中台战略是否过时?

 

在大中台小前台整体思路下,可以看到中台越做越厚,能力越来越强,前台逐渐变成仅仅是中台能力的组装和编排。正如前面我谈到的,一个前台应用的完成就必然会依赖大量的中台能力中心提供的服务接口,这种依赖越多,那么前台的自治能力越弱。

其次,前台依赖中台,很多前台之间的应用协同交互则需要通过中台中转才能够完成,这本身也是加长了业务和数据流的流转链条。

在微服务架构里面经常会强调去中心化,去中心化架构下强调尽量不要去引入一个大的集成点,这个集成点可以是类似ESB总线这种集成平台,也可能是共性依赖的中台能力层。

前面拆中台,里面有个重点就是中台本身拆分小,每个中台能力中心都独立自治,也不需要再通过能力开放平台进行能力聚合和开放。

前台应用和中台能力之间应该逐步形成一种去中心化的架构,前台节点和中台节点之间可以去中心化交互,同时前台和前台间,中台和中台间同样也可以去中心化集成和交互。在这种模式下往往更加容易扩展单个节点能力,同时降低对整体中台层的依赖。

从阿里提出的拆中台,聊聊中台战略是否过时?

 

对于拆中台,我们完全可以参考类似ServiceMesh服务网格思路,对于企业的业务能力组件化后也形成业务能力网格交互,彻底的将业务去中心化,管控流和业务数据流分离。因此,拆中台并不是说中台没有了,而是中台这个很厚的共性订座不再存在,中台能力变成了一个个可以独立提供服务接口的能力单元,并去中心化协同。


 

相关 [阿里 中台 中台] 推荐:

从阿里提出的拆中台,聊聊中台战略是否过时(201226)

- - 人月神话的BLOG
最近一段时间有个热点经常被大家转发,就是阿里拆中台. 起因是阿里张勇在内网发文谈到中台太厚,反而影响到了阿里业务发展和敏捷响应能力. 从15年张勇提出大中台,小前台战略,到今天又自我否定提出了拆中台,那么是否真正中台战略思想已经过时. 对于这里的拆实际应该从两个方面理解. 其一是分拆,即原来的中台太大了需要进行分拆,从谈到最多的业务中台和数据中台,包括业务中台能力也进一步分拆为独立的中台,比如人力服务中台,供应链中台,知识和搜索中台.

中台经验谈——从京东、阿里到科蒂

- -
我在京东的搜索与大数据团队和阿里集团中台都待过,后来换到品牌科蒂(全球第三的美妆公司)做数字化转型,也就是在跨国公司做中台. 所以我就从业务和组织架构层面跟大家聊聊在甲乙方都转了一圈后的感受. 2015 年中旬,马总参观 Supercell 游戏公司后,提出按照“大中台、小前台”理念对阿里进行组织升级(注意是组织升级,不单单是技术).

七问七答:亲历者讲阿里中台落地的实践

- - 人人都是产品经理
笔者2013年转岗到阿里巴巴交易平台,从2014年开始推动阿里巴巴交易运营平台的建设(阿里交易中台的前身),此后推动阿里巴巴交易中台的建设直到2016年离开阿里创业. 本篇文章中,笔者从自己的工作经历出发,为大家介绍了阿里中台落地实践的具体情况. 在过去一年的时间中台这个词流行了起来,从市面上的文章看很多朋友讲中台的时候倾向于把平台等同于中台,甚至是后台当中台.

细品中台

- -
两年前正当中台概念爆发的时候,我曾经写了三篇文章(. 网易杭研的中台往事)对中台做了一次梳理,这两年,中台仍然持续是热门话题(虽然没有更热),我们及行业对中台的理解和实践也有了长足的进步. 从我们而言,两年前我们的中台和支撑技术(如网易轻舟和有数)只能说有了基础,这两年都成熟很多. 我们也服务了一些外部客户,获得了一些非互联网行业中台经验.

再谈企业中台(12.02)

- - 人月神话的BLOG
首先我再整理下我原来提到过的一些关于企业中台的观点. 企业中台是企业共性业务能力的下沉,体现的是业务能力可复用和灵活组合. 企业中台区别传统的IaaS和PaaS平台,更多是一个业务平台,包括了业务中台和数据中台. 中台构建本身参考了微服务架构思想,并基于业务高内聚进行了微服务化并提供能力. 对于一个专业细分的业务领域而言,软件企业要做的就是将对业务领域的多年经验和理解沉淀到业务中台,形成可复用的各个业务中台能力中心,然后为上层灵活多变的各类应用提供服务能力.

微服务架构-数据中台和业务中台(3.27)

- - 人月神话的BLOG
首先我们看下阿里巴巴Aliware团队对企业中台的定义. 即企业中台是由业务中台和数据中台构建起数据闭环的运营体系,实现以数字化资产的形态构建企业核心差异化竞争力. 在原来我谈企业中台的时候,很少专门谈到数据中台和业务中台,更多谈的是技术中台和业务中台,技术中台类似我们原来说的技术平台层和业务不相关.

谈谈中台架构之交易中台

- - 掘金 架构
中台的概念说了好多年了,起源就是芬兰的游戏公司 supercell,之后阿里就提出了大中台小前台的战略,然后和疯狗一样侵蚀了中国. 很多小公司为了显得牛逼,管他呢,干他,就要硬怼个中台出来,反正有个名字叫出来就显得很叼的样子. 其实然并卵,中台的目的还是为了更快的能承接业务的需求,释放开发的重复劳动.

谈业务中台模块识别(12.03)

- - 人月神话的BLOG
注:图片来源于阿里云栖大会相关材料. 再谈业务中台前,首先看下对于中台原来我们一般说法就是包括了业务中台和数据中台,而现在另外一种说法是包括了业务中台,数据中台,技术中台和AI中台. 而实际上 对于技术中台不建议划分到中台里面,可以划分到底层的技术支撑平台,属于技术PaaS平台的一部分. 而对于AI中台单独划分出来本身也没有必要,AI中台可以划分到数据中台的大范畴里面.

谈业务中台构建场景(12.04)

- - 人月神话的BLOG
注:图片来源阿里云栖大会材料. 最近我谈企业中台的文章比较多,主要原因还是我们看到企业对于中台构建的需求越来越多,这里面有些企业是想参考互联网企业的最佳实践,觉得是业务和技术发展趋势,但是中台建设究竟提供哪些业务价值并不清楚,还有一些企业是确实明白了一点,就是我原来提到过的中台是企业核心共性业务能力下沉,是属于企业业务资产和核心竞争力.

有赞数据中台建设实践

- - IT瘾-dev
概述究竟什么是中台, 业界并没有一个标准答案, 各个厂商都有自己的定义. 笔者比较认可的一个定义是 ThoughtWorks 提出的"企业级能力复用平台". 各个领域涌现出很多中台产品, 如业务中台, 搜索中台, 数据中台等. 其中数据中台这个词汇越来越多的出现在视野中, 从百度指数中可以看到这一趋势.