近年來從互聯網領域到傳統行業竟爭變得日益激烈，消費者的層次結構和個性化需求在快速發生變化，企業為了應對這種變化不得不進行業務的快速迭代，在此背景下IT行業裡中臺的概念逐漸火了起來，大家都在談論或實施中臺化戰略，中臺有什麼魔力能有這樣的號召力，各類企業特別是跨業態的集團化企業都希望通過中臺戰略解決自身問題，但是我們也看到一些企業在實施中臺項目中出現了嚴重的問題和偏差，阿里巴巴張勇曾說過：“如果一個企業奔著中臺做中臺，就是死”，中臺最早是由阿里提出的一種IT架構理念和方法，其實中臺思想古來有之，只是在互聯網時代給它賦予了新的涵意。
那麼什麼是中臺呢？我認為日常生活中我們每天能都接觸到中臺的服務，中臺能對資源進行向下整合，向上共享複用，前段時間同事在貝殼上買了一套商品房，服務體驗非常好，貝殼將線下各類房產中介公司的房源進行了整合，形成統一的房源池，提供真實的房源、房價和小區的近期成交數據，客戶只需要在貝殼一個平臺找合適自己的房子，貝殼還整合了各家銀行的工作人員在貝殼交易中心上班，那裡每一家銀行有一個辦公室，客戶可以自己選擇在哪個銀行貸款，甚至將房管局、稅務局等過戶手續部門都整合在貝殼交易中心，這在沒有貝殼前是完全不可想像的，從中可以看出貝殼平臺就是客戶與房源的中臺，客戶與銀行、房管局、稅務局的中臺，貝殼將買房需要的找房、網籤、貸款、交稅和過戶的手續都放在貝殼交易中心完成，全流程實現了線上化和移動化，極大的方便了客戶、房東和中介公司辦理業務。
中臺思想我理解就是一層層對細節的抽象，這和IT系統建設中抽象設計模式的道理一樣，將軟件中有共性的、可複用的部分提煉出來，快速滿足多業務場景的需求和發展，企業中的業務中臺將後臺資源進行整合和抽象，並向前臺提供簡單可重用的共享服務能力，實現了後臺業務資源到前臺易用能力的轉化，這種中臺思想能不能解決企業中碰到的瓶頸呢？
我從事IT系統研發十幾年，負責了多個大型信息平臺的建設，也見證了國內企業IT架構十幾年的發展歷程，從解決一個業務問題的應用系統發展到以數據平臺為基礎支撐的架構，到互聯網微服務和中臺架構，背後總是用戶的迫切需求驅動著企業響應能力的提升，技術的飛速發展對於各方都是個極大的挑戰。技術層面經歷了從上古時代的EJB、Servlet、Struts、Spring架構、模板技術、到現在的微服務、前後端分離、Serverless、AI技術等，我發現每一次的技術更新都是對複雜問題進一步的抽象和複用，讓使用者不需要關心具體的實現方式，只需要通過簡單的集成就能使用，對於將來的IT技術發展我估計也是這樣的發展方向，IT技術會逐步下沉到更底層，對外輸出的僅僅是傻瓜化的工具，讓非專業的業務人員參與到IT建設中來，甚至是系統功能的創造者。比如我們講的QuickBI和DataV這兩個BI工具，開發人員只需要把基礎數據提供出來，剩下的事都交給工具和業務人員完成，這不僅僅是技術的升級，甚至已經影響到將來全社會的分工協作界限。技術可以一次次抽象出來複用，那業務模塊是不是也可以這樣幹？
從理論上說將業務模塊抽象到合適的粒度是有可能實現的，服務鐵路旅客的業務能力，能不能直接挪到航空旅客用？這就是業務中臺解決的問題。但很明顯由於業務和組織存在更高複雜度和差異度，所以會非常非常難。很多傳統企業沒有自己的研發團隊，像很多國有企業IT系統基本都是依靠第三方供應商提供和服務支撐，而且大多是以傳統項目制和採購產品的方式經過多年實施逐步形成的，這種方式基本以甲方出需求，乙方設計實施，甲方驗收的流程建設，是由業務和職能單位發起針對自己的問題確定方案，這些單位很難主動去考慮與其它業務實體間的協同交互，這種組織架構形成了部門牆，數據和業務也是煙囪式的，相互協作困難。如果大家能在一個平臺上運行，用戶數據、產品數據、支付數據、訂單數據進行統一處理，這樣數據就可以在平臺上流動起來，多業務實體間的協同服務，簡化旅客出行的流程是完全可能的。對用戶來說每多一個操作步驟，就會多損失一半的用戶。但有一個很大的風險是組織結構的適應調整，中臺項目失敗很大原因就是資源得不到滿足。阿里巴巴中臺戰略的成功也是組織中臺的不斷調整和完善作為保障的。
以前一個企業要建信息平臺一般分為前臺和後臺。很多企業的後臺系統在立項建設時不是為了服務於前臺系統也不面向最終用戶，而更多的是為了實現管理手段的電子信息化，提升企業的管理效率。這類系統一部分是當年花大價錢採購，需要每年支付大量的服務費，版本老舊變更困難；一部分自建的年久失修同樣變更困難，對業務的響應慢，動不動改個小功能還要花一大筆費用，從集團公司最頂層看各成員企業幾百個信息系統，很多系統都是這樣，不僅僅是慢和貴，更重要的是被系統供應商給綁架了，很多系統代碼的產權是誰的都說不清楚，而且幾乎看不到哪個系統有擴容規劃、災備演練、降級限流等架構的實際落地和執行。
此時前臺和後臺就像汽車上兩個轉速不協調的齒輪，賽車手希望前臺的四個輪胎轉速越快越好，而發動機作為一臺汽車的心臟它的齒輪轉速則不是越高越好，它需要考慮車速、檔位、油耗、溫度和安全等綜合指標，中臺就是找到一個最合理的平衡點來保證前後的協調一致，想要快速響應前端用戶的大量需求，要求能夠快速創新迭代，所以前端要求轉速越快越好；後臺由於對應的是相對穩定的後端資源，系統變更困難越穩定越好，希望轉速越慢越好。隨著企業業務的不斷髮展，前後臺架構導致齒輪不匹配的問題就逐步顯現出來。後臺變更越來越困難，但還要響應用戶持續不斷的需求，導致業務邏輯直接在前臺實現，致使前臺系統不斷膨脹和複雜，形成了一個個煙囪式系統，業務沉澱不下來，系統交互困難，用戶響應能力低下。
中臺的出現將前臺與後臺的齒輪轉速進行適配。將後臺資源集成開放響應用戶的需求。將前臺應用中的穩定通用業務能力逐步下沉中臺，提高前臺的用戶響應能力；又可以將後臺系統中需要頻繁變化或是需要被前臺直接使用的業務能力抽取到中臺實現，為前臺提供更強大的炮火支援。2020年新冠疫情爆發，全國馳援武漢，我們國家發揮了強大的中臺整合能力，一方有難八方支援，政府從各地組織醫療資源和抗疫物資，通過疫情數據和病症情況的實時監控，不停的迭代醫治方案，很快控制住了疫情的發展，體現了在中臺的支持下前臺快速的應變能力，一省馳援一市的方案體現了微服務化的分而治之架構，國家將抗疫的經驗分享給其它國家，援助醫療物資體現了中臺的共享複用，但我們從數據上了解還有很多發達國家對疫情的控制沒到位，更能體現出IT中臺架構的建設風險和運營的風險都比較大。
從第一次接觸業務中臺的概念到負責中臺設計、實施、上線運行，我認為中颱概念非常合理先進，從架構的角度看，對企業數字化轉型和IT架構一下子清晰了很多，可以從更高的層次分析和把握整個企業的IT架構，前臺業務敏捷迭代快速響應用戶需求，中臺業務穩固支撐。反過來前臺的大量需求不斷的滋養中臺的成長和完善。不過在企業裡真實情況真是這樣嗎？真正能做好、運營好業務中臺的可能並不多，提出中臺概念的阿里巴巴也是經過了十幾年的沉澱才達到目前的階段，能夠想象到過程一定很不容易。阿里巴巴是以戰略提出的中臺架構，京東以組織架構中臺化開始，不難想象某個集團企業要開發上線一箇中臺的信息系統來解決企業存在的問題，我個人認為失敗的風險極大。我從技術的維度將實施業務中臺的一些經驗教訓進行了分析和總結，後期我會盡最大化歸納整理一個高可靠、高性能、低成本、低運維的業務中臺模型。提幾點我對實施業務中臺的建議和思考：
企業中存在很多相同或類似的業務需求，通過IT技術將這些業務功能抽象化，下沉為通用的、複用的業務能力，全面支持各業務線的快速發展，並提供業務創新的能力平臺和底座，這是實施業務中臺的核心價值。所以業務中臺是為業務服務的，各業務中心要了解和掌握你所支撐的業務具體情況是什麼樣子，對業務知識和流程要有深刻的認識。
業務中臺化不會有一套拿來改改就能用的方案，必須具體情況具體分析，中臺化的過程不出意外一定是痛苦和艱難的。需要讓企業的主要負責人知道什麼是中臺，信息系統中臺化後組織結構的調整和業務流程重組可執行嗎？企業的業務發展到了必須實施中臺戰略嗎？
能用微服務解決就暫時用微服務技術去支撐業務的發展，如果微服務能解決還要上中臺的話，我個人不太推薦。用微服務的技術支撐了業務中臺的運行，我們上線了業務中臺後也在逐步的調整和適應，步子邁的稍微大了一點，業務中心分的太細導致複雜的業務依賴關係和分佈式事務的問題，所以也在對業務中心進行從細到粗的合併，一些鍍金的功能以微服務的方式運行提供能力支撐。
中臺化要用互聯網思維建設，選擇更容易實施的業務領域開始，而不是全面開花，如果是大型集團化企業要實現整體架構中臺化，可能在市場上就沒有這樣一個承建商敢承接，另一方面不能抱著建信息系統的項目制實施，應通過敏捷迭代的方式每個月，甚至每週每天都能看到成果和問題，逐步迭代完善，採用小步快跑、快速試錯的方式實施，如果等到上線的時候才發現問題那就比較麻煩，涉及的業務太全面，可變因素和不確定性就會很多，失敗的風險相應也更大。
中臺項目的實施要有自己的業務專家、IT架構師和研發團隊，中臺建設是個長期的工作，它需要逐步成長和完善，如果直接交給IT承建商去實施，風險有點大，我們在建設中臺的時候我作為集團公司IT架構師全程參與並決策整個架構的設計，工作細到每個業務中心的數據模型和字段，每天對承建商的代碼級評審，而且通過外包的方式組建了一隻自己的研發團隊參與到中臺和業務應用的開發中，我們業務中臺的驗收標準是上線的那一天就是承建商撤離的時間點，也不需要承建商二期以及運維，需要完全由自己的外包研發團隊承接，這個其實很容易，因為自己的外包研發團隊和承建商的研發團隊整個實施過程都是一起開發，分工協作，比如承建商做訂單業務中心，自有外包團隊做支付中心。另一方面從業務上由我們信息部門的業務經理按條線分工去現場瞭解、收集和分析需求，這樣可以把握需求的範圍和質量，因為我們的業務經理是都是從機場一線上來的，最懂業務最瞭解現場情況，而不是直接將需求管理交給承建商去做。
要處理好業務中臺和業務應用這兩層之間的關係，很多傳統企業沒有自己的開發團隊，上層的業務應用層可能有幾十個IT廠家要基於中臺開發和改造。有專業化比較高的應用，還有一些應用直接使用的SAAS服務，如何在架構上處理好還真不容易，需要從多個維度來解決。我們在開發業務中臺時人為的將項目團隊分為兩個組，一組專門做業務中心，另一組則開發新的業務應用，當業務應用基於業務中心開發完成時，那麼基於業務中心開發業務應用的標準就出來的。另一方面從架構上也要適應業務應用層的多樣性。
企業建設業務中臺不應該完全從IT技術層面考慮，需要從技術、業務、組織和運營多個維度協同推進，而不單單是IT系統的一個維度。業務中臺只是支持業務場景的手段，並將多渠道的業務能力抽象沉澱下來，業務中臺的逐步成長完善也需要獨立的組織進行運營，平臺型組織是業務中臺的重要基礎也是企業轉型的方向，前後臺業務的拉通是平臺型組織的發展大趨勢，阿里中臺之所以成功不僅是技術，更是敏捷的組織變革，阿里提出“大中臺、小前臺”的中臺戰略後，進行過十幾次組織調整和部門合併，都是為拉通前中後臺提供了基礎。
中臺架構的實施落地推薦從易到難逐步實施，從最簡單的資源中臺開始，到技術中臺、數據中臺->業務中臺->組織中臺，最終完成企業架構的中臺化。這個過程是漫長的也是曲折的，我們在兩年的中臺建設中，碰到的問題大多與技術無關，更多出現在組織的邊界劃分上，我作為IT架構師更多的努力是從技術手段去解決碰到的問題，但往往在關鍵的節點是繞不開組織的問題。我曾經看到別人寫的一段話：“組織可能不是中臺建設的阻礙，而恰恰是中臺建設的本質”，只有親身經歷過中臺建設的人，才能正真體會出中臺早已超出了技術的範疇。
設計再完美的架構在建設過程中也會有變化，因為實施各階段面臨的影響因素非常多，所以變是正常的，不變才是有問題的。大型信息系統都是從小到大一步步完善，在每個階段都會遇到各類系統性和業務類問題，然後在不斷的解決這些問題，所以架構是由業務規模驅動而逐步演進完善的，當然IT架構也不應過度設計而捨本逐末。