阿里巴巴架構師:十問業務中臺和我的答案
一切業務資料化,一切資料業務化。
“中臺”概念這幾年非常火,特別是阿里、騰訊、百度、京東等網際網路公司最近頻繁的基於中臺調整組織架構,把“中臺”的熱度又上升到另一個高度,甚至有這樣的聲音, 90 年代不做 ERP 會死,現在不做中臺也會定企業生死。中臺的概念起源於阿里,也發展於阿里。筆者有幸參與阿里業務中臺方法體系建設,也主導參與一些阿里雲新零售業務中臺專案,經常被問到如下問題。本文作為“阿里巴巴業務中臺”專題的第一篇,和大家分享一些思考(本文內容僅代表作者個人觀點,歡迎交流)。
什麼是業務中臺?
中臺起源於阿里,2015年,阿里提出了 “大中臺,小前臺”戰略,靈感來源於芬蘭的一家遊戲公司Supercell,僅300名員工,卻在短時間推出多個爆款遊戲,成為全球最會賺錢的遊戲公司。其實,阿里早在 2009 年建設“共享事業部”開始,就已經開始了中臺的探索,並透過十年上百個客戶的實踐,阿里也將自己的技術和業務能力沉澱成為一整套解決方案和方法論體系。
中臺是什麼?不同的人有不同解讀。我認為,中臺是一套結合網際網路技術和行業特性,將企業核心能力以共享服務形式沉澱,形成“大中臺、小前臺“的組織和業務機制,供企業快速低成本的進行業務創新的企業架構。中臺又可以進一步細分,比如業務中臺,資料中臺,xx中臺。本質上,都是對企業通用能力在不同層面的沉澱,並對外能力開放。
業務中臺將企業的核心能力以數字化形式沉澱為各種服務中心。業務中臺的目的是“提供企業能夠快速,低成本創新的能力”。業務中臺的核心是“構建企業共享服務中心”。業務中臺的過程是透過業務板塊之間的連結和協同,持續提升業務創新效率,確保關鍵業務鏈路的穩定高效和經濟性兼顧的思想體系,並突出組織和業務機制。業務中臺也包含技術和組織兩大部分,透過“方法+工具+業務理解”加以實現。
資料中臺透過資料技術,對海量資料進行採集、計算、儲存、加工,同時統一標準和口徑。資料中臺把資料統一之後,會形成標準資料,再進行儲存,形成大資料資產層,進而為客戶提供高效服務。資料中臺建設的基礎還是資料倉儲和資料中心。
那業務中臺和技術中臺的關係是什麼呢?阿里有句話非常形象,“一切業務資料化,一切資料業務化”。業務中臺源源不斷地從業務造資料,把業務實時線上的交易資料進行統一記錄和沉澱,這就是“業務資料化”;而資料中臺對沉澱的資料進行二次加工,透過資料標準及演算法,產生進一步的分析型資料服務,這些資料服務反向又服務於業務,將業務固化,形成業務閉環,也就是“資料業務化”。比如天貓淘寶的使用者實時線上的交易資訊,存放在業務共享中心的交易中心當中;而資料中臺基於這些使用者歷史資訊,並透過資料分析後的使用者畫像和標籤屬性,提供服務給到前端,形成千人千面。這就是我們一直講的資料驅動、資料閉環、資料價值。
阿里業務中臺核心架構是什麼?
阿里巴巴超過數十個業務單元(如淘寶、天貓、聚划算、阿里巴巴)均不是獨立構建在阿里雲之上,在後端阿里雲技術平臺和前端業務之間有“共享業務事業部“(也就是這裡講的“業務中臺”),將業務當中公共、通用的業務沉澱下來,包括使用者中心、商品中心、交易中心、評價中心等十幾個共享單元,是“厚平臺的真正實現“。而後端的阿里雲提供計算資源和中介軟體PaaS雲服務能力做載體。同時,使用集團近十年的雙11、雙12的高可靠、可穩定的運維保障能力,對整個系統進行支撐。中臺的使命是從下到上逐步完善阿里的整個體系,從阿里雲、資料、中介軟體、演算法,到上面支撐的各種業務解決方案,構建阿里自己核心的能力。
談到中臺,不得不提阿里共享服務事業部的由來,在淘寶初期,主要面向C2C的電商領域,整個系統都是圍繞一套“煙囪式”的淘寶技術框架進行。隨著業務的不斷擴張,集團成立出天貓事業部主抓B2C電商領域,又形成了一套煙囪式發展。這種煙囪式的架構體系帶來了諸多不足,比如成本的重複投入和維護、資料之間打通複用的難度、幾年之後推倒重建的風險。為了解決這些問題,集團已經開始構建共享服務體系,來沉澱和複用業務能力,但是由於沒有過多的業務話語權,共享服務體系的建設一開始並不順利。之後,隨著“聚划算”團購專案的啟動,各種系統的流量都需要透過聚划算,這時,共享服務中心得以大展手腳,逐步將集團核心的業務能力構建成使用者中心、商品中心、交易中心、評價中心、店鋪中心等等數十個共享服務。可以說整個阿里中臺的革命也是共享服務中心的革命,各共享服務中心聚焦核心業務單元能力的構建,協助目前集團上百個前臺業務的快速創新。
我的企業需要業務中臺嗎?
阿里業務中臺如此強大,那對於傳統企業,在做數字化轉型的過程中,是否需要業務中臺呢?我認為,如果你的企業有以下問題的任何一個,有必要考慮建設業務中臺:
- 業務具有不確定性:創新困難,無法支撐市場高速變化。如渠道扁平化管理,統一會員營銷,全渠道等。
- 業務不線上:企業資訊化程度不足,大量人工統計,核心業務沒有做到實時、線上、統一。比如會員訂單不完整,經銷商進銷存資料不線上等。
- 煙囪式系統多:系統割裂,資料孤島,端到端無法實時協同,更無法基於現有系統進一步構建資料中臺。
- 系統重複建設:內部大量重複建設,缺乏業務核心的固化沉澱,系統服役到期只能推倒重建。
- 業務與網際網路緊密:業務與網際網路緊密相關,特別是面向市場消費者,系統的彈性不足,需要支撐不確定的使用者數量。
有些同學認為業務中臺是大公司要考慮的,而對於業務不復雜、人員也不太多的中小公司不適合。我有不同的觀點,其實,無論業務複雜與否、人員龐大與否,只要你的業務與網際網路相關,需要快速應對消費者帶來的不確定需求,需要打通煙囪林立的系統,需要業務線上來提高企業創新和協同,都應該考慮建設業務中臺;同時,業務中臺也不一定徹底推到整個系統,首先要改變意識,分步實施、小步快跑,有很多可落地的途徑和方法。
那業務中臺對企業有什麼價值呢?這裡我們先簡單羅列一下。
1、激發創新:讓企業透過核心能力的沉澱,給予快速創新機會,拉通業務整體的點線,降低了試錯成本;
2、高效協同:中臺側重的是跨部門跨團隊的深入合作,啟用了組織創新;
3、業務線上:服務中心化的構建打破了煙囪式的IT架構,提高核心資料實時/線上/統一;
4、人員提升:業務沉澱中臺提升了IT人員能力,提高業務運營以及全域性意識,成為既懂業務又懂技術的核心戰略人才;
5、變現營銷:會員資產化,全渠道下沉,補全客戶畫像,提升精準營銷;
6、智慧商業:業務資料化+資料業務化的閉環模式,構建了商業智慧的基礎;
可以看出,業務中臺無論對企業戰略發展、商業模式創新,還是內部高效協同、人員培養提升等都會帶來很多好處。
如何規劃和建設業務中臺?
很多人認為業務中臺落地難,其實難在具體的規劃和落地實施上,我們對業務中臺的建設路徑有這樣的一些看法:
1、決心變革:企業內達成戰略共識,一把手牽頭,業務/技術等團隊全域性共識。做總體戰略規劃、分步實施,找準切入點,解決具體業務問題。比如會員營銷、經銷商門店、全渠道、採購供應鏈,不同的切入點策略不同。
2、成功試點:透過業務和系統分析調研,明確業務目標和範圍,完成技術平臺引入、中臺建設方法論宣導,並選擇驗證過的技術平臺和實施團隊。進行試點,梳理標杆,積累經驗。比如從新的業務系統嘗試,或者改造現有系統,步步為營。
3、持續融合:總結出適合企業自身的理念和規範,最佳化組織、提升中臺效率。並全面迭代和構建企業業務能力生態。
現有系統如何改造?
前文講到業務中臺在分步實施中,講究總體規劃、分步實施。面對現有系統,並不一定都要進行中臺改造,我們建議“外鬆內緊”:
外松:面向市場和客戶方面,以精細化運營為驅動,這些系統更適合建設業務中臺。對外市場,快速應變,敏捷創新。比如電商、客戶管理、全渠道、營銷、創新業務。
內緊:面向內部和員工,以標準化流程為驅動,這些系統更適合保持不變,與業務中臺進行對接。對內管理,流程嚴謹,標準規範。比如PLM、MES、HR、OA、財務。
共享中心如何建設?
在企業的中臺能力中心建設中,核心是共享服務中心的建設,不同行業的業務中心有所不同,比如新零售領域,一些參考可以有使用者中心、會員中心、營銷中心、商品中心、庫存中心、交易中心、結算中心、渠道中心。中心設計需要關注如下幾點:
1、共享中心是核心業務通用能力沉澱,需要考慮能力地圖,產品整體規劃,以及協議標準、業務需求構建標準等;
2、共享中心目的是複用和協同,需要透過領域模型,對業務場景流程進行有效建模;
3、共享中心要考慮能力開放,透過API介面、配置管理、或者low-code的高可配置執行機制;
4、共享中心實現前端應用和後臺的解耦,需要一定組織機制和考核傾斜,制定溝通機制和衝突升級機制。
業務中臺與前臺/後臺/平臺的關係?
業務中臺與前臺和後臺,我認為,主要是這樣的配合關係:
前臺:敏捷創新,面向不同使用者的觸點,“點”狀繁花似錦。比如2C的電商應用、2B的門店管理等,使用中臺開放能力快速變化滿足市場的不同業務場景。
中臺:核心能力共享沉澱, “面”狀協同複用。比如交易中心,正常的交易下單、雙十一的預復購、團購秒殺的拼團場景,都可以透過公用的交易中心統一配置。
後臺:強大的支撐能力,比如支撐系統穩定高效執行的各種後端系統,以及前文提到的面相內部標準化管理的系統,由中臺統一協同和對接。
比較晚前中後臺,我們來比較一下中臺、平臺和中心化。
中心化類似煙囪式架構,一箇中心解決整個技術堆疊,而平臺和中臺都是為了去中心化而生,具體的區別如下:
1、中臺是面向業務的能力組合和複用,提供整合化的解決方案:中臺的目的是提高研發效率、降低創新的成本。中臺包括人,組織,平臺,資料,標準,規範,是人和系統的一整套體系。
2、中臺是平臺的自然演進:平臺是單一團隊、部門、系統的效率提升,而中臺是多領域、多BU、多系統的負責協同。如果說平臺的目標為高內聚、低耦合、職責邊界清晰;中臺是平臺化的自然演進,這種演進帶來“去中心化“的組織模式,突出複用、協調、業務創新差異化構建。
3、中臺不是系統,中臺是一種體系/生態/方法論:中臺有標準和機制,解決頂層領域下各業務子域的高效協同和資源複用問題。各部門、業務域共同建設,是中臺能力的使用方也是提供方。同時,中臺提供整個業務快速響應的一種理念和方法,對上層業務支撐。
業務中臺建設的關鍵要素
我們認為,企業在業務中臺建設當中要關注4個升級:
1、戰略升級。透過中臺建設,落地企業數字化戰略。中臺一定是“一把手工程”,整體規劃分步實施。
2、組織升級。組織架構需要與中臺架構相匹配,根據企業實際情況最佳化組織效率,提升效能,資料化運營,更好支援業務發展和創新
3、流程升級。將企業現有流程進行梳理,最佳化及固化企業流程,提高企業共享複用能力,提升企業運作效率。
4、技術升級。透過網際網路技術,對企業基礎技術設施進行升級,降本增效,達到企業IT部門整體技術升級。
業務中臺需要哪些核心技術來支撐?
業務中臺落地中需要一些核心技術,我們也叫“技術中臺”,有一些通用的建議:
1、儘可能拆分,共享中心建設:企業應該儘可能地拆分自己的應用,進行共享服務中心的建設,將核心的業務能力複用和沉澱。共享中心的拆分也可以有層次,可從從基礎主資料、核心業務、流程規則等角度來進行拆分。
2、去中心化,線性擴充套件:企業需要採用去中心化架構,沒有核心流量匯入點,服務中心儘量無狀態,便於水平擴充套件。這樣平均分擔壓力,負載均衡,對單箇中心帶來的負載更小,故障影響的範圍也更小。
3、資料化運營:去中心化也會面對系統運維和管理成本上升的問題。企業需要對自身的運維運營過程進行積累和沉澱,整理出資料化、自動化運維的經驗,同時增強監控告警、限流降級、效能分析診斷等方面的能力,精準定位目前系統中存在的問題,並提出相應的改善方案。
4、非同步化,最終一致:在大量的實踐中,大部分業務流程不需要強一致性,而使用最終一致來平衡。我們需要使用非同步解耦,如使用訊息佇列來完成業務邏輯,縮短相應週期。
5、儘可能自動化:企業進行中臺改造,要求企業儘可能提高自動化能力,比如自動部署、自動彈性擴容、自動升降級、自動限流降級,降低運營成本,也提高系統的穩定性和業務連續性。
6、儘可能使用成熟元件:中臺的建設要求企業將重心放在服務中心上,對於底層元件,尤其是中介軟體層面,儘量使用成熟的雲原生元件來提高系統穩定性和效能。目前,阿里巴巴中介軟體已經將多年經雙十一購物狂歡節的嚴苛考驗的技術沉澱,以阿里雲標準雲服務的方式輸出給外部客戶,其中包括多款阿里云云原生中介軟體產品(比如K8S/EDAS/MQ/DRDS/ARMS/PTS/CSB/GTS/MSE/ACM),阿里與流行的雲原生技術完整融合(比如Dubbo/SpringCloud/K8S/RocketMQ/Nacos)。
阿里在業務中臺建設上能提供什麼?
阿里是最早提出中臺概念,併成功實施落地,阿里中臺所配套的中介軟體是經過阿里多年雙十一洗禮的成熟產品。阿里內部幾百個業務應用,共享一個技術中臺底座,服務新的業務場景,帶來更好的使用者業務體驗。同時,阿里雲透過為上百個外部客戶實施業務中臺,培養了一大批具備中臺實施交付能力的行業ISV,同時沉澱了大量行業最佳實踐。
阿里雲提供一整套“業務中臺技術解決方案”可以解決的問題有:
- 將企業核心能力下沉共享,加速企業創新速度;
- 規範IT全生命週期管理,提升研發效率與質量;
- 提供行業最佳實踐,助力企業快速落地中臺戰略。
架構優勢
- 雲原生:支援彈性排程、微服務化解耦,自動化運維;
- 高可靠:阿里中介軟體產品支援,歷經多年雙11考驗;
- 高併發:支援按流量線性擴充套件,支撐海量使用者。
更為重要的,阿里基於近十年的最佳實踐,沉澱了一整套業務中臺實施的方法論,包括中臺架構設計、微服務架構設計、中臺開發規範、全鏈路壓測等方面的最佳實踐。這些全方位的中臺建設方法論、阿里商業能力、阿里雲技術支撐,不僅僅是技術紅利的分享,更重要的是整個阿里中臺戰略思想的傳播。
更多可以參考“阿里雲業務中臺技術解決方案官網”。
小結
本文希望透過筆者在阿里業務中臺方法體系建設及專案中的一些經驗,為企業在業務中臺建設過程提供一些幫助。同時本文是“阿里巴巴業務中臺”專題的第一篇,後續我們還會有中臺方法、中心設計、典型場景、最佳實踐等更多精彩內容,敬請期待,歡迎與我交流。
本文為雲棲社群原創內容,未經允許不得轉載。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69949601/viewspace-2667131/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 基於大中臺架構的電商業務中臺最佳實踐之一:業務中臺總體架構介紹架構
- FAQ丨構建業務安全平臺架構,你想要的答案都在這裡架構
- 趣頭條 業務架構師架構
- 架構師之路 - 業務領域建模架構
- 架構師害怕程式設計師知道的十項技能架構程式設計師
- 業務架構架構
- 不懂業務創新的工程師,不是好的架構師 | 深度工程師架構
- 如何看待阿里巴巴最新的「大中臺,小前臺」組織架構?阿里架構
- 單體架構&微服務架構&中臺服務架構架構微服務
- 按照業務領域畫資料架構圖 業務架構 資料架構架構
- 程式碼重構-業務中臺化
- 金融分析平臺架構師招聘架構
- 談談中臺架構之交易中臺架構
- 架構思考-業務快速增長時的容量問題架構
- SaaS業務架構:業務能力分析架構
- 馬雲:我和我的阿里巴巴是幸運的阿里
- 阿里巴巴十年Java架構師分享,會了這個知識點的人都去BAT了阿里Java架構BAT
- 關於軟體架構和業務架構的思考架構
- 微服務業務架構的探索微服務架構
- 阿里十年架構師用一張圖告訴你什麼是系統架構師阿里架構
- 十幾位資深架構師,整理了最新架構師學習體系,分享給大家!架構
- CRM業務架構分析架構
- 在阿里架構師眼中構建一個較為通用的業務技術架構就是如此簡單阿里架構
- Java架構-到底什麼才是業務架構?Java架構
- 一文搞懂SaaS業務架構:價值流、業務能力、業務流程、業務物件、組織架構架構物件
- 軟體架構師應具備的十大特點架構
- 微博平臺架構和安全——微博平臺首席架構師楊衛華演講架構
- 業務中臺系統架構:大中臺+小前臺電子商務系統搭建框架思維架構框架
- 架構師修煉之道(二)——架構?設計?架構師?架構
- 基於大中臺架構的電商業務中臺最佳實踐之三:交易中臺技術要點設計之高效能架構
- 企業架構師、解決方案架構師和技術架構師的異同 - Briqi架構
- 【架構入門系列】從業務到平臺的思維轉變架構
- 架構師的工作架構
- 架構師眼中的高併發架構架構
- 業務架構、資訊架構、技術架構三位一體架構
- 架構師架構
- 阿里巴巴宣佈天貓組織架構調整:和聚划算業務合併阿里架構
- 軟體架構與架構師架構