最近處處惹人愛的中臺到底是什么
在當下互聯(lián)網(wǎng)圈子里要問什么最火莫過于中臺這一概念了,各大公司都開始了一輪跑馬圈地似的中臺建設,那么到底中臺是什么呢?本文我們就來談談這個話題。
一、什么是前臺,后臺
在以往的互聯(lián)網(wǎng)企業(yè)生產(chǎn)流程中,我們可以將研發(fā)團隊宏觀的劃分為前臺與后臺兩部分。
所謂前臺就是用戶直接接觸到的產(chǎn)品部分,如可在應用商店下載的APP,像微信、抖音、淘寶,或者可以使用的網(wǎng)站等。
用戶對產(chǎn)品的認知與體驗也由此而生。比如大家對于微信的理解就是這個前臺APP展示的一切給大家描繪的:一個綠色圖標的應用,里面有我的A、B、C好友。
而后臺包含兩個部分:
- 企業(yè)的內(nèi)部管理服務的統(tǒng)稱,如:內(nèi)部的CRM,ERP等;
- 為前臺提供服務能力的,如:數(shù)據(jù)壓縮能力,并發(fā)等。
后臺最重要的特點就是其提供的服務都是不被普通用戶所感知的,就像用戶不會因為應用的并發(fā),傳輸速度而記住微信這個品牌。
在搞清楚了前臺與后臺的概念后,前后臺模式的產(chǎn)品服務模式我們就可以用一張圖來概括描述:
圖1
總的來說就是在應用中后臺提供能力與計算,前臺將后臺的能力進行封裝以圖形化的形式展示給用戶,讓用戶能更容易的使用公司提供的服務來解決個人需求。
二、中臺的白話解釋
在開始談論中臺之前,我們先要明白:當下的主流前后臺模式并不是在業(yè)務實現(xiàn)上出現(xiàn)了問題,不支持眼下出現(xiàn)的種種新業(yè)務場景;相反地,這種前后臺反而是公司最省事省力的一種提供服務的解決方案。因為這種模式不需要提供額外的建設,前臺完成信息展示與交互,后臺做好對應需求的解決邏輯就組成了一個產(chǎn)品。
實際上,中臺的出現(xiàn)更多是因為公司業(yè)務在發(fā)展到某一階段時,在擁有多個業(yè)務線時繼續(xù)發(fā)展遇到瓶頸與障礙后,為了解決如何繼續(xù)朝下走的實際問題而提出的一個組織前臺業(yè)與后臺關系新解決方案的統(tǒng)稱,而不是某個新的系統(tǒng)。
在互聯(lián)網(wǎng)進入日益復雜的市場環(huán)境的今天,市場中由于存在眾多的競爭者,也逼迫著企業(yè)需要不斷去更新產(chǎn)品去搶奪市場。
而作為實際用戶真正接觸的前臺業(yè)務,如:APP、小程序、網(wǎng)站等,必須要快速迭代新的功能才能讓用戶感知到。
而在這個大背景下帶來的矛盾就是——以往為了支撐前臺越來越多的業(yè)務,后臺不斷地建設龐大起來的系統(tǒng),由于一直在追求穩(wěn)定性而生,反而在這個時候顯得越發(fā)笨重起來。這樣的后臺變得越來越?jīng)]法去快速響應前端變化所帶來的改變。原來的前后臺模式的這種直接關聯(lián)決定了兩者的沖突不可避免。
例如:傳統(tǒng)我們的一個電商網(wǎng)站,由于用戶前端需要組織各種新的銷售方式(拼團,一元購等),導致每次活動頁面開發(fā)的時候,不僅需要前端重新設計頁面,從后臺接口提供與數(shù)據(jù)表都要重新設計。
這無疑大大拉長了我們的需求響應時間,很有可能會導致在活動模塊還沒開發(fā)完成,我們的風口就已經(jīng)過去了。因此我們需要一個能最少改動就能完成大部分需求的解決方案,這就是中臺。
中臺解決方案到底是什么呢?讓我們舉個通俗的例子來說,如果將互聯(lián)網(wǎng)公司的研發(fā)中心比作一個廚房,將研發(fā)新產(chǎn)品的過程比做菜的話,我們就可以很容易理解這個概念了。
首先請大家想一個問題,在一家客流量非常大的餐廳中我們要如何縮短客人的等待時間呢?
相信很多人的第一想法就是增加多名廚師,但時大多數(shù)的餐廳單純的增加廚師這是不實際的,因為每增加一個廚師是有很高成本的,而且每天忙的就是中午和晚上這兩個時間點,雖然在飯點解決了問題,但是在一天中其他的時間里,廚師人員就顯得非常冗余了。
而正確的做法是先將做菜這個任務拆分,讓做菜這一件事變?yōu)槎鄠€環(huán)節(jié)來思考。也就是將做菜變?yōu)椋?/p>
圖2
通過這樣的拆分后我們可以發(fā)現(xiàn)無論是做什么菜系,買菜與配菜都是共有的兩個步驟,我們完全可以只需要增加一位配菜的小哥來代替廚師去進行前兩步,這也就是現(xiàn)在大多數(shù)上規(guī)模餐廳的組織架構:
圖3
這樣我們每一位廚師新做一道菜時沒有必要一定要從買菜,洗菜,切肉這些最基礎的環(huán)節(jié)開始,而是完全可以直接使用他人切好的肉片,洗好的菜下鍋,唯一需要關心的就是如何在搭配調料上研究不同的創(chuàng)意。完全可以大大提高廚師的做菜速度,同時在成本上我們只增加了一個人就解決了所有問題。
回到研發(fā)流程來看,買菜其實就是我們研發(fā)的后臺,他們幫助我們解決最基礎原料問題。廚師是我們的一個個業(yè)務前臺團隊,他們要做的就是根據(jù)不同地區(qū)口味烹飪出對應的菜系,而在業(yè)務多元化后洗菜,切菜,配菜都可以交給中臺解決方案去完成,做菜的時候作為大廚只需要喊一句要什么材料既可,當然這里的配菜小哥就是我們的中臺。
所以說有了中臺之后我們的前臺業(yè)務就可以快速嘗試迭代,不需要每件事都是從0到1開始了。
讓我們再站在架構的層面來看看中臺對整個系統(tǒng)業(yè)務所起到的作用。
假設我們是一個電商平臺在我們未使用中臺的時候,每一個前臺的用戶終端都需要與后臺進行一次對接,就像下圖:
圖4
而后臺的每一個模塊都需要維持與前臺業(yè)務的關聯(lián),并根據(jù)不同業(yè)務前臺的特征加入適配。這樣造成的結果:
- 后臺的每一個模塊都需要加入與前臺適配的部分,從而大大加大了開發(fā)量;
- 每個前端在啟動時需要分別對接不同的后臺模塊,也加大前臺啟動時的工作量;
- 當后臺進行升級或架構調整時還需要考慮與前臺的對接,并進行逐一的調整。
當我們引入中臺后,讓中臺作為一個對接層,幫我們?nèi)ソy(tǒng)一對接前臺的不同終端,同時對后臺各個子系統(tǒng)進行統(tǒng)一的封裝,讓前臺能無感知的使用各項服務而不需要單獨設計通道,我們的系統(tǒng)也就簡化成了這個樣子:
圖5
通過對比我們能清楚的看到中臺對于公司的整個業(yè)務架構起到了非常大的簡化作用。
用一句話來概括就是:中臺的核心本質就是服務共享,目標是支持前臺的快速創(chuàng)新或試錯,而實現(xiàn)的手段是微服務架構、敏捷基礎設施和公共基礎服務。
三、中臺解決方案
那么到這我們可以給中臺解決方案下一個定義:
中臺解決方案的組成 = 能力輸出 + 標準化中間件
讓我們來一個個解釋:
第一部分:能力輸出
所謂能力輸出就是要規(guī)劃出什么是公司的核心競爭力,理清楚公司發(fā)展的戰(zhàn)略與目標與未來公司里的主要業(yè)務會涉及到哪些方面。并在這些業(yè)務層面中去提煉哪些模塊是以共性存在的,并會在每個新開拓的業(yè)務中不斷使用,然后就把他歸類到中臺進行建設。這也就是中臺的一個重要的意義:為不同的前臺業(yè)務提供可以重復使用的能力,形成一次建設多次使用。
例如我們規(guī)劃了公司的核心方向是視頻方向,未來可能會涉及的業(yè)務形態(tài)有:
- 在線視頻
- 視頻直播
- 短視頻
- ……
分析上面的業(yè)務方向我們不難判斷出最基礎要抽取的模塊可以劃分為:
- 在線視頻編輯
- 視頻壓縮
- 多人點播
- ……
完成拆分后我們就可以通過中臺去實現(xiàn)這幾個通用模塊。
值得提一下的是雖然這里在說中臺要考慮復用性、擴展性,但是要考慮多少,考慮多深這里又是一個非??简灝a(chǎn)品功力的地方。
還是舉上面的例子來說我在設計一個視頻社區(qū)APP的積分商城系統(tǒng)時,需要將商城交易方式抽象為能力時,這里我們大體上可以抽象為如下三種交易方式:
表1
但是同樣的疑問來了,我們僅僅為了支持一個積分商城需要將中臺的復用與擴展放大要考慮引入股票交易才使用到的撮合交易模式嗎?
當然這里的案例比較極端我們能快速判斷,但是在具體的中臺規(guī)劃中我們會碰到很多這種類似的范圍決策,我們必須要按照公司的核心業(yè)務規(guī)劃來嚴格定義中臺的能力,避免在中臺出現(xiàn)過度建設的現(xiàn)象。
第二部分:標準化中間件(整合能力,并封裝頭尾)
在我們確定了公司的業(yè)務發(fā)展需要哪些能力之后,中臺解決方案的另一個組成部分就是需要做一個將每個能力進行封裝,形成一個統(tǒng)一的可供前臺業(yè)務端方便使用的中間件。
這里的統(tǒng)一具體表現(xiàn)在如下的幾個方面:
- 不同終端中的叫法與含義;
- 定義統(tǒng)一化的輸入輸出;
為什么要統(tǒng)一呢?
以往的前后臺模式中同一家公司內(nèi)的不同業(yè)務如:直播項目組、短視頻項目組各自為戰(zhàn)的時候,經(jīng)常會出現(xiàn)一個事物被不同項目因為場景化的需求,而出現(xiàn)兩個稱呼的現(xiàn)象,但是實際上他們本質上是同一個事物。這也是原來不同項目組想要進行復用前人的模塊時一個天然的巨大障礙——無法快速對接。
例如:就那一個用戶昵稱這個字段來看,在不同項目組中的應用中可能會叫:用戶名稱、用戶昵稱、稱號、花名等等,而在數(shù)據(jù)庫中又可能會有不同的字段名稱:username、UN、name等等。
因此我們需要一個中心化的產(chǎn)物幫助我們定義好這些個通用屬性,使在公司中不同的業(yè)務端都能統(tǒng)一。
面對這種現(xiàn)象,在有了中臺后,我們就可以通過定義標準化的中間件來解決。以后假設公司內(nèi)部孵化的項目組再次要使用用戶昵稱這個字段的時候,無論具體是什么業(yè)務前端都會是一個叫法、一種存儲,這樣不僅能直接使用之前項目的模塊,同時還可以和公司內(nèi)部的管理系統(tǒng)如CRM/BI等快速完成對接。
四、最后
在競爭日趨激烈的互聯(lián)網(wǎng)行業(yè)中,如何低成本又快速地完成業(yè)務創(chuàng)新去占領市場是每個企業(yè)所追求的方向,而中臺解決方案的出現(xiàn)給我們當下的互聯(lián)網(wǎng)企業(yè)帶來了一個全新的發(fā)展思路。
本文內(nèi)容來自《中臺產(chǎn)品經(jīng)理寶典》一書
本文由 @?三爺 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉載
題圖來自Unsplash,基于CC0協(xié)議
專欄作家
三爺,微信公眾號:三爺茶館,人人都是產(chǎn)品經(jīng)理專欄作家,2019年年度作者?!吨信_產(chǎn)品經(jīng)理寶典》作者,原萬達高級產(chǎn)品、MBA特約講師、獨立創(chuàng)業(yè)者,現(xiàn)叮咚買菜B端產(chǎn)品線負責人,擁有多款集團項目從零到一經(jīng)驗并帶領實現(xiàn)商業(yè)化布局。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉載。
題圖來自Unsplash,基于CC0協(xié)議。
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
新加入到一個公司,模式就是“1+4+5”一個平臺 四個中臺 五個產(chǎn)品的意思,一開始并不懂中臺的意義,看完懂得了一些。
我是做 saas 產(chǎn)品的,其實一直覺得 saas 產(chǎn)品跟中臺產(chǎn)品的考慮點挺相似的,一方面都需考慮通用性,只是 saas 考慮的是各行業(yè)客戶,而中臺考慮的是內(nèi)部各前臺業(yè)務,另一方面也需要預見擴展性,saas 是為了更好滿足客戶釋放的更多需求,中臺則是為了支持業(yè)務創(chuàng)新、響應業(yè)務需求
如何做到適度建設,需求頻率、可復用性等,還有什么體系化的評判標準嗎?可以聊一下~
在我的新書以及新書的拓展30講專欄里有介紹可以參看哈
已購,支持下,哈哈 你應該也是阿里人吧
其實中臺更簡單的理解就是微服務模塊的匯聚,組合,形成新的重新組合而成的產(chǎn)品支撐服務
通俗易懂,點個贊
中臺并不是純粹解決你app、web、微信等渠道統(tǒng)一訪問后臺而衍生的概念,就像阿里只有淘寶的時候,也有app,web等渠道,但是那個時候的沒有中臺的痛點,中臺的痛點是阿里有了天貓、1688之后才產(chǎn)生的問題。
為了通俗理解的例子而已
我的理解,上述后臺的這些問題其實是后臺架構設計不合理導致的吧,加入中臺其實不就是重塑后臺了嗎?
我也覺得是這樣,后臺做好功能模塊分裝,調用起來不就不麻煩了嗎?
我的理解是:在當下是無法預知未來的變化,中臺可以實時應對變化,以前業(yè)務單一的時候設計沒有問題,但是隨著業(yè)務的變化,是很難做到全而廣,中臺的意義是,統(tǒng)一對外輸出,后臺業(yè)務新增,作為數(shù)據(jù)輸出的后臺只需變化對應的業(yè)務不需要去思考他的多方輸出,后臺的輸出只是中臺,減少了繁雜的自檢,而中臺主要是提供統(tǒng)一的方法出去,即使后臺變化了很多,但是前端對接只需要和中臺對接,且中臺是統(tǒng)一提供給多方調用。因此后端主攻業(yè)務變化,少了對接前端的困擾,中臺主要是為前端提供對接服務,從而做到術業(yè)有專攻。(其實中臺是做了后臺對接給前端的服務,后端核心是應對業(yè)務變化和數(shù)據(jù)支持)
舉的那個做菜的例子其實不大準確,如果一開始沒有分配菜、做菜的步驟后面增加了配菜環(huán)節(jié),是對后臺流程的重塑。但是如果一開始就分了配菜、做菜的流程,但是每位廚師有自己專門的配菜人員,這樣隨著廚師的增加,配菜的人也要增加,并且配菜的邏輯不統(tǒng)一,帶來管理上的復雜。這個時候可以引入配菜中臺的概念,分一個配菜組統(tǒng)一管理所有廚師的配菜(菜切的大小統(tǒng)一標準),感覺這樣更像中臺的概念。
我也是這么認為的,做菜的列子是后臺模塊化的重構。
作為技術出身的產(chǎn)品經(jīng)理,我的理解是,前臺-中臺-后臺,是一個產(chǎn)品體系上的分層,如同研發(fā)的架構設計,通過對業(yè)務流程及模塊的細化,拆分,分離出公共可復用的模塊,適配模塊,達到解耦前臺與后臺,快速響應新業(yè)務的目的。
用廚房舉例,中臺一下子就理解了
用戶畫像
簡單說就是適配中心
軟件的封裝與分層,這是軟件設計里非?;镜闹R。只是在具體實踐過程中如何劃分,以及在何種情況下需要再進行分層,這就要依據(jù)具體問題去看。無非是要依據(jù)具體需求從直接高效與間接靈活之中尋找一種可接受的平衡。
你的最后一句話說的很精辟,在直接高效與間接靈活之間找到一個平衡點,佩服!