一個業務型產品經理眼里的中臺
編輯導讀:自從阿里巴巴提出“大中臺、小前臺”戰略以來,關于中臺是什么的文章討論已經不勝枚舉了,但是很多人對于中臺仍然是一知半解。本文作者從業務產品經理的角度出發,結合業務案例,從是什么、有什么、怎么做三個方面對中臺展開了詳細說明,與大家分享,希望能夠給大家帶來一定的啟發。
2017年秋天某個下午,星巴克大華風情店一樓,柜臺后面沖咖啡的人換了一個,今天沖泡的香草拿鐵比平時難喝,比起和店員理論,我更期待的是接下來的環節。因為我和朋友老A約在這里,向他請教有關“中臺”的原理,這個讓我身邊不少人都焦慮了起來東西到底為何物。
他們中有些人是怕錯過高科技,有些人是怕錯過風口,有些人擔心不知道中臺會給自己成長帶來不利,這也更加深了我的好奇心。
老A低著頭,翻起筆記本電腦的蓋子,一陣53231323的輸入過后,微微抬起頭,透過他那看起來好幾天沒擦過的眼鏡片,開啟了我們今天的談話。
“鐘華那本《企業IT架構轉型之道:阿里巴巴中臺戰略思想與架構實戰》看了嗎?”
“好的,沒看也沒事兒,里面的內容你看起來也沒什么幫助,講技術架構的東西比較多,你們沒有技術背景的產品經理看這本書會有啟發,但實際上幫助不大”我還沒聽清楚書名,老A把他的電腦屏幕移過來對著我,自顧自的補充說到。
(我說話了嗎?)
老A是特別資深的開發,在top2互聯網大廠里參與過無數大小項目,在大廠10年的時間里,從工程師做到了業務架構師,出來后在一家創業團隊做CTO。在他的授業計劃里,今天準備把他們公司的內容脫敏后,跟我講一個千萬用戶社交電商APP的技術架構,以及在這個過程中他們怎么中臺得到實踐。
到這里,如果你腦袋里瞬間閃過一些問號,那么,你和我當初剛聽到“中臺”時的情景一樣。接下來本文我將分三個部分,來討論你和我腦袋里閃過的問號,由此來了解什么是中臺。
- 問號1:中臺是什么?
- 問號2:中臺有什么可借鑒?
- 問號3:中臺該怎么做?
01 中臺是什么?
和老A的面基結束后,我在京東買了鐘華的書來看,書里面不少內容的語句風格是這樣的,開放存儲服務OSS、關系型數據庫服務DRDS、消息服務MQ等等,從這里我能得出的線索也僅僅是NB兩個大字了,畢竟這些技術術語聽起來是很吃力。
現在回想起來,老A當時對我說的話,也不無道理。阿里巴巴提出“大中臺、小前臺”戰略的一個初衷是為了規避重復開發相似功能的問題,這也就意味著中臺是技術驅動。
至今我還清楚記得,老A他們的技術架構是按照業務來區分,總共是17個微服務,每個微服務提供了豐富的API接口,其他業務單元只需根據自身的運營需求來調用這些API就行。這樣的架構能讓單個業務的效率更高的同時,也能讓系統更安全。
他舉了個例子,比如在做中臺構建之前的某次雙十一,由于秒殺業務的流量飆升,導致了他們其他業務模塊也收到了影響,有的用戶在支付訂時無法支付的情況發生。
這17個微服務之一的“用戶中心”,支撐的業務有用戶登錄注冊、用戶畫像生成、用戶標簽生成更新、風控系統、優質用戶管理、黑名單用戶自動生成等等,這里面單獨一個業務都可以是一個復雜的產品,而這些業務之間又是高度關聯的。
比如說黑名單用戶就和風控系統離不開,而這兩個東西又和用戶的畫像關聯度高。把這些關聯度高的業務集合在一個微服務里面,抽離出高度相似的場景,然后為這些場景去開發功能,當其他業務需要的時候就可以直接調用,這也是阿里巴巴提出中臺時提到的一個關鍵特點,歸攏高度相似的業務,把底層功能開發出來提供支撐,避免重復開發。
那中臺是什么呢?
我們通過兩個例子來嘗試理解,中臺是一個什么樣的存在。
例子一
圖1-1 中臺示意圖
我理解中臺分為以下三步:
- 第一步,先把APP上的一切內容、數據抽象為底層;
- 第二步,把這些內容和數據管理的功能歸納成一層,這一層也就是中臺了;
- 第三步,抽離出哪些端或業務在使用中臺對應的功能,比如APP端、PC端、微信小程序分別用中臺里面的哪些功能,這也就能理解中臺了。
我們展開看第二層里面的商品管理,一個商品從采購計劃制定開始,直到商品最終發送到用戶的手中,中間至少需要經歷入庫、信息采集、上架、借調/出庫,而這些環節并不是在相同的一個系統里面能完成的,比如入庫、信息采集、出庫是由商品管理系統進行管理的,也就是我們常說的WMS系統(Warehouse Management System),而上架和發貨訂單管理又是由商城的運營后臺系統進行管理的,我們假設該系統為PMS(Plant Management System)。
同一個商品,需要先經過WMS系統入庫、再上架到PMS系統去進行售賣,PMS系統售賣出去后又需要回到WMS系統進行發貨出庫,再把物流信息和庫存信息同步會PMS系統。
針對商品管理的系統原理是一樣的,那同一個商城如果有多個售賣業務的話,就不需要去重復開發雷同的功能了,只需要把最底層的商品管理做成可配置或可靈活調用的基礎設施,其他業務只需要把其中的參數進行修改就能繼續復用,節省團隊大量的人力物力。
例子二
我在對接開放平臺的過程中,越發覺得各種開放平臺其實也是一種中臺,比如說支付寶支付、微信支付能力是介于開發者和銀行系統之間的一種服務能力。
比如一個賣書的APP,用戶在APP端使用購書服務,中間的支付環節是由支付寶或微信支付承接的,至于最后面銀行對應的清算系統開發者完全沒有觸碰到,在這個業務流程里面來看,支付平臺也承擔著中臺的角色。
我們回想一下,用戶網易嚴選APP上購買了一個拖把、又去得到APP上購買一套心理學課程,也就是說,不管用戶支付實際商品、還是購買虛擬服務,這兩個場景下都調用了同樣的支付APP來進行了支付,支付是一個高度相似的場景。
支付開發平臺給商家通過代付代收、科目明細服務,支付平臺在后面已經把資金管理、支付渠道對接、支付訂單建立與通知等等工作做完了,對外打包成一個簡化的接口,開發者僅僅需要調用即可。
這里可以得出一個啟發,在某些功能設計的過程中,產品經理可以借用中臺的思想去進行構思。
結論:中臺是一種高度集成、有共同特征的不同業務可復用的技術架構方案。
02 中臺有什么可借鑒?
在拜讀了鐘華《企業IT架構轉型之道:阿里巴巴中臺戰略思想與架構實戰》后,我理解的中臺至少有以下兩個優勢可以借鑒。
1. 避免重復開發
我的產品經歷里面有一個案例,進入了一個新的項目組做增長,和團隊合計下來后決定做砍價功能,Boss覺得原來的老系統太復雜了,希望我們沖洗做砍價功能。
明顯,需要重新開發商品管理、訂單管理,團隊如實和Boss反饋了情況后,建議先在原有的系統上做延伸,若砍價業務的業務增長要求需要我們去做一個新的系統的時候,我們再重新做。
如果新作一套砍價系統,后面不僅僅是商品管理、訂單管理需要重新做,商品庫存的及時同步、運營平臺和倉庫管理系統之間訂單狀態的同步等功能也相當于是要重新對接,重復開發并不是什么好事。中臺思想在這個過程中能起到較好的引導作用。
2. 簡化復雜
作者在書中提到的一個事實,淘寶的WAR包里面有200多個功能,這些功能里面有些更新頻次低,而運營類的功能更新頻次較高,這樣導致淘寶平臺整體業務受到影響的情形出現。
隨著淘寶業務的增長,功能變得越復雜,作者在書里有一張被無數錯綜復雜電線纏繞的電線桿,用來形容淘寶當時復雜的系統。經過沉淀,截止書出版時阿里集團超過25個業務單元均是由“共享事業部”提供服務(中臺),如下圖所示;
圖2-1 共享業務事業部在阿里巴巴業務架構中的重要地位(截圖來自鐘華的書)
03 中臺該怎么做?
在向老A請教完之后,已經有一個明顯的結論在我心底產生,如果要回答中臺該怎么做,我的結論是“中臺是在業務上長出來的,不是刻意做出來的”。
管理學上有一個理論是組織結構是由業務決定的,團隊里面需要什么樣的人是由于公司的業務發展到那個階段了,需要有對應技能的人才來做支持,所以業務的發展決定著公司的人員、管理結構。通過這個理論可以映射出一個結論,隨著業務不斷的新增和發展,對應的功能也變得越來越復雜,而中臺在復雜的功能里面能夠起到簡化的作用。
那中臺要不要做呢?
我不建議創業團隊去構建自己所為的中臺,這有兩個原因:
第一個原因是構建中臺對應的是一個完整的業務模型,我們回頭看本文前面提到的那張圖2-1,創業團隊的業務不會復雜到需要這么個復雜的系統來支持,不要把簡單的事情復雜化;
第二個原因是資源投入問題,小團隊的問題不是去建立復雜的中臺系統,如果小團隊的目標是A,那么構建中臺只不過是個方法,可能它能解決的問題是BCD,并不能解決A的問題,小團隊應該把資源集中在重要的問題上。
后記
自從老A給我分享了中臺的理念后,就一直對我很受用,我和團隊在后來的項目中也經?;凇氨苊庵貜烷_發、簡化復雜”的想法去設計產品功能。最后分享一個簡單的例子,對中臺思想做個的實踐做個補充。
圖3-1 用戶中心后臺原型(筆者項目原型截圖)
圖3-2 用戶中心接口輸出說明圖
用戶中心向其他業務提供用戶所在城市、用戶行為標簽、支付標簽、風控標簽等等接口,可支持查詢和調用,大大提升運營效率。
例子一:A/Btest
新功能或者是新的業務需要驗證時,APP版本管理可以調取用戶中心提供的任意接口,把新版本提供給指定用戶群體自動更新,比如我們提取抽用戶收件信息里面用戶所在城市,針對該城市的用戶發新版本;
例子二:定向營銷
根據用戶的指定標簽推送對應的營銷活動,提高推送準確度的同時,讓活動有效曝光給匹配的用戶;對于不活躍的用戶,還可推送定向召回的內容,提升用戶活躍度;
例子三:精準推薦
我們當時在個人主頁和購物車頁面都有推薦商品列表,這里的推薦商品就是根據用戶的標簽、購買能力、活躍時段進行組合后推薦的,并不是簡單的按照商品的發布時間來做顯示,幫助商品提高流通效率。
最后,中臺不僅僅是技術活,也是產品經理該踐行的一種思想。
#專欄作家#
芒果道長,人人都是產品經理專欄作家,起點學院特聘導師。
本文獨家首發于人人都是產品經理,未經本站許可,不得轉載,謝謝合作。
題圖來自 Unspalsh,基于 CC0 協議。
講的不錯,受教了,中臺解決功能復用的問題,不過前提是需要有一套完整的產品體系,大、小廠都適用。
還是要由業務決定的,業務本身不復雜的話,中臺也沒啥用,哈哈