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

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

文章插图

1.0中台中的计费不支持授信，此时我们使用插件；
调用中台还是商户预充值服务：虚拟充值金额2万，以此让中台认为该商户已经完成还款充值，此处的还款充值额度就为给商户开的授信额度；
在插件中记录2万为授信额度，在月底的商户账单中自动冲销2万元，从而实现金额的闭环。

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