大咖說中台 | 中台不是「銀彈」

csdn 發佈 2020-08-23T01:01:21+00:00

筆者曾經參與過不少定位為統一平台的項目,其中有不少失敗的案例,對於這個問題有一點個人的思考:也許中心化系統都是反傳統管理體制的,煙囪式的生態系統是企業組織架構在IT 上的投影,小到「數據湖」,大到中台,沒有強力對等的中心化組織去主導,結果是很難預料的。

作者 | 耿立超

來源 | 《大數據平台架構與原型實現:數據中台建設實戰》

本質上,中台是一種中心化、平台化的企業組織架構和業務形態,當這樣的組織和業務架構投射到IT 系統上時會自然地形成我們今天討論的IT 意義上的「中台」。筆者曾經參與過不少定位為統一平台的項目,其中有不少失敗的案例,對於這個問題有一點個人的思考:也許中心化系統都是反傳統管理體制的,煙囪式的生態系統是企業組織架構在IT 上的投影,小到「數據湖」,大到中台,沒有強力對等的中心化組織去主導,結果是很難預料的。

繼本系列前一篇文章對中台架構作了整體性的介紹之後,本文我們將繼續從組織架構的角度上展開對中台的介紹,這是中台建設中不得不談論的話題,雖然在任何企業里這都是一個非常敏感的話題,但對中台建設來說,這一問題必須要思考清楚。另外,本文的後半部分,我們會冷靜地分析一下中台所「不能」的地方,避免讀者對中台產生錯誤的不切實際的理解與期望。本文核心觀點援引自作者所著的《大數據平台架構與原型實現:數據中台建設實戰》一書,全書對數據中台的理念、架構和具體實現做了詳細論述。

中台的組織架構

組織架構無疑是一個重大而敏感的問題,但確實是在建設中台過程中不得不面對的,一家企業如果想要在中台化轉型上取得成功,就必須直面這個問題。我們前面探討煙囪式的生態系統和SOA 架構時提到的諸多問題和挑戰都與組織分工、團隊協作有關,這些問題的根源都是組織架構。在過去的煙囪式生態系統下,每一個應用系統都由一個專職的團隊負責,團隊的核心任務與首要KPI 是確保本系統持續穩定地運行,這使得每一個團隊都必然地從本應用系統的立場和角度看待和思考問題。

然而企業的業務流程是一個有機的整體,這在客觀上必然要求各個應用系統和運維團隊緊密協作,這時候組織架構的問題就會顯現出來。過去不管是點對點式的集成還是SOA 改造,當它們作為一個項目交付之後,隨著時間的推移,在集成新系統時又會變得像以前一樣舉步維艱,究其原因是並沒有一個長期有效的組織架構在持續地推動系統融合。

中台架構的提出對企業的組織架構產生了巨大的影響,有了與中台相適應的組織架構,企業才能很好地完成中台建設並從中受益。中台架構有一很鮮明的特點,那就是它徹底破除了應用系統的邊界,從企業的全業務領域著手,切分出業務中心,每一個業務中心所支撐的不是一個孤立的應用系統,而是企業在該領域的全部核心業務,所以每一個業務中心都需要非常專業的團隊來負責,團隊必須對這部分業務非常了解,而且必須站在企業的全局去支撐和把控這一業務領域。

我們來看一下阿里巴巴共享業務事業部的故事。2003 年阿里巴巴首先成立了淘寶事業部,伴隨著B2C 業務的興起,2008 年從淘寶團隊中拆分出了天貓事業部,但是這兩大事業部依靠的都是淘寶的技術團隊,這樣帶來的問題是技術團隊會優先響應來自淘寶的業務需求,影響了天貓事業部的發展。另外一個問題也是很典型的,那就是這兩個電商平台是完全獨立的,都有各自的商品、交易、支付等功能模塊,可見阿里巴巴也曾經走過煙囪架構的老路。

為了解決這個問題,阿里巴巴開始了第一次大膽的嘗試,在2009 年成立了「共享業務事業部」,主要由淘寶的技術團隊構成,但是這個事業部與淘寶和天貓兩個事業部是平級的,這一架構調整的用意很明確,阿里巴巴希望通過共享業務事業部來梳理和沉澱兩個電商平台的業務,抽離出公共的部分,避免重複建設。但事情的發展卻出乎阿里巴巴的預料,由於淘寶和天貓作為核心業務部門,顯然擁有更大的主導權,共享業務事業部發展緩慢。

這一狀況的轉變源自聚划算的出現,聚划算作為阿里巴巴的團購業務事業部,在成立之初擁有強大的引流能力,淘寶和天貓的產品一旦進入聚划算,銷售額就會暴增,因此兩大事業部都迫切地想要將自己的平台和聚划算對接。此時阿里巴巴做出了一個重要決定,其他業務平台如果要和聚划算平台對接,必須通過共享業務事業部,正是這一舉措讓共享業務事業部找到了發展的抓手,進而將自己提升到與其他業務事業部同等的公平位置上。

從阿里巴巴共享業務事業部的故事中我們可以看到,組織架構對於中台戰略的有效實施至關重要,在整個組織架構中,企業需要仔細梳理和界定關鍵部門的職責及相關部門之間的關係。

  • 中台事業部

由於中台的定位在於支持企業的共享業務,所以必須要由一個專職的實體部門對其負責,而不能是一個虛擬組織,這個部門必須要被賦予足夠大的權限,過去分散於多個業務部門和系統運維團隊的部分職責需要拆分並重組到中台部門,由中台統一管理和負責。

  • 中台各業務中心

中台各業務中心的人員一般來自該中心對應的過去某個核心業務系統,如用戶中心團隊的骨幹應該來自原CRM 系統,被劃歸到中台的個人和團隊將面臨一次內部轉型,他們過去只對單一業務系統負責,而現在需要站在企業的全局來看待和梳理相關業務,這需要中台團隊在廣度上要能觸達各個業務渠道的前端需求,同時要在深度上不斷地挖掘和提煉共享業務,並最終落地到中台服務上。中台各個業務中心的職責劃分必須清晰明確,特別是在一些關聯性較強的業務領域上一定要做好切割,將各方的職責界定清楚。

  • 中台與前台團隊的關係

前台團隊直接面向市場和終端用戶,從這個角度來看前台團隊扮演著中台用戶的角色。一方面,前台團隊經常會提出各種各樣的需求,有些需求可以在團隊內部消化,有些則需要中台團隊的支持,這時候前台團隊就會對中台團隊產生依賴;另一方面,對於中台團隊來說,也非常需要來自前台的業務「滋養」。因此兩個團隊應該維持緊密的合作關係,這對於能否成功建立中台架構是非常關鍵的,如果兩個團隊之間在合作上出現問題就會導致兩種可能的後果:

  • 如果前台團隊強勢,就會組織力量在自己可控的範圍內實現自己的需求,導致一些本該出現在中台上的共享服務被放在了某個前端應用上,這在客觀上弱化了中台的「威力」,同時會導致其他前台應用重複建設該功能,這是在「開倒車」;
  • 如果前台團隊弱勢,就會放棄或推遲新的構想和嘗試,這會讓企業逐漸失去抓住市場機遇的能力。

中台不是「銀彈」

前面花了大量的篇幅討論了中台的各種優勢,但是我們也必須理性客觀地看待它,就像討論以往出現過的任何新技術和新理論一樣,我們可以看重或推崇它們的優勢,但不能過分篤定或誇大它們的作用。中台是一種非常理想化的架構,當企業進化到這樣先進的架構時自然可以藉助中台創造巨大的業務價值。也可以反過來說,因為企業自身的組織和業務足夠先進而催生了中台架構(從某種意義上來說這才是中台的真正由來),兩者是相輔相成的。建設中台的難度是非常大的,其難度並不技術上,更多是在業務和組織架構上。

最近兩年,中台的火爆讓很多企業都跟風嘗試,但真正成功的案例還不多,業界對中台的討論也很激烈,有人認為中台可能僅僅是一種「烏托邦」,因為它過於理想化,在現實中缺乏生存的土壤,很多企業的現有組織形態與中台是不符甚至是對立的,這樣的企業盲目上馬中台項目必然是要失敗的。這裡我們不妨思考一下:為什麼煙囪架構在企業中普遍存在?儘管我們在前面討論了它的各種問題,但是至少有一點是煙囪架構的優勢,那就是它的目標指向性極強,它是專門用於解決某一業務問題的,相應地,它背後的技術和業務團隊的職責也是高度清晰的,這種目標指向性會驅使組織高效地運轉,即使在不同的團隊和環節上存在重複建設,在某些時候,付出這種代價也是值得的。

在這種視角下反觀中台,我們會看到,業務中心在對業務的廣度和深度上都有一個介入度的問題。從廣度上看,不同業務部門、不同業務方向上的業務需求都可能全部或部分落地到中台上,而中台部門需要根據自身的情況來指定開發的優先級,這就決定了在中台建設過程中,並不是所有的業務請求都能得到及時的響應,業務端的體驗會與之前煙囪架構有一定的落差;從深度上看,在垂直方向上的業務問題一部分是由前台應用處理掉的,另一部分是由中台解決的,這一點我們在前面講如何進行前台和中台切分時也提到過,這會導致過去的單一業務問題由單一系統負責變成前台和中台兩個參與方或團隊負責,如果我們用目標指向性來度量這一狀況,顯然中台不如煙囪架構有優勢,簡單地說就是容易出現前台和中台之間的「扯皮」現象。

本文的討論主要是提醒讀者客觀理性地看待中台架構,畢竟它還是相對新的一種思想,業界需要更多的時間去實踐和檢驗,對於這個行業的從業者而言,我們應該保持一種積極的、謹慎樂觀的態度看待它。不過相較於業務中台,本系列著重討論的數據中台並沒有這麼多不確定的挑戰,不管是理論還是實現技術都是比較明朗和確定的。

關於作者:耿立超,架構師,14年IT系統開發和架構經驗,對大數據、企業級應用架構、SaaS、分布式存儲和領域驅動設計有豐富的實踐經驗,熱衷函數式編程。目前負責企業數據中台的架構設計和開發工作,對Hadoop/Spark 生態系統有深入和廣泛的了解,參與過Hadoop商業發行版的開發,曾帶領團隊建設過數個完備的企業數據平台。

關鍵字: