從軟件架構看中臺:中臺首先是管理方法,其次才是軟件方法

0 評論 252 瀏覽 2 收藏 14 分鐘

近幾年IT市場上中臺產品的建設情況,應該是可以用“有人辭官歸故里,有人星夜趕科場”來形容,各家拆中臺、建中臺此起彼伏,各路中臺好壞的說法甚囂塵上,這里面有對中臺深有研究的專家給出中肯之言,也有只在吹噓高大上概念的,也有在說中臺末路的,信息魚龍混雜;

這篇文章想擱置爭議,我們更多的想去聊一聊中臺的背后,在企業軟件架構中的位置,中臺可能的做法;設計中臺之初想解決的是什么問題以及為什么有的落地的好,有的落地的很差,這背后的要點在哪里。同時,幫助非IT的同學也能對中臺有基本的了解去更好的用好中臺,對一些八股文免疫,無論對方來自所謂的大廠。

這是一張傳統電商企業經典的軟件架構圖,我們以此為案例進行分析:

圖1 軟件架構圖

從最開始的小門小店、軟件的MVP到后面各個板塊完善的系統,企業的發展過程也是企業軟件架構逐步完善的過程,世界上沒有最完善的軟件架構,只有當前場景下盡量最優和最合適的軟件架構:

康威定律:“任何組織在設計系統時,都會傾向于構建出與其自身信息結構相匹配的系統”,即一個組織內部的溝通方式、團隊的結構與企業管理文化,是直接影響最終軟件系統的架構和設計。

所以籠統的去談論中臺好壞并無意義,因為中臺首先是管理方法,其次才是軟件方法,我認為更值得客觀討論的是:企業在什么場景下,引入和設計怎么樣的中臺對企業發展是有利的,什么樣的認知是有害的,這篇文章會就此問題進行討論。

一、中臺的適用場景

我們軟件傳統的開發模式無非是前臺+后臺,上面的架構圖里面的軟件系統和整體系統基本都是這么設計的,各個組織和各個系統各司其職對業務進行支持,如果此時:

  1. 隨著公司業務的發展,公司內部開始開發多條產品線,這多條業務線隸屬于多個部門,但它們又有很多通用的模塊,對所有共性的業務模塊的支持,如何提升效率;
  2. 產品服務的某些能力是有可能在多種場景下去復用,需要的是對問題較為完善的解決方案框架;
  3. 業務部門增多,但是不同業務部門都會只專注于自己的事情,提的需求也只是局部的,那么問題是,難道局部最優就是整體最優了嗎?或者說業務部門此時此刻理解的局部最優,就是真的是符合整體利益的局部最優解嗎?
  4. 在直線職能式的組織框架下,很多時候遇到的問題愈發深刻,已經不是單個團隊可以解決的時候,我們經常說要去做難而正確的事情,但是在kpi或okr的機制下,很多時候很多組織事實上是在回避那些長期困難的事情,那什么樣的組織和軟件架構去執行產品運營戰略,先行去攻克那些交叉的復雜問題,也得有能力去探索出一條可行的路出來,打造MVP(最小可用版本,寧缺毋濫)和PMF(適配客戶,小步迭代)出來?
  5. 信息和數據分散在各個系統,如何打破各個異構系統之間的孤島,統一數據讓數據產生價值?

需要說明的是,這些問題也是企業發展中遇到的常規性問題,歷代管理人員和軟件工程師都給出了解決路徑,中臺只是其中的一種,事先人們不應該過度夸大中臺的作用,應以落地結果為導向進行客觀評價。中臺為解決上面的問題提出了三種形式:產品中臺、技術中臺和數據中臺:

  • 產品中臺:產品中臺首先應該代表先進生產力,設計和沉淀可復用標準化產品和產品能力,為業務提供完善的問題解決方案或產品能力,堅持長期主義,在效率和核心價值提升上助力業務發展和敏捷創新;
  • 技術中臺:將企業通用的底層技術能力,基礎設施、工具鏈、中間件、開發支持平臺等抽象和統一管理為可復用的中臺服務,為各個業務線提供統一、規范的技術支撐,核心目標是避免重復開發來提升效率、降低系統故障率、通過標準化能力支持產品創新和沉淀技術資產;
  • 數據中臺:建立合理的數據管理框架,沉淀數字資產,將企業內部多源異構系統的數據進行采集、整合、治理、建模與服務化,統一管理進行全鏈路分析。

二、數據中臺的本質

在圖1的企業架構圖我們可以看到,在目前的架構下,企業各個業務系統都在管理自己那一塊的數據,多個異構系統之間就必然存在數據孤島,數據和信息已經被分散在各處,對以上的問題5的數據孤島問題,為了完成對數據的統一管理,數據中臺包含了2個部分:

  1. 數據采集:實現基本的數據采集、數據倉庫建立和數據分析能力的共享,是將做數據相關工作的技術團隊整合,根據頂層設計和業務需要進行統一管理;
  2. 數據應用:對各業務線的數據打通、數據共享和協同運用,以實現具體的業務目標為目的,比如企業經營數據分析、用戶數據分析等,一般是通過數據倉庫的bi分析工具、建立主數據分析平臺來實現。

圖2 數據建設

通過建立數據倉庫(DataWarehouse),解決異構系統統一的數據經營分析問題而存在(所以數據倉庫只讀不寫),在管理上從上而下把統一分析的體系定下來,然后再通過統一的規則,對數據倉庫進行寫入和存儲,然后再根據統一標準進行分析做應用層的呈現。其次,對于一些固定數據的加工邏輯,可以在數據倉庫上建立了小的數據倉庫即數據集市(Data Mart)來進行交易和映射完成,方便不同的業務對數據進行規范化的處理需求,底層數據源還是一致的;

主數據平臺一般是以人或物或某個基礎的實體,可以打通各個業務屏障將數據資產統一管理起來,根據需要把全鏈條必要的客觀的數據也放進來進行統一管理和分析,在全局角度根據業務模型統一分析找到規律來輔助決策,主數據特別是用戶主數據在對用戶數據全鏈路分析方面極具意義,物料清單主數據對產品生產所需材料及其相關信息的核心數據進行管理,對企業標準化生產、成本核算和供應商物料供應效率都很有意義,讀者可以根據產品設計所需進行靈活應用;

建設數據中臺是發掘數據價值的基礎,在Ai時代,Ai的實時數據分析和推理能力將會進一步放大數據價值,但是基礎一定是要先做好數據框架的管理和維護。同時,需要說明的是,在軟件行業大家普遍認為數據中臺并不是一個新的事物,因為在中臺出現之前這些數據工作已經在進行,數據中臺到目前并沒有很突出的理論貢獻出來,不過這也反過來一定程度上也證明了這套數據設計框架自身的先進性。

三、產品中臺的本質

產品中臺是想從小中臺驗證價值,通過中臺實現杠桿效應,提升效率,撬動業務實現規?;瘎撔拢瑸榱藢崿F這個目標,產品中臺的建設可以概括為中臺向前和中臺向后:

  • 中臺向前:產品中臺向前直面業務,對標核心數據,實現業務需求,打造系統化的完整產品解決方案進行完整的輸出,沉淀優質經驗,不斷迭代;
  • 中臺向后:產品中臺向后把某些產品能力抽象為更細的通用能力,在更多場景里面接入,對此同類問題提供標準化的解決能力;

圖3 產品中臺

在企業發展越來越大的時候,在直線職能式的組織框架下,很多時候遇到的問題已經不是單個團隊可以解決的了,對以上的問題4,需要去探索出前沿的這些交叉復雜性問題,打造出來產品的MVP版本。中臺在這方面具有先天的優勢,從以上架構圖可以看到,中臺日常就會調用后臺的各種基礎服務,是從全局的角度來看待問題和設計系統,找到最本質的流程去設計,然后承接前臺各個業務線的需求,輸出通用優質的產品框架和個性化方案,落地即是當前最優解;

中臺事實上承擔了各個業務支撐器的作用,支撐著多個部門和系統,由中臺牽頭,以業務的核心數據指標為優化目標,以“小中臺大前臺”的方式,可以更高效的設計出MVP最小可用版本進行小范圍驗證,再通過PMF適配客戶進行落地,以此來解決復雜交叉的企業問題,同時以此推理,對于新的產品創新這個路徑同樣具備可行性,中臺理論上可以以MVP和PMF為抓手,作為創新中心進行存在,根據頂層戰略需要,提前預判業務發展方向,在中臺層面探索新的產品方案建設,為業務探索前沿的產品能力建設,主動去解決復雜問題,既能開疆拓土,也能打掃后院。

四、寫在最后

在行業來看,無論是阿里、字節、美團、SHEIN等企業內部中臺建設,無非也是以上幾種,效果也是有好有壞,比如美團以產品中臺統一外賣、到店、酒店和旅行等用戶體系和交易流程,字節的APP工廠的成績,也有大廠的中臺偏離業務導致總是落后一步。中臺首先是管理方法,其次才是軟件方法,希望我們的視野更加廣闊,兵無常勢,水無常形,產品經理的角色必須為始終產品的價值埋單才是唯一正途,回歸常識而不是虛名,從最本質的東西出發才是最有力量,希望這篇文章能對你有所啟發。

本文由@大風吹 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!