Yuraku
阿里自2015年起執行“數據中臺戰略”走在前面，除此之外，騰訊、華為、用友、京東等都結合自身優勢開啟數據中臺的探索，並提供對外服務。
9月30日，騰訊發佈的戰略與架構升級中，提到了成立技術委員會和“技術中臺”的概念。
- 再說華為，華為提出了構建數字化轉型的“共同平臺”，打造支撐業務增長的“黑土地”。
- 用友網絡今年同樣提出了【中臺戰略】，副總裁兼CTO程操紅先生首先發布了用友雲平臺重磅產品——技術中臺、業務中臺、數據中臺。
- 看看京東的玩法：2017年末，京東商城技術團隊拆分為前臺與中臺，前臺研發職能對接商城各事業部，中臺研發則聚焦於解決共性需求
（原創）文 | 劉成軍，工業互聯網研習社發起人，造奇智能新媒體創始人兼主編
造奇智能新媒體發現，【中臺】思想充分體現了阿里關於“業務數據化，數據業務化”的思考與實踐。這是今年演講的一張圖片，非常清晰簡單明瞭，高度抽象化表達，容易理解。這是當前的一種狀態，正如石紅生總所講，此框架不是一下子就演變成這個樣子的，也許後面還會變得更簡單。
如果我們按照歷史事件和業務邏輯來梳理的話，可以有幾句話值得講一下：
- 1、外部：響應速度慢，服務能力跟不上客戶的節奏；
- 2、內部：組織和部門的組織壁壘，垂直IT系統櫃形成的數據壁壘；
多種IT系統之間的層層壁壘使得公司內外部的各種信息無法有效流通，眾多高價值數據也只能在自身系統的小圈子裡轉，無法在更大的格局與鏈條上發揮價值。同時，內部創新力不足。
這無論對於有著數十年閹割的傳統制造企業來說，還是對於新興的互聯網公司來講，都面臨著冗餘、包袱，而缺乏效率和及時響應，這意味著用戶體驗極差，在互聯網公司和商界競爭力，這是不被允許的。
阿里敏銳的發現了自己的困境，並尋求解決方案。這裡有一個故事，在《中臺》那本書裡有詳細的介紹。
從2009年開始建設的“共享事業部”為阿里巴巴的架構轉型奠定了基礎。這是一個轉折點。但由於組織架構、事業部之間的博弈，剛開始的“共享事業部”並沒有按照預期發展。這時，阿里集團要求三大電商平臺如果要與聚划算平臺進行業務對接，必須通過共享事業部！正是有了這“點睛之筆”，共享事業部便有了一個極強的抓手，將原本與三大電商平臺對話權不平等的情況拉平，這使得“共享事業部”成為了阿里巴巴集團的核心業務平臺。
這個架構的形成和剛才發的2018年的架構在整體部署上沒有明顯差異。
這個轉折之後的共享事業部和新架構從09年開始磨合運行，直到2015年底，當大多數企業忙著進行年度總結和規劃時，阿里巴巴集團宣佈全面啟動“中臺戰略”，構建符合DT時代的“大中臺、小前臺”組織機制和業務機制。
阿里巴巴中間件首席架構師、《阿里巴巴中臺戰略思想與架構實踐》作者鍾華表示，在用阿里技術推動企業數字化轉型、建立數字中臺的過程中，第一大挑戰是業務、其次才是技術。所謂業務挑戰，就是從業務視角，把共性的業務模塊沉澱到共享業務中臺，把個性化的業務剝離出去後形成前臺，形成“大中臺，小前臺”新格局。（這是業務部門（人員）與IT部門（人員）深度融合的典型）總結阿里發展數字中臺的核心經驗：
原有的共享IT部門必須要找到極強的互聯網業務作為抓手，把自己變成核心業務部門，才能夠真正轉型成為企業的共享業務事業部，而不是某種變形的、換湯不換藥的共享IT部門，這也就是阿里共享業務事業部經常講的“業務滋養”的概念。
在共享業務抽象與沉澱的過程中，還需要一個開放的技術平臺來承載不斷沉澱下來的共享業務單元，這就是阿里雲中間件Aliware平臺（“厚平臺、薄應用”）
阿里發展數字中臺還有一個關鍵經驗，這就是共享中心的技術團隊組織構成，不再是之前與業務相匹配的流水線模式：之前是UED用戶體驗設計師對於前端交互界面、架構師和開發人員對應業務邏輯、運維工程師和DBA對應數據庫等；
深度思考、認知升維、跨界連接，歡迎加入#工業互聯網研習社#社群
（欲加入研習社，歡迎私信諮詢）
—筆者在知識付費領域的探索，2018年1月1日，造奇智能產業新媒體獨家推出、業界首份聚焦工業互聯網領域的高質量實名付費社群——[工業互聯網研習社]，依託[知識星球]而建。致力於打通工業互聯網從資訊→信息→知識→認知→見識→服務的鏈式通路，助力您的職業發展和機遇把握。這是在工業媒體與知識分享領域的知識付費嘗試！
—近300位付費研習社社友遍佈上海、北京、深圳蘇州、杭州、武漢、蕪湖等工業重鎮，初步構建起覆蓋工業互聯網平臺、工業軟件、底層數據採集、工業數據分析、系統集成商、大學及產業資金在內的全國價值網絡。
工業互聯網研習社
有幸讀過《企業IT架構轉型知道：阿里巴巴中臺戰略思量與架構實戰》，從書中也吸取了阿里數據中臺建設的一些思想。（這本書很不錯，建議大家閱讀以下）
阿里最早的時候，是隻有淘寶的，後來有的天貓，我們就那這兩個舉例，如果沒有數據中臺的話，淘寶是一個系統，天貓是一個系統。這就是"煙囪式"的架構, 也就是每個業務線雖然類似但都各自搞一套。
這樣"煙囪式"的架構，會有什麼弊端呢？
重複建設和維護帶來的重複投資：這個好理解；如果除了淘寶、天貓之外，想再建一個類似的系統，裡面包括會員、商品、商家、物流、支付等等功能，一定很浪費資源。
打通煙囪式系統間交互的集成和協作成本高昂：一個客戶在淘寶買了一件商品，又在天貓買了一件商品，那麼客戶應在在淘寶或者天貓任何一個客戶端上，看到這兩個商品；現在如果是兩個獨立的系統，那麼很多類似的功能，做起來會非常費時費力。
不利於業務的沉澱和繼續發展：例如某個業務流程需要優化，那麼就要在每個系統裡面改一遍。
“大中臺，小前臺”說白了可以看成：淘寶和天貓都有很多類似的功能，那麼把這些功能單獨的抽出來，作為一個一個獨立的系統，比如會員系統、商品系統、物流系統、支付系統等等。一個完整的系統，就是一個前段+各個流程所需系統組成。
那“大中臺，小前臺”的共享服務體系到底有什麼優點呢？
服務可重用：例如淘寶和天貓都要有支付，那麼就單獨做一個支付服務；不必為不同的前端業務，開發相同或者類似的服務。
服務被滋養：書中提出了一個觀點：服務最不需要“穩定”。服務需要被不停的滋養，促使服務不斷的自我成長，這樣服務才能最終成為IT資源，而服務所需的滋養正是來自新的業務不斷的接入。
服務助創新：共享服務平臺中的諸多服務是經過清晰的沉澱，可以通過重新編排、組合，快速的響應市場，達成創新，說白了就是一個字兒——快。
服務敢試錯：共享服務平臺由於具備快速編排、組合服務的能力，可以以較小的成本投入來構建出一個新的前端業務，即使失敗了，公司損失也很小。
希望我的回答，能夠幫助到你！
我會持續分享Java程序開發、架構設計、職業發展等方面的知識和見解，希望能得到你的關注【會點代碼的大叔】。
