今年 9 月份，我參加雲棲大會，瞭解了中臺發展的現狀和趨勢，並和業界同行進行了深入交流。為此，我寫了自己第一篇關於中臺的文章《向左還是向右？聊聊中臺建設中的那些糾結事》。該文章首發於 InfoQ，並得到多家媒體的轉載，反響熱烈。如果說這篇文章是關於中臺的思考和選擇，那本篇文章我想介紹一下我們的中臺實踐和這個過程中的思考邏輯。
一、為什麼決定做中臺？
2019 年，我被老闆調去做整個公司的研發總監，負責公司各產品線的研發工作。這對我而言，其實是一個很大的挑戰：一是，過去幾年，我一直負責某一個具體的產品線，涉及產品、技術、運營到銷售，並非純粹的技術工作或者研發工作；二是，公司研發體系較分散，統一整合難度很大。對於已經離開研發一線的我來說，前景未知。但已被安排在這個位置上，就要履行好自己的職責，全力而為。上任伊始，整個公司不少於五個事業部，每個事業部都不止一條產品線。對我來說，快速將各產品線研發統一，這的確是非常頭疼的事。
首先，我對各產品線進行初步調研，發現各產品線所涉及的領域都有重複。這也不足為怪，畢竟所有產品線都是圍繞醫療、醫藥領域，雖然應用場景不同，但很多基礎服務卻是相同的。
此前的一篇文章中，我已經指出符合以下情形的企業適合實施中臺：
1. 大型複雜的生態系統
2. 業務形態具備不確定性
3. 存在重複建設
4. 存在數據互聯互通的問題
從我們產品線的現狀看，除第一條目前並不特別匹配外，其他三條都符合，尤其最後兩項最突出。2019 年是中臺架構最火熱的一年，並且雲棲大會的主題也基本都以中臺為核心。帶著老闆交待的把研發統一整合的任務，我萌生了基於中臺架構來實施的想法。
二、做中臺前，我做了哪些準備？
翻開阿里中臺的建設歷程，其道路並非一帆風順，甚至是步履維艱，障礙重重。人們通常認為中颱戰略是老闆工程，沒有自上而下的推動想要做成幾乎是不可能的。但中臺作為一個全新概念，讓老闆認清中臺，讓同事接受中臺也不是一蹴而就的事情。
1. 建立共享研發團隊
實施中臺架構的一個重要原因是存在大量的重複性建設，一個根本原因是我們過去只重產品線發展而不重視能力線的建設，沒有一個團隊對公共的部分負責，所以我們要建立共享研發團隊來承擔對公共基礎服務的建設。
首先，將產品線的部分人員抽調出來組成共享研發團隊，如此，產品開發團隊的資源減少，加大各產品團隊重複“造輪子”的難度。
其次，建立項目評審和技術評審機制，讓共享研發團隊參與到各產品開發團隊的業務中，這樣將公共部分從產品開發團隊提煉到共享研發團隊。最後，通過設置合理的考核體系，強化制度執行。
2. 統一公司技術路線
在我們中小規模團隊，竟存在 Java、.NET、PHP 三條技術棧。由此可見，我們過去是如何輕視技術管理，任由各團隊自我發揮。
但是，問題在於太過分散的技術棧導致團隊之間無法有效協同，人員間不能很好補位，並且非常不利於團隊技術的深度積累。
2.1 確立 Java 技術棧為主路線
在上述三個技術棧中，從團隊人數、團隊質量和技術應用程度來看，Java 最高。並且，在青島這個城市，Java 人才最好招聘。
因此，確立 Java 作為公司內部長期發展的技術路線，而其他技術路線則收縮或向 Java 靠攏。
2.2 推行微服務開發模式
由於資源問題，無法很快短時間統一到一條技術路線上，三條技術路線將會持續很長一段時間，所以公共組件的重用無法在代碼級別進行，只能採取服務方式提供。微服務的架構非常符合當前現狀，三個 Java 主線的技術團隊中已經有兩個開始實施微服務的開發模式。因此，微服務開發模式和 SpringCloud 的體系也就順理成章的確立下來。
2.3 統一前端開發框架
對於 web 應用開發，前端開發其實佔用很大精力，因此為了更好的組件重用和團隊間協同，最好統一前端開發框架。這樣，就可以讓大家在同一個前端技術體系下協同和積累。
我們最終選擇以 VUE.JS 作為團隊統一的前端開發框架，共享研發團隊提供的組件全部以 VUE 開發的前端為其他團隊提供。
三、如何邁出中臺建設第一步？
一切變革都會從組織和人開始，中臺戰略的實施也不例外，這是它被認為是“老闆工程”的原因之一。
很多公司想做中臺，往往失敗或遲遲邁不開第一步，原因在於不敢調整架構，不敢動組織，沒有不破不立的膽略。《中臺禁區：為什麼最關鍵的組織架構卻鮮少人談？》
當我有中臺建設的想法後，老闆支持我創建專門的中臺團隊。雖然團隊規模不大，但讓中臺建設有了載體。這讓我們邁出了最重要的一步。這件事如果能有成績，首先得益於自上而下的推動。
至此，整個共享研發體系已初見成效，這為中颱戰略的順利執行奠定了堅實基礎。
四、為什麼要從技術中臺開始？
在阿里的中臺體系中，它是業務中臺和數據中臺雙核驅動，這也是大部分企業建設中臺的參考模式。
但是，對於我們以研發為核心的公司，不存在複雜的生態系統，而且在初創期並沒有大量數據，所以業務中臺和數據中臺在我們這裡的驅動力不夠。
更何況，構建業務中臺對我們以研發為主的團隊來說，也缺少業務抽象和架構的人員，碰壁的可能性會比較大。
任何一個變革要想成功，都要找到最容易的突破口，迅速建立效果，建立自信。而技術中臺因為更基礎，複用程度更大一些。並且，因為不具備業務特性，所以更加容易被抽象。
中臺定義是企業級能力複用的平臺，所以通過構建技術中臺來快速實現複用，從而讓中臺建設快速取得成效，並使團隊建立自信，這是我們深入中臺的基礎。
在這半年時間，我們在技術中臺方面快速構建了一些被經常用到的基礎組件，比如聚合支付、IM、人臉識別、呼叫中心等等。
五、如何選擇業務中臺的切入點？
在技術中臺建設過程中，我們讓前臺儘早體會到和中臺協同的益處，這也驗證中臺的確能為我們各前臺應用帶來價值——是時候來構建業務中臺了。
雖然我們重複“造了一些輪子”，但由於業務場景的差異，這些輪子其實是神似形不同，如何做到合適的抽象，這也是業務中臺構建的難點。新架構在開始時一旦做不好，往往不能解決前臺問題，反而會製造各種障礙。
那麼，問題來了，為推進更加順利，如何選擇業務中臺的切入點？
1. 價值考慮
- 尋找複用度高的業務，通過更多的複用降低整體的投入成本
- 需要持續運營的業務。持續運營意味著長期投入，不適合重複建設
2. 可控考慮
- 從新的業務開始
- 成熟業務沉澱共享
基於以上考慮的出發點梳理自身業務，從而確立業務中臺前期建設內容：
- 隨訪中臺–新的業務，且涉及多個產品線
- 內容中臺–已存在成熟業務，應用範圍很廣，且需要持續運營
- 藥品中臺–應用範圍很廣，且需要持續運營
半年時間，在項目繁多、資源緊張的情況下，我們小心翼翼的推進中臺建設。雖然進展緩慢，但中臺和前臺已經開始緊密協同，逐步打消我剛開始對推進中臺的擔憂，也讓團隊越來越有信心，這是一個不錯的成果。
過去，我們開發一個個單體應用，重複“造各種輪子”，數據也不統一。架構永遠都不是一蹴而就的，它在不斷演化，這對中臺架構更是如此。我們要有清晰的規劃，同時要穩步改造，不要冒進。
六、為何 PaaS 成為我們的重點？
中臺建設就是把可複用的能力沉澱下來，但這些可複用的能力如何被管理？如何快速複用？很多人形容中臺架構模式就像搭積木方式一樣構建應用系統，怎麼幫助開發人員快速的拼裝積木呢？
這需要構建在中臺之上的 PaaS 平臺來完成。
其實，急於建設 PaaS 層，更源於我們業務的變化和現存的問題。去年下半年，公司業務再調整，產品線在聚焦、收縮，我們的定位也轉成以面向 TO B 應用的產品研發為主，醫療行業的產品以本地化部署居多，互聯網業務在減少，中臺服務的迫切性已經不那麼高了。
而作為我們前臺的各個產品都存在標準化不足，擴展性不夠的問題，這就造成項目交付需要大量定製化開發，極大影響了交付成本和速度。因此，通過構建低代碼開發的 PaaS 平臺來解決這些問題成為當前重中之重。
在代號為 OECP 的 PaaS 平臺 1.0 beta 版推出後，快速應用在幾個項目上，這讓項目開發效率提升數倍以上。而去年頂著項目壓力研發的這個平臺初見成效，我內心的焦慮也得到適當緩解。
從長遠看，中臺 +OECP 的建設不僅解決了我們自身研發的成本和效率問題，而且在這個體系指導下，我們還可以擴大到整個集團範圍，幫助集團數字化轉型。並且，我們構建的醫療服務中臺，也將成為我們的產品優勢和亮點，助力客戶數字化轉型，搭建新型智慧醫院的服務體系。
七、為什麼很多中臺項目都失敗了？
前段時間，一篇《中臺，我信了你的邪》的文章給風風火火的中臺潑了一盆臘月的冰水，這也引起行業大討論。
茅臺的中臺項目到底如何，因為其實施方雲徙科技的闢謠而更撲朔迷離。前段時間，我看到另外一家醫藥企業的中臺項目招標書，也是深吸一口涼氣，估計結局也可能和茅臺一樣。
為什麼會失敗？為什麼推行不下去？我感覺有以下原因：
- 中臺之風太熱，導致企業對於中臺的期望過高！中臺不是“包治百病的萬能神藥”，它只是企業架構演化的一個階段或一種方式，它只能解決企業數字化轉型的部分問題而不是全部。
- 太注重形式，一切向大廠看齊！阿里的中臺是一蹴而就的嗎？阿里的中臺適合所有的企業嗎？每家企業的發展過程不一樣，每家企業的問題也有所不同，盲目照搬不僅問題沒解決，還消耗大量資源。
中臺是企業級能力複用的平臺，我們要把握中臺之神韻：以複用為核心，以企業級為視角、以各種能力為複用範圍。千萬不要被互聯網大廠的各種中臺之形而掣肘，因為中颱對數字化轉型的傳統企業，對像我們這樣的研發型企業，都有不同的應用動機和場景。
所以，落地中臺，貴在其神，活用其形！
譚明智 ，經歷技術、產品、運營等多個領域，現在負責百洋智能科技產品研發。喜歡並擅長做 IT 架構和產品架構，微信公眾號：菜根亂譚（ID:CGLT_TAN），歡迎關注，聊產品，聊技術。
閱讀更多 菜根亂譚 的文章
