剛火了的中台轉頭就拆，一大波公司放不下又拿不起來！


作者：小傅哥
博客：//bugstack.cn

沉澱、分享、成長，讓自己和他人都能有所收穫！😄

一、前言

離數學越遠代碼，價值越低！

代碼編程是對數學邏輯的具體實現，就相當於用磚頭蓋個廁所、碼個豬圈、砌出個磚牆等是一樣，磚還是那批5毛錢的磚，但蓋在哪裡蓋出了啥價值就不一樣了！

程序員也一樣，你碼的磚是公司里的；核心組件、通用模塊、高並發業務還是一些ERP查詢、接口包殼、屎山尋寶呢？通常那些複雜的業務邏輯或者具備一定技術深入的核心組件，才是最讓人程序員快速成長的地方。

當然有些時候沒有辦法，不是不想做而是沒得機會，或是因為初入職場、或是由於部門較差、也可能更多的是當前自身能力不足等等。但終究成長是自己事情，有了方向快是最大的障礙，腳踏實地把自己武裝起來，才有談判的機會！

二、為什麼建中台？

1. 什麼時候熱的

通過百度指數搜索中台關鍵詞，發現它是從19年5月21日突然熱起來的，如下圖；

百度指標搜索

2. 怎麼就熱了呢

說來奇怪怎麼中台就熱了呢，發生了啥？

騰訊湯道生：騰訊開放中台能力 助力產業升級

3. 中台從哪來的

你玩過《海盜奇兵》嗎？那《部落衝突》、《皇室戰爭》呢？咋滴，玩遊戲還和中台有關係？

芬蘭遊戲公司Supercell 海盜奇兵

  • supercell（超級細胞），芬蘭移動遊戲巨頭。擁有《部落衝突》、《卡通農場》、《海島奇兵》、《皇室戰爭》和《荒野亂斗》 [1] 等全球熱門遊戲。
  • 芬蘭移動遊戲巨頭supercell在2016年3月宣布，公司旗下遊戲每日活躍用戶（DAU）人數已經突破1億。這家公司的CEO埃卡·潘納寧（Ilkka Paananen）在推特上分享了這個消息，並向全球玩家表示感謝。
  • 在Supercell，每個獨立遊戲開發團隊，稱為「細胞」團隊，核心人員通常只有5人，最多也不會超過7人。員工雖然少，但都是行業頂尖人才，還有充分的自由度。
  • 團隊自己決定做什麼樣的產品，然後最快時間推出產品公測版，看看遊戲是否受用戶歡迎。如果用戶不歡迎，迅速放棄這個產品，再進行新的嘗試，期間幾乎沒有管理角色的介入。
  • 團隊研發的產品失敗後，不但不會受到懲罰，甚至還會舉辦慶祝儀式，以慶祝他們從失敗中學到了東西。
  • 2015年年中，馬雲帶領阿里巴巴集團高管，拜訪了位於芬蘭赫爾辛基的移動遊戲公司Supercell。
  • 騰訊控股與其他參與財團已於2016年6月21日下午6點左右（北京時間）發佈最新消息，確認已同意透過買方（財團的全資附屬公司）收購Supercell的大部分股權。

綜上，一個馬老闆收購了大部分股權，另一個馬老闆從 Supercell 團隊開發模式，聞到中台的味道，細胞和部落 對應 小前台和大中台，至此半年後每一個程序員都被中台洗禮了。

三、建了哪些中台？

1. 技術中台

  • 難度：⭐⭐⭐⭐
  • 描述：技術中台提供了建設系統所需的基礎設施、開發環境、數據服務、分佈式能力等各類底層技術問題，同時技術中台有時也涵蓋了研發中台的概念，主要是為了幫助工程的快速搭建、測試、集成、交付、運維、監控等。
  • 備註：技術中台基本是每個公司必備的，但可能每個公司會有多套測試環境、預發環境、上線環境，以及各類技術組件存在多套。建設中台的時候需要把這些能力進行整合，統一建設，統一維護。

2. 數據中台

  • 難度：⭐⭐⭐⭐
  • 描述：數據中台提供數據採集、運算、分析、算法等數據動作，並提供相應的數據服務；量化指標、人群標籤、知識圖譜、業務報表等。

3. 業務中台

  • 難度：⭐⭐⭐⭐⭐
  • 描述：業務中台提供可復用的服務能力，例如：交易、支付、活動、用戶、訂單等，這些服務可以標準化、簡單化、統一化。
  • 備註：中台最想也最難的就是對業務中台的處理，支持淺了滿足不了業務訴求、支持深了又太個性化滿足不了所有需求。同時每一塊業務拆分時可不只是系統，還有相應的業務、產品、運營，他們該如何提需求又提給誰。提的太複雜中台做不了，給後台做，做多了又想着平台化了。所以這也是最難的一塊！

四、剛建好又要拆？

原來是建中台火，現在突然變成拆中台了。如果不是阿里自己說要拆中台，可能其他人也不敢說！

拆中台的起因是阿里內網說中台太厚了，影響到業務發展和敏捷響應能力。為啥這麼說呢？

說白了，中台、低代碼這些概念的指導結果，都是為了通用性服務的組裝和編排。對於創新型顛覆式的需要快速試錯的業務場景，就不太容易使用中台搭建。

但中台很適合類似盒馬這樣的場景誕生，有用戶、有訂單、有支付、有營銷一整套的服務在中台都可以支撐，對於快速建設同類服務就變得非常容易。

可一些創新性，中台不具備或者不完全具備的服務，在通過前台、中台、後台，就變得非常困難，所有的需求沒得把中台擊穿就已經錯過了市場。所以說中台太厚了，要拆中台。

1. 新需求響應難度增加

當中台為了通用性、共用性、平台性的原則建設新需求的時候，實際對業務響應的敏捷度就是下降的。

這包括一個新需求，不需要你的流程太長、也不需要你的通用性、甚至可能不需要你做完整的分庫分表、數據採集、接口通用等等，如果你都按照中台的方式建設，那麼這一個小需求的整體時間成本都將翻倍。

所以當這樣的需求越來越多以後，你會發現建設的中台並沒有沉澱下可復用的服務，這些服務最終後被前台系統沉澱下來。本來希望是中台做的厚一些，現在看是前台變得更厚了，前台對中台的依賴也越來越小了。這主要是因為前台離需求變化最近，敏銳度最高

2. 服務集成複雜度增加

中台提供了大量可復用的接口，但一個需求的實現會需要很多中台的接口集成，最終因為這些接口串聯、組合、調試都過於冗長，使得效率不增反降。

原本一個需求由一個組可以實現，現在依賴中台需要很多組開會、協同、排期，嚴重拖慢了交付的進度，同時也不一定能提高交付質量。

3. 可復用實現難度增加

如果為了可復用則需要把一個需求放大，考慮它會發展成什麼樣，將來要擴展出哪些功能，留出什麼樣的口子，打哪種地基建設。基於各項的考慮把各類支撐需求的服務抽象化、去業務化，提取共性支撐業務組裝。

這就像中間件的建設是為了屏蔽底層差異化一樣，而你屏蔽的時候各類業務的差異化，而一個業務需求的變更都可能會影響到實際抽離出的業務組件該如何支撐。如果因為中台的通用性不能支持差異化需求，那麼這類需求就會被建設在前台。

所以一個公司原本就沒有很深、很廣、很足的業務場景覆蓋度，那麼中台的建設會成為需求的絆腳石，投入的人力也將增大，每一次需要構建和完善時也會成為中台建設的災難。

五、總結

  • 綜上我們看到中台並不是沒有益處，但也不是什麼都能幹。只是離業務太遠就追不上業務的變化，離的太近有靠近前台，所以現在希望把中台做的薄一些，能快速的支撐業務發展和敏捷為導向。
  • 如果公司沒有那麼個需求和實力，就算想建中台也不要一下步子太大，最後可能中台建完了，公司受不了了。阿里拆中台拆也不是完全的拆，因為已經有中台可以很好支撐的場景了，那麼需要快速變化的場景可以交給業務團隊。
  • 無論是中台、低代碼，相對於個人技術成長來說，都是看你在每一場技術遊戲中，承擔了什麼角色、留下了什麼價值，不會有永遠穩定一成不變的技術組織，只需要關心在變化中不斷積累個人成長所需的知識。

六、系列推薦

Tags:

VirMach 便宜 VPS

QNews

QNews