01 “水深火熱”的中臺
“中臺”概念的緣起大家都清楚，來自馬雲先生對一家歐洲遊戲公司考察後的感悟，一個比喻。實踐層面，鍾華老師寫的《企業IT架構轉型之道：阿里巴巴中臺戰略思想與架構實戰》是第一本比較完整地闡述阿里巴巴中臺實踐過程的著作，可以說是中臺佈道的開始吧，鍾華老師如今仍在實踐其理念。
2019年中臺可謂火的一塌糊塗，既有從原產地阿里巴巴出來的創業團隊，也有將其原有實踐簡單包裝冠以中臺名號的“貼牌”者。
去年在的一次交流中，筆者曾經用Gartner曲線的形式，串起了與中臺相關的書和文章，與參會者開了一個小小的玩笑，如圖11所示：
▲圖11 中臺曲線
彼時還沒有那篇炸了圈兒的文章，筆者也無意將其補進去，畢竟這張圖也只是個玩笑。任何技術形態都會經歷這個歷程，架構理念也不例外。有價值的自然會重新走回上升態勢，哪怕是10年以後，或者像AI一樣幾起幾落；沒價值的也就壽終正寢了。
Richardson 也說過：“人們往往容易被情緒因素所驅動，這也是為什麼會有這麼多關於技術的兩極分化和過度粉飾的爭論”。
中臺就其設計理念而言，仍是為了有效降低系統設計複雜度、提升複用能力的企業架構方法。
去年南京中臺大會的閉門討論中，主持人曾要求每位演講嘉賓用一句話概括自己對中臺的認知，筆者當時說的也是“跟我實踐過的EBA相似，也只是一種架構方式”，確實，就目的而言，二者殊途同歸，都是在考慮識別、沉澱企業的業務能力，將其模塊化、服務化之後，更好地支持業務變化。
筆者在《企業級業務架構設計：方法論與實踐》一書中對EBA的定義：“以實現企業戰略為目標，對企業能力進行整體規劃並將其傳導到IT實現端的結構化分析方法”。
EBA與中臺的差別，在實操層面也許主要是EBA並未考慮要將沉澱的業務能力剝離為中颱層，因為EBA主張企業級複用，從這個角度講，也不需要單獨進行一個特殊的表達。EBA形成的業務組件之間按照調用的頻率也可以適當進行分層，但這種分層結果並非現在中臺的含義。除此之外，中臺目前對企業戰略如何分解落地也沒有很詳細的解釋方法。
EBA的一般設計過程如圖6所示：
▲圖6 EBA設計的一般過程
EBA的整體邏輯如圖7所示：
▲圖7 EBA的整體邏輯
如圖8所示，EBA強調的是“知行合一”，強調企業自己對方法論的駕馭和對架構師的培養，未來的企業管理必然包含架構管理，企業管理追求的“韌性”很可能將來自於架構的“彈性”和演化能力。
▲圖8 業務架構的知行合一
EBA方法也是一個業務架構設計與IT實現之間不斷迭代的過程，如圖9所示：
▲圖9 業務架構設計與IT實現的持續迭代過程
阿里巴巴也是業務架構理念的實踐者，業務架構根據其設計範圍可以區分為領域級和企業級，阿里巴巴對業務架構的應用，從其自身披露信息來看比較側重於領域級，業務架構師按領域配置和開展工作。當然，設計發展到一定程度，總是會自然關注到企業級。
對中臺的探索，筆者認為仍然值得開展下去，無論它以後還叫不叫中臺，這是對架構設計理念的探索。從阿里巴巴的角度看，也是他們在技術底層實踐越來越成熟之後，對上層設計的必然追求。
筆者也不太贊同按照企業規模去給中臺劃個准入門檻，畢竟企業無分大小，只要系統建到一定規模或者數量，時間累積到一定程度，總有“技術債務”要還，總有重構的十足理由，那麼作為一種架構設計理念去應用中臺方法，未嘗不可。
如果說到成本，規模小的企業當然不必仿照阿里巴巴的方式構建昂貴的基礎設施，設備成本是由系統的非功能性需求決定的，與企業的規模、財務能力也是匹配的，所謂中臺燒錢，可能主要是想照搬阿里的技術方案造成的吧。拋開這個，它與一般的重構相比，是否真的會大幅度提高重構成本，筆者還是懷疑的。
至於進行業務梳理的成本，只要企業想改革，這個成本無論用任何方法都是要付出的。
玄難和毗盧離職前，阿里的中臺計劃取名為“星環”，據說名稱創意來自於劉慈欣老師的《三體》，是那艘超光速飛船的名字，對於快的追求不言而喻。但是從筆者的角度來看，倒是更喜歡美劇《無垠太空》中的“星環”，每個“星環”都是通向一個世界入口。
企業自建中臺需要自身的沉澱，中臺產品提供商則需要行業沉澱，現實中，還需要對行業中處於不同位置或者細分領域的客戶進行不同分類的沉澱，如此看，中臺就像“星環”一樣，是通向不同世界的入口。如果願意再揶揄一下，走進入口，遇見的可能是“天堂”，也可能是“地獄”。
EBA也可以成為“星環”，道理是一樣的。通過EBA也可以不斷積累對行業或者細分領域的模型，這些模型不僅對架構設計者有所幫助，而且可能是未來走向自動化設計、AI設計的必經之路，因為AI也需要架構數據的供給才能產生設計能力，而目前架構領域連案例都經常是語焉不詳、光怪陸離，更不說積累數據了。
02 中臺與“組合拳”
其實中臺與“組合拳”的關係，阿里巴巴的人自己出來多講講會更好。
從筆者的瞭解來看，阿里巴巴的中臺實踐中，“組合拳”的應用是不少的，他們的特點是一般不會強制團隊使用某種方法。微服務顯然是廣泛使用的，敏捷開發、DDD在不同的團隊中也都有應用，但是，應該不是每個團隊在每次開發中都採用這些方法。
阿里巴巴的中臺，據說在大規模構建之前面對的問題之一就是企業已經有上萬個微服務，每次承接新需求都可能有數百個微服務受到波及，而服務數量如此之多，以至於沒有人能搞清楚業務能力到底有哪些、是如何分佈的，所以，搞起了業務架構，分離業務領域，理清不同領域的業務模式，再沉澱業務能力，形成中臺。
微服務是中臺在技術層面落地的方式之一，但是中臺設計要有效地為微服務的劃分提供指導，並從架構層面提供業務能力的可視化，進而支持業務能力的持續優化，通過架構演進指導微服務的設計與變化。微服務則在技術落地上提升對業務能力的運維支持，提供良好的升級維護和可擴展性。
在分離業務領域方面，DDD方法也有一定範圍的使用，畢竟這種方法與微服務的結合被廣泛傳說，而且DDD的思維方式就是側重對限界上下文的分離，以達到在同一個限界上下文內對同一業務概念理解上的一致。每年Thoughtworks的大會上，也都有阿里人來分享應用DDD的經驗。至於敏捷開發，更是常被當作互聯網企業的標配。
中臺跟“組合拳”的關係，其實也應該類似於EBA跟“組合拳”的關係，只是現有的信息中，中臺並沒有像EBA那樣給出一個明確的設計過程和方法，所以，分析也很難做的更深入，這並不是對著幾張漂亮的架構圖就可以做的比較。
03 特化與泛化
筆者從各種交流，包括對筆者文章的留言中，也能感受到，中臺面臨的一個問題就是領域的積累達到一定程度之後，必須從企業層面去思考問題。
所謂的做中臺以支持業務的靈活變化，那到底業務是什麼？到底是支持需求還是支持業務？技術人員到底理不理解業務？需要理解到什麼程度？需求到底是來自業務人員的還是來自真實客戶的？
說到底，就是技術到底怎麼支持業務，其實這樣說還是有些“見外”，應該說，技術到底怎麼跟業務融合。
這波對中臺的爭論，也反映了對阿里中臺的一個認知問題，它到底是個特化的方法還是泛化的方法。
從阿里自身看，這首先是一個特化的方法，理由不難理解，他們要梳理自身過於複雜的微服務實現狀況，要支持業務端給數千萬商戶提供的千變萬化的營銷、管理手段，要面對複雜的商業生態和大量的不確定性，應對每年“雙十一”獨步全球的高併發環境，應對互聯網領域“唯快不破”的殘酷競爭，還要應對大量的技術“無人區”，這樣可謂“極端”生存環境下產生的方法，一定是個“特化”的方法。
其實每個方法誕生之初都是“特化”的，面對的環境越極端，方法的特化性相應也越強，阿里的中臺也理應屬於這種情況。
但是大家需要的是一個泛化的方法，這就需要首先解釋清楚方法的特化之處，考慮清楚對特化的處理，才能實現泛化的目標。
作為一個局外人來看，筆者建議，把阿里中臺方法中的各種武器首先拆分清楚來看，先不要抱著“要要要”“買買買”的想法，而是搞清楚武器之間的關係和成本，應用的前提條件和最適宜解決的問題，再對號入座，實現“客戶化”過程。
比如，業務能力梳理方法、組織結構是不是直接對標阿里（阿里可是經常變的）、微服務要不要搞、阿里技術棧選用哪些、需要全鏈路壓測嗎等等之類的問題。
一個泛化的方法在應用過程中還是會再經歷一次本地的特化，尤其是中臺、EBA之類的企業級方法，這也代表需要足夠的時間和成本。“九尺之臺，起於壘土”，中臺的構建，也少不了“搬磚”的過程。
對於做中臺產品的服務提供商而言，應當把中臺認真當成一個軟件工程方法看待，把其中的組成要素、軟件過程、可選方案都研究明白，“工欲善其事必先利其器”，這是對工匠的基本要求。
對於這些廠商而言，幫助客戶搞清楚自己要的到底是特化的阿里中臺還是泛化的中臺，是很重要的。
泛化的中臺意味著要根據客戶的實際情況決定中臺的實施目標，而非靠“對標”的方式預先誘導實施目標，後者銷售的意味太過強烈。當然，這種情況不只中臺有，但凡商業化的東西，都有這個問題，說“酒香不怕巷子深”的越來越少了。
中臺說到底也是一個技術怎樣與業務融合的問題，看到了一個有成功實踐做背書的技術理念，但是套用到自家業務實踐上，卻發現“知行合一”遠非易事。
作者：付曉巖，《企業級業務架構設計：方法論與實踐》圖書作者，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計，現就職於建信金融科技有限責任公司。
閱讀更多 運營增長 的文章
