中臺建設(shè)，是近兩年非?；馃岬囊粋€話題，從產(chǎn)品中臺，到技術(shù)中臺，再到組織中臺，各種概念、理念，以及方法論被深度的研究、探討。
對于互聯(lián)網(wǎng)產(chǎn)品領(lǐng)域來講，中臺更多的是2B產(chǎn)品建設(shè)中涉及的課題，因為軟件系統(tǒng)的抽象復(fù)用，更多的是做復(fù)雜B端系統(tǒng)建設(shè)中面臨的問題。因此，中臺產(chǎn)品設(shè)計，是所有B端產(chǎn)品經(jīng)理應(yīng)該深度關(guān)注的課題。
針對B端產(chǎn)品設(shè)計領(lǐng)域，中臺產(chǎn)品到底該如何設(shè)計？有何特點？設(shè)計的本質(zhì)是什么？有何挑戰(zhàn)？本文將從全新的視角，重新審視中臺產(chǎn)品建設(shè)，讓您更加深刻地理解中臺產(chǎn)品設(shè)計精要。
首先，我們有必要回顧下經(jīng)典的中臺建設(shè)視角。一般來講，行業(yè)內(nèi)往往從組織中臺、產(chǎn)品中臺、數(shù)據(jù)中臺、技術(shù)中臺這四個主題切入并探討中臺建設(shè)。
組織中臺：組織中臺研究的是企業(yè)內(nèi)部的組織結(jié)構(gòu)設(shè)計，如何通過合理的權(quán)責(zé)劃分，以及管理架構(gòu)搭建，提高業(yè)務(wù)部門的經(jīng)營能力，迅速響應(yīng)市場變化，并且能夠讓企業(yè)提升整體跨部門跨業(yè)務(wù)線協(xié)作效率，降低運(yùn)營成本，實現(xiàn)標(biāo)準(zhǔn)化管理。所謂組織中臺的設(shè)計思路，實際上已經(jīng)存在了很多年了，在集團(tuán)企業(yè)中，往往采取事業(yè)部制的組織形態(tài)，再配合各種共享服務(wù)中心的建設(shè)，實現(xiàn)前后端業(yè)務(wù)分離，前端業(yè)務(wù)保持機(jī)動性，后端業(yè)務(wù)提供火力支援。類似于財務(wù)共享服務(wù)中心FSSC（Financial Shared Service Center），人力資源共享服務(wù)中心HRSSC（Human Rersources Shared Service Center），其實就是典型的中臺管理思路下的組織形態(tài)和職能部門建設(shè)的方法，如下圖。
一個常見的事業(yè)部制的組織機(jī)構(gòu)圖
產(chǎn)品中臺：產(chǎn)品中臺研究的是企業(yè)內(nèi)部的軟件系統(tǒng)如何進(jìn)行抽象和設(shè)計，從而讓企業(yè)的軟件系統(tǒng)就像搭建積木一樣靈活，可以重復(fù)高效利用現(xiàn)成的軟件組件，快速組裝開發(fā)出新的軟件系統(tǒng)，從而節(jié)約軟件開發(fā)成本，并能夠快速支持新業(yè)務(wù)開展。很多文章也把這類中臺產(chǎn)品稱作業(yè)務(wù)中臺，或業(yè)務(wù)中臺產(chǎn)品。目前被廣泛討論的產(chǎn)品中臺包括電商交易中臺、賬號中心中臺等，其中電商交易線又被更加廣泛的探討，包括了訂單中臺、支付中臺、商品中臺、促銷中臺等。產(chǎn)品中臺還有另一層含義，即能夠給全公司全企業(yè)提供一致服務(wù)的管理軟件產(chǎn)品，也可以納入產(chǎn)品中臺的范疇，例如呼叫中心、項目管理軟件。從某種程度上來講，這些標(biāo)準(zhǔn)化軟件產(chǎn)品也是中臺產(chǎn)品。
數(shù)據(jù)中臺：數(shù)據(jù)中臺研究的是企業(yè)內(nèi)部的數(shù)據(jù)管理、治理問題，以及數(shù)據(jù)產(chǎn)品體系和數(shù)據(jù)底層結(jié)構(gòu)的搭建問題。數(shù)據(jù)中臺研究的范疇，包括企業(yè)統(tǒng)一的數(shù)據(jù)安全、數(shù)據(jù)規(guī)范、元數(shù)據(jù)管理、數(shù)據(jù)編碼管理，以及數(shù)據(jù)倉庫、數(shù)據(jù)集市的拓?fù)浼軜?gòu)，也包括大數(shù)據(jù)底層和運(yùn)算能力建設(shè)和復(fù)用。要注意的是，數(shù)據(jù)中臺更多的關(guān)心從業(yè)務(wù)和產(chǎn)品層面對數(shù)據(jù)的治理、管理、應(yīng)用，而非技術(shù)層面問題。
技術(shù)中臺：技術(shù)中臺研究的是軟件產(chǎn)品的技術(shù)實現(xiàn)過程中，哪些技術(shù)上的處理能力和架構(gòu)可以進(jìn)行抽象復(fù)用，例如消息中間件MQ，分布式計算框架Hadoop，分布式服務(wù)框架HSF，各種Open API等等。技術(shù)中臺是純粹從技術(shù)實現(xiàn)底層來思考基礎(chǔ)服務(wù)和基礎(chǔ)模塊的復(fù)用能力，其設(shè)計思路和產(chǎn)品中臺一脈相承，是技術(shù)人員需要深度思考的問題。
以上四個主題，涵蓋了互聯(lián)網(wǎng)模式下對于企業(yè)中臺建設(shè)的所有課題范圍，其中，對于產(chǎn)品經(jīng)理來講，工作相關(guān)性最強(qiáng)，最需要關(guān)注的是產(chǎn)品中臺和數(shù)據(jù)中臺。
實際上，上述四個主題，也正是傳統(tǒng)企業(yè)信息化建設(shè)中非常核心的企業(yè)架構(gòu)EA（Enterprise Architecture）理論，對企業(yè)業(yè)務(wù)管理的IT視角下的切分。其中組織中臺對應(yīng)EA中研究的企業(yè)業(yè)務(wù)架構(gòu)EBA（Enterprise Business Architecture）中的組織架構(gòu)治理部分，產(chǎn)品中臺對應(yīng)EA中研究企業(yè)應(yīng)用架構(gòu)的EAA（Enterprise Application Architecture），數(shù)據(jù)中臺對應(yīng)EA中研究企業(yè)數(shù)據(jù)架構(gòu)的EDA（Enterprise Data Architecture），技術(shù)中臺對應(yīng)EA中研究企業(yè)技術(shù)架構(gòu)的ETA（Enterprise Technology Artchitecture）。
關(guān)于EA的論述，可能讓很多純互聯(lián)網(wǎng)背景的同學(xué)讀起來很困惑，但實際上，互聯(lián)網(wǎng)企業(yè)所謂的中臺建設(shè)思路，逃不出經(jīng)過幾十年沉淀的信息技術(shù)理論框架，以及管理理論框架。而傳統(tǒng)信息技術(shù)理論，在互聯(lián)網(wǎng)企業(yè)的B端產(chǎn)品建設(shè)中具有極強(qiáng)的參考、借鑒價值。
然而，我們今天討論的主題，還不是研究企業(yè)架構(gòu)EA對中臺建設(shè)的指導(dǎo)，而是嘗試從更加深層次的角度，去探索產(chǎn)品中臺、數(shù)據(jù)中臺的設(shè)計本質(zhì)，尤其是對于B端產(chǎn)品經(jīng)理來講非常核心的產(chǎn)品中臺的設(shè)計精要。
對于產(chǎn)品中臺，目前公認(rèn)的關(guān)鍵要點包括如下關(guān)鍵詞：企業(yè)級、抽象、下沉、復(fù)用，這些關(guān)鍵詞代表了產(chǎn)品中臺建設(shè)的特點，同時也是在企業(yè)應(yīng)用架構(gòu)設(shè)計中需要深層次思考的問題。（所謂企業(yè)應(yīng)用架構(gòu)，是指企業(yè)內(nèi)部的各個軟件系統(tǒng)，應(yīng)該以什么樣的形式建設(shè)、組合，從而高效的支持企業(yè)的經(jīng)營運(yùn)作）因此，如果要深層次的思考軟件產(chǎn)品的企業(yè)級抽象、下沉、復(fù)用問題，可以從以下三個角度進(jìn)行全新的審視，分別是：基于抽象復(fù)用的視角，基于架構(gòu)合理性的視角，基于業(yè)務(wù)統(tǒng)一管理的視角。
我們通過從這三個視角切入，可以全面的解構(gòu)中臺產(chǎn)品設(shè)計的要義，并且可以更加全面的窮舉中臺建設(shè)的方法論、要點和難點。
所謂抽象復(fù)用，是指對軟件中重復(fù)的功能和模塊進(jìn)行抽象并下沉一層。
什么叫抽象？什么叫下沉？我們舉例說明。
如下圖，有兩個系統(tǒng)I和II，其中系統(tǒng)I中具有模塊M，系統(tǒng)II中具有模塊N，經(jīng)過分析發(fā)現(xiàn)，模塊M和N的功能高度類似重復(fù)，完全可以抽象合并，避免重復(fù)建設(shè)。
識別共性模塊
現(xiàn)決定將模塊M和N分別從系統(tǒng)I和II中剝離出來，如下圖。
抽離共性模塊
將M和N剝離出來后，我們對其功能進(jìn)行抽象合并，如下圖。M和N合并后，得到模塊A + B + C，其中A是M和N中共有的功能，B和C分別是針對系統(tǒng)I和II提供的一些定制化功能。雖然有少量功能無法做到完全合并和復(fù)用，但新模塊中絕大多數(shù)功能集合A已經(jīng)被高度抽象，可以被系統(tǒng)I和II復(fù)用。而被剝離合并后的全新模塊A+B+C，將會下沉一層，作為基礎(chǔ)服務(wù)，為系統(tǒng)I和II提供支持。如下圖。
合并共性模塊
以上案例，演示了系統(tǒng)功能如何被合并、抽象、下沉，這種設(shè)計思路，節(jié)約了軟件研發(fā)成本，是一種非常經(jīng)典的中臺設(shè)計思路。
接下來，我們通過一個實踐案例，進(jìn)一步演示這種設(shè)計思路。
案例背景
某流量型互聯(lián)網(wǎng)公司，變現(xiàn)模式主要為針對中小企業(yè)的廣告售賣，業(yè)務(wù)團(tuán)隊包括電話銷售團(tuán)隊（IS，Inbound Sales），外勤線下銷售團(tuán)隊（OS，Outbound Sales），以及客服團(tuán)隊。三個業(yè)務(wù)團(tuán)隊有著各自獨(dú)立的業(yè)務(wù)系統(tǒng)支持其運(yùn)轉(zhuǎn)，每個業(yè)務(wù)系統(tǒng)中既有個性化功能，例如針對IS的外呼管理、針對OS的拜訪管理、針對客服的關(guān)懷回訪；也有功能高度類似的重復(fù)功能，例如客戶管理列表，客戶詳情頁。系統(tǒng)架構(gòu)圖如下圖所示。
重復(fù)的客戶詳情頁建設(shè)
遇到的問題
三套業(yè)務(wù)系統(tǒng)各自有產(chǎn)品研發(fā)團(tuán)隊維護(hù)，系統(tǒng)早期為了快速支持業(yè)務(wù)從而分別建設(shè)，快速響應(yīng)業(yè)務(wù)訴求，為業(yè)務(wù)發(fā)展立下了汗馬功勞。但隨著系統(tǒng)的逐步成熟，其中一些問題也逐漸凸顯，首要問題就是功能重復(fù)開發(fā)建設(shè)問題。雖然三個業(yè)務(wù)部門對客戶關(guān)注的側(cè)重點不同，但基本訴求是一致的，希望能看到客戶所有的重要信息。因此，三個系統(tǒng)的客戶詳情頁功能已經(jīng)高度類似，而每次針對客戶資料的調(diào)整變化，需要三個研發(fā)團(tuán)隊分別重復(fù)開發(fā)三遍，非常浪費(fèi)人力資源。
解決方案
為了解決三套業(yè)務(wù)系統(tǒng)中高度類似的客戶詳情頁的重復(fù)開發(fā)問題，也為了給業(yè)務(wù)人員提供一致的、準(zhǔn)確的客戶視圖，公司決定將客戶詳情頁模塊從三個業(yè)務(wù)系統(tǒng)中剝離，將功能合并后，建設(shè)“統(tǒng)一客戶視圖（ECIF）”模塊，該模塊擁有一致的客戶數(shù)據(jù)底層，并提供完整的客戶信息查詢服務(wù)化接口，以及可以嵌入業(yè)務(wù)系統(tǒng)直接使用的客戶詳情頁面組件?！敖y(tǒng)一客戶視圖”將作為中臺產(chǎn)品，為各個業(yè)務(wù)系統(tǒng)提供企業(yè)客戶數(shù)據(jù)查詢的服務(wù)以及視圖。如下圖。
將客戶詳情頁抽象下沉建設(shè)統(tǒng)一客戶視圖中臺
任何業(yè)務(wù)系統(tǒng)，既可以調(diào)用該模塊的成熟接口查詢客戶數(shù)據(jù)并自己設(shè)計前端頁面，也可以直接嵌入“統(tǒng)一客戶視圖”提供的現(xiàn)成的客戶詳情頁組件，并且該頁面組件還可以進(jìn)行靈活的權(quán)限配置，定義針對不同的業(yè)務(wù)系統(tǒng)、不同用戶角色的數(shù)據(jù)查看、編輯范圍。
由此，我們完成了對客戶詳情頁的抽象下沉，三套曾經(jīng)重復(fù)開發(fā)的頁面被合并成了一套，以后研發(fā)團(tuán)隊只需要維護(hù)這一套頁面，研發(fā)人力得到了釋放。
這就是典型的基于抽象復(fù)用的視角設(shè)計的中臺產(chǎn)品。這種模式有一個顯著特點，即軟件的抽象和復(fù)用是成本問題，不影響業(yè)務(wù)。案例中，雖然有三套客戶詳情頁被重復(fù)建設(shè)，但只是個資源浪費(fèi)問題，并不會影響到業(yè)務(wù)的開展。
對軟件功能模塊進(jìn)行抽象復(fù)用，是具有很強(qiáng)挑戰(zhàn)性的工作。如果分析不當(dāng)或經(jīng)驗不足，有可能做出錯誤的抽象方案。
我們總是希望能夠?qū)浖凸δ苓M(jìn)行正確的抽象決策，讓抽象出的系統(tǒng)和模塊具有高度重疊的特性，例如下圖這樣。
期望的抽象結(jié)果
然而受限于經(jīng)驗不足，或掌握的信息不足，很可能做出錯誤的判斷和設(shè)計，做出了錯誤的抽象決策，最后被抽象的系統(tǒng)模塊，并不能被充分復(fù)用，只是制造了一個畸形的別扭的模塊，生硬的把一堆毫無關(guān)聯(lián)的功能強(qiáng)行捏在一起，給研發(fā)工作反而帶來的更大的麻煩，如下圖。
錯誤的抽象結(jié)果
我們將通過實際案例，給大家演示這種設(shè)計錯誤。
案例背景
某互聯(lián)網(wǎng)公司同時開展了電商業(yè)務(wù)和電影票業(yè)務(wù)。每條業(yè)務(wù)線都有獨(dú)立的C端系統(tǒng)、后臺交易系統(tǒng)（包括商品管理、訂單管理、促銷管理）來支持業(yè)務(wù)。為了追逐潮流，公司決定將兩條業(yè)務(wù)線的訂單中心合并，實現(xiàn)訂單中臺，如下圖。
并不一定正確的訂單中臺
錯誤的決策
實際上，公司經(jīng)營的B2C電商業(yè)務(wù)和影票業(yè)務(wù)，在交易形態(tài)上有較大區(qū)別，尤其體現(xiàn)在訂單模塊的設(shè)計上，訂單的狀態(tài)機(jī)、數(shù)據(jù)模型和財務(wù)賬務(wù)處理模式完全不同，強(qiáng)行將兩者合并后，并沒有太多的共性模塊和功能，最終只是表面上看起來實現(xiàn)了訂單中臺，但是里邊的功能模塊各自獨(dú)立，各自運(yùn)轉(zhuǎn)，完全沒有抽象和復(fù)用。
擴(kuò)展難題
現(xiàn)在，公司管理者以為擁有了強(qiáng)大的“訂單中臺”，可以為任何新業(yè)務(wù)的快速開展提供支持。很快，公司決定開展機(jī)票售賣業(yè)務(wù)，針對機(jī)票業(yè)務(wù)，有獨(dú)立的C端，商品管理，促銷管理。但是當(dāng)產(chǎn)品經(jīng)理和工程師開始期待訂單中臺的強(qiáng)大能力時，遺憾的發(fā)現(xiàn)訂單中臺無法給機(jī)票業(yè)務(wù)提供任何現(xiàn)成的功能復(fù)用能力，機(jī)票的訂單模型和電商以及影票都不相同。
機(jī)票業(yè)務(wù)線的設(shè)計人員面臨一個尷尬的局面，要么“政治正確”的將機(jī)票訂單中心納入訂單中臺統(tǒng)一建設(shè)，但實際上這會嚴(yán)重降低開發(fā)效率，因為中臺研發(fā)團(tuán)隊肯定不會像機(jī)票業(yè)務(wù)自己的研發(fā)團(tuán)隊那樣重視新業(yè)務(wù)的開展；要么就拋棄訂單中臺，自己獨(dú)立開發(fā)訂單模塊，但這樣做又會顯得訂單中臺沒有產(chǎn)生該有的價值。如果你是機(jī)票業(yè)務(wù)的負(fù)責(zé)人，該怎么權(quán)衡取舍呢？此時的系統(tǒng)架構(gòu)如下圖。
訂單中臺并不能很好的支持機(jī)票業(yè)務(wù)
可見，訂單中心，在不同業(yè)務(wù)模式下，并不一定適用于中臺化建設(shè)，設(shè)計人員要有足夠的思辨能力，判斷產(chǎn)品形態(tài)上是否值得抽象下沉，是否能夠提供復(fù)用能力。然而這也是軟件工程設(shè)計中非常難的部分。
任何軟件系統(tǒng)的設(shè)計，都是基于歸納法，而非演繹法，即軟件設(shè)計人員總是通過對現(xiàn)有世界和業(yè)務(wù)的總結(jié)提煉，完成軟件設(shè)計，而無法通過推測演繹，完成軟件設(shè)計。設(shè)計人員無法對業(yè)務(wù)的未來做出預(yù)測，只能基于有限的經(jīng)驗，盡量的保證設(shè)計的靈活性和正確性。理解這一點非常重要，這會讓你在軟件設(shè)計、產(chǎn)品設(shè)計時心存敬畏之心，不會一味地追求短期無法論證的結(jié)論而產(chǎn)生的嚴(yán)重的過度設(shè)計。
以下是基于抽象復(fù)用的視角建設(shè)中臺的幾條建議。
明顯具備共性的模塊盡早抽象
B端產(chǎn)品的體系化設(shè)計中，很多形態(tài)的產(chǎn)品是具備明顯共性的，可以盡早的進(jìn)行抽象設(shè)計，這樣在系統(tǒng)架構(gòu)建設(shè)的早期，就能做出正確的設(shè)計方案，而且并不會增加多少研發(fā)工作量，但會讓未來的系統(tǒng)擴(kuò)展更加輕松。例如，業(yè)務(wù)系統(tǒng)的統(tǒng)一權(quán)限管理系統(tǒng)、單點登錄系統(tǒng)、組織架構(gòu)系統(tǒng)、公告系統(tǒng)、短信系統(tǒng)，這些系統(tǒng)都應(yīng)該盡早抽象建設(shè)。
不確定共性的模塊事后抽象
例如統(tǒng)一客戶視圖、訂單中心、商品系統(tǒng)，這些軟件模塊，很難判斷在多業(yè)務(wù)線場景下能夠完全復(fù)用，如果對于是否抽象拿不準(zhǔn)主意，完全可以先不做抽象，等業(yè)務(wù)漸漸明確后，有足夠的信息作出充分的分析和判斷，再決定是否合并抽象。
避免人力外包中臺
中臺的建設(shè)一定要有合理的原因，如果只是為了中臺而中臺，會讓系統(tǒng)的架構(gòu)混亂，工作效率反而降低。而且很容易產(chǎn)生“人力外包中臺”現(xiàn)象，即下游業(yè)務(wù)團(tuán)隊把中臺團(tuán)隊當(dāng)做乙方來合作，“反正你們要幫我們打理好這些模塊，不管是否合理，需求提交給你就必須得高優(yōu)支持，否則就是不支持業(yè)務(wù)一線”，這樣會讓中臺產(chǎn)品和中臺團(tuán)隊失去該有的氣質(zhì)，形成團(tuán)隊間的敵意和隔閡。
軟件的應(yīng)用架構(gòu)設(shè)計，不是隨意任性的系統(tǒng)、模塊組合，而是有著深刻的設(shè)計方法論與合理性訴求。為了滿足應(yīng)用架構(gòu)合理性的要求，很多時候需要將軟件抽象并下沉一層。
所謂應(yīng)用架構(gòu)合理性，是為了避免因為應(yīng)用架構(gòu)設(shè)計的不合理，而造成業(yè)務(wù)問題。企業(yè)中軟件系統(tǒng)的建設(shè)，很容易出現(xiàn)兩個常見問題，一個叫做煙囪應(yīng)用，一個叫做數(shù)據(jù)孤島。
企業(yè)內(nèi)部的軟件系統(tǒng)，很多都是為了某個獨(dú)立的業(yè)務(wù)部門而設(shè)計研發(fā)，例如CRM，WMS，OA。這些系統(tǒng)設(shè)計初衷是支持業(yè)務(wù)部門的獨(dú)立運(yùn)作，而企業(yè)內(nèi)部跨部門的業(yè)務(wù)流程和數(shù)據(jù)傳遞是無處不在的。如果業(yè)務(wù)系統(tǒng)沒有做很好的架構(gòu)設(shè)計或服務(wù)化處理，那么系統(tǒng)之間就無法通信交流，業(yè)務(wù)流程就會被割裂，每一個應(yīng)用系統(tǒng)就像一根根煙囪一樣，互無聯(lián)系，這就是“煙囪應(yīng)用”。煙囪應(yīng)用會造成部門墻，讓企業(yè)的業(yè)務(wù)無法順暢流轉(zhuǎn)運(yùn)作。
煙囪應(yīng)用
因為煙囪應(yīng)用的存在，每個應(yīng)用系統(tǒng)生產(chǎn)的數(shù)據(jù)會更加孤立，系統(tǒng)之間數(shù)據(jù)沒有關(guān)聯(lián)，沒有打通，系統(tǒng)之間的數(shù)據(jù)就像一座座孤島，彼此獨(dú)立，數(shù)據(jù)的價值被嚴(yán)重弱化，數(shù)據(jù)孤島會造成嚴(yán)重的業(yè)務(wù)問題，接下來的案例，會演示數(shù)據(jù)孤島問題，以及如何通過中臺化的架構(gòu)設(shè)計思路解決該問題。
數(shù)據(jù)孤島
案例背景
某公司開展了線下零售店和線上商城兩條業(yè)務(wù)線，由于這兩條業(yè)務(wù)線開展之初是獨(dú)立經(jīng)營建設(shè)管理，因此系統(tǒng)建設(shè)也是由兩個產(chǎn)研團(tuán)隊分別負(fù)責(zé)，這就造成了線上和線下業(yè)務(wù)分別有一套客戶數(shù)據(jù)庫?，F(xiàn)在公司設(shè)立了獨(dú)立的客服一級部門同時服務(wù)于線上線下業(yè)務(wù)，而客服人員使用的客服業(yè)務(wù)系統(tǒng)，是不能同時訪問兩套客戶數(shù)據(jù)庫的，因此只能將兩套客戶數(shù)據(jù)庫冗余成一套針對客服業(yè)務(wù)系統(tǒng)使用的客戶數(shù)據(jù)庫。此時，公司內(nèi)部一共有三套客戶數(shù)據(jù)庫，各自像孤島一樣存在。如下圖所示。
客戶數(shù)據(jù)存在孤島
遇到的問題
顯然，上述應(yīng)用架構(gòu)存在嚴(yán)重的數(shù)據(jù)孤島問題，并且會產(chǎn)生嚴(yán)重的業(yè)務(wù)問題。具體如下：
線上客戶如果想體驗線下服務(wù)需要重新注冊會員，客戶體驗極差
線下客戶如果想體驗線上業(yè)務(wù)需要重新注冊賬號，客戶體驗極差
線上線下客戶數(shù)據(jù)重復(fù)，無法識別唯一性
呈現(xiàn)給客服人員的客戶數(shù)據(jù)是同步后的具有滯后性
客服無法準(zhǔn)確識別客戶信息并幫助客戶修改資料
企業(yè)無法做線上線下客戶消費(fèi)的關(guān)聯(lián)性分析，無法做交叉銷售
解決方案
因為應(yīng)用架構(gòu)設(shè)計的不合理，導(dǎo)致業(yè)務(wù)受到嚴(yán)重影響，客戶體驗差。如何解決多個業(yè)務(wù)系統(tǒng)中存在的數(shù)據(jù)孤島問題呢？實際上解決辦法也很簡單，就是將客戶數(shù)據(jù)庫合并后只保留唯一的一份客戶數(shù)據(jù)資料，所有下游業(yè)務(wù)系統(tǒng)都訪問這個唯一的客戶數(shù)據(jù)庫，進(jìn)行客戶數(shù)據(jù)的增刪改查操作。此時，系統(tǒng)之間的拓?fù)浣Y(jié)構(gòu)發(fā)生了改變，新的應(yīng)用架構(gòu)圖如下圖。
通過主數(shù)據(jù)設(shè)計思路解決孤島問題
這種針對企業(yè)的核心的、相對穩(wěn)定不容易變化的、被充分共享的數(shù)據(jù)，叫做主數(shù)據(jù)MDM（Master Data Management），通過主數(shù)據(jù)的設(shè)計思路，可以很好地解決煙囪應(yīng)用和數(shù)據(jù)孤島問題，尤其是數(shù)據(jù)孤島問題。主數(shù)據(jù)作為一種基礎(chǔ)服務(wù)，正是一種中臺化的治理理念。企業(yè)內(nèi)常見的主數(shù)據(jù)包括客戶主數(shù)據(jù)、供應(yīng)商主數(shù)據(jù)、組織機(jī)構(gòu)主數(shù)據(jù)、商品主數(shù)據(jù)等等。你可能之前沒有聽到過主數(shù)據(jù)的概念，但仔細(xì)想想，實際上主數(shù)據(jù)在B端產(chǎn)品的架構(gòu)設(shè)計中時刻存在。
基于應(yīng)用架構(gòu)合理性的視角來構(gòu)建中臺，這種模式的特點，是軟件的抽象和架構(gòu)設(shè)計會影響業(yè)務(wù)，這和基于抽象復(fù)用的視角構(gòu)建中臺有著顯著地區(qū)別，前者如果不做抽象和下沉，會造成很多業(yè)務(wù)問題，例如案例中提到的客戶管理問題；后者如果不做抽象和下沉，只是成本問題，不影響業(yè)務(wù)，例如之前統(tǒng)一客戶視圖的案例，雖然開發(fā)資源浪費(fèi)，但系統(tǒng)的問題并不會影響業(yè)務(wù)開展。
有時候，對于企業(yè)來講，正確的架構(gòu)并不一定是合理的選擇，反而錯誤的架構(gòu)可能更有益于業(yè)務(wù)發(fā)展。理想化的架構(gòu)設(shè)計，可能反而會拖慢業(yè)務(wù)節(jié)奏。這是架構(gòu)設(shè)計中經(jīng)常面臨的問題，我們通過一個案例來進(jìn)行闡述。
背景
某互聯(lián)網(wǎng)公司起家于短視頻業(yè)務(wù)，業(yè)務(wù)發(fā)展良好，市場占有率高，短視頻產(chǎn)品功能形態(tài)豐富。公司基于各方面考慮，決定同時開展理財業(yè)務(wù)，希望在火爆的P2P市場中狂歡一場。
公司的短視頻業(yè)務(wù)的賬號中心，建設(shè)初期就采用了服務(wù)化的思路，因此很好的和短視頻前臺業(yè)務(wù)的C端APP實現(xiàn)了解耦合，實際上已經(jīng)實現(xiàn)了中臺化的建設(shè)部署。面對新開展的理財業(yè)務(wù)，產(chǎn)研負(fù)責(zé)人決定復(fù)用一套賬號中心（Passport），從而發(fā)揮中臺產(chǎn)品優(yōu)勢，為新業(yè)務(wù)賦能。理財業(yè)務(wù)的產(chǎn)品技術(shù)體系是獨(dú)立的，雖然想完全獨(dú)立研發(fā)所有的前后端系統(tǒng)，但是迫于壓力，不敢違背公司搞大中臺、小前臺的指導(dǎo)思想，決定復(fù)用基于短視頻業(yè)務(wù)構(gòu)建的賬號中心中臺來開展業(yè)務(wù)。整個架構(gòu)圖如下圖。
理財業(yè)務(wù)復(fù)用了短視頻業(yè)務(wù)的賬號中心中臺
遇到的問題
賬號中心作為中臺產(chǎn)品，除了為短視頻業(yè)務(wù)提供服務(wù)，還能快速賦能新業(yè)務(wù)，支持理財業(yè)務(wù)開展業(yè)務(wù)。理財業(yè)務(wù)只需要建設(shè)對應(yīng)的APP C端和簡單的管理后臺，對于比較復(fù)雜的賬號中心，完全不用浪費(fèi)人力從頭開發(fā)?？雌饋?，完美的架構(gòu)發(fā)揮了優(yōu)勢，支持了業(yè)務(wù)。產(chǎn)研負(fù)責(zé)人很開心，中臺理念得到了落地，在老板面前有面子。然而事實真的如此么？
理財業(yè)務(wù)開展過程之中，需要針對賬號中心做較多的個性化功能定制，例如需要實現(xiàn)賬號的信用認(rèn)證管理，地址管理，銀行卡管理等等，相對于短視頻業(yè)務(wù)的賬號中心，理財業(yè)務(wù)對賬號中心的功能要求、安全性要求、風(fēng)控要求更高。理財團(tuán)隊給賬號中心提交了一堆需求，但是賬號中心的響應(yīng)速度非常緩慢，因為兩個團(tuán)隊不是一個產(chǎn)研體系，也沒有管理關(guān)系，賬號中臺團(tuán)隊總是將理財業(yè)務(wù)的需求優(yōu)先級調(diào)到最低。
因為賬號中臺的響應(yīng)速度慢，理財業(yè)務(wù)負(fù)責(zé)人多次找老板溝通協(xié)調(diào)，但公司對待理財業(yè)務(wù)的態(tài)度又變的有些曖昧，并沒有保持最強(qiáng)有力的支持，這下就比較尷尬了，理財業(yè)務(wù)雖然有自己的研發(fā)團(tuán)隊，但是賬號中心用的卻是中臺的，而中臺團(tuán)隊又不是很支持理財業(yè)務(wù)（按照中臺團(tuán)隊的說法，理財業(yè)務(wù)提交的需求個性化太強(qiáng)，工作量巨大，對短視頻業(yè)務(wù)一點價值都沒有，投入產(chǎn)出比低，優(yōu)先級低），導(dǎo)致業(yè)務(wù)進(jìn)展緩慢，不能很好地支持客戶需求和業(yè)務(wù)發(fā)展訴求，浪費(fèi)了寶貴的競爭時間，只能眼睜睜的看著對手攻城略地，越走越遠(yuǎn)。
可見，設(shè)計了正確的中臺產(chǎn)品，以及保證了架構(gòu)的合理性，在某些情況下，反而會影響到業(yè)務(wù)的快速發(fā)展。
架構(gòu)設(shè)計的核心目標(biāo)是支持業(yè)務(wù)發(fā)展，某些時候可以允許不合理的架構(gòu)存在。
在Passport的案例中，理財業(yè)務(wù)實際上是按照獨(dú)立公司、獨(dú)立品牌運(yùn)作的，包括產(chǎn)品研發(fā)團(tuán)隊都是獨(dú)立的。作為一個不確定性高、市場變化迅速的創(chuàng)新業(yè)務(wù)，極有可能運(yùn)作半年后項目就中止了，這時候業(yè)務(wù)上更希望保持快速的響應(yīng)和落地能力，而不是考慮軟件架構(gòu)是否合理，即便理財業(yè)務(wù)獨(dú)立開發(fā)了Passport，即便理財業(yè)務(wù)發(fā)展成功、最后又需要將兩套Passport合并，即便兩套Passport合并非常麻煩，成本高，但是，至少業(yè)務(wù)通過快速響應(yīng)，迅速切入市場，取得了成功。
而且，有些時候，所謂的中臺化改造，架構(gòu)合理性設(shè)計，會嚴(yán)重影響到原有系統(tǒng)和業(yè)務(wù)的穩(wěn)定性。例如，假設(shè)新開展的B2B業(yè)務(wù)，要復(fù)用B2C業(yè)務(wù)的訂單中心，將B2C業(yè)務(wù)的訂單中心實現(xiàn)中臺化改造，那么問題來了，B2C業(yè)務(wù)作為公司的核心主營業(yè)務(wù)，承擔(dān)了每日十幾萬的訂單交易量，營收占公司整體營收的95%。而B2B業(yè)務(wù)作為創(chuàng)新實驗項目，預(yù)計每個月只能帶來幾十萬的GMV，并且，如果要將B2C的訂單中心中臺化，兼容B2B業(yè)務(wù)，要承擔(dān)非常高的系統(tǒng)改造風(fēng)險。那么問題來了，有必要為了架構(gòu)合理的中臺化建設(shè)，而承擔(dān)高風(fēng)險（甚至有可能把主營業(yè)務(wù)的核心B2C訂單系統(tǒng)干趴下），去支持小體量的創(chuàng)新業(yè)務(wù)么？
產(chǎn)品設(shè)計人員、架構(gòu)師、產(chǎn)研負(fù)責(zé)人，在面臨這些問題時，必須謹(jǐn)慎思考，基于對業(yè)務(wù)、市場、系統(tǒng)、代碼、架構(gòu)、人員、團(tuán)隊，各方面進(jìn)行綜合判斷后，做出決策，即便有時候做出的決策在系統(tǒng)架構(gòu)上看起來是錯誤的，但對于公司和業(yè)務(wù)的長遠(yuǎn)利益來講上是正確的。
企業(yè)發(fā)展到一定階段后，往往會出現(xiàn)集中化管理的訴求，對之前各自獨(dú)立的子公司、事業(yè)部，在某些方面實現(xiàn)集中化的管理控制，一方面為了加強(qiáng)集團(tuán)管控能力，另一方面也是因為業(yè)務(wù)協(xié)同經(jīng)營需要。
如果想實現(xiàn)這類業(yè)務(wù)訴求，就必須通過對軟件的下沉和抽象，來實現(xiàn)業(yè)務(wù)的集中化管控。下邊，我們來通過案例進(jìn)行說明。
案例背景
某保險集團(tuán)經(jīng)過多年發(fā)展，實現(xiàn)了壽險、財險、理財穩(wěn)定的業(yè)務(wù)三角。三條業(yè)務(wù)線分別由獨(dú)立的全資控股子公司經(jīng)營，三家公司的所有業(yè)務(wù)系統(tǒng)，從C端到B端，也全部獨(dú)立建設(shè)，互無交集。簡化版的系統(tǒng)架構(gòu)如下圖。
某集團(tuán)三條業(yè)務(wù)線下的系統(tǒng)架構(gòu)
業(yè)務(wù)訴求
三家公司獨(dú)立經(jīng)營，保持了充分的靈活性，能夠快速響應(yīng)市場變化，取得了成功。但是，隨著經(jīng)營的深入，有一些問題也逐步暴露，并且變得越來越嚴(yán)重，總部高度關(guān)注，需要盡快解決，典型問題如下：
三家公司經(jīng)常出現(xiàn)重復(fù)采購流量的現(xiàn)象，浪費(fèi)集團(tuán)營銷成本；
三家公司往往對同一個客戶重復(fù)營銷，造成客戶投訴；
客戶價值不能充分挖掘，跨業(yè)務(wù)線的交叉銷售和向上銷售做的不好；
現(xiàn)在，集團(tuán)下定決心解決這些問題，而解決這些問題，必須通過軟件產(chǎn)品的中臺化建設(shè)來實現(xiàn)。
解決方案
針對集團(tuán)面臨的三點問題，解決方案如下：
建立集團(tuán)的統(tǒng)一客戶標(biāo)識數(shù)據(jù)庫（作為集團(tuán)統(tǒng)一客戶管理中心的核心模塊來建設(shè)），從集團(tuán)層面識別客戶唯一性，確保各個業(yè)務(wù)線采買流量時能夠正確過濾已有客戶，節(jié)約成本。
具備客戶唯一性識別的能力后，可以實現(xiàn)集團(tuán)層面的統(tǒng)一客戶營銷管理、客戶旅程管理、以及防騷擾控制。通過統(tǒng)一客戶管理中心實現(xiàn)客戶旅程模塊、防騷擾控制模塊，將控制策略插入到各個子公司的銷售系統(tǒng)中，確保各個子公司的銷售觸達(dá)任務(wù)開始之前首先要經(jīng)過集團(tuán)層面的控制中心的校驗和管理，從而確保同一客戶不會同時被幾條業(yè)務(wù)線的銷售重復(fù)騷擾。
統(tǒng)一客戶管理中心還可以實現(xiàn)交叉銷售模塊，針對某些業(yè)務(wù)場景下的客戶數(shù)據(jù)，進(jìn)行跨業(yè)務(wù)線的銷售任務(wù)分發(fā)，例如識別某壽險客戶經(jīng)濟(jì)實力較好，則將客戶推送到理財業(yè)務(wù)的銷售系統(tǒng)，嘗試二次銷售轉(zhuǎn)化。
整個系統(tǒng)架構(gòu)如下圖。
通過集團(tuán)統(tǒng)一客戶管理中心實現(xiàn)跨業(yè)務(wù)線的客戶銷售管控
綜上可見，集團(tuán)層面，如果想對各個子公司的客戶資料、客戶營銷、客戶觸達(dá)進(jìn)行統(tǒng)一管理，就必須建立統(tǒng)一客戶管理中心，首先實現(xiàn)客戶唯一性標(biāo)識，其次基于客戶唯一性標(biāo)識落地各種統(tǒng)一客戶管理策略。集團(tuán)統(tǒng)一客戶管理中心，正是中臺設(shè)計思路的實踐應(yīng)用。而集中化的業(yè)務(wù)管理訴求，則必須通過軟件的抽象和架構(gòu)設(shè)計來實現(xiàn)，這也是這種中臺建設(shè)模式的特點。
業(yè)務(wù)集中管控的策略，總是滯后的，這是因為業(yè)務(wù)開展很長的一段時間中，各個業(yè)務(wù)線獨(dú)立運(yùn)作，相安無事，即便有一些小問題，也是可以容忍的，或無關(guān)緊要的。但是當(dāng)企業(yè)規(guī)模增長到一定階段，業(yè)務(wù)線之間的管理問題會越來越突出，之間的協(xié)同問題也會越來越明顯，此時就有必要進(jìn)行集中化的管理和控制。
滯后的業(yè)務(wù)管理決策，會對系統(tǒng)建設(shè)帶來較大的挑戰(zhàn)，因為各個業(yè)務(wù)線、事業(yè)部、子公司的系統(tǒng)已經(jīng)發(fā)展的非常成熟，針對成熟的系統(tǒng)，去調(diào)整架構(gòu)，改變系統(tǒng)和業(yè)務(wù)的邏輯，置入新的外部邏輯，是一件很有挑戰(zhàn)的事情。
針對未來可能的集中管控訴求，是否能夠在系統(tǒng)架構(gòu)上提前布局，做好結(jié)構(gòu)性的設(shè)計，以便未來的某一天，業(yè)務(wù)需求發(fā)生時，能夠順暢、輕松的進(jìn)行支持么？實際上這也是不現(xiàn)實的，因為業(yè)務(wù)上的需求是一個未知數(shù)，沒必要對未知的需求做架構(gòu)上的過度設(shè)計。
總之，集中化的業(yè)務(wù)管理訴求總是滯后的，這會給系統(tǒng)、中臺的設(shè)計和實現(xiàn)帶來挑戰(zhàn)。設(shè)計人員要對這個問題有清晰地認(rèn)知。
針對業(yè)務(wù)集中管控訴求下的中臺建設(shè)，有以下建議。
不要過多考慮未來不一定發(fā)生的事情
集中管控是不一定發(fā)生的需求，產(chǎn)品設(shè)計初期和中期，沒有必要為未來不確定的事情提前做過多的布局，因為很有可能未來根本用不到，卻會產(chǎn)生過度設(shè)計，造成開發(fā)資源的浪費(fèi)，甚至也會讓系統(tǒng)架構(gòu)看起來非常奇怪。例如，案例中的集團(tuán)客戶管理中心，在壽險、財險發(fā)展初期和中期，有必要在系統(tǒng)上做出這樣復(fù)雜的架構(gòu)設(shè)計么？在各自獨(dú)立經(jīng)營的子公司推進(jìn)這種架構(gòu)的落地，如果沒有明確的收益和價值，難度和成本巨大。
通過業(yè)務(wù)價值和業(yè)務(wù)訴求驅(qū)動系統(tǒng)迭代抽象
沒有明確的收益和價值，卻采用了這種集中控制調(diào)度的軟件架構(gòu)設(shè)計，這會讓各個事業(yè)部的核心銷售系統(tǒng)被割裂，被控制，被牽制，恐怕各個事業(yè)部是不會愿意配合這種項目的。即便這種架構(gòu)很合理，在可預(yù)期的未來一定是必須的，但是在當(dāng)前階段下卻沒有任何價值，還會影響各個事業(yè)部各自的工作。沒有業(yè)務(wù)價值和業(yè)務(wù)訴求的系統(tǒng)迭代抽象工作，是很難推動落地的。
項目必須有高管介入確保推進(jìn)
即便業(yè)務(wù)上已經(jīng)有明確的訴求，公司決定了執(zhí)行架構(gòu)調(diào)整，實現(xiàn)集中管控，項目的推進(jìn)，依然會阻力重重，因為這種調(diào)整首先會打破原有的利益格局，也會造成工作習(xí)慣的巨大改變。這類集中管控的項目，如果想成功落地，必須有集團(tuán)層面的，超越了各個下游業(yè)務(wù)線的非常高級別的管理人員牽頭掛帥，管理團(tuán)隊必須有統(tǒng)一的認(rèn)識，通過強(qiáng)有力的項目管理手段，才能保證在項目執(zhí)行過程中化解任何困難，成功落地。
我們已經(jīng)分別介紹了基于抽象復(fù)用的視角、基于架構(gòu)合理性的視角、基于業(yè)務(wù)統(tǒng)一管理的視角，這三種視角下的中臺建設(shè)模式，以及每種模式的建設(shè)目的、建設(shè)特點、面臨的挑戰(zhàn)。匯總后得到下表。
這三種視角（或叫三種模式），從左到右，業(yè)務(wù)屬性從弱到強(qiáng)。即最左側(cè)的抽象復(fù)用的視角，純粹是成本問題，和業(yè)務(wù)關(guān)系不大；中間的架構(gòu)合理性的視角，具備了一定的業(yè)務(wù)含義和業(yè)務(wù)價值；最右側(cè)的業(yè)務(wù)統(tǒng)一管理的視角，則完全是個業(yè)務(wù)問題了。
任何系統(tǒng)的中臺化建設(shè)，都可以從這三個視角中找到影子，要么是基于其中的某個視角建設(shè)，要么是基于其中的某兩個視角來建設(shè)。
例如，統(tǒng)一客戶視圖、報表引擎，這類產(chǎn)品純粹是成本問題，遵循著抽象復(fù)用視角下的中臺建設(shè)特點。主數(shù)據(jù)、賬號中心、數(shù)據(jù)集市，這類產(chǎn)品兼具了架構(gòu)問題和業(yè)務(wù)問題，遵循著后兩種視角下的中臺建設(shè)特點；而防騷擾、大積分體系（即集團(tuán)多套積分體系的打通和匯兌中心），則純粹是基于業(yè)務(wù)出發(fā)而建設(shè)的產(chǎn)品中臺，遵循著業(yè)務(wù)統(tǒng)一管理視角下的中臺建設(shè)特點。
在很多情況下，中臺產(chǎn)品兼具了多種屬性，例如，訂單中心、賬號中心、組織機(jī)構(gòu)管理、權(quán)限管理，這些中臺產(chǎn)品，既是研發(fā)成本問題，也是架構(gòu)問題，同時還會影響業(yè)務(wù)。再例如，支付、清結(jié)算、促銷重心、商品中心等中臺產(chǎn)品，則既是為了解決業(yè)務(wù)問題，也是為了解決架構(gòu)問題，同時也可能還解決了成本問題。
總之，上述三種中臺建設(shè)的視角，在一定程度上窮舉了產(chǎn)品中臺（即產(chǎn)品經(jīng)理關(guān)注的軟件產(chǎn)品的中臺化，也就是媒體上常說的業(yè)務(wù)中臺）建設(shè)中的所有出發(fā)點和可能性。你可以思考下，目前你所接觸的中臺，是否處于上述三種視角下的某一種或某幾種，通過我們的論述，你是否對相關(guān)中臺產(chǎn)品設(shè)計的特點和要點有了更深刻的認(rèn)識和理解呢？
