中臺的末路

3周帶你玩轉Excel!在行第一行家手把手帶學+作業實戰+答疑輔導,升職加薪快人一步,了解一下>>

中臺的概念不絕于耳,眾多公司忙著搭建中臺,這些中臺背后的問題,你了解嗎?

從2015年開始,到2019年現在為止。各大公司都在吹捧中臺理念。仿佛中臺是業務復雜性的救世主,是某些架構師和PM的新出路,各種割韭菜的講中臺的課程層出不窮。

當然,吹牛逼的時候大家都是揀好的說,苦逼的東西就只有內部人士知道。中臺到底靠譜還是不靠譜,只憑各路英雄的演講內容,那看起來是靠譜的。

先來看看這些公開的觀點,再以我的視角還原“中臺”的真相。

按照慣例,手動貼上文章的目錄:

中臺的末路

一、公開的觀點

1.1 中臺是什么

阿里巴巴集團前端業務中公共、通用的業務沉淀到了這個事業部,包含了用戶中心、商品中心、交易中心、評價中心等十幾個中心,而共享業務事業部正是“厚平臺”的真實體現,為阿里巴巴各種前端業務提供著相應服務中心領域內最為專業、穩定的業務服務。

——鐘華,《企業IT架構轉型之道:阿里巴巴中臺戰略思想與架構實戰》

中臺實際上是通用業務的下沉。

企業在一個行業耕耘多年之后,一般都會形成一些公用的業務,而這些業務是可以像中間件那樣進行下沉共享的。

再往前推一些,也就是比較早期人們常說的偏業務的基礎服務,在概念上并不是創新。

1.2 為什么要做中臺

中臺解決了什么問題?

其實和把程序內的公用邏輯封裝為Library差不多,就是盡量避免重復造輪子。一個輪子造100遍,對部門是沒有任何好處的;一個系統造100遍,對企業自然是沒什么幫助的。

早期的企業經常借鑒騰訊經驗,鼓勵內部競爭。但內部競爭的度往往不好把握,經常會出現“所有部門都在造差不多的系統”的現象。

中臺從公司戰略角度,將這些行為進行了規范化,公共的部分交給公共系統部門去做。

1.3 中臺給企業帶來的收益

1)工程方面

就像上面提到的,首先是有效減少了重復造輪子、重復建系統的現象。有相對統一的業務收斂位置,并在公共服務上快速高效迭代出新的業務。

2)數據方面

有了統一的用戶、訂單系統,就不會再有各種惡心的數據打通問題,不會有跨部門的數據墻。

有了統一的中臺,也就有了統一的數據規范。

對于大數據相關的需求,可以從相對唯一的數據出口進行業務迭代,不需要為每一個部門進行定制開發,浪費人力。

3)創新方面

這一項目也很好地詮釋了之前所說的“點、線、面”的理論,在“點”上根本感知不到的問題,在“線”和“面”的平臺上,更容易發現這些問題的本質,通過專業的技能解決這些問題,為企業帶來實實在在的業務價值,這就是很好的創新!

——鐘華,《企業IT架構轉型之道:阿里巴巴中臺戰略思想與架構實戰》

有了公共的中臺,意味著有了相對全局的視角,更能發現單點觀察難以發現的問題,在更大的業務層面進行一定的創新——聽著很有道理。

二、真相

中臺能解決問題么?是能解決的。

中臺能解決所有問題么?那顯然是不能的。

就像微服務架構一樣,架構師吹牛的時候天花亂墜,你做起來卻發現這條路上全都是坑。

2.1 技術方面

公用業務下沉,這個理念其實很樸素。

所有程序員都知道我們公用的邏輯要進行封裝、抽象,變成Library。中臺的本質其實就是把這種樸素的思想進行了一定程度的推廣。

1)難以應對 Cross cutting concern

根據中臺進行系統拆分和部門調整之后,還是會遇到 cross cutting concern,什么是 cross cutting concern:

The crosscutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross-cutting concerns.

有些需求難以避免地會影響整個流程中的所有系統:

比如,從技術范疇進行的一些改造(如為了完成tracing,所有系統增加trace id,并在log中默認攜帶)。

比如,從業務范疇進行的i18n改造(注:i18n是國際化的意思,Internationalization去掉頭尾的i和n剛好還剩下18個字符,程序員的智慧)。

這些改造需求一般天生就是跨系統、跨組、跨部門的,事情一帶上“跨”的字眼,就不好搞了。

舉一個典型的例子,某巨型互聯網公司員工抱怨,在當前的微服務和中臺架構前提下,做一個需求經常要改20+個模塊,苦不堪言,連上線順序都不一定搞得清楚。

當這20+個模塊又是跨部門的時候,就更難了。想要推動其它部門做一些短期看起來沒啥收益的事,太難了。

2)穩定性和靈活性的矛盾

對于一個系統來說,追求穩定性,那么必然會在修改和升級上較為消極;追求靈活性,那在功能迭代上一定會較為激進。這兩方面的矛盾本來就是難以調和的。追求其中之一,在一定程度上就得放棄另一方面。

就像網友經常講的不作死就不會死,沒有代碼才是真正的穩定之道。

Google程序員在Github上發起的行為藝術項目:nocode,沒有 code,就沒有bug——可謂棄療的典范。

有很多中臺系統被剝離之后,因為用戶眾多,一旦出現技術上的問題,影響面巨大。

從我的實際觀察來看,中臺部門的系統雖然初始立項的時候聲勢浩大,但基本也沒什么人關注這些公共系統的代碼質量或者測試質量。最終只不過是大家公用了一堆“垃圾”,“垃圾”在轉過幾手之后,后來的人基本就不太想對原來的代碼進行修改了。

可能有人會講你可以重構啊。

嗯,重構的前提是系統有完善的測試用例和可以跑的測試。事實上一般都沒有!在沒有測試的情況下,我們可以根據過往的系統需求文檔和 PRD來還原當時的業務場景,并進行測試補充。

但你又發現,中臺的性質(大多偏技術項目,基本沒什么PM把關或者出文檔)使其基本沒有什么靠譜的、詳盡的文檔。寫的復雜的中臺,連業務流程都理不清楚,還想寫測試,別做夢了哦。

3)中臺與前臺的模糊業務邊界、距離

在實際實踐時,中臺與FT的邊界往往劃得不清不楚。比如,用戶服務、用戶權益、用戶在各種子系統中的狀態,這些內容可能并不是用戶服務本身關心的內容。

但往往需求也會提給用戶服務,這時候用戶服務就只是進行字段存儲,而狀態機變化則完全在外部。

如果對系統內的個別數據不進行管理,那么有其它接入方接入時,就無法解釋清楚字段的含義和使用場景。

如果不接受這些不相干的數據接入,那么前臺流程系統可能會在自己內部重新建立自己的數據系統,這部分系統又極有可能和中臺有功能上的重疊。

如果想要把這些數據接管過來,那么中臺又需要梳理所有業務場景。或者說明需要把所有對數據進行修改的邏輯全部收攏到中臺內部,這往往又會產生與中臺與前臺業務邊界的沖突。

難以給出有效的邊界,就意味著無窮無盡的撕逼。這便是很多中臺的兩難:我接不是,不接也不是。

如果去問那些中臺業務部門的系統開發負責人:某些業務要不要你們來做,連這些人自己都說不清楚。

2.2 人方面

如果要做中臺,那往往需要將業務部門的一部分系統進行下沉。

下沉并不僅僅是一個技術問題。

如果要把系統從一個部門變到另一個部門,這一定會帶來人員的調動。從情感上來講,人們都是討厭這種部門變動的。因為“領導”會在部門調整中發生變化,同事也經常會隨著部門調整而離職。只留自己在原地填坑給誰都不愿意。

也有些公司在調整中進行粗暴的系統交接,如果系統需要下沉,那我直接從原來的維護團隊手里奪過來,交給中臺部門來管理。

這一樣會引起雙方的反感:

  • 交接方:這是我們加班加點,辛辛苦苦開發出來的系統,憑什么交給別人?奮斗了半年難道就是為了給別人摘桃子?
  • 被交接方:這個系統原來的維護團隊水平極低,代碼就是一堆“垃圾”,他們不想搞了就隨便扔給我們?憑什么啊?我們又不是接盤俠。

即使貴司運氣好,在系統交接過程中沒有出現問題,那交接后也不好說。被交接的系統在交接后往往陷入消極維護狀態,這時候前臺業務接入中臺會比以往更加困難,這種困難使前臺業務的不滿積累到一定程度之后,會再次催生前臺部門重新造一套新的自己的中臺,而部分或全部放棄原來的中臺。這樣,原來的中臺部門便會陷入尷尬的境地。

生存空間被擠壓,人也自然很難待得下去,各公司的中臺部門,人跑的比香港記者都快。

2.3 部門、公司、組織架構方面

1)跨部門溝通障礙、跨部門目標差異

進行部門劃分之后,每個業務部門會有自己的一套目標體系。部門與部門的目標(KPI)一般是不相同的,如果相同的話,那也就沒必要分多個部門了。

而部門與部門之間的目標在某種程度上甚至可能有沖突。

例如,A部門Feature Team較多,主要負責業務功能迭代,需要更強的靈活性;而B部門負責中臺數據,主要關心系統穩定性,也就是前文提到的靈活性和穩定性的矛盾。

若此時出現cross cutting concern,兩個部門需要在矛盾上取得一定程度的平衡,這種平衡在個別情況下是不可得的。

例如在一段時間內,中臺部門的目標是提高某個商業指標,讓公司更賺錢/省錢。這時候前臺業務提來了新的需求,這種需求是能使流程開發更加靈活的,但與中臺部門的KPI不在一個航道上。

中臺部門顯然要把需求排排優先級,把任務排排主次。前臺部門又會覺得中臺支持個需求怎么這么龜速又唧唧歪歪,不如自己實現了。

前臺業務也有自己的理由:“自閉環”嘛,這詞真是好用。

2)公司利益分配

毫無疑問,距離業務近的地方比距離業務遠的地方能分到更多公司增長的成果。

中臺看起來是業務,但又是公共業務,既然是公共業務,那基本上沒辦法分享到任一單一業務成功的紅利。縱使其成功的原因中,中臺的強大、便捷是重要原因。

這會導致什么問題呢?

沒有人愿意接手中臺項目,中臺項目變成燙手的山芋。大佬無法在中臺項目上獲得紅利,小弟們沒法在中臺項目上獲得利益。中臺功能確定以后,只有出事故的時候大家才想起你來。穩定運行是應該的,出事就是你的鍋!

3)利潤中心?其實是成本中心

最重要的是讓信息中心部門從之前在企業中“業務支持”的組織職能,轉變為基于企業核心業務和數據進行運營的團隊,這個團隊會更快、更好地支持業務發展的同時,逐漸掌握企業最核心的業務和數據,逐步培養出企業最稀缺的“既精通業務,又熟悉技術”的復合型人才。

在接下來整個社會進入開放共享的時代,企業最大的價值將會是基于這些核心業務和數據進行對外開放的運營,到那個時候,這個部門將成為企業最為寶貴的資產。

——鐘華,《企業IT架構轉型之道:阿里巴巴中臺戰略思想與架構實戰》

在大多數公司,中臺部門和基礎架構一樣,會被當成是包袱而不是財富。可能有些人讀到這里會不太爽。

我們來看看,科技公司是怎么看待員工的呢?

在DDD相關的書里提到兩個概念:成本中心、利潤中心。

技術對業務參與不強的情況下,技術部門基本上都會被當作是成本中心。也就是老板要達成自己的目標,必須不情不愿地花錢去養你們這些技術團隊。

對應業務側開發來說,想要改變老板的這種看法,需要讓業務系統和業務人員之間進行強聯動,將一部分業務人員變成系統人員架構中的業務專家角色,或者是研發人員自己變成一個業務領域專家,就是有些人常說的你得跟老板穿一條褲子。

從這方面來講,大多公司的基礎架構角色就比較尷尬。業務驅動的公司,基礎架構并不是其致勝要素。所以不管你做的再好,只要公司沒有用技術賺錢,那么這部分的支出就只能被當作單純的成本。

當然了很多做基礎的大佬也根本不在乎,公司只是個練兵場,練成了帶小弟們跳槽就好。

中臺也是一樣的,從業務一線剝離到后方之后。中臺離業務的距離越來越遠。公司高層漸漸看不到繼續對中臺進行投入的價值,中臺便漸漸變成了他們眼中純粹的成本中心,是公司財務的包袱而不是財富。

2.4 行業方面

中臺建設一般要考慮公司的實際情況,這樣建設出來的系統可以應對一段時間內的公司業務變化。然而公司的壓力有時并不來自于自己的業務方向,可能來自于行業內其它公司的模式挑戰。

理論上來說,只要一個公司的業務系統架構建設完成了,便已經完成了一種架構上的固化。這時行業內如果有新的模式獲得了成功,公司肯定要進行跟進,但是新的模式一定意味著對原有系統、架構的挑戰。

試想,原來系統架構是針對線上交易設計的,突然有一天,O2O模式被證明有利可圖,大多數公司都開始轉向線下。原有的流程、模式當然想要復用,但是這時候復用的成本很可能比重新開發還要高。

眼睜睜看著競爭對手們甩掉包袱,輕裝上陣,以更低的成本更短的時間攻城略地,擠壓自己的生存空間。

這時候怎么辦呢?

大多數公司給出的方案是成立新的業務部門,在新趨勢新陣地沖鋒陷陣。新部門肯定也要用到原來公司的老服務,又碰到了我們的老問題:跨部門合作,新部門的成功并不會讓老部門多得到多少好處,配合自然不會太積極。

如果新部門的嘗試獲得了初步成功,得到了公司資源的傾斜,獲得了有效的人力資源補充。之后又會帶來新一輪重復造輪子,互相不合作,互相撕逼的腥風血雨。

——簡直是一個輪回。

三、結語

經常有小伙伴說,國內某公司中臺非常好,大家都在學。

嗯,我倒是想問問了,如果真的做的好,某公司旗下的金融公司和電商公司還會需要兩套完全一樣的基礎架構,和好幾朵云?

作為一個技術人員,在各種烏七八糟、花里胡哨的概念“轟炸”下,應該能夠保持理智,不要被各種人帶節奏。

最后,把曹大博客的slogan分享給大家:

If you don’t keep moving, you’ll quickly fall behind.

第一次讀到的時候,振聾發聵,和大家共勉!

 

作者:曹春暉;公眾號:碼農桃花源(ID:CoderPark)

來源:https://mp.weixin.qq.com/s/OSTMAMal_XLV0feMERamBA

本文由 @碼農桃花源 授權發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

評論
歡迎留言討論~!
  1. 文章分析很透徹,指出了中臺建設中遇到過的很多必須面臨的實際問題。我司在中臺建設過程中,也經歷過誠如筆者所提的成本中心、包袱等問題困擾。
    個人認為,透過現象看本質,從技術角度講“中臺”還是一套信息化系統、一副工具。工具的作用是提高人的工作效率,企業的信息系統則是滿足企業的業務需求,提高企業運作的整體效率。
    在不同的階段、不同的時期,需要的工具也大不相同。誠如原始時代石器就能滿足需求,但在工業時代蒸汽機才能滿足基本需求是一樣的。電腦才開始普及的年代,企業業務發展的渠道比較單一、簡單的時候,可能一個excel都是很先進的信息化系統了。隨著業務的發展,進銷存、erp、mes、oa慢慢的進入企業的信息化采購清單。從線下到線上,oms成了必選項。再到O2O、OAO,隨著業務的發展,中臺建設又成了企業必須要考慮的。
    中臺的出現和發展有它必然的時代和需求環境,它要完成的也是它某一階段的歷史使命。企業在不斷發展,信息系統就要不斷適配其發展需求,所有的信息系統都將成為過去式,別指望一個中臺能用到世界末日。
    中臺不是一個放之四海而皆準的東西,每一個企業都有自身的業務的特殊情況,別人的經驗可以借鑒,但不可能照單全抄的,就像佳沛奇異果和品勝充電寶的信息系統肯定是不同的,雖然都是銷售商品。
    正確看待和解決中臺建設過程中的問題,筆者所列的問題,不僅僅是中臺,很多也是企業信息化必然面臨的問題,諸如:技術和業務部門的扯皮、業務前置或后置的矛盾。這些問題只有想辦法去解決和克服,才能讓企業發展不被束縛,發揮信息系統——中臺應有的價值和作用,進而用好這一工具,發揮它最大的效能。

    回復
    1. 誠然,中臺本質上是企業內部的復雜信息化系統,屬于基礎設施,其建設過程要比單純的業務系統更為復雜、更加系統化、耗費更多資源,尤其是需要長期迭代維護,才能更好的簡化前臺,為前臺提供火力支持。

      回復
  2. 自己做不好不代表這個東西是壞東西。沒思考自己業務是否需要中臺時,做中臺當然無意義。
    從系統構成看,是一個高度抽象的能力復用集合,降低重復造輪子的成本和提高單系統的價值;從業務組織看,是業務的引擎也是快速支持前臺業務變化的緩沖池,業務成型且有沉淀價值時才適合下沉到中臺。

    中臺無非就是做個水庫,來供應整個流域的工業農業居民用,但不是單一供應給工業用。

    回復
    1. 理想很豐滿,現實和骨感

      回復
  3. 我司實施中臺戰略之后原來的前臺業務部變成了交付實施部門,連業務邏輯都轉移到中臺了,交付實施從中臺挑選不同的功能組件合并出一個版本交付給客戶,美其名曰個性化配置。

    回復
    1. 可能是貴司對中臺概念的理解犯了拿來主義的錯誤,本質上可能就是想做個性化配置的業務,順便搭配上中臺戰略思想的概念,蹭個熱度吧。

      回復
    2. 確實是為了BP里面寫一些新名詞,每次看企業宣傳片都覺得是在說別人的公司

      回復
豹子机赌大小玩法