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