那些“爛尾”中臺的天坑，誰來填？
點選“技術領導力”關注∆每天早上8:30推送
作者|Mr.K 整理| Emma
來源|技術領導力(ID：jishulingdaoli)
程式設計師上班就兩件事：挖坑、填坑。
我的朋友王架構，最近有點煩。擺在他眼前的這個坑有點大，可以用“天坑”來形容。
中臺留下的"天坑"，誰來填？
那麼，“天坑”怎麼來的呢？一年前風風火火的“業務中臺專案”留下的，在同事間，這是心照不宣的祕密。
“業務中臺專案”是公司去年的明星專案，曾獲得總經理頒發的“突出貢獻獎”，基調都已經定好了，誰敢說中臺專案不成功？
可眼前的爛攤子又怎麼收拾呢？王架構摸了摸他那顆被上帝親吻過的頭顱，很是無奈，他面臨的問題是：
1、“業務中臺”的後續維護工作，缺乏資源。當初成立專案組，從各業務線調人，專案上線後，團隊就解散了。在領導們看來，中臺專案已經“成功”了，慶功宴都吃了3回了，還能有什麼後續工作？專案完美收官，交給架構部維護，就這樣愉快地決定了。
2、“業務中臺”脫離業務，需求響應慢。王架構的團隊做的是基礎架構，不是應用架構，缺乏對業務的瞭解。讓一個基礎架構團隊來維護“業務中臺”，這顯然是個外行人的決策。在公司看來，卻是神來之比：中臺是個架構呀，當然由架構部負責維護。
3、明星專案的“詛咒”。在大公司裡這樣的現象非常普遍，就是去年的“明星”專案，很可能是今年的“乞丐”專案。這個很好理解，“明星”專案就是當年的公司戰略方向，而公司的戰略方向每年都是不一樣的，很少有同一個專案連續兩年都是明星專案。
人往高處走，優秀的員工爭著做明星專案。去年的“明星”專案“業務中臺”，今年淪落成“乞丐”專案，根本拿不到資源。
王架構所在公司的“中臺”建設，主要問題是：
1、把中臺當成技術專案。老K之前也寫過這個問題，“本以為中颱是個技術問題，後來發現是個組織問題，最後才知道這個戰略問題”，這是許多公司對中臺的認知過程，這個過程所教的學費，少則幾十萬，多則幾千萬。把中臺當做技術專案，所以組織上沒有配合做變革。中臺專案做完，專案組解散，中臺專案難免“爛尾”或“年久失修”。
2、中臺戰略不清晰。甚至可以說沒有所謂的中臺戰略，如果有戰略，那麼在組織上應該有所體現。要解決的問題也是不清晰的，究竟是降低成本，還是提升體驗，不夠明確聚焦。中臺專案上線後，就鳴金收兵了，殊不知，中臺是需要業務滋養的，專案上線僅僅只是開始而已。
這種現象普遍嗎？非常普遍。老K調研了20多家網際網路公司，70%在這一兩年內都建立了中臺，四成以上都是採用專案制的方式。跟上面的案例很相似，面臨的問題也很類似。
王架構的公司是幸運的，至少中臺專案是“成功”的。讀者Bear就沒那麼幸運了。
“爛尾”的中臺，鍋誰來背？
Bear給我留言，講述了他們公司的中臺現狀：
我們公司就是想做中臺，一家saas企業應用軟體供應商，先拆微服務，拆完沒人管理和運維了，發現做不成中臺了，現在就這散架子跑著，微服務的計算研發團隊變成運營和運維。。艱苦的跑著~
從Bear的描述來看，這是一個“自下而上”的中臺專案。先把SaaS架構，拆成微服務，這樣有利於服務的抽取，這是中臺架構演進的普遍做法，技術方案上沒什麼錯。
拆完發現做不成中臺，Bear沒有說得很清楚，可能是技術問題，也可能是規劃問題。拆都拆了，怎麼辦呢？跑著唄，微服務架構總歸比原來一個大單體要健壯、可擴充套件一些，但是維護成本也高一些。
Bear他們公司的中臺建設存在的問題是：
1、中臺建設，自下而上。中臺是戰略層面的事情，只能自上而下，進行組織變革、業務模式變革、技術變革。少一環不聯動，都極有可能失敗，這個過程非常複雜，不是幾個技術人員能夠推動的。
2、決心不足，投入不足。從公司層面對中臺建設的決心不足，導致了資源投入不足。戰略上沒有重視，覺得你們試試看吧，小範圍跑跑，跑起來再說。現在一看，果然跑不起來。“中臺沒戲，都是騙人的玩意，還好我不是韭菜”，老闆暗中觀察，獨自竊喜，為自己的“英明決策”自嗨。
這類公司就更多了，一群技術人員，覺得中臺是個時髦的概念，看了幾篇中臺雞湯乾貨，擼起袖子開始幹，幸福都是奮鬥出來的，天坑也是這麼挖出來的。先上微服務，拆成幾百個獨立應用，再整成大中臺。合的時候出問題了，合是合好了，就是多出了幾個模組，怎麼也組裝不起來。哈哈哈哈，跟老K當年拆IBM筆記本的過程是一樣的。
技術人員給自己挖坑，然後再默默地填上，這一挖一填之間，神奇的事情發生了：簡歷上漂亮了，專案得獎了，工資也漲了，就是公司倒大黴了。
總之，中臺是一種很玄的東西。
作者簡介：Mr.K，知名電商公司技術老K級人物。文出過暢銷書，武做過CTO，若非生活所迫，誰願一身才華。
-END-
推薦一個專門研究BAT大廠技術架構的公號，“BAT架構”，偏技術一些，感興趣的關注一下。
“BAT架構”，技術架構高手都在看！
大家在看：