如果将服务中心再拆解一下,可以看到:

“服务中心 = 业务组件 + 数据组件 + 拓展服务”

组件服务就是前面提到的中台技术属性落地产物,提供技术复用;

拓展服务就是前面提到的中台业务属性落地产物,提供场景化复用;

要想建设一个服务中心,这里为大家带来一个标准的服务中心建设方法,也就是Summary-Details分离设计。

中台既然是要做一个可复用的一个模块,就必须要去响应不同的业务线场景,那么这里为了能实现场景响应,我们就需要去把业务信息从服务中心中进行剥离,只管理摘要信息,具体的详情信息和具体的场景解决方案是由业务线去进行实践。

例如在订单服务中心中中台只存储了订单id和订单标的,其他具体的详细信息,由业务线进行设计,只有这样的建设情况下,我们的服务中心才可以去兼容各种不同的场景的订单。这实际上来说就是我们服务中心建设过程中常用的一个方法。

看完了服务中心建设后,我们最后再来看一个东西,叫做中台特异性管理。

什么是特异性呢?其实就是我们在中台建设过程中,不管设计的多么好,都会遇到有一些场景它是跳出我们的中台原有流程。

这里最常见的例子就是说当我们新孵化了一个业务,他有很多流程是不按照原有公司流程去走的,那么这个时候我们要怎么去把接入中台呢?

此时中台有两种方案,一种彻底不接,第二种就是去改造中台去把他兼容进来,但是如果我们贸然去选择改造中台,由于这是一个探索业务,很有可能在中台改造完成之后或者改造过程中,这个业务就被下马了。

那这个时候我们的改造就浪费掉了,况且作为公司的基础服务中台,为了稳定性本身也不能频繁改动,所以我们要怎么解决这个问题呢?

这里就需要我们使用插件概念,让他去接入到中台中。

所谓插件也就是中台开放一些对应的接口,允许业务方去插入一个自定义的代码段,自定义代码段可以去调用我们中台的上层服务,去跳过部分场景。

我举个例子来说,我经历过一个新孵化的业务想要调用客服服务中心的服务,但是由于新业务中人员较少,原有的客服流程较长,且每一步都有对应的单据,导致新业务的客服工作压力巨大,此时我们就让该业务线以插件的形式接入中台,并在部分环节调用中台接口自动产生单据,这样就解决了新业务线的问题。

可以说插件可以帮助业务线既接入中台,同时又去符合了新业务的特性,那么这就是插件带来的意义。

所以有了插件之后,我们中台解决方案又做了一次升级,就得到了完整的方案架构:

“中台 = 服务中心(组件 + 拓展服务) + 插件”

让我们最后总结下MSS框架得出的完整中台架构内容:

(1)调研阶段完成了完整的企业内外双重调研

(2)预建阶段完成了企业内部标准化建设

(3)建设阶段完成了服务中心与特异性性管理

4

中台实战建设的复盘感悟

在我们完成了整个中台建设方法论的讲解之后,接下来我来谈一谈,在我经过了这么多中台项目之后,对于中台建设的一个感悟:中台为什么难建?

从这张图上我们其实看到一家企业的信息化过程实际就是从左至右的四步,我们看到所有产品功能的本质都是在为企业战略服务的。

因此就是我前面所说的中台建设的本质是企业自身管理上的一次升级,所以需要管理者能去规范企业内部运营管理,而规范管理的本质就是这三个框出来的部分(IT架构/企业架构/企业战略架构)的一次标准化

所以中台建设的核心难点在于如何将不同业务线的这三部分标准化,找出一套统一的规则。

“中台建设的根本难点是企业的内部管理如何升级而不是中台系统开发”