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