大型企業中業務中台建設思考

近年來從網際網路領域到傳統行業竟争變得日益激烈，消費者的層次結構和個性化需求在快速發生變化，企業為了應對這種變化不得不進行業務的快速疊代，在此背景下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架構也不應過度設計而舍本逐末。