“中台”的概念火了之後，不論業務場景是否適合，稍微有一些聚合功能的產品架構都被冠以“中台”的頭銜。本文以一個業務中台產品的角度分析如何“盤活”一個業務中台。
一箇中台項目的存在，必然要有它的積極意義：
中台具有天生的區別於普通業務的特點，而捋清楚業務中台的特點能幫助更好的在場景下提煉架構。
自從“中台”的概念火了之後，感覺什麼都在蹭它的熱度，不論業務場景是否適合，稍微有一些聚合功能的產品架構都被冠以“中台”的頭銜，甚至於還存在實現基本聚合功能之後的中台項目就邁入了冰封期（那為啥還搞中台，沒有意義嘛！）。
但卻並非所有場景都適用，以下情況相對適用：
綜上所述，中小企業業務單一的場景下，執着於開發中台，只會消耗成本，畢竟，中台需要較大成本，接入方的接入也會耗費一些成本。
以目前我所遇到的情況來進行分析，試驗之下主站的打卡挑戰活動帶來了不錯的戰績，也因此吸引了業務組的入駐。為了提高研發效率，統一管理活動數據，提取需求構建中台迫在眉睫。
對於挑戰活動來説，主流程為：參與活動——累加次數——活動達成。
首次架構設計及項目評審
徹底剝離業務關聯，提供後台管理活動，提供兩種活動模式，其餘包括活動主流程均由業務組自行處理。至此，所謂的業務中台僅承擔了一個數據管理的作用。
項目評審時收集各方意見，也讓我由構建者轉變為使用者的視角看待這個產品，產品的弊端暴露無疑：
我們還是趕鴨子上架的上上去了！
但我也為了讓這個中台發揮它最大的價值，“盤活”這個挑戰活動中台，做了深層次的分析：
中台的性質決定了接入方必須遵循它的規則，那既然沒有辦法避免這個問題，過度的解耦只會讓這個中台成為一個“數據庫”，與其如此，不如改變方向，讓它承擔更多的責任，參與到活動的主流程中去，同時提供多種活動模式。為了提高複用，方便後期業務沉澱，活動模式向高擴展方向設計。
終於要發揮作用了
想法只是想法，受其他因素影響，未找到時機真正“盤活”挑戰活動中台，一度讓我感到很遺憾，直到迎來了新的機會點。
歷史遺留問題導致有很多存在在多個項目甚至多個業務組中的挑戰活動，而如今希望以列表統一的方式展示給用户。這可難倒了大家（更為可怕的是，居然原本有提議寫死部分活動，What？？？），我勇敢的站了出來，開始遊説我的方案。
當然，為了“盤活”這個中台，前期是需要消耗不少成本的（這也成為了遊説過程中的一大難點），可預想帶來的收益也是可觀的：
具體實現方案不便贅述，也未必是最佳方案，隨着場景的變化，也會進行調整，但方向不會發生變化，相較於我歷史對中台產品的理解，有一點是特別的——業務中台未必要極度追求解耦，具體業務耦合程度取決於各方成本。
PS：如果有其他見解，記得評論哦～
本文由 @今天也是要暴富的Ev 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議