【轉帖】作中臺找死，不作中臺等死？

作中臺找死，不作中臺等死？

http://developer.51cto.com/art/201911/605254.htm

 

今年參加了雲棲大會，做爲中颱的踐行者，我也更關注中臺架構實施的行業情況，學習了其餘公司中臺的思想和經驗。

圖片來自 Pexels

雲棲大會上，我和作中臺實踐的同窗，以及在阿里作中臺的朋友進行了深刻的交流和探討，對作中臺過程當中遇到的比較糾結的問題進行了思考和總結。

在探討中臺哪些讓人糾結不定煩心事以前，咱們依然要談談咱們爲何要作中臺(注：本文中臺侷限於企業 IT 架構的中臺，非廣義上的中臺)，作中臺到底給我帶來哪些好處，想不清楚這些就去深刻到中臺的細節裏也無心義。

中臺概念這幾年特別火，就像 90 年代不作 ERP 是等死同樣，如今作不作中臺也好像能定企業生死同樣，弄得你們都在搞中臺。

可是不是全部的企業都適合作中臺，只有符合如下條件的企業，纔有實施中臺的必要，切莫亂搞。

企業適合作中臺的條件

因此，若是您是創業團隊，或者業務線比較單一，建議不要盲目嘗試中臺架構，不然將拖累你業務發展的速度 。

另外，咱們也要清晰的知道實施中臺的目的，以及中臺會給企業帶來的價值，沒有實際利益的推進中臺就很難落地，或者有形而無神。

中臺的價值

明確了中臺的應用場景和價值體現，咱們開始實施中臺架構的落地。我從今年上半年開始推進中臺這件事差很少有幾個月的時間，在這個過程當中也是摸着石頭過河。

雖然有不少中臺的理論知識能夠學習，可是實際的過程當中發現，中臺的落地是一件很是難的事情，它沒有標準，認識也不統一，在一些關鍵環節存在很多分歧。

正好這次在雲棲大會約了幾個實踐中臺的朋友進行了深刻的探討，把討論的內容進行總結，但願中臺的建設少一些糾結，多一分信心。

中臺定義：思想 VS 工具

什麼是中臺?每一個人可能有不一樣的理解，行業裏也沒有嚴格的定義，但我更認同其中一個說法就是：中臺是企業級能力複用的平臺。

如何來解釋這句話呢?

中臺的定義

既然核心是能力複用，業務流派認爲中颱實際上是一套思想，只要可以實現能力的複用，知足降本增效的企業目標，採起的全部措施，和一切可複用的能力都是中臺的範疇，因此中臺是一種組織方式。

而技術流派的人則認爲，既然是能力複用的平臺，就必定要有支撐複用的工具，就必須定義一套技術規範來支持複用，中臺必定要有基礎平臺來支撐的。

中臺首先要統一思想，圍繞能力的複用進行組織管理，將能力組件化，以下圖最底層部分。

同時，中臺之上咱們要構建能快速落地的技術平臺(如圖中 OECP 部分)，經過 Low code 的平臺能力，實現組件的組裝和流程的設計，快速的構建應用。

技術平臺是業務無關性的，但業務中臺必定是業務相關性的，只要把業務和技術有機的組合起來，把企業的能力沉澱並複用起來，這就有了中臺的基礎。

中臺之上集成開發能力

複用粒度：粗粒度 VS 細粒度

複用是中臺建設的核心，是一切的基礎，沒有複用的意識導向，中臺就變成了自娛自樂的遊戲。

也許不少人會說，沒有中臺以前複用無處不在啊，咱們寫程序複用代碼，作方案複用案例，爲何必定要建設中臺呢?

首先，再次重申下中臺的複用範圍是「企業級」，它既不侷限於技術同窗內的程序複用，也不侷限於一個團隊內部的複用，而是站在企業最高的視角，做用於整個企業的 IT 架構;其次是「能力的複用」，能力的範圍更加寬泛。

和阿里的朋友談到複用時，咱們也提到了複用的級別，像阿里雲其實就是在基礎設施這個級別上的複用。

我本身把複用的級別抽象成下圖所示的 5 層：

複用的級別

級別越低，粒度越小，複用的範圍越廣，但價值體現較低;級別越高，粒度越大，複用的價值越高，但複用範圍也比較侷限。

因此站在業務和價值角度上，都是先從最高的層次上去複用。只有上層沒法實現複用，咱們纔會逐步向下層去尋找。

可是有時候站在技術角度，咱們習慣在低層次上去複用，由於這裏最接近本身的工做，粒度越小，技術上越可控。

但不論怎樣只要咱們能把這些能力很好的組織管理起來並實現複用，就是中臺的思惟。

具體到中臺落地的 IT 架構，微服務基礎架構是目前最流行的方式，由於單純程序代碼的複用價值有限，而傳統單體應用的複用又極其的不靈活，而基於微服務架構的業務組件的複用則處在中間層級，靈活性和複用度比較平衡。

組件複用的核心思想是領域驅動設計(DDD)，而我認爲 DDD 最大難點是粒度的控制，粒度太粗不靈活、複用性差，粒度太細雖然複用性好，但耦合較大，運維成本較高。

Gartner 對服務粒度劃分

Gartner 在研究報告裏提出了宏服務、小服務和微服務的粒度劃分：

• 宏服務：一種傳統的 Web 服務，支持將功能封裝於單體應用內。宏服務不支持獨立部署或擴展， 它們只能部署爲單體應用的一部分，並且它們不須要微服務基礎架構。
• 小服務：就服務粒度範圍而言，小服務是一種粗粒度、鬆散耦合、支持獨立部署的應用組件。小服務須要微服務基礎架構。
• 微服務：微服務處於粒度範圍的遠端，是一種可獨立部署的組件，可以支持單個應用功能的實施。微服務可直接部署到微服務運行時環境中，也每每具有專用數據存儲區。微服務須要微服務基礎架構。

我本人很是喜歡 Gartner 的劃分方式，基於這三種服務的粒度，我也談談我對粒度把握的一些思路。

若是咱們想對已存在系統的能力進行復用，能夠採用宏服務模式進行，宏服務的模式適合作系統的集成和治理。

咱們對於新的業務和項目，剛開始建議採用小服務的方式進行業務領域的拆分，不建議拆分的過細，這個小服務能知足該需求的基本抽象便可。

從適中的粒度開始，服務的粒度必定是業務推動的過程當中不斷演化的，創新業務推進服務的粒度向更細的粒度裂變，而業務成熟穩定後，又推進服務向粗粒度方向聚合。

流程支持：服務編排 VS SOP

實踐證實，業務能力輸出的內容主要是核心業務數據和業務流程。而在我上面定義的複用級別上，業務流程的複用處在 LV4，也是比較高階的複用能力。

雲棲大會的朋友聚會上，我一個實踐中臺的同窗談到中臺服務如何更加靈活的支撐前臺時談到服務的編排。

他們的作法是給前臺同事提供了一套服務編排的工具，而後發佈一系列的原子性的服務，由各前臺團隊按照本身流程去編排適合本身的邏輯流程。

我不反對服務編排，並且在 SOA 和微服務的架構下，服務編排是必不可少的能力。可是我不承認給前臺提供編排工具，而中臺只提供原子性服務。

由於咱們在中臺的建設中，一直說起的是中臺必定是業務相關性的，中臺輸出的不只僅是工具，更要深刻到具體的業務場景中，提供業務流程的優秀實踐。

阿里的朋友在討論這個問題時提到了 SOP(Standard Operation Procedure)的概念，他認爲最好的作法是提供一套標準化的流程+預留可動態注入的擴展點的方式來對前臺提供。

好比淘寶和天貓在業務上能夠共享一套 SOP，在這套 SOP 的擴展點上各自注入本身不一樣的規則，從而知足本身的需求。

從中臺的複用範圍來看，我特別認同這種方式，由於中臺只有提供 SOP，纔是真正的實現業務流程這種高階的複用(就像國外 ERP 宣揚的那樣，你購買的不僅是一套系統，還有企業管理到優秀實踐)。

固然若是要作到 SOP 的定義，中臺團隊必須有既精通業務又熟悉技術的人，咱們俗稱「業務架構師」，不過水平高的人實在可遇不可求啊。從這點我也理解把工具開放給前臺本身作服務編排的同窗了。

雖然我一直在強調中臺要深刻業務，要提煉 SOP，但中臺又不能過分參與業務，不能由於中臺掣肘了業務的敏捷性。

中臺提供的能力要具備靈活性和可定製性，便於業務方根據規範自主完成，減小溝通成本，提高效率。

因此服務編排做爲工具仍是須要提供，前期經過工具快速嘗試探索合適的業務流程，後期經過業務的優秀實踐造成 SOP。

服務編排快速創新，SOP 穩定複用

前後順序：先業務中臺 VS 先數據中臺

雖然各類中臺不少，可是真正和業務保持密切協同的是業務中臺和數據中臺，阿里巴巴的中臺核心也是這雙中臺驅動的，這裏面體現的核心就是一切業務數據化，一切數據業務化，業務產生數據，數據又賦能業務。

業務中臺和數據中臺雙驅動

在和某 Gartner 分析師交流的時候，他的觀點是先有業務中臺，再有數據中臺。

雖然咱們也是從業務中臺開始，但我我的並非特別承認這個觀點的，我更承認的是先業務後數據，可是對於哪一個中臺先開始，徹底要看各企業的自身狀況。

若是企業當前最迫切的訴求是避免重複造輪子，提高 IT 生產力，數據基礎相對較好或者數據量級不夠，建議業務中臺先行。

若是企業當前最迫切的訴求是系統繁多但孤島嚴重急須要打通，企業已經存在大量的數據急須要在業務上發揮價值，建議數據中臺先行。

具備自主技術研發團隊特色的科技企業更適合先業務中臺，而自主開發能力較弱，應用系統更多依賴第三方外採的偏傳統企業，可能更適合數據中臺先行。

中臺團隊：委員會 VS 許願池

中臺的建設是一把手工程，沒有自上而下的推進，中臺是很難落地的。因此中臺變革的第一步就是組織架構的調整，須要創建一箇中臺團隊來負責組織、協調和建設。

中臺組織的創建

如何對中臺團隊定位也是一個難題，在我所見所經歷的中臺組織中，常常出現兩種形態：

第一種是委員會。中臺團隊是由各業務線選派的同事組成的虛擬組織，其中大部分都是領導，更多的承擔組織、協調的角色，具體執行工做分散在原有的各個部門裏，這種可稱爲委員會似的中臺。

由於各部門的領導組成，相互之間增強了信息共享，也逐步有了複用的意識，但在企業 IT 建設這個環節，由於沒有具體的專一於共享業務的執行團隊，協做成本會增高、實際產出可能比較務虛，看着熱鬧，其實很難體現複用的價值。

第二種是許願池。中臺只是普通的共享研發部門，前臺直接把需求丟到這個許願池裏，而後期盼着中臺提供一個現成的組件、服務，中臺成了爲前臺打工的了。

累不用說還不討好，阿里早期的共享業務事業部估計就是這種窘境，沒有業務話語權。

中臺團隊既不該該是委員會也不應是許願池，中臺不只能組織、能引領，又必需要有實際的產出。

中臺須要前臺滋養，前臺更須要中臺賦能，中臺團隊只有成爲具備核心話語權的實體團隊，企業能力的複用才能最大化的發揮出來。

因此阿里巴巴讓其 CTO 行癲張建峯掛帥推動中臺戰略，纔有了今天阿里中臺的影響力。

中臺和前臺要相互賦能

其實中臺建設過程當中碰到的問題遠不止這些，須要咱們在實踐中去探索正確的解題方法。

中臺成功的行爲準則和行動綱領

最後引用《中臺戰略》書中的內容結束本文，但願踐行中臺的同仁都能馬到成功。

參考資料：

《中臺戰略：中臺建設及數字商業》 陳新宇等 機械工業出版社

《MASA 架構》 Gartner 分析報告

做者：譚明智

簡介：經歷技術、產品、運營等多個領域，如今負責百洋智能科技產品研發。喜歡並擅長作 IT 架構和產品架構，微信公衆號：菜根亂譚，歡迎關注，聊產品，聊技術。