本文以一个业务中台产品的角度分析如何“盘活”一个业务中台。
业务中台的积极意义
一个中台项目的存在，必然要有它的积极意义：
- 对公司全局：减少开发成本，提高研发效率，统一管理数据，为数据分析赋能
- 对各个业务组：对于中台而言，业务组就是用户，“Don’t make me think”+完美闭环是接入方最希望看到的
业务中台存在的问题
中台具有天生的区别于普通业务的特点，而捋清楚业务中台的特点能帮助更好的在场景下提炼架构。
- 影响面广：中台作为业务的基石，一旦出现问题，影响的是整个生产线，也因此，中台项目的质量监控应当极为严苛
- 不可避免的二次开发：中台作为抽取各个业务组共性需求而形成的产品，难以做到迎合所有业务组的需求，在特殊场景下势必需要进行二次开发，这也是造成推进困难的原因之一
- 推进困难：业务组在接入中台时，首先会考虑到接入成本以及服务可靠性，如果接入成本不低，并需要花费大量沟通成本，而且还要承担服务不可控带来的风险，那么请问，为什么不自己实现一套呢？
- 闭环问题：我从实践中发现，很难做到完美闭环，究其原因，一为以中台的角度确实很难考虑到所有场景情况，二为服务接入机制的不完善会导致闭环的失败
如何解决以上问题
- 质量监控：业务中台必须加强质量监控，并且做好兜底策略，尽量减少损失。
- 业务沉淀：中台既然是为了解决以前“SOA项目制”带来的问题，那么就应该拥抱变化，接受业务变化，并通过沉淀，打造一个高可用的中台服务。另一方面，多场景也能促进项目趋向于完美闭环。
- 完善的服务接入机制：如果业务线足够多，完善的接入机制就成了减少沟通成本的最好方法（开大会介绍产品没问题，但梳理接入方式？有一半的人能听进去就算我输）。
什么样的情况下适合构建业务中台
自从“中台”的概念火了之后，感觉什么都在蹭它的热度，不论业务场景是否适合，稍微有一些聚合功能的产品架构都被冠以“中台”的头衔，甚至于还存在实现基本聚合功能之后的中台项目就迈入了冰封期（那为啥还搞中台，没有意义嘛！）。
但却并非所有场景都适用，以下情况相对适用：
- 多业务线且拥有共性需求。
- 集中管理数据，能为用户行为、用户习惯等数据分析进行赋能。
综上所述，中小企业业务单一的场景下，执着于开发中台，只会消耗成本，毕竟，中台需要较大成本，接入方的接入也会耗费一些成本。
案例分析——以挑战活动中台为例
以目前我所遇到的情况来进行分析，试验之下主站的打卡挑战活动带来了不错的战绩，也因此吸引了业务组的入驻。为了提高研发效率，统一管理活动数据，提取需求构建中台迫在眉睫。
对于挑战活动来说，主流程为：参与活动——累加次数——活动达成。
首次架构设计及项目评审
彻底剥离业务关联，提供后台管理活动，提供两种活动模式，其余包括活动主流程均由业务组自行处理。至此，所谓的业务中台仅承担了一个数据管理的作用。
项目评审时收集各方意见，也让我由构建者转变为使用者的视角看待这个产品，产品的弊端暴露无疑：
- 由于所有业务逻辑由业务组自行决定，解耦的同时带来了大量的二次开发成本
- 没有完善的接入机制，甚至于没有足够容易理解的文档，也给接入带来了不小的沟通调试成本
我们还是赶鸭子上架的上上去了！
但我也为了让这个中台发挥它最大的价值，“盘活”这个挑战活动中台，做了深层次的分析：
中台的性质决定了接入方必须遵循它的规则，那既然没有办法避免这个问题，过度的解耦只会让这个中台成为一个“数据库”，与其如此，不如改变方向，让它承担更多的责任，参与到活动的主流程中去，同时提供多种活动模式。为了提高复用，方便后期业务沉淀，活动模式向高扩展方向设计。
终于要发挥作用了
想法只是想法，受其他因素影响，未找到时机真正“盘活”挑战活动中台，一度让我感到很遗憾，直到迎来了新的机会点。
历史遗留问题导致有很多存在在多个项目甚至多个业务组中的挑战活动，而如今希望以列表统一的方式展示给用户。这可难倒了大家（更为可怕的是，居然原本有提议写死部分活动，What？？？），我勇敢的站了出来，开始游说我的方案。
当然，为了“盘活”这个中台，前期是需要消耗不少成本的（这也成为了游说过程中的一大难点），可预想带来的收益也是可观的：
- 极大减少了接入方二次开发的成本
- 解决了历史遗留多项目难以数据聚合的痛点
- 为更多模式活动的开发预留了空间
结语
具体实现方案不便赘述，也未必是最佳方案，随着场景的变化，也会进行调整，但方向不会发生变化，相较于我历史对中台产品的理解，有一点是特别的——业务中台未必要极度追求解耦，具体业务耦合程度取决于各方成本。
