如何做好一个业务中台框架

好的中台是能够应对未来业务的不确定性的。

比如你过去建设的一些能力，在未来新业务出现时，是可以为新业务的建设落地提效的，一旦做到了这样的效果，那么这个业务中台就是一个好的业务中台。

做好中台的关键点是什么？

首先，好的业务中台，要得到决策层对组织的支持。

如果要做一个共享能力中心的话，一定是在整个组织上形成一个共识。

并且要去定义能力中心这个组织，他的人才是跨领域的。因为中台是面向业务的，所以业务专家和技术专家，需要深度参与，并且互相拥抱。

其次，业务中台在落地时要有经验丰富的专家。

大家要对中台的理解和研究非常的深。

还有，在交付团队里面，要有对每个领域知识理解非常深的交付专家。

以上是三个非常重要的要素。

好的中台要构建和沉淀可复用的业务能力，如果要沉淀可复用的能力，就需要有专家，懂技术、懂业务的专家。

复用是中台的核心能力。

复用很重要，但不代表不被修改，不被修改的完全复用是不现实的。

被复用的能力是需要持续长大的。

能力复用包括直接复用，能力需要被在线复用，比如通过api方式复用。

另一种复用是扩展复用，通过改变小的业务逻辑，让前端去扩展，进而复用了过去大部分核心的能力，这是一种扩展的复用。

扩展复用分为几个层次，包括数据层的复用，业务逻辑层的复用，还有一种是沉淀资产的分发复用。

比如在总部构建了一系列的基础能力，各个省中心调研总部服务是有些困难的。所以总部需要将能力分发到省中心去，然后他们再去共享复用。

这是一种资产在总部进行沉淀，然后分发到外部去做中台，可以叫做分布式中台。

总部需要一种能力，去看到各个分公司的复用是不是真的用起来了，用的情况怎么样，之前简单的代码拷贝独立部署的方式是做不到这点的。

所以，应用能力分发也是一种复用方式。

除了复用之外，有的时候需要多种能力的组合。

我们常讲的业务敏捷，就是说你的能力要原子化。原子化之后，要有一套工具可以把他们再组装起来。

比如组装成一个流程，或组装成一个更大的业务单元。

所以，总结来说，首先的复用是状态的复用，通过api。

还有一种是分发之后再共享复用。

还有一种是把这些业务能力组装，通过工具快速的去做组装，再去复用。

这种工具，往往是一个低代码工具，可以解决一些不懂技术的业务人员做创新，他们把原子能力再组装成一个新的业务。

当然，最传统的一种复用是代码复用。

但代码复用有一个问题，就是代码和文档常常是对不上的。

这个问题怎么解决呢？

想到一种方法，就是通过代码快速去还原一些领域模型，数据模型。

也就是有一种能力，实现了代码和模型的同步，那么在这种情况下复用，可以快速去理解这个代码，也能去做复用。

一个平台变大之后，api非常多，比如5000个api，这些api就变得越来越难以理解，你想要找到想要的api就比较困难了。

像阿里，就提出了能力地图的工具，帮助你找到快速复用的能力，帮助你去理解哪些东西是可以复用的。

中台成不成功，复用是非常重要的一个指标。

比如api被调用得越来越多，说明他的能力是成功的。

比如应用支持分发，去支持其他事业部，证明你的能力是成功的。

另一个考核能力的重要指标是稳定性，因为用的人多了，稳定性差影响的人就多了。

所以能力先复用，再易用，再好用。

能力不只让技术看懂，还要让业务看懂。

如果一个组织中可复用的能力超过80%，那么这个组织再重新支持一个新业务的话，可能大部分的能力都不需要做了，这样你的业务的上线时间就非常短了，效率变高了。

那如何做，实现中台能力的可复用运营呢？

关键点在于，业务能力中心的规划。

本质是你如何解构你的业务，企业中有不同领域的不同能力。解构能力的粗或细，都会影响到未来复用性上和组装能力上的效果。

中台能力的定义，是业务人员和技术人员相互协作介入搞定的。

需要定义出，什么样的业务能力应该放到中台，哪些不应该放在中台，这是和公司的战略相关的。

在阿里有中台委员会，会帮你看这个能力要不要放到中台来。

第二个问题是，这个业务能力应该放在哪个业务中心，这背后和你业务逻辑的解构有关。

要用产品思维做中台，把中台看作产品，不断迭代。

做好中台，首先要有好的架构，要有好的工具，接下来是持续得运营。

微服务不等于能力中心，但能力中心基本上都是通过微服务实现的。

一套微服务框架，加上一套DevOps，基本上就是一个中台技术的标配。

微服务是个技术，但我们聊的复用，是业务和技术的一个协同。

比如我们做业务解构时，经常用DDD这样的理念去解构业务。

中台后半部分是持续运营，我们要有工具做到持续运营。

先发现哪些能力需要运营，需要一种发现机制，就是说能力是需要可发现的，接下来才能谈可复用。

所以业务的概念，要通过框架能力注入到架构里面。

所以在微服务基础之上，定义了一套框架，框架可以把技术和业务做更好的协同，就是把它定义出来。

通过这个框架提供的工具集，进行数据建模，领域建模，然后一键生成这个框架的框架代码。

这套生成的代码跑起来，是需要配套的容器环境支持的，代码跑起来之后，还需要考虑如何做应用的分发。

在不同可用区下，如何把基础资源调度起来。

在框架中，如果要做扩展实现和差异化的复用，比如对同一个api的不同调用方的不同sla，其实背后也是靠着不同的容器实现的，类似于不同业务角色的不同租户。

在能力定制之后，需要有一个服务于应用分发的工具和技术。

核心解决可组装业务能力的实现，围绕于可组装业务能力提供一站式工具，同时降低了一系列使用层面的门槛。

对于框架，组装和持续能力是用得比较多的功能。

总之来说，框架要缩短客户获取可共享，可组装的业务能力的时间，这是框架为业务带来的关键价值。