編輯導語:早在2015年阿里就提出“大中台,小前台”的概念,今年在國內開始火熱起來,不少企業都開始建設自己的中台;那中台到底是什麼?什麼時候適合建設自己企業的中台?中台有什麼優缺點?本文作者對中台進行了詳細解讀。
2020年之際,除了新冠疫情之外,在信息化工作者的圈內,圍繞着中台之熱、中台之痛;網上出現了各類的文章,一路看來,都觸動着我們IT人員的神經。
對於中台這一概念,一千個人可能有一千個看法,下面是我個人的一些淺表的看法。
一、何謂中台首先對於中台,我是這樣進行解讀的。
何謂中台:信息化的的發展過程中,常常出現“台”的概念,IT人員最常接觸的就是:平台、前台、後台。
- 平台(整體解決產品):是為了快速響應與解決用户的需求而建立的,是一個寬泛的概念(我們使用的各類管理系統,是我們常説的前台、後台等共同組成平台,如大型企業ERP、銷售+客服系統、移動平台等)。
- 後台(管理工具):指的管理資源的系統,如內容管理系統、客户管理系統、物流管理系統等(往往管理的是企業內部的核心資源,例如內訓題庫、視頻、用户信息、主數據,權限管理,也是數據資產的底層)。
- 前台(用户可達):是指的企業與用户直接接觸的系統,如網站、app、微信小程序等用户直接使用的軟件。(不要與開發中的前端後端混淆,往往前台系統又會存在前端頁面與後端接口,用户界面和接口這相當於是前台系統的子模塊)。
對於前台、後台、平台,中台又是什麼呢?
- 由於前台系統直接面向用户,所以為了快速響應用户需求,前台系統會不斷建設(變動、重構);
- 由於後台系統管理的是企業內部的核心資源,改動成本非常龐大,無法及時響應前台系統的快速變化。
往往在系統設計中,將後台系統的資源管理與前端系統的業務規則掛鈎,最終導致不同的前台系統出現了各自的後端系統,這些系統基本相似但又不完全相同,這種系統我們稱為:煙囱式架構(系統)。
這些系統會使得我們開發人員不斷的重複造輪子,所以我們需要一個介於前台系統與後台系統之間的系統,來解決我們所面臨的問題。
中台就是企業級能力複用平台,企業級指的是中台的範圍,可以理解為中颱是服務於多前台的產品團隊的,為多個產品提供共性支撐。
所以在建設中台的時候要從全局出發,企業所包含的能力:技術能力、業務能力、數據能力等,中台就是為了複用企業的各種能力,並且被前面所説的多前台的產品團隊所使用。
簡而言之,中台就是企業所有可以被“多前台產品團隊”複用能力的載體,不斷抽象前台業務下沉到中台,用SaaS的方式打造一個自助式的中台。
中台不是一種技術,而是一種管理思維,是一種戰略調度思維的轉變,用得是否好是取決於業務架構的理解深度。
能夠從治理的角度,對業務的微服務進行清晰的邊界劃分,使得共享共用能力可以組合落地,避免工作節點上的各類重疊與技術重複做輪子的集成平台。
從技術角度來説是一種重後台、活前台、快實現、標準化的能力。
現階段,對於中台的理念,來看各類數字化複用能力均提出自身中台建設的方向,對此,擬對中台進行簡單的分類,分別從技術方向、業務方向、數據方向進行探討。
1. 技術方向技術中台:技術中台就是使用雲或其他基礎設施的能力將各種技術中間件的能力進行整合和包裝。
技術中台提供了易於使用的接口,使得參與前台建設與業務中台建設的開發人員無需關心中間件的細節。
阿里雲的一系列套件:ecs、oss、rds等等都可以理解為技術中台。
提供了自建系統部分的技術支撐能力,幫助我們解決了基礎設施,分佈式數據庫等底層技術問題。
- 研發中台:提供了自建系統部分的管理和技術實踐支撐能力,幫助我們快速搭建項目、管理進度、測試、持續集成、持續交付。
- IOT中台:聯接物聯網管理的應用,為數據收集、業務調度等提供更有效的支持業務方向。
- 業務中台:業務中台將後台資源進行抽象包裝整合,轉化為前台友好的可重用共享的核心能力,實現了後端業務資源到前台易用能力的轉化;業務中台使得前台可以隨意的組合、複用。
- 組織中台:為我們的項目提供投資管理,風險管理,資源調度等。
- 流程中台:通過對業務的理解和組織壁壘的打破,打造以流程引擎為核心的中台。
- 數據中台:集成數據治理及數據分析能力,形成企業化的數據資產,幫助我們從數據中學習改進,調整方向。
- 算法中台:利用業務趨勢及企業自身形成的規律,結合數據分析與流程優化等思路,為企業後台提供算法能力,幫助我們提供更加個性化的服務,增強用户體驗。
業務的管理思路也發生了變化,從原有的粗放式管理向精細化管理轉變,從產品生產的需求驅動轉向場景化驅動。
如:營銷團隊關注線上線下的聯動、社羣領導的引流變化,對於渠道的關注點向關係網、互動、直播等轉變,信息化工作者更需要適應變化的能力。
將後台各式各樣的資源轉化為前台易於使用的能力,真正實現複用的平台,我們都可以稱之為中颱。
中台總是為前台業務服務,如果沒有前台的需求,也就不存在中台前台即為中颱的用户。
中台集成了運營、產品、客服、數據能力,可以迅速地形成對前台有力的支撐,幫助企業更好的應對市場的變化。
(前提是:前台業務清晰,目標明確,可切分為各種業務服務集,可通過不斷的組合形成新的業務張力。)
數據中台——技術中台(IOT中台)——打破組織壁壘——業務中台
中台建設需要對應的時機:企業的規模和業務形態足以支撐中台落地、企業業務需要數字化價值的體現、企業戰略方向上認可中台需要持續投入的認知、企業組織壁壘已做好變革的準備。
三、中台的優缺點1. 建設中台的優點(通過業務微服務的切割與技術敏態支持的能力,創造出場景化的輸出,避免重複做輪子。)
- 實現資源整合,集中研發力量,打破數據治理的困局,可通過中台的微服務化組合,更靈活的適應於業務組織的變化(變革)及對業務執行進行快速響應。
- 通過數據中台來展示業務價值,利用技術中台來快速實現業務管理落地,藉助組織中台來靈活調度資源,結合業務中台來推進企業戰略目標的達成。
例如,需要應對市場的新需求開發新產品擁有中台可以:
- 調用現有業務中微服務模塊直接支撐新業務發展中一部分功能(包括但不限於:調用現有的技術框架、引擎、組件,利用數據中台或客户畫像等數據支持實現從產品線上千人千面引流、調用現有算法實現某些分析能力……)。
- 取得效果:開發迅速、能搶佔市場先機,開發成本低,有一定試錯空間。
(敏態支撐不代表創新敏態,只是靈活敏態,適合打組合拳,而不適合創造拳法,需要對組織生態進行解剖重建,也不容易體現投入產出的價值。)
- 動了別人的利益:專業分工下的破局,打破原有管理的壁壘,會有技術指揮業務發展的壓力。
- 成本高、週期長:中台建設要整合多個已分化的項目組,重構成本、溝通成本很高;為應對多種業務場景,所以建設時很重視兼容性,這使得中台項目邏輯複雜、成本很高、建設緩慢。
- 業務變革下新增中台模型會加倍困難:現有模塊不能實現時,需要開發新的中台模塊;但中台模塊的開發重視複用性、兼容性,使得開發相對傳統後台開發要緩慢。
在中台開發團隊排期緊張時,複用性差的模塊可能被放緩。
解決思路:特殊需求,在原對市場發展的情況下,保持原有張力,先實現前台到後台的開發支持,在有餘力的時間點進行中台化整合。
信息化建設本身就是需要“領導支持,迭代變化,不斷修正”,向陽而生。
感謝一直在路上的信息化人員,也感謝這個社會給到我們不斷進步和學習的機會。
本文由 @麥冠球 原創發佈於人人都是產品經理,未經許可,禁止轉載
題圖來自Unsplash,基於 CC0 協議