|如何“盘活”一个业务中台？

业务中台未必要极度追求解耦，具体业务耦合程度取决于各方成本。本文以一个业务中台产品的角度分析如何“盘活”一个业务中台。

本文插图

业务中台的积极意义
【|如何“盘活”一个业务中台？】一个中台项目的存在，必然要有它的积极意义：

对公司全局：减少开发成本，提高研发效率，统一管理数据，为数据分析赋能
对各个业务组：对于中台而言，业务组就是用户， “Don’t make me think”+完美闭环是接入方最希望看到的

业务中台存在的问题
中台具有天生的区别于普通业务的特点，而捋清楚业务中台的特点能帮助更好的在场景下提炼架构。

影响面广：中台作为业务的基石，一旦出现问题，影响的是整个生产线，也因此，中台项目的质量监控应当极为严苛
不可避免的二次开发：中台作为抽取各个业务组共性需求而形成的产品，难以做到迎合所有业务组的需求，在特殊场景下势必需要进行二次开发，这也是造成推进困难的原因之一
推进困难：业务组在接入中台时，首先会考虑到接入成本以及服务可靠性，如果接入成本不低，并需要花费大量沟通成本，而且还要承担服务不可控带来的风险，那么请问，为什么不自己实现一套呢？
闭环问题：我从实践中发现，很难做到完美闭环，究其原因，一为以中台的角度确实很难考虑到所有场景情况，二为服务接入机制的不完善会导致闭环的失败

如何解决以上问题

质量监控：业务中台必须加强质量监控，并且做好兜底策略，尽量减少损失。
业务沉淀：中台既然是为了解决以前“SOA项目制”带来的问题，那么就应该拥抱变化，接受业务变化，并通过沉淀，打造一个高可用的中台服务。另一方面，多场景也能促进项目趋向于完美闭环。
完善的服务接入机制：如果业务线足够多，完善的接入机制就成了减少沟通成本的最好方法（开大会介绍产品没问题，但梳理接入方式？有一半的人能听进去就算我输）。

什么样的情况下适合构建业务中台
自从“中台”的概念火了之后，感觉什么都在蹭它的热度，不论业务场景是否适合，稍微有一些聚合功能的产品架构都被冠以“中台”的头衔，甚至于还存在实现基本聚合功能之后的中台项目就迈入了冰封期（那为啥还搞中台，没有意义嘛！）。
但却并非所有场景都适用，以下情况相对适用：

多业务线且拥有共性需求。
集中管理数据，能为用户行为、用户习惯等数据分析进行赋能。

综上所述，中小企业业务单一的场景下，执着于开发中台，只会消耗成本，毕竟，中台需要较大成本，接入方的接入也会耗费一些成本。
案例分析——以挑战活动中台为例
以目前我所遇到的情况来进行分析，试验之下主站的打卡挑战活动带来了不错的战绩，也因此吸引了业务组的入驻。为了提高研发效率，统一管理活动数据，提取需求构建中台迫在眉睫。
对于挑战活动来说，主流程为：参与活动——累加次数——活动达成。
首次架构设计及项目评审
彻底剥离业务关联，提供后台管理活动，提供两种活动模式，其余包括活动主流程均由业务组自行处理。至此，所谓的业务中台仅承担了一个数据管理的作用。
项目评审时收集各方意见，也让我由构建者转变为使用者的视角看待这个产品，产品的弊端暴露无疑：