代码段|业务中台09:中台实战中的特异性问题管理( 二 )


可以说插件可以帮助业务线既接入中台,同时又去符合了新业务的特性,那么这就是插件带来的意义。
假以时日等到这条业务线变得越来越健壮了之后,这个业务越来越成熟,越来越多业务线都需要该插件的功能后,我们再把这个插件拆掉,让插件升级为中台的一个能力,这样的情况下是中台最安全最节省成本的一种方式。
那这里我们还是以一个具体的案例来看,在L电商内部是怎么使用插件解决这个问题的。
三、案例:L电商公司中台插件引入在之前的文章中,我阐述过L公司中通过商户全局商户号与全局协议,我们实现了对商户的唯一化管理,但是随着业务的发展,特别是当我们与一些头部客户合作时,头部的客户对我们提出要求,要求我们在原有账期到期后,在打款期间依旧能临时使用我们的服务。
也就是需要我们在这段时间给予商户一个授信额度,允许在规定账期之外对我们进行赊账。
但是这个时候,已经标准化了的整个商户管理服务和支付中心不支持这样的服务,在到达账期后,商户不进行结款,不会允许商户进行使用。
面对这样的业务需求,我们不得不跳过中台所提供的部分功能,从而满足这位客户的个性化需求。
当时我们有两种解法,第一种解法立即启动中台升级,在支付中心中增加授信模块,但是这样做等待时间比较长,无法及时响应客户现在的需求。
第二种方法就是我们要去介绍的通用中台特异性管理方法,由业务线提供个性化服务的代码段来跳过中台的限制,从而既不破坏中台的要求,又能符合业务的新需求。
根据前面的介绍我们知道这个代码段有它自己特殊的名称,也就是中台的插件,他的特征有如下两个:
具体落地到业务上来看,我们是这样实现的,如图所示
代码段|业务中台09:中台实战中的特异性问题管理
文章插图

  1. 1.0中台中的计费不支持授信,此时我们使用插件;
  2. 调用中台还是商户预充值服务:虚拟充值金额2万,以此让中台认为该商户已经完成还款充值,此处的还款充值额度就为给商户开的授信额度;
  3. 在插件中记录2万为授信额度,在月底的商户账单中自动冲销2万元,从而实现金额的闭环。
所以看到插件就是在满足不影响底层业务的情况下的一个绕弯,当然之所以不把这个业务单独拉出去去做,是因为目前我们只对接了一个客户。该模式的规模化特征还不明显,此时我们如果贸然的将它加入到中台中来,只用一次的需求对于中台来说,无疑是开发资源的巨大浪费。
所以我们会先选用插件的模式,从而快速复用中台其他的逻辑,当账期需求在多个业务线都出现,成规模化需求时,再进行中台对应模块的开发,由插件变为中台内部的一个服务。
也就是当出现多个插件使用服务时:
综上我们通过插件实现了中台实施的特异性管理。
#专栏作家#三爷,微信公众号:三爷茶馆,人人都是产品经理专栏作家,2019年年度作者。《中台产品经理宝典》作者,原万达高级产品、MBA特约讲师、独立创业者,现叮咚买菜B端产品线负责人,拥有多款集团项目从零到一经验并带领实现商业化布局。
本文原创发布于人人都是产品经理。未经许可,禁止转载
【 代码段|业务中台09:中台实战中的特异性问题管理】题图来自Unsplash,基于CC0协议。