起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識半年中臺實踐的思考：落地中臺，貴在其神，活用其形
今年9月份我參加了云棲大會，親臨現(xiàn)場體會了中臺發(fā)展的現(xiàn)狀和趨勢，和業(yè)界同行進行了深入的交流，為此寫了我第一篇關于中臺的文章《向左還是向右？聊聊中臺建設中的那些糾結事》。這篇文章發(fā)表到infoq上，也得到了多家媒體的轉載，反響還是很不錯的。
如果說第一篇中臺的文章是一種思考，一種選擇，那么今天的這篇文章，我想介紹一下我們的中臺實踐，以及過程中的思考邏輯和實施內容。
我為什么決定做中臺？
2019年，我被老板調去做整個公司的研發(fā)總監(jiān)，負責公司各產品線的研發(fā)工作。這對我其實是一個很大的挑戰(zhàn)，其一過去幾年我一直負責其中一條產品線，從產品，技術到運營、銷售，什么都要做，并非純粹的技術工作或者研發(fā)工作；其二是公司的研發(fā)體系比較分散，想統(tǒng)一整合難度很大，對于已經離開研發(fā)一線的我，的確前景未知。
但既然被安排在這個位置上，就要履行自己的職責，盡力把工作做好。
上任伊始，整個公司不少于五個事業(yè)部，每個事業(yè)部都不止一條產品線，一下子把各產品線研發(fā)統(tǒng)一，對我初來乍到的人來說，的確是非常頭疼的事情。我對各產品線進行了初步的調研，發(fā)現(xiàn)各個產品線所涉及的領域都非常的重復，其實這也不足為怪，畢竟所有產品線都是圍繞醫(yī)療、醫(yī)藥領域，雖然應用場景各有不同，但是很多基礎的服務卻是一樣的。
各產品線的領域范圍
在之前的中臺文章中我也分析了，符合以下情形的企業(yè)是適合實施中臺的：
- 大型復雜的生態(tài)系統(tǒng)
- 業(yè)務形態(tài)具備不確定性
- 存在重復建設
- 存在數據互聯(lián)互通的問題
從我們的產品線現(xiàn)狀看，除了第一條目前并不特別匹配外，其他三項都符合當前團隊的狀況，而最后兩項尤其突出。2019年是中臺架構最為火熱的一年，云棲大會的主題也基本都以中臺為核心，帶著老板交給的進行研發(fā)統(tǒng)一整合的任務，萌生了基于中臺架構來實施的想法。
做中臺之前我做了哪些準備？
翻開阿里中臺建設的歷程，其道路并不是一帆風順的，甚至是步履維艱，障礙重重。人們通常認為中臺戰(zhàn)略是老板工程，沒有自上而下的推動要想做成幾乎是不可能的。但是中臺作為一個全新的概念，讓老板認清中臺，讓同事接受中臺也不是一蹴而就的事情。
1. 建立共享研發(fā)團隊
實施中臺架構的一個重要原因是存在大量的重復性的建設，其根本原因之一就是過去我們只重視產品線發(fā)展而不重視能力線的建設，沒有一個團隊對公共的部分進行負責，所以首先我們要建立共享研發(fā)的團隊來承擔對公共基礎服務的建設。
將產品線上的部分人員抽調出來組成共享研發(fā)團隊成員，這樣產品開發(fā)團隊的資源減少了，從而加大了各產品團隊重復制造輪子的難度；其次，建立了項目評審和技術評審的機制，讓共享研發(fā)團隊參與到各產品開發(fā)團隊的業(yè)務之中，從而將公共部分從產品開發(fā)團隊提煉到共享研發(fā)團隊；最后，通過考核體系，加強制度的執(zhí)行。
2. 統(tǒng)一公司技術路線
對于我們中小規(guī)模的團隊，居然存在Java，.NET，PHP三條技術棧，可見過去我們對于技術管理是如何的輕視，任由各個團隊自我發(fā)揮。太過分散的技術棧導致團隊之間無法有效的協(xié)同，人員之間不能很好的補位，也非常不利于團隊技術的深度積累。
（1）確立Java技術路線為主路線
在這三個技術棧之中，Java的團隊人數，團隊質量，以及技術應用程度都是最高的，并且在青島這個城市，Java的人才也是最好招到的，所以確立以Java作為公司內長期發(fā)展的技術路線，其他技術路線收縮或者向Java靠攏。
（2）推行微服務開發(fā)模式
因為資源問題，不可能一下子統(tǒng)一到一條技術路線上來，三條技術路線將會持續(xù)很長一段時間。所以公共組件的重用無法在代碼級別進行，而只能采取服務的方式提供，而微服務的架構非常符合當前的現(xiàn)狀，而三個Java主線的技術團隊有兩個已經開始實施微服務的開發(fā)模式，微服務的開發(fā)模式以及SpringCloud的體系也就順理成章的被確立下來。
（3）統(tǒng)一前端開發(fā)框架
對于web應用開發(fā)，其實前端開發(fā)占用了很大的精力，為了更好的組件重用和團隊間協(xié)同，最好要統(tǒng)一前端開發(fā)的框架，讓大家在同一個前端技術體系下協(xié)同和積累，根據各團隊使用的普及度，最終選擇以VUE.JS作為團隊統(tǒng)一的前端開發(fā)框架，共享研發(fā)團隊提供的組件全部以VUE開發(fā)的前端對其他團隊提供。
中臺建設的第一步如何邁出？
一切變革都會從組織和人開始，實施中臺戰(zhàn)略也不例外，這也是它之所以被認為是“老板工程”的原因之一。很多公司想做中臺，但都以失敗告終或者就遲遲邁不開第一步的原因就是不敢調整架構，不敢動組織，沒有不破不立的膽略。
《中臺禁區(qū)：為什么最關鍵的組織架構卻鮮少人談？》 在我有了中臺建設的想法后，老板支持我創(chuàng)建了專門的中臺的團隊，團隊雖然不大，但讓中臺的建設有了載體。不管我和老板在中臺的定義和目標的理解是否完全一致，但我們邁出了最重要的一步，感謝老板的支持，這件事如果能夠有成績，首先得益于自上而下的推動。
至此，整個共享研發(fā)的體系已經初見成效，為中臺戰(zhàn)略的順利執(zhí)行奠定了堅實的基礎。
共享研發(fā)體系
為什么要從技術中臺開始？
在阿里的中臺體系中，是業(yè)務中臺和數據中臺雙核驅動，這也是大部分企業(yè)建設中臺的參考模式。但對于我們以研發(fā)為核心的公司，不存在復雜的生態(tài)系統(tǒng)，而且在初創(chuàng)期并沒有大量的數據。所以業(yè)務中臺和數據中臺在我們這里驅動力不夠，更何況構建業(yè)務中臺對于我們以研發(fā)為主的團隊來說，也缺少業(yè)務抽象和架構的人員，一上來碰壁的可能性會比較大。
任何一個變革要想成功，都要找到最容易的突破口，迅速建立效果，建立自信。而技術中臺因為更加基礎，復用程度會更大一些；而且因為不具備業(yè)務特性，所以更加的容易被抽象。
中臺的定義就是企業(yè)級能力復用的平臺，所以通過構建技術中臺從而快速實現(xiàn)復用，從而讓中臺建設快速取得效果，讓團隊建立自信，是我們深入中臺的基礎。
這半年的時間，我們在技術中臺方面快速的構建了我們產品和項目經常被用到的一些基礎組件，比如聚合支付、IM、人臉識別、呼叫中心等等。
如何選擇業(yè)務中臺的切入點？
在技術中臺的建設過程中，我們讓前臺盡早的體會到和中臺協(xié)同的益處，也驗證了中臺的確能為我們各前臺應用帶來價值，是時候來構建業(yè)務中臺了。我們雖然重復制造了一些輪子，但是由于業(yè)務場景的差異，這些輪子其實也是神似形不同，如何做到合適的抽象，這也是業(yè)務中臺構建的難點。
新的架構在開始一旦做不好，往往不能解決前臺問題，反而會制造各種障礙，為了推進更加順利，如何選擇業(yè)務中臺的切入點呢？
1. 價值考慮
- 尋找復用度高的業(yè)務，通過更多的復用降低整體的投入成本；
- 需要持續(xù)運營的業(yè)務，持續(xù)的運營意味著長期的投入，不適合重復建設。
2. 可控考慮
- 從新的業(yè)務開始；
- 成熟業(yè)務沉淀共享。
確立業(yè)務中臺的切入點
基于以上考慮的出發(fā)點梳理自身業(yè)務，從而確立了業(yè)務中臺前期建設內容：
- 隨訪中臺–新的業(yè)務，且多個產品線涉及；
- 內容中臺–已存在成熟業(yè)務，應用范圍很廣，且需要持續(xù)運營；
- 藥品中臺–應用范圍很廣，且需要持續(xù)運營。
半年的時間，在項目繁多、資源緊張的情況下，我們小心翼翼的推進中臺的發(fā)展，雖然進展緩慢，但中臺和前臺已經開始緊密協(xié)同，逐步打消我剛開始推進中臺的擔憂，也讓團隊越來越有信心，依然是一個不錯的成果。
過去我們開發(fā)了一個個的單體應用，重復制造了各種輪子，數據也不統(tǒng)一，但架構永遠都不是一蹴而就的，都是在不斷演化的。對于中臺架構更是如此，我們要有清晰的規(guī)劃，同時要穩(wěn)步的改造，不要冒進。
中臺架構演進
為什么PaaS成為我們的重點？
中臺建設就是把可復用的能力沉淀下來，但這些可復用的能力如何被管理？如何快速的復用？很多人形容中臺的架構模式就像搭積木的方式一樣構建應用系統(tǒng)，怎么幫助開發(fā)人員快速的拼裝積木呢？需要在構建在中臺之上的PaaS平臺來完成。
其實著急建設PaaS層，更源于我們業(yè)務的變化和現(xiàn)存的問題。去年下半年公司的業(yè)務再調整，產品線在聚焦收縮，我們定位也在轉成以面向TO B應用的產品研發(fā)為主，醫(yī)療行業(yè)的產品以本地化部署居多，互聯(lián)網業(yè)務在減少，中臺服務的迫切性已經不那么高了。
而作為我們前臺的各個產品都存在標準化不足，擴展性不夠的問題，造成了項目的交付需要大量的定制化的開發(fā)，極大影響了交付的成本和速度，通過構建低代碼開發(fā)的PaaS平臺來解決這些問題成為當前更重點的事情。
OECP的主要方向
代號OECP的PaaS平臺1.0beta版推出后，快速的應用在幾個項目上，讓項目的開發(fā)效率提升了數倍以上，去年頂著項目壓力研發(fā)的這個平臺初見成效，內心的焦慮也適當的得到了緩解。
從長遠看，中臺+OECP的建設不僅解決我們自身研發(fā)的成本和效率問題，在這個體系指導下我們還可以擴大到整個集團范圍，幫助集團數字化轉型。而我們構建的醫(yī)療服務中臺，也將成為我們產品的優(yōu)勢和亮點，幫助客戶做數字化轉型，搭建新型的智慧醫(yī)院的服務體系。
為什么很多中臺項目都失敗了？
前段時間，一篇《中臺，我信了你的邪》的文章，給風風火火的中臺潑了一盆臘月的冰水，也引起了行業(yè)的大討論。茅臺的中臺項目到底如何，因為其實施方云徙科技的辟謠而更撲朔迷離。前段時間，我看到了另外一家醫(yī)藥企業(yè)的中臺項目的招標書，也是深吸一口涼氣，估計結局也可能和茅臺一樣。
為什么會失敗，為什么推行不下去，我感覺有以下原因：
- 中臺之風太熱，導致企業(yè)對于中臺的期望過高！中臺不是包治百病的萬能神藥，它只是企業(yè)架構演化的一個階段或一種方式，它只能解決企業(yè)數字化轉型的部分問題而不是全部。
- 太注重形式，一切向大廠看齊！阿里的中臺是一蹴而就的嗎？阿里的中臺適合所有的企業(yè)嗎？每家企業(yè)的發(fā)展過程不一樣，每家企業(yè)的問題也有所不同，盲目的照搬不僅問題沒解決，還消耗了大量資源。
中臺是企業(yè)級能力復用的平臺，我們要把握中臺之神韻：以復用為核心，以企業(yè)級為視角、以各種能力為復用范圍。而不要被互聯(lián)網大廠的各種中臺之形而掣肘，因為中臺對數字化轉型的傳統(tǒng)企業(yè)，對于像我們這樣的研發(fā)型的企業(yè)，都有不同的應用動機和場景。
所以，落地中臺，貴在其神，活用其形！
#專欄作家#
菜根亂譚，微信公眾號：CGLT_TAN，人人都是產品經理專欄作家。經歷程序員、技術Leader、產品經理、研發(fā)Leader等多種崗位。關注醫(yī)療，早教領域，擅長企業(yè)IT架構及互聯(lián)網產品架構。
本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協(xié)議
醫(yī)療項目，大差不差，但又總有些差異化。如何降本快速交付才是真香。做政企類B端客戶的，不走這一步終究是吃不消的，不然就是招人招人招人….
受教了，感謝
以作者這個策略，從原有團隊里抽人或者再招聘增加些人手，組建團隊建中臺，再用中臺去開發(fā)原有產品。5條產品線，要么折騰死你最后失敗告終，折騰不死就說明你公司本來人員就冗余。
如果作者寫的這件事是真的，那這老板支持你做這件事無非3個原因：
1. 他真的對公司有長遠規(guī)劃，這個長遠是指超過10年以上。
2. 他打算把你建好的中臺拿來賣或者其它形式產生收入
3. 他腦子發(fā)熱
1的可能性不大，能做10年的企業(yè)很少。2的可能性也不大，能拿出來賣的中臺，得做得比較通用，這里的成本很高，一般人都不具備這么高的研發(fā)水平。所以，更大可能是3
我們要有一個大概的成本估算，做一個給你的企業(yè)內部用的能支撐得起現(xiàn)有所有業(yè)務的中臺，其開發(fā)成本是你現(xiàn)有所有產品開發(fā)成本總和起碼一半以上，所以花這么多成本做一件事，必須要賺得回來。
所以，我覺得一個務實的做法：
1. 把現(xiàn)有的產品，能做服務的做成服務，供其它系統(tǒng)使用。所以，無需立即統(tǒng)一技術，用PHP的繼續(xù)用PHP。
做服務比較簡單，無非定義好對外的接口，少量開發(fā)即可。
2. 有新業(yè)務或者舊業(yè)務系統(tǒng)很差勁要重做，就用新成立的中臺技術團隊去開發(fā)。沒有，就無需立即建中臺。
3. 等中臺做得差不多了，就把原來產品一個一個用中臺開發(fā)，界面是不會重新開發(fā)的，因為這會影響用戶使用。無非替換掉原有的服務。
期間成本承受不住可以隨時暫停。
復用是為了減少成本，你重新做個中臺無形中增加了成本，意義何在？！
感謝您回復了這么多內容，說明您對中臺有深刻的思考。但是正如本文標題所闡述的，中臺沒有標準，每個人對中臺之形的理解都是不一樣的，您怎么就斷定我們中臺的建設成本巨大呢？我統(tǒng)一主流的技術路線也沒說干掉其他的技術路線啊，我想干掉也不現(xiàn)實??！我們中臺的確是在逐步的管理php，.net發(fā)布的共享服務啊。我們對于中臺的定義是做到服務層即可，但是一些需要復雜交互的中臺提供基于vue的界面，但是前臺可以使用，也可以不使用，至少有服務提供的。成本的評價要放在整個公司來考慮，對中臺團隊肯定是增加了成本，但是相應的整體的成本因為共享就降下來了呀。
作為對客戶交付的產品，很多項目的招標書中提到了需要中臺的能力，做一些中臺服務，套一些中臺概念，的確是提升產品競爭力的方式的。
當然，如果這些團隊一開始就是我組建的，我的確無需搞中臺，我只需要統(tǒng)一技術路線，采用微服務架構就足夠了，其實我們現(xiàn)在對于共享服務也是這么做的。
還是你那句話：落地中臺，貴在其神，活用其行。中臺只是一種叫法而已！
什么中臺，不就是復用嗎，馬云天天炒概念，新零售也是。有句話說的好，“說人話”
是的，所以理解中臺精神，即使不談中臺，也能取得自己想要的結果。對于炒概念，也沒什么不對啊，商業(yè)上需要包裝才能更好推廣，這一點不得不佩服馬云?，F(xiàn)在看看很多項目的招標要求，很多把中臺寫了進去，不管它用途到底多大，至少套用概念，才更接近機會。所以，落地中臺，還是要領會精神為自己所用，達到自己目的就可以了。
忽悠的最高境界就是內行人都是信，外行傻子能不跟風
復用不一定需要中臺，中臺也不單純是復用
復用只是我簡單的一種說法，懂的人都懂
中臺無形勝有形，10年前在阿里做的平臺化和這個沒有本質區(qū)別，天天炒概念，研發(fā)成本不少反多；中臺的意義是解決合適效能，減少研發(fā)人員和成本，而非形式過場
非常認同，所以用中臺的思想解決企業(yè)內部的問題，而不要糾結于具體形式。既然中臺概念很火，用之更容易讓人理解，讓領導認同，讓客戶認可?，F(xiàn)在很多客戶的信息化項目都要求中臺化，如果我們解決方案里不靠攏中臺的概念，也不利于項目的開展。
國內需要做中臺的公司產品沒幾家吧？數據沒有上億級別的玩中臺就是拿**打小鳥
那是太在意中臺之形了，太參考大廠的中臺的樣子。中臺沒有嚴格標準，用中臺精神解決自身問題，豈不是更合理的做法呢？
還是比較同意作者的觀點，我們集團化的企業(yè)就是用中臺來解決的后臺數據不互通，業(yè)務不互聯(lián)的，功能重復開發(fā)的問題，中間遇到過很多困難，也走過彎路，但是目前來看效果還是比較不錯的