向左還是向右?中臺建設(shè)才不止這點(diǎn)糾結(jié)事

14 評論 9754 瀏覽 35 收藏 18 分鐘

今年參加了云棲大會,作為中臺的踐行者,筆者非常關(guān)注中臺架構(gòu)實(shí)施的行業(yè)狀況,學(xué)習(xí)了其他公司中臺的思想和經(jīng)驗(yàn)。云棲大會上,筆者和做中臺實(shí)踐的同學(xué),以及在阿里做中臺的朋友進(jìn)行了深入的交流和探討,對做中臺過程中遇到的比較糾結(jié)的問題進(jìn)行了思考和總結(jié)。

在探討中臺哪些讓人糾結(jié)不定煩心事之前,我們依然要談?wù)勎覀優(yōu)槭裁匆鲋信_(注:本文中臺局限于企業(yè) IT 架構(gòu)的中臺,非廣義上的中臺),做中臺到底給我?guī)砟男┖锰?,想不清楚這些就去深入到中臺的細(xì)節(jié)里也無意義。

中臺概念這幾年特別火,就像 90 年代不做 ERP 是等死一樣,現(xiàn)在做不做中臺也好像能定企業(yè)生死一樣,弄得大家都在搞中臺。

但是不是所有的企業(yè)都適合做中臺,只有符合以下條件的企業(yè),才有實(shí)施中臺的必要,切莫亂搞。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

企業(yè)適合做中臺的條件

所以,如果您是創(chuàng)業(yè)團(tuán)隊(duì),或者業(yè)務(wù)線比較單一,建議不要盲目嘗試中臺架構(gòu),否則將拖累你業(yè)務(wù)發(fā)展的速度。

另外,我們也要清晰地知道實(shí)施中臺的目的,以及中臺會給企業(yè)帶來的價(jià)值,沒有實(shí)際利益的推動(dòng)中臺就很難落地,或者有形而無神。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

中臺的價(jià)值

明確了中臺的應(yīng)用場景和價(jià)值體現(xiàn),我們開始實(shí)施中臺架構(gòu)的落地。我從今年上半年開始推動(dòng)中臺這件事差不多有幾個(gè)月的時(shí)間,在這個(gè)過程中也是摸著石頭過河,雖然有很多中臺的理論知識可以學(xué)習(xí),但是實(shí)際的過程中發(fā)現(xiàn),中臺的落地是一件非常難的事情,它沒有標(biāo)準(zhǔn),認(rèn)識也不統(tǒng)一,在一些關(guān)鍵環(huán)節(jié)存在不少分歧。

正好此次在云棲大會約了幾個(gè)實(shí)踐中臺的朋友進(jìn)行了深入的探討,把討論的內(nèi)容進(jìn)行總結(jié),希望中臺的建設(shè)少一些糾結(jié),多一分信心。

中臺定義:思想 VS 工具

什么是中臺?

每個(gè)人可能有不同的理解,行業(yè)里也沒有嚴(yán)格的定義,但我更認(rèn)同其中一個(gè)說法就是:中臺是企業(yè)級能力復(fù)用的平臺。

如何來解釋這句話呢?

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

中臺的定義

既然核心是能力復(fù)用,業(yè)務(wù)流派認(rèn)為中臺其實(shí)是一套思想,只要能夠?qū)崿F(xiàn)能力的復(fù)用,滿足降本增效的企業(yè)目標(biāo),采取的所有措施,和一切可復(fù)用的能力都是中臺的范疇,所以中臺是一種組織方式。

而技術(shù)流派的人則認(rèn)為,既然是能力復(fù)用的平臺,就一定要有支撐復(fù)用的工具,就必須定義一套技術(shù)規(guī)范來支持復(fù)用,中臺一定要有基礎(chǔ)平臺來支撐的。

中臺首先要統(tǒng)一思想,圍繞能力的復(fù)用進(jìn)行組織管理,將能力組件化,如下圖最底層部分;同時(shí),中臺之上我們要構(gòu)建能快速落地的技術(shù)平臺(如圖中 OECP 部分),通過 Low code 的平臺能力,實(shí)現(xiàn)組件的組裝和流程的設(shè)計(jì),快速的構(gòu)建應(yīng)用。

技術(shù)平臺是業(yè)務(wù)無關(guān)性的,但業(yè)務(wù)中臺一定是業(yè)務(wù)相關(guān)性的,只要把業(yè)務(wù)和技術(shù)有機(jī)的組合起來,把企業(yè)的能力沉淀并復(fù)用起來,這就有了中臺的基礎(chǔ)。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

中臺之上集成開發(fā)能力

復(fù)用粒度:粗粒度 VS 細(xì)粒度

復(fù)用是中臺建設(shè)的核心,是一切的基礎(chǔ),沒有復(fù)用的意識導(dǎo)向,中臺就變成了自娛自樂的游戲。也許很多人會說,沒有中臺之前復(fù)用無處不在啊,我們寫程序復(fù)用代碼,做方案復(fù)用案例,為什么一定要建設(shè)中臺呢?

首先,再次重申下中臺的復(fù)用范圍是“企業(yè)級”,它既不局限于技術(shù)同學(xué)內(nèi)的程序復(fù)用,也不局限于一個(gè)團(tuán)隊(duì)內(nèi)部的復(fù)用,而是站在企業(yè)最高的視角,作用于整個(gè)企業(yè)的 IT 架構(gòu);其次,是“能力的復(fù)用”,能力的范圍更加寬泛。

和阿里的朋友談到復(fù)用時(shí),我們也提到了復(fù)用的級別,像阿里云其實(shí)就是在基礎(chǔ)設(shè)施這個(gè)級別上的復(fù)用。

我自己把復(fù)用的級別抽象成下圖所示的 5 層。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

復(fù)用的級別

級別越低,粒度越小,復(fù)用的范圍越廣,但價(jià)值體現(xiàn)較低;級別越高,粒度越大,復(fù)用的價(jià)值越高,但復(fù)用范圍也比較局限。

所以站在業(yè)務(wù)和價(jià)值角度上,都是先從最高的層次上去復(fù)用。只有上層無法實(shí)現(xiàn)復(fù)用,我們才會逐步向下層去尋找。

但是有時(shí)候站在技術(shù)角度,我們習(xí)慣在低層次上去復(fù)用,因?yàn)檫@里最接近自己的工作,粒度越小,技術(shù)上越可控。但不論怎樣,只要我們能把這些能力很好地組織管理起來并實(shí)現(xiàn)復(fù)用,就是中臺的思維。

具體到中臺落地的 IT 架構(gòu),微服務(wù)基礎(chǔ)架構(gòu)是目前最流行的方式,因?yàn)閱渭兂绦虼a的復(fù)用價(jià)值有限,傳統(tǒng)單體應(yīng)用的復(fù)用又極其的不靈活;而基于微服務(wù)架構(gòu)的業(yè)務(wù)組件的復(fù)用則處在中間層級,靈活性和復(fù)用度比較平衡。

組件復(fù)用的核心思想是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD),而我認(rèn)為 DDD 最大難點(diǎn)是粒度的控制,粒度太粗不靈活、復(fù)用性差,粒度太細(xì)雖然復(fù)用性好,但耦合較大,運(yùn)維成本較高。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

Gartner 對服務(wù)粒度劃分

Gartner 在研究報(bào)告里提出了宏服務(wù)、小服務(wù)和微服務(wù)的粒度劃分:

  • 宏服務(wù):一種傳統(tǒng)的 Web 服務(wù),支持將功能封裝于單體應(yīng)用內(nèi)。宏服務(wù)不支持獨(dú)立部署或擴(kuò)展, 它們只能部署為單體應(yīng)用的一部分,而且它們不需要微服務(wù)基礎(chǔ)架構(gòu)。
  • 小服務(wù):就服務(wù)粒度范圍而言,小服務(wù)是一種粗粒度、松散耦合、支持獨(dú)立部署的應(yīng)用組件。小服務(wù)需要微服務(wù)基礎(chǔ)架構(gòu)。
  • 微服務(wù):微服務(wù)處于粒度范圍的遠(yuǎn)端,是一種可獨(dú)立部署的組件,能夠支持單個(gè)應(yīng)用功能的實(shí)施。微服務(wù)可直接部署到微服務(wù)運(yùn)行時(shí)環(huán)境中,也往往具備專用數(shù)據(jù)存儲區(qū)。微服務(wù)需要微服務(wù)基礎(chǔ)架構(gòu)。

我本人非常喜歡 Gartner 的劃分方式,基于這三種服務(wù)的粒度,我也談?wù)勎覍α6劝盐盏囊恍┧悸贰?/p>

如果我們想對已存在系統(tǒng)的能力進(jìn)行復(fù)用,可以采用宏服務(wù)模式進(jìn)行,宏服務(wù)的模式適合做系統(tǒng)的集成和治理。我們對于新的業(yè)務(wù)和項(xiàng)目,剛開始建議采用小服務(wù)的方式進(jìn)行業(yè)務(wù)領(lǐng)域的拆分,不建議拆分的過細(xì),這個(gè)小服務(wù)能滿足該需求的基本抽象即可。

從適中的粒度開始,服務(wù)的粒度一定是業(yè)務(wù)推進(jìn)的過程中不斷演化的,創(chuàng)新業(yè)務(wù)推動(dòng)服務(wù)的粒度向更細(xì)的粒度裂變,而業(yè)務(wù)成熟穩(wěn)定后,又推動(dòng)服務(wù)向粗粒度方向聚合。

流程支持:服務(wù)編排 VS SOP

實(shí)踐證明,業(yè)務(wù)能力輸出的內(nèi)容主要是核心業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)流程。而在我上面定義的復(fù)用級別上,業(yè)務(wù)流程的復(fù)用處在 LV4,也是比較高階的復(fù)用能力。

云棲大會的朋友聚會上,我一個(gè)實(shí)踐中臺的同學(xué)談到中臺服務(wù)如何更加靈活的支撐前臺時(shí)談到服務(wù)的編排。他們的做法是,給前臺同事提供一套服務(wù)編排的工具,然后發(fā)布一系列的原子性的服務(wù),由各前臺團(tuán)隊(duì)按照自己流程去編排適合自己的邏輯流程。

我不反對服務(wù)編排,而且在 SOA 和微服務(wù)的架構(gòu)下,服務(wù)編排是必不可少的能力。但是我不認(rèn)可給前臺提供編排工具,而中臺只提供原子性服務(wù)。

因?yàn)槲覀冊谥信_的建設(shè)中,一直提及的是中臺一定是業(yè)務(wù)相關(guān)性的,中臺輸出的不僅僅是工具,更要深入到具體的業(yè)務(wù)場景中,提供業(yè)務(wù)流程的最佳實(shí)踐。

阿里的朋友在討論這個(gè)問題是提到了 SOP(Standard Operation Procedure)的概念,他認(rèn)為最好的做法是提供一套標(biāo)準(zhǔn)化的流程 + 預(yù)留可動(dòng)態(tài)注入的擴(kuò)展點(diǎn)的方式來對前臺提供。

比如淘寶和天貓?jiān)跇I(yè)務(wù)上可以共享一套 SOP,在這套 SOP 的擴(kuò)展點(diǎn)上各自注入自己不同的規(guī)則,從而滿足自己的需求。從中臺的復(fù)用范圍來看,我特別認(rèn)同這種方式,因?yàn)橹信_只有提供 SOP,才是真正的實(shí)現(xiàn)業(yè)務(wù)流程這種高階的復(fù)用(就像國外 ERP 宣揚(yáng)的那樣,你購買的不只是一套系統(tǒng),還有企業(yè)管理的最佳實(shí)踐)。

當(dāng)然如果要做到 SOP 的定義,中臺團(tuán)隊(duì)必須有既精通業(yè)務(wù)又熟悉技術(shù)的人,我們俗稱“業(yè)務(wù)架構(gòu)師”,不過水平高的人實(shí)在可遇不可求啊,從這點(diǎn)我也理解把工具開放給前臺自己做服務(wù)編排的同學(xué)了。

雖然我一直在強(qiáng)調(diào)中臺要深入業(yè)務(wù),要提煉 SOP,但中臺又不能過度參與業(yè)務(wù),不能因?yàn)橹信_掣肘了業(yè)務(wù)的敏捷性。

中臺提供的能力要具有靈活性和可定制性,便于業(yè)務(wù)方根據(jù)規(guī)范自主完成,減少溝通成本,提升效率。所以服務(wù)編排作為工具還是需要提供,前期通過工具快速嘗試探索合適的業(yè)務(wù)流程,后期通過業(yè)務(wù)的最佳實(shí)踐形成 SOP。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

服務(wù)編排是工具支持快速創(chuàng)新,SOP是業(yè)務(wù)成果價(jià)值復(fù)用

先后順序:先業(yè)務(wù)中臺 VS 先數(shù)據(jù)中臺

雖然各種中臺很多,但是真正和業(yè)務(wù)保持密切協(xié)同的是業(yè)務(wù)中臺和數(shù)據(jù)中臺,阿里巴巴的中臺核心也是這雙中臺驅(qū)動(dòng)的。這里面體現(xiàn)的核心就是一切業(yè)務(wù)數(shù)據(jù)化,一切數(shù)據(jù)業(yè)務(wù)化,業(yè)務(wù)產(chǎn)生數(shù)據(jù),數(shù)據(jù)又賦能業(yè)務(wù)。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

業(yè)務(wù)中臺和數(shù)據(jù)中臺雙驅(qū)動(dòng)

在和某 Gartner 分析師交流的時(shí)候,他的觀點(diǎn)是先有業(yè)務(wù)中臺,再有數(shù)據(jù)中臺。雖然我們也是從業(yè)務(wù)中臺開始,但我個(gè)人并不是特別認(rèn)可這個(gè)觀點(diǎn)的,我更認(rèn)可的是先業(yè)務(wù)后數(shù)據(jù)。但是對于哪個(gè)中臺先開始,完全要看各企業(yè)的自身情況。

如果企業(yè)當(dāng)前最迫切的訴求是避免重復(fù)造輪子,提升 IT 生產(chǎn)力;數(shù)據(jù)基礎(chǔ)相對較好或者數(shù)據(jù)量級不夠,建議業(yè)務(wù)中臺先行。

如果企業(yè)當(dāng)前最迫切的訴求,是系統(tǒng)繁多但孤島嚴(yán)重急需要打通,企業(yè)已經(jīng)存在大量的數(shù)據(jù)急需要在業(yè)務(wù)上發(fā)揮價(jià)值,建議數(shù)據(jù)中臺先行。

具有自主技術(shù)研發(fā)團(tuán)隊(duì)特點(diǎn)的科技企業(yè),更適合先業(yè)務(wù)中臺,而自主開發(fā)能力較弱,應(yīng)用系統(tǒng)更多依賴第三方外采的偏傳統(tǒng)企業(yè),可能更適合數(shù)據(jù)中臺先行。

中臺團(tuán)隊(duì):委員會 VS 許愿池

中臺的建設(shè)是一把手工程,沒有自上而下的推動(dòng),中臺是很難落地的。所以中臺變革的第一步就是組織架構(gòu)的調(diào)整,需要建立一個(gè)中臺團(tuán)隊(duì)來負(fù)責(zé)組織、協(xié)調(diào)和建設(shè)。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

中臺組織的建立

如何對中臺團(tuán)隊(duì)定位其實(shí)也是一個(gè)難題,在我所見所經(jīng)歷的中臺組織中,經(jīng)常出現(xiàn)兩種形態(tài):

  1. 委員會:中臺團(tuán)隊(duì)是由各業(yè)務(wù)線選派的同事組成的虛擬組織,其中大部分都是領(lǐng)導(dǎo),更多的承擔(dān)組織、協(xié)調(diào)的角色,具體執(zhí)行工作分散在原有的各個(gè)部門里,這種可稱為委員會似的中臺。因?yàn)楦鞑块T的領(lǐng)導(dǎo)組成,相互之間加強(qiáng)了信息共享,也逐步有了復(fù)用的意識,但在企業(yè) IT 建設(shè)這個(gè)環(huán)節(jié),因?yàn)闆]有具體的專注于共享業(yè)務(wù)的執(zhí)行團(tuán)隊(duì),協(xié)作成本會增高、實(shí)際產(chǎn)出可能比較務(wù)虛,看著熱鬧,其實(shí)很難體現(xiàn)復(fù)用的價(jià)值。
  2. 許愿池:中臺只是普通的共享研發(fā)部門,前臺直接把需求丟到這個(gè)許愿池里,然后期盼著中臺提供一個(gè)現(xiàn)成的組件、服務(wù),中臺成了為前臺打工的了,累不用說還不討好,阿里早期的共享業(yè)務(wù)事業(yè)部估計(jì)就是這種窘境,沒有業(yè)務(wù)話語權(quán)。

中臺團(tuán)隊(duì)既不應(yīng)該是委員會也該是許愿池,中臺不僅能組織、能引領(lǐng),又必須要有實(shí)際的產(chǎn)出。

中臺需要前臺滋養(yǎng),前臺更需要中臺賦能,中臺團(tuán)隊(duì)只有成為具有核心話語權(quán)的實(shí)體團(tuán)隊(duì),企業(yè)能力的復(fù)用才能最大化的發(fā)揮出來。所以,阿里巴巴讓其 CTO 行癲張建峰掛帥推進(jìn)中臺戰(zhàn)略,才有了今天阿里中臺的影響力。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

中臺和前臺要相互賦能

其實(shí)中臺建設(shè)過程中碰到的問題遠(yuǎn)不止這些,需要我們在實(shí)踐中去探索正確的解題方法。

最后引用《中臺戰(zhàn)略》書中的內(nèi)容結(jié)束本文,希望踐行中臺的同仁都能馬到成功。

向左還是向右?聊聊中臺建設(shè)中的那些糾結(jié)事

中臺成功的行為準(zhǔn)則和行動(dòng)綱領(lǐng)

參考資料:

《中臺戰(zhàn)略:中臺建設(shè)及數(shù)字商業(yè)》 陳新宇等,機(jī)械工業(yè)出版社

《MASA 架構(gòu)》 Gartner 分析報(bào)告

#專欄作家#

菜根亂譚,微信公眾號:CGLT_TAN,人人都是產(chǎn)品經(jīng)理專欄作家。經(jīng)歷程序員、技術(shù)負(fù)責(zé)人、產(chǎn)品經(jīng)理等多種崗位,現(xiàn)在負(fù)責(zé)百洋智能科技的研發(fā)管理。關(guān)注醫(yī)療,早教領(lǐng)域,擅長技術(shù)應(yīng)用型產(chǎn)品的設(shè)計(jì)和運(yùn)營。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 看了這篇文章覺得很棒
    最近在做中臺產(chǎn)品 有問題可以請教您嗎

    來自浙江 回復(fù)
    1. 沒問題

      來自山東 回復(fù)
  2. 有個(gè)問題想咨詢下,會員的訂單記錄、商品瀏覽記錄、商品推薦記錄這些邏輯提供,應(yīng)該是會員中臺、訂單中臺還是商品中臺呢? 這個(gè)邏輯提供的 邊界如何把控?

    來自上海 回復(fù)
    1. 訂單記錄在訂單中心,商品瀏覽、商品推薦記錄既可以放在商品中心,也可以直接到數(shù)據(jù)中臺。邊界的把控需要業(yè)務(wù)架構(gòu)的能力,方法工具可以用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)來做

      來自山東 回復(fù)
    2. 客戶中臺,不是應(yīng)該把客戶的所有數(shù)據(jù)邏輯,放到客戶中臺來處理么?

      否則客戶的一些行為數(shù)據(jù),要去其他中臺去獲取,不就交叉了嗎

      來自上海 回復(fù)
    3. 不是這樣的邏輯,所有事都和客戶有關(guān),照這么說我們就不用切分了。中臺組件高內(nèi)聚,低耦合,不是不耦合。DDD里有核心域,有支撐域,有輔助域,訂單中臺的核心域是訂單相關(guān)的,訂單域的輔助域包含了會員域和商品域。訂單中包含了下訂單時(shí)的當(dāng)時(shí)狀態(tài)的商品信息,這部分屬于訂單域。但關(guān)聯(lián)的商品展示頁面的信息的商品屬于商品域。訂單的商品和實(shí)際上線的商品之間有關(guān)系,訂單域中保留這個(gè)關(guān)系即可。
      業(yè)務(wù)邊界的劃分的確是考驗(yàn)一個(gè)業(yè)務(wù)架構(gòu)人員的素質(zhì)的,嘗試用DDD來做下分析試試

      來自山東 回復(fù)
    4. 了解,感謝

      來自上海 回復(fù)
    5. 還有哦,如果客戶的行為數(shù)據(jù)邏輯都相關(guān)其他中臺,客戶中臺還能做點(diǎn)什么邏輯呢?例如您上面的醫(yī)藥例子?

      來自上海 回復(fù)
    6. 客戶中臺的東西挺多的啊,客戶的創(chuàng)建、維護(hù);客戶的征信授信;客戶主數(shù)據(jù)的維護(hù)同步。一般情況,我們分業(yè)務(wù)中臺和數(shù)據(jù)中臺,業(yè)務(wù)中臺主要是滿足業(yè)務(wù)處理流程所共享的服務(wù),主要是事務(wù)性的服務(wù),比如我上面說的幾個(gè);其實(shí)還有一個(gè)數(shù)據(jù)維度的數(shù)據(jù)中臺,您上面問的情況其實(shí)是包含了很多數(shù)據(jù)相關(guān)的需求,您感覺業(yè)務(wù)邊界不好切分,因?yàn)榇嬖谔嚓P(guān)聯(lián)。我的理解是數(shù)據(jù)中臺復(fù)用的是數(shù)據(jù)的價(jià)值,在數(shù)據(jù)中臺的數(shù)據(jù)層上,需要搭建數(shù)據(jù)聚合層,來進(jìn)行數(shù)據(jù)的合并、連接,而數(shù)據(jù)中臺可以按照主題發(fā)布各種數(shù)據(jù)服務(wù)接口和分析接口,這部分服務(wù)可以整合到同一個(gè)業(yè)務(wù)中臺對外提供。
      簡單來說,從數(shù)據(jù)層面,業(yè)務(wù)中臺因?yàn)橛忻黠@的領(lǐng)域區(qū)分,可以按照業(yè)務(wù)邊界切分成多個(gè)業(yè)務(wù)庫。但數(shù)據(jù)中臺需要把離散的數(shù)據(jù)再整合到一個(gè)大數(shù)據(jù)庫中,對數(shù)據(jù)進(jìn)行加工、萃取、連接,挖掘各種數(shù)據(jù)的內(nèi)在關(guān)聯(lián)關(guān)系,分析核心價(jià)值及延伸的價(jià)值。

      來自山東 回復(fù)
    7. 有問題,可關(guān)注我微信公眾號給我留言,或者加我微信

      來自山東 回復(fù)
    8. 求微信

      來自浙江 回復(fù)
    9. yongtree

      來自山東 回復(fù)
  3. 新的見解,不錯(cuò)

    回復(fù)
  4. 厲害了 ??

    來自北京 回復(fù)