作者 | 耿立超

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

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

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

?

中臺的組織架構

?

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

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

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

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

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

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

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

• 中臺事業部
  

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

• 中臺各業務中心
  

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

• 中臺與前臺團隊的關系
  

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

• 如果前臺團隊強勢，就會組織力量在自己可控的范圍內實現自己的需求，導致一些本該出現在中臺上的共享服務被放在了某個前端應用上，這在客觀上弱化了中臺的“威力”，同時會導致其他前臺應用重復建設該功能，這是在“開倒車”；

• 如果前臺團隊弱勢，就會放棄或推遲新的構想和嘗試，這會讓企業逐漸失去抓住市場機遇的能力。

?

中臺不是“銀彈”

?

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

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

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

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

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

本文摘自《大數據平臺架構與原型實現：數據中臺建設實戰》，已在京東上架

個人技術博客：

https://laurence.blog.csdn.net/

推薦閱讀

• 學會這10大高性能開發技術，輕松躲過裁員名單！

• 為什么說下一個十年的主戰場在Serverless？

• 什么？一個核同時執行兩個線程？

• 假如有一門叫做 Ctrump 的編程語言...

• Get了！用Python制作數據預測集成工具 | 附代碼
  

總結

以上是生活随笔為你收集整理的大咖说中台 | 建设数据中台系列（五）——中台架构详解（下）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。