文章來自健薦微信公衆號,做者王健,ThoughtWorks高級諮詢師。王健將於5月18-19日在上海A2M峯會分享關於中臺的話題,更多A2M峯會內容可點擊此處查看。前端
從去開始,好像就有一隻無形的手一直將我與「微服務」、「平臺化」、「中臺化」撮合在一塊兒,給我帶來了不少的困擾和思考與收穫。算法
平臺化正興起,從基礎設施到人工智能等各個領域不斷涌現的各種平臺,對於軟件開發人員及企業帶來了深遠的影響。然而,在中國提「數字化平臺戰略」你們可能會以爲比較抽象,比較遠大空;如果提「中臺」你們則會更熟悉一些。數據庫
那…中臺究竟是什麼?會不會又是另外一個Buzzword呢?這個從名字上看像是從前臺與後臺中間硬擠出來的新斷層,它與前臺和後臺的區別和界限到底在哪兒?什麼應該放到中臺,什麼又應該放到前臺或是後臺?它的出現究竟是爲了解決什麼問題呢?後端
這一個接一個的問題就不斷的涌出並縈繞在個人腦子裏。直到一年多後的今天,隨着參與的幾個平臺化、企業中臺相關的項目已順利步上正軌,終於能夠坐下來回顧這一年的實踐與思考,再次試圖回答這些問題,並梳理成文,與你們交流探討。安全
1、中臺迷思微信
處處都在喊中臺,處處都是中臺,中臺這個詞在我看來已經被濫用了。架構
在一部分人眼裏:中臺就是技術平臺,像微服務開發框架、DevOps平臺、PaaS平臺,容器雲之類的,人們都叫它「技術中臺」;
在一部份人眼裏:中臺就是微服務業務平臺,像最多見的什麼用戶中心、訂單中心,各類微服務集散地,人們都叫它「業務中臺」;
在一些人眼裏:中臺應該是組織的事情,在釋放潛能:平臺型組織的進化路線圖 (豆瓣)中就提出了平臺型組織和組織中臺的概念,這類組織中臺在企業中主要起到投資評估與投後管理的做用,相似於企業內部資源調度中心和內部創新孵化組織,人們叫它「組織中臺」。框架
看完本篇你就會理解,上邊的這幾類「中臺」劃分仍是靠譜的,更多我看到的狀況是,你們爲了響應企業的「中臺戰略」,乾脆直接將本身系統的「後端」或是「後臺」改個名,就叫「中臺」。分佈式
中臺究竟是什麼?它對於企業的意義究竟是什麼?當咱們談中臺時咱們到底在談些什麼?微服務
想要尋找到答案,僅僅沉寂在各自「中臺」之中,如同管中窺豹,身入迷陣,是很難想清楚的。不如換個⾓度,從各種的「中臺迷陣」中跳脫出來,嘗試以更高的視角,從企業均衡可持續發展的角度來思考中臺,反推它存在的價值。
爲了搞明白中臺存在的價值,咱們須要回答如下兩個問題:
企業爲何要平臺化?
企業爲何要建中臺?
一、企業爲什麼要平臺化?
先給答案,其實很簡單:
由於在當今互聯網時代,⽤戶纔是商業戰場的中心,爲了快速響應用戶的需求,藉助平臺化的力量能夠事半功倍。不斷快速響應、探索、挖掘、引領⽤戶的需求,纔是企業得以⽣存和持續發展的關鍵因素。
那些真正尊重用戶,甚⾄不惜調整⾃己顛覆⾃己來響應⽤戶的企業,將在這場以⽤戶爲中心的商業戰爭中得以⽣存和發展;反之,那些在過去的成就上故步⾃封,存在僥倖⼼理但願⽤戶會像以前同樣繼續追隨⾃己的企業,則會被用戶淘汰。
很殘酷,但這就是這個時代最基本的企業⽣存法則。
平臺化之因此重要,就是由於它賦予或增強了企業在以用戶爲中心的現代商業戰爭中最最最核心的能力:⽤戶響應力。這種能力能夠幫助企業在商戰上先發制⼈,始終搶得先機。
能夠說,在互聯網時代,商業的鬥爭就是對於用戶響應力的比拼。
又有點遠大空是否是?咱們來看⼏個經典的例子:
例子1
提及中臺,最早想到的應該就屬是阿⾥的「⼤中臺,⼩前臺」戰略。阿⾥⼈經過多年不懈的努力,在業務的不斷催化滋養下,將⾃己的技術和業務能力沉澱出一套綜合能力平臺,具有了對於前臺業務變化及創新的快速響應能力。
例子2
海爾也早在⼗年前就已經開始推動平臺化組織的轉型,提出了「平臺⾃營體⽀撐⼀線⾃營體」的戰略規劃和轉型⽬標。構建了「⼈單合一」、「⽤戶付薪」的創客文化,真正將平臺化提⾼到了組織的⾼度。
例子3
華爲在幾年前就提出了「⼤平臺炮火支撐精兵做戰」的企業戰略,「讓聽獲得炮聲的人能呼喚到炮火」,這句話形象的詮釋了大平臺⽀撐下小前臺的做戰策略。
這種極度靈活又威力巨⼤的戰法,使之能夠迅速響應瞬息萬變的戰場,一旦鎖定目標,經過大平臺的炮火羣,迅速精準對於戰場進行強大的火⼒支援。
可⻅,在互聯⽹熱火朝天,第四次工業革命的曙光即將到來的今日,企業可否真正作到「以用戶爲中心」,並不斷提高本身的用戶響應力來追隨甚至引領用戶的腳步,持續規模化創新,終將決定企業可否在這樣充滿挑戰和機遇的市場上笑到最後,在商業上長久保持創新活力與競爭力。
而平臺化剛好能夠助力企業更快更好的作到這些,因此這回答了第一個問題——企業須要平臺化。
二、企業爲何要建中臺?
好,到此咱們想明白了爲何須要平臺化。可是平臺化並非一個新概念,不少企業在這個方向上已經作了多年的努力和積澱。那爲何最近幾年「中臺」這個相對較新的概念又會異軍突起?對於企業來說,傳統的「前臺+後臺」的平臺化架構又爲何不能知足企業的要求呢?
這就引出了咱們的第二個問題:企業爲何要建中臺?
定義一下前臺與後臺
由於平臺這個詞過於寬泛了,爲了能讓你們理解我在說什麼,我先定義一下本文上下文我所說的前臺和後臺各指什麼:
前臺:由各種前臺系統組成的前端平臺。每一個前臺系統就是一個用戶觸點,即企業的最終用戶直接使用或交互的系統,是企業與最終用戶的交點。例如用戶直接使用的網站、手機App、微信公衆號等都屬於前臺範疇。
後臺:由後臺系統組成的後端平臺。每一個後臺系統通常管理了企業的一類核心資源(數據+計算),例如財務系統、產品系統、客戶管理系統、倉庫物流管理系統等,這類系統構成了企業的後臺。基礎設施和計算平臺做爲企業的核心計算資源,也屬於後臺的一部分。
後臺並不爲前臺而生
定義了前臺和後臺,對於第二個問題(企業爲何要建中臺),一樣先給出個人答案:
由於企業後臺每每並不能很好的支撐前臺快速創新響應用戶的需求,後臺更多解決的是企業管理效率問題,而中臺要解決的纔是前臺的創新問題。
大多數企業已有的後臺,要麼前臺根本就用不了,要麼很差用,要麼變動速度跟不上前臺的節奏。
咱們看到的不少企業的後臺系統,在建立之初的目標,並非主要服務於前臺系統創新,更多的是爲了實現後端資源的電子化管理,解決企業管理的效率問題。
這類系統要不就是當年花大價錢外購,須要每一年支付大量的服務費,而且版本老舊,定製化困難;要不就是花大價錢自建,年久失修,一身的補丁,一樣變動困難,也是企業所謂的「遺留系統」的重災區。
總結下來就兩個字「慢」和「貴」,對業務的響應慢,動不動改個小功能就還要花一大筆錢。
有人會說了,你不能拿遺留系統說事兒啊,咱們能夠新建後臺系統啊,整個2.0問題不就解決了?
但就算是新建的後臺系統,由於其管理的是企業的關鍵核心數據,考慮到企業安全、審計、合規、法律等限制,致使其一樣每每⽆法被前臺系統直接使用,或是受到各種限制⽆法快速變化,以⽀持前臺快速的創新需求。
此時的前臺和後臺就像是兩個不一樣轉速的⻮輪,前臺因爲要快速響應前端用戶的需求,講究的是快速創新迭代,因此要求轉速越快越好;⽽後臺因爲⾯對的是相對穩定的後端資源,⽽且往系統陳舊複雜,甚至還受到法律法規審計等相關合規約束,因此每每是穩定至上,越穩定越好,轉速也天然是越慢越好。
因此,隨着企業務的不斷髮展,這種「前臺+後臺」的⻮輪速率「匹配失衡」的問題就逐步顯現出來。
隨着企業業務的發展壯大,由於後臺修改的成本和⻛險較⾼,也就驅使咱們儘可能選擇保持後臺系統的穩定性。
但由於還要響應用戶持續不斷的需求,天然就會將大量的業務邏輯(業務能力)直接塞到了前臺系統中,引入重複的同時還會導致前臺系統不斷膨脹,變得臃腫,造成了一個個⼤泥球的「煙囪式單體應用」,漸漸拖垮了前臺系統的「⽤戶響應⼒」。
用戶滿意度下降,企業競爭力也隨之不斷降低。
對於這樣的問題,Gatner在2016年提出的一份《Pace-Layered Application Strategy》報告中,給出了一種解決方案,即按照「步速」將企業的應用系統劃分爲三個層次(正好契合前中後臺的三個層次),不一樣的層次採用徹底不一樣的策略。
而Pace-Layered Application Strategy也爲「中臺」產生的必然性,提供了理論上的支撐。
Pace-Layered Application Strategy
在這份報告中Gatner提出,企業構建的系統從Pace-Layered的⾓度來看能夠劃分爲三類: SOR(Systems of record ),SOD(Systems of differentiation)和SOI(Systems of innovation)。
處於不一樣Pace-Layered的系統由於⽬的不一樣、關注點不一樣、要求不一樣,變化的「速率」天然也不一樣,匹配的也須要採⽤不一樣的技術架構、管理流程、治理架構甚至投資策略。
⽽前面章節咱們提到的後臺系統,例如CRM、ERP、財務系統等,它們⼤多都處於SOR的Pace-Layered。
這些系統的建設之初每每是以規範處理企業底層資源和企業的核⼼可追溯單據(例如財務單據,訂單單據)爲主要⽬的。它們的變動週期每每比較⻓,⽽且因爲法律律審計等其餘限制,致使對於它們的變更須要嚴謹的申報審批流程和更高級別的測試部署要求,這就致使了它們每每變化頻率低、變化成本高、變化⻛險高、變化週期⻓,⽆法滿⾜由⽤戶驅動的快速變化的前臺系統要求。
咱們又要盡力保持後臺(SOR)系統的穩定可靠,⼜要前臺系統(SOI)可以⼩而美,快速迭代。就出現了上文提到的「齒輪匹配失衡」的問題,感受魚與熊掌不可兼得。
正當陷入僵局的時候,天空中飄來一聲IT諺語:
軟件開發中遇到的全部問題,均可以經過增長⼀層抽象而得以解決!
⾄此,⼀聲驚雷滾過,「中臺」腳踏七彩祥雲,承載着SOD(Systems of differentiation) 的前世寄託,橫空出世。
咱們先試着給中臺下個定義:
中臺是真正爲前臺而生的平臺(能夠是技術平臺,業務能力甚至是組織機構),它存在的惟一目的就是更好的服務前臺規模化創新,進而更好的響應服務引領用戶,使企業真正作到自身能力與用戶需求的持續對接。
中臺就像是在前臺與後臺之間添加的⼀組「變速齒輪」,將前臺與後臺的速率進行匹配,是前臺與後臺的橋樑。它爲前臺而生,易於前臺使用,將後臺資源順滑流向用戶,響應用戶。
中臺很像Pace-Layered中的SOD,提供了比前臺(SOI)更強的穩定性,以及⽐後臺(SOR)更高的靈活性,在穩定與靈活之間尋找到了⼀種美妙的平衡。
中臺做爲變速齒輪,連接了用戶與企業核心資源,並解決了配速問題:
有了「中臺」這⼀新的Pace-Layered斷層,咱們就能夠將早已臃腫不堪的前臺系統中的穩定通用業務能力「沉降」到中臺層,爲前臺減肥,恢復前臺的響應力;
又能夠將後臺系統中須要頻繁變化或是須要被前臺直接使用的業務能力「提取」到中臺層,賦予這些業務能力更強的靈活度和更低的變動成本,從而爲前臺提供更強大的「能力炮火」支援。
因此,企業在平臺化的過程當中,須要建設本身的中臺層(同時包括技術中臺、業務中臺和組織中臺)。
三、小結
思考並回答了文初提出的兩個關於中臺價值的核心問題,解決了我對於中臺產生的一些困惑,不知道對你有沒有啓發?我最後再來總結一下:
以用戶爲中心的持續規模化創新,是中臺建設的核心目標。企業的業務響應能⼒和規模化創新能力,是互聯⽹時代企業綜合競爭⼒的核⼼體現。平臺化包括中臺化,只是幫助企業達到這個目標的⼿段,並非⽬標自己。
中臺(不管是技術中臺、業務中臺仍是組織中臺)的建設,根本上是爲了解決企業響應力困境, 彌補創新驅動快速變化的前臺,穩定可靠驅動變化週期相對較慢的後臺之間的⽭盾,提供⼀箇中間層來適配前臺與後臺的配速問題,沉澱能⼒,打通並順滑連接前臺需求與後臺資源,幫助企業不斷提高用戶響應⼒。
因此,中臺究竟是什麼根本不重要,如何千方百計持續提升企業對於⽤戶的響應力纔是最重要的。而平臺化或是中臺化,只是恰巧走在了了這條正確的大道上。
2、到底中臺長啥樣?
列舉了這麼多各式各樣的中臺,最後都扯到了組織層面,是否是有種越聽越暈的感受?好像什麼東西加個「中臺」的後綴均可以靠到中臺上來?那估計很快就會看到例如AI中臺、VR中臺、搜索中臺、算法中臺……對了,算法中臺已經有了……
讓咱們引用一段阿里玄難在接受採訪時提到對於中臺的一段我很是認同的描述:
本文中咱們一直提到的一個詞就是「能力」,從玄難的這段採訪也能夠看出,在阿里「能力」也是中臺的核心。
甄別是否是中臺,還要回到中臺要解決的問題上,也就是我上面主要關注的問題。我認爲一切以」以用戶爲中心的持續規模化創新」爲目的,將後臺各式各樣的資源轉化爲前臺易於使用的能力,幫助咱們打贏這場以用戶爲中心的戰爭的平臺,咱們均可以稱之爲中颱:
業務中臺提供重用服務,例如用戶中心、訂單中心之類的開箱即用可重用能力,爲戰場提供了強大的後臺炮火支援能力,隨叫隨到,威力強大;
數據中臺提供了數據分析能力,幫助咱們從數據中學習改進、調整方向,爲戰場提供了強大及時的雷達監測能力,幫助咱們掌控戰場;
移動及算法中臺提供了戰場一線火力支援能力,幫助咱們提供更加個性化的服務,加強用戶體驗,爲戰場提供了陸軍支援能力,隨機應變,所向披靡;
技術中臺提供了自建系統部分的技術支撐能力,幫助咱們解決了基礎設施,分佈式數據庫等底層技術問題,爲前臺特種兵提供了精良的武器裝備;
研發中臺提供了自建系統部分的管理和技術實踐支撐能力,幫助咱們快速搭建項目、管理進度、測試、持續集成、持續交付,是前臺特種兵的訓練基地及快速送達戰場的機動運輸部隊;
組織中臺爲咱們的項目提供投資管理、風險管理、資源調度等,是戰場的指揮部,戰爭的大腦,指揮前線,調度後方。
因此,評判一個平臺是否稱得上中臺,最終評判標準不是技術,也不是長什麼模樣,仍是得前臺說了算,畢竟前臺纔是戰爭的關鍵,是感覺獲得戰場的殘酷、看得見用戶的那部分人。
前臺想不想用,愛不愛用,好很差用;幫了前臺多大的忙,從中臺得到了多大的好處,願意掏出多少利潤來幫助建設中臺,這些纔是甄別中臺建設對錯好壞的標準。對於中臺來說,前臺就是用戶,以用戶爲中心,在中臺一樣適用。
3、中臺就是「企業級能力複用平臺」
若是讓我給出一個定義,目前我認爲最貼切的應該是: 中臺就是「企業級能力複用平臺」。很簡單,有點失望是否是?可是爲了找到一個靠譜的定義,我幾乎花了快兩年的時間,期間有各類各樣的定義曾浮現出來,但至少到目前爲止,只有這個定義我以爲最貼切、最簡單、也最準確,它能解釋幾乎全部我碰到的關於中臺的問題,例如:
爲何會有那麼多中臺,像上文提到業務中臺,數據中臺,搜索中臺,移動中臺,哪些纔是中臺,哪些是蹭熱點的?
中臺與前臺的劃分原則是什麼?
中臺化與平臺化的區別是什麼?
中臺化和服務化的區別是什麼?
中臺該怎麼建設?
等等…
這9個字看起來簡單,重要的是其背後對「中臺」價值的闡釋,下面就讓我爲你們一一拆解來看。
企業級
當作中臺建設的時候,必定是跳出單條業務線站在企業總體視角來審視業務全景,尋找可複用的能力進行沉澱,從而但願經過能力的複用一方面消除數據孤島業務孤島,一方面支撐企業級規模化創新,助力企業變革,滋生生態。
因此雖然中臺的建設過程雖然能夠自下而上,以點及面。但驅動力必定是自上而下的,全局視角的,而且須要必定的頂層設計。這也解釋了爲何在企業中推進中臺建設的每每都是跨業務部門,例如CIO級別領導或是企業的戰略規劃部門,由於只有這些橫跨多條業務線的角色和組織,纔會去常常反思與推進企業級的能力複用問題。
這一點也引出了中臺建設的一個關鍵難點,就是組織架構的調整和演進以及利益的從新分配,這是技術所不能解決的,也是中臺建設的最強阻力。同時企業級也是區分企業中臺化與應用系統服務化的關鍵點,簡而言之中臺化是企業級、是全局視角,服務化更可能是系統級、是局部視角。
因此從中臺的興起與爆發能夠看到一種趨勢,就是愈來愈多的企業不管是因爲企業運營效率的緣由仍是因爲創新發展的須要,對於企業全局視角跨業務線的能力沉澱都提升到了史無前例的戰略高度。
能力
提到中臺,最常聽到的一個詞就是「能力」。多是由於能力這個詞足夠簡單,又有着足夠的包容度與寬度。
企業的能力可能包含多個維度,常見的例如計算能力,技術能力,業務能力,數據能力,AI能力,運營能力,研發能力…其中大部分的能力還能夠繼續細化和二次展開,從而造成一張多維度的企業能力網。能夠說,中臺就是企業全部能夠被「多前臺產品團隊」複用能力的載體。
複用
雖然咱們一直講「去重複用」講了不少年,但仔細想一想,大多平臺化建設會將重點放在「去重」(消除重複)上,而對於「複用」則沒有足夠的關注。
不少企業都號稱已經建成了各類各樣成熟的平臺,可是咱們問心自問一下,有多少平臺是業務驅動的?有多少前臺產品團隊又是自願將本身的產品接入到平臺上的?有多少平臺建設者是在真正關注前臺產品團隊的平臺用戶體驗?
「去重」講的更可能是向後看,是技術驅動的;「複用」講的更可能是向前看,是業務驅動和用戶驅動的。
因此「去重」與「複用」雖然常常一塊兒出現,一塊兒被說起,可是談論的徹底不是一件事情,目的不一樣,難度也不一樣,作到「去重」已然很是困難,關注「複用」的就更是寥寥無幾,因此:
「複用」是中臺更加關注的目標;
「可複用性」和「易複用性」是衡量中臺建設好壞的重要指標;
「業務響應力」和「業務滿意度」也纔是考覈中臺建設進度的重要標準。
而實現更好的複用,經常改進的方向有兩個方面:
一方面將更高抽象(例如業務模式級別)的通用業務邏輯經過抽象後下沉到中臺,這樣前臺就會更輕,學習成本和開發維護成本更低,越能更快的適應業務變化;缺點是,抽象級別越高,越難被複用,須要架構師對於各業務有深刻的理解和很是強的抽象能力。
另外一方面就是經過對於中臺能力的SaaS化包裝,減小前臺團隊發現中臺能力和使用中臺能力的阻力,甚至經過自助式(Self-Service)的方式就快速定位和使用中臺能力。目前不少企業在嘗試的內部API集市或是數據商店就是在這方面的努力和嘗試。
平臺
這裏的平臺主要是區別於大單體的應用或是系統。傳統的企業數字化規劃更多的是圍繞業務架構,應用架構和數據架構展開。產出也是一個個基於應用和系統的數字化建設規劃,例如要採購或是自建哪些具體的系統,例如ERP、CRM等。
固然這個過程並無什麼問題,能夠理解此時這些獨立的系統就承載了企業的各類能力,因爲企業各業務線統一使用一個應用或系統,也天然實現了能力的複用。
但問題經常出如今兩個方面:
一個是大單體系統的業務響應力有限,缺乏「柔性」,當業務發展到必定階段後,必然產生大量定製化需求,隨着內部定製化模塊的比例逐漸上升,響應力成指數降低,成爲業務的瓶頸點。
另外一個則是系統間的打統統常比較困難,容易造成業務孤島和數據孤島。
因此愈來愈多的企業開始像互聯網學習,以平臺化的方式重塑企業IT架構,從而對於業務提供足夠的「柔性」,來知足對於業務的快速響應和複用的需求。
小結
「企業級能力複用平臺」這個定義雖然看起來簡單,但通過這麼長時間對於中臺的實踐與思考,我以爲如上文所述的這個定義背後所表明的意義是目前對中臺價值的最貼切的闡釋:
有了定義後,如何建中臺的思路也就豁然開朗:若是說中臺是「企業級能力複用平臺」的話,那中臺化就是「利用平臺化手段發現、沉澱與複用企業級能力的過程」。