“三层式”清结算中台

我们都知道清结算，因为有一系列文章做了详细的介绍；我想我们很多人也都知道中台，因为这个概念活了很长时间；那么什么是“清结算中台”呢？

我想也很容易理解，无非就是用“中台的理念”建设“清结算体系”。

要想做好中台，首先就要理解什么是中台，中台的核心是什么；清结算的相关系统如何向中台靠拢，做成中台的样子…… 这是这篇文章要介绍的内容。

可以说我们在创造一种事物或者系统建设的理念和方法，抽取这个理念和方法首先就需要挖掘其最核心最突出的特征；清结算业务或者相关系统本身跟商品系统、购物车、订单、服务履约等系统，除了功能模块不同以外本质没有实质性差别，都是基于某项业务将功能集成了一个系统；所以说在系统本身没有最突出的特征；那么最突出的特征就必然从“中台”这个系统建设理念上去挖掘。

什么是中台呢，中台又有什么最核心的特征；我们常说的抽象通用能力，规避重复建设等这些是中台的目的；而我们分析中台的核心特征可以概括为这样一个模型：三层式。

如果将清结算体系规范成“三层式”去建设，那么就是“清结算中台”，这三层式是什么呢？

一、业务层

清结算中台要关注业务场景，为业务场景提供系统服务，多业务线，复杂的业务场景中的清结算业务是清结算中台服务的对象，所以说清结算不再是独立的一个个后台系统，而是一个服务集群，我们要基于“服务”去建设系统。

二、服务层

服务层是基于服务对象抽象出来的服务单元，就像我们去银行办事，大厅的接待员会接待你。

传统上来说她是个接待员，但是站在服务的角度，她提供了“接待服务”；虽然她还是她，虽然接待还是接待，但是已经大不同；基于接待服务去思考，我们会更关注服务本身，而不是她这个接待员；所以清结算中台，我们不再关注清结算体系内单独的系统本身，而是去关注这套系统能向外提供的服务，以服务论影响。

既然是“服务层”，那么我们就需要去抽象这些服务，定义这些服务，以及设计这些服务的准入标准、流程、规范，以及这些服务的提供方式，API、MQ、SQL还是……

三、基础层

这一侧就如“接待员”一样，是我们对外提供服务的能力基础，所以我们可以称之为“能力基础层”。

这一层是以系统能力为建设对象，比如清算计费的能力、账务记录的能力、账户冻结的能力；这些能力简单的说就是我们曾经的叫“功能”的另一个说法，为了显得我们是一个专业的中台，我们对外宣称，我们这不是简单的功能，而是能力集群。

这三层之间的关系，我们不如用一段描述来定义；公司的业务复杂，为了规避重复建设，搭建通用的系统，可以多业务线复用，未来新业务可以复用。

我们基于业务场景进行抽象，抽象出原子化的服务单元；这些服务单元需要一系列的系统功能来支撑，而这些系统功能抽象出通用的系统服务能力，将这些服务能力进行封装，构建成了一个能力集群，所以说清结算中台的未来要关注三个东西。

基于业务场景构建基础能力，反过来将基础能力封装出标准服务，去覆盖更多的业务场景；那么清结算中台其实就是做下面的三件事。

对清结算中台的能力集群进行更简洁的表达，将多个能力进行分组，对每一组从业务视角阐述，我们就可以得到清结算中台的几大服务集群。

所以如果大家要做清结算系统，那么就做好系统的架构和功能；如果要做清结算中台，那么就做好“三层式”，定义好每一层以及每一层之间的协同；然后在每一层内做好更细颗粒度的规划和抽象，至少你会是一个合格的“清结算中台”的样子……

思维模型只不过是翻山越岭沧海桑田以后对这段路途最刻骨铭心的归纳和抽象！

#作者#

陈天宇宙，微信公众号：陈天宇宙。多平台支付领域专栏作者，十年资深产品；天使投资人；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！