|如何“盘活”一个业务中台?( 二 )

我们还是赶鸭子上架的上上去了!
但我也为了让这个中台发挥它最大的价值 , “盘活”这个挑战活动中台 , 做了深层次的分析:
中台的性质决定了接入方必须遵循它的规则 , 那既然没有办法避免这个问题 , 过度的解耦只会让这个中台成为一个“数据库” , 与其如此 , 不如改变方向 , 让它承担更多的责任 , 参与到活动的主流程中去 , 同时提供多种活动模式 。 为了提高复用 , 方便后期业务沉淀 , 活动模式向高扩展方向设计 。
终于要发挥作用了
想法只是想法 , 受其他因素影响 , 未找到时机真正“盘活”挑战活动中台 , 一度让我感到很遗憾 , 直到迎来了新的机会点 。
历史遗留问题导致有很多存在在多个项目甚至多个业务组中的挑战活动 , 而如今希望以列表统一的方式展示给用户 。 这可难倒了大家(更为可怕的是 , 居然原本有提议写死部分活动 , What???) , 我勇敢的站了出来 , 开始游说我的方案 。
当然 , 为了“盘活”这个中台 , 前期是需要消耗不少成本的(这也成为了游说过程中的一大难点) , 可预想带来的收益也是可观的:

  • 极大减少了接入方二次开发的成本
  • 解决了历史遗留多项目难以数据聚合的痛点
  • 为更多模式活动的开发预留了空间
结语
具体实现方案不便赘述 , 也未必是最佳方案 , 随着场景的变化 , 也会进行调整 , 但方向不会发生变化 , 相较于我历史对中台产品的理解 , 有一点是特别的——业务中台未必要极度追求解耦 , 具体业务耦合程度取决于各方成本 。
PS:如果有其他见解 , 记得评论哦~
本文由 @今天也是要暴富的Ev 原创发布于人人都是产品经理 。 未经许可 , 禁止转载
题图来自Unsplash , 基于CC0协议


推荐阅读