中臺，數字時代企業需要掌握的新技能
ThoughtWorks作爲一家有態度的技術公司，我們每年都會進行有態度的前沿技術解析，並以雷達的方式呈現當下技術領域的快照。3月15號我們在深圳舉辦了最新一期的“技術雷達峯會”，技術雷達委員會也全部聚齊在深圳，Martin.Fowler，Neal Ford這些技術江湖上的前輩在大會上進行了精彩的分享。
在雷達峯會上我也有幸分享了一個話題：中臺爲什麼這麼火。主要是基於我們在中臺上的實踐和研究，從市場競爭，企業管理，IT架構等多個視角來更深入的理解中臺，從而明確如何建設中臺。這篇文章是把我分享的內容給完整的寫出來，希望不論是聽過分享的還是沒有聽過的朋友，都能夠通過這篇文章瞭解我對中臺的分析論證和邏輯推演。
整個分享一共有四個部分：
- 中國特色的中臺，介紹爲什麼中臺這個概念是中國獨有的。
- 企業希望中臺解決什麼問題，介紹在數字時代企業面臨的問題是什麼，企業的陣型又會怎樣變化。
- 如何實現中臺，介紹如何圍繞着可重用的數字化服務來實現中臺。
- 中臺的技術選型，介紹有什麼省時省力的好方法幫助我們進行中臺技術選型。
1.中國特色的中臺
很多人以爲中颱這個概念是最近這幾年纔出現的一個新名字，其實在中國的古代唐朝就曾經使用過這個名字。在中國古代的政府組織中大家一定比較熟悉三省六部這個概念，三省是門下省，尚書省，中書省，六部是工部，刑部，兵部，禮部，戶部，吏部。其中最重要的是尚書省，這個機構是從漢代皇帝的祕書機關發展而來，然後逐漸發展壯大成爲整個政府的中樞。公元662年唐高宗李治下週宣佈機構改革，以門下省爲西臺，中書省爲東臺，將尚書省改爲中臺。
雖然唐朝的中臺和我們今天所說的中臺不是一回事，但根據古代中臺的作用，我倒覺得這給了我們一個理解中臺的新方向。不再只是因爲在技術上我們劃分出了前臺和後臺，所以把前臺和後臺中間的東西稱之爲中颱，能不能也和唐朝一樣成爲一個企業組織的中樞？
所以在給雷達委員會介紹中臺時，我沒有使用直接的英文翻譯：Middle-End或者Middle-Platform
，而是直接用拼音作爲中颱的英文名：Zhong Tai.
讓我們從唐朝回到現代，當今的中國，互聯網和數字化已經深入的滲透到了每個人的工作和生活當中。現在中國人每天出門之需要一個手機就夠了，吃飯的時候點餐可以掃一掃，要付錢的時候可以掃一掃，出行要騎自行車可以掃一掃，進出辦公室的大門可以掃一掃，基本上現在一箇中國人日常需要完成的大部分事情都可以通過手機完成。而對比西方，不論政府還是社會在接受數字化上都還相對保守，最近剛有一個新聞是費城立法要對無現金商店罰款2000美金。
在這樣一個大的數字化市場環境下，我們發現了一個有意思的現象：我們接觸到的很多中國企業都會提到一個相同的訴求：想要建設一箇中臺。而且提出這些訴求的客戶來自於各個行業，金融行業，通訊行業，汽車行業，電腦製造行業，家電製造行業，傳統零售，甚至有的企業專門準備了20億預算來建設中臺。但是當和這些企業深度討論的時候，又發現大家對中臺的理解又不太一致，有的企業以爲中颱就是類似於ERP，CRM的的系統，可以開箱即用；有的企業在糾結中臺應該有什麼，什麼可以放到中臺裏面，什麼不能放到中臺裏面；有的企業不清楚中臺應該如何和現有系統集成。
要回答這些問題，我覺得需要研究一下中臺的起源，以及這些年發生的和中臺有關的事件。2015年12月7日阿里巴巴宣佈進行業務升級和調整。阿里巴巴集團CEO張勇宣佈正式啓動2018年中臺戰略，打造“大中臺、小前臺” 的組織機制和業務機制，由樹狀管理變爲網狀管理，實現管理模式創新。同時，張勇還提拔了七位80後擔任更重要的職位，稱“讓集團更多優秀的年輕人承擔起更大的責任”。
但那時候市場上其他人都不明白中臺是什麼，更不明白阿里要幹什麼，所以市場上並沒有其他企業跟進。在兩年後，阿里在2017出了一本《企業IT架構轉型之道》，介紹了這兩年阿里在建設中臺時積累的經驗，同時市場也發現了阿里的變化，很多互聯網企業開始宣佈要構建中臺。滴滴在構建出行總檯，鵝廠進行組織架構調整，開始構建企業中臺，美團在構建數據中臺，京東直接在組織架構中使用中臺。
對於這些市場的變化我們有兩個疑惑：
- 爲什麼阿里，騰訊，京東在構建中臺的時候都要調整企業組織架構？
- 大家究竟是希望用中臺來解決企業的什麼問題呢？
2.企業希望中臺解決什麼問題
通過與很多互聯網公司朋友以及我們客戶的討論，他們的感受是數字化的滲透過程誕生了一批各個行業的顛覆者，顛覆者們利用新的數字化技術在很多企業還沒有反應過來的時候就快速地佔領了市場，然後很快他們又被更新的創新者挑戰，這讓大部分企業都處在深深的焦慮中，大家都擔心自己會被顛覆。而要想不被顛覆，就只能讓自己適應數字化浪潮，一方面要讓自己掌握新的數字化玩法，能夠有效地防禦住自己的優勢領域；另一方面還要能夠非常快速地集結資源進入某個創新領域進行嘗試，以前很多大公司會成立實驗室來進行這項工作。但在當今的中國，實驗室的研發週期對市場來說太慢了。而要滿足速度要求，就必須能夠重用企業的一些自有能力，還要能夠快速地集成一些企業的外部能力。
所以這個時代的企業需要的是數字化敏捷力，數字化敏捷力對企業來說主要是滿足兩個方面的訴求：
- 老業務全面數字化。讓企業目前還處在優勢的業務能力數字化，可以讓用戶通過各種數字化渠道來達到目標，可以整合外部資源構建數字化生態，還要能夠做到基於精準的運營數據對業務進行調整。
- 快速地重用成熟業務模式來嘗試新業務，新戰略。對於新業務，可以重用企業的某些能力，能夠基於一部分真實用戶快速嘗試新業務，還要能夠分享在嘗試新業務時獲得的經驗。
基於這兩點核心訴求，我們認爲中颱的定義應該是：企業級能力複用平臺。
- 企業級定義了中臺的Scope，中臺不同於單系統的服務化和微服務。
- 能力定義了中臺的主要承載對象，可以是業務能力，技術能力，數據能力，甚至是財務能力，人力資源管理能力。
- 複用定義了中臺的核心價值，傳統的IT系統對於複用沒有太多的關注，而中臺要求組織需要通過複用實現數字化敏捷力
- 平臺定義了中臺的主要形式，區別於傳統IT系統的煙囪式構建，通過對能力的更細粒度識別，實現企業能力的柔性複用。
下面讓我們用一個實際的例子看看傳統的企業IT系統架構有什麼問題，以及如何解決這些問題。這個例子是一個整車製造廠商，它原本有兩個系統，一個是對C端用戶的微信小程序，一個是對B端用戶的經銷商銷售管理，這兩個系統都是單獨構建的，還採購了獨立的服務器存放在企業的數據中心裏。現在企業需要啓動一個新車電商新業務，按照這種IT架構模式只能當作一個新系統全新構建，然後再通過API集成和數據庫集成等方式和現有系統進行集成。這樣的煙囪式IT系統架構在每一層都會有一個突出的問題：
- 對於用戶觸點前臺，由於每個應用都是獨立搭建硬件和軟件，所以發佈成本高，實現高可用困難
- 對於支撐前臺的API，基本上做不到IT資源的重用，所以很難快速的響應業務的變化需求
- 對於業務流程中產生的數據，必然會產生冗餘的數據，這將帶來高維護成本，並且難以從數據中獲取價值
- 最後是支撐煙囪式應用的數據中心，通常都需要自己維護服務器，機櫃，機房，甚至網絡，不僅需要高昂的硬件成本，而且很難具有彈性，靈活性也差。
數據中心的問題隨着現在雲技術的全面普及已經得到了很好的解決，當然使用雲的過程中可能會存在一些具體的細節問題，比如如何能夠把公有云和私有云組合起來使用，如果需要給AI計算提供支撐如何搭建雲基礎設施，如何搭建Serverless的雲基礎設施等等。但企業通過使用IaaS和PaaS已經可以解決數據中心的彈性問題，靈活性問題和運行成本問題。
然後採用DDD方法對每個系統的業務能力進行分析，可以發現這些系統提供的功能和數據其實都代表着企業的某種服務能力。並且如果我們站在企業的全局視角來審視這些服務能力，會很容易地發現不同系統之間存在服務能力重疊，比如新車電商，微信小程序和經銷商小時都需要相同的客戶服務，新車電商和經銷商銷售都需要新車庫存服務，新車訂單服務。如果把這些服務能力變成數字化服務，那麼也就不會存在數據冗餘，並可以提高IT資源的複用率，前端應用也不再是跟隨原來的單體應用架構進行部署，而是可以在應用層進行獨立部署，根據業務需要快速組合數字化服務提供的API來響應，還能夠通過應用和服務的多實例部署來很容易地實現高可用性。
前面是企業IT架構視角，讓我們從業務流程視角來看看會發生什麼改變。針對現有的微信小程序業務流程我們分析出3個業務流程節點A1，A2，A3，針對每個業務流程節點進行分析可以知道這個節點需要使用什麼能力來支撐，然後我們把這些能力轉化成可重用的數字化服務。當企業需要嘗試一個新的業務流程時，通過業務分析發現了新業務的流程節點B1，B2，B3，然後用相同的方法對這些流程節點進行分析可以知道這些新節點需要使用什麼能力，哪些能力是企業現有的數字化服務，哪些能力是需要新建或者從外部獲取的。那麼對於這些業務流程，這些數字化服務，企業應該如何進行管理呢？
基於數字化服務的企業陣型就開始轉變成了“大中臺，小前臺”的樣子，隨着越來越多的企業能力變成了數字化服務，如何管理好這些服務將會是企業面臨的新挑戰。比如如何評估數字化服務的價值，如何在不影響前臺業務的前提下對這些數字化服務進行拆分和合並，設計一個數字化服務需要注意什麼，如何提高研發數字化服務的效率，如何組織研發和運營數字化服務的資源，如何計算這些數字化服務的成本和收益等等各種問題。
所以我想需要研究一下管理思想體系，以及這些管理學派的創建背景，來看看有沒有什麼管理理論可以幫助我們管理這些數字化服務的。根據郭鹹綱老師的《西方管理思想史》一書，到目前爲止管理思想主要有三個重要階段：
- 第一階段稱爲古典管理理論，發起自1911年前後，那時候的世界在各種科學技術的推動下，工業有了非常迅猛的發展，但是這個發展過程並非順暢的，這期間遭受了5次世界性經濟危機的打擊。工人和資本家的矛盾越來越尖銳；壟斷型大企業開始出現，如何管理這些大型組織；如何快速地把農民轉換成高效率的工人。這三個主要問題隨着資本主義發展越來越突出，社會迫切需要一種管理理論來推動和維護社會發展。在這樣的大背景下，泰勒提出了科學管理理論來改善工人的操作；法約爾從企業活動出發，提出了組織管理理論，把企業活動分成了6大類：技術活動，商業活動，財務活動，安全活動，會計活動，管理活動；馬克思韋伯從集權組織視角出發，針對大型壟斷組織提出了行政集權組織理論。這些管理理論構築起了古典管理理論。
- 第二階段稱爲現代管理理論，從二戰到八十年代，這段時間由於二戰和之後的冷戰世界的科技發展更迅猛，美國的國勢與經濟水平都得到了大幅度的發展，企業所處的環境，生產經營方式以及社會資源的配置方式都發生了重大變化，企業面臨很多新情況和新問題，這些變化都需要新的管理理論。在這樣的大背景下，巴納德創立了社會系統學派，把企業當成一個社會系統研究人們的協作關係；西蒙發展出了決策理論學派，研究如何更好的進行企業決策；還有我們非常熟悉的彼得德魯克是經驗主義學派的掌門人，主張管理學就是研究管理的經驗，學習管理中的成功和失敗，就能解決管理中的問題；還有從企業經理的職務和工作來分析的經理角色學派。還有很多這個階段產生的管理理論無法一一列舉，但是可以看出隨着經濟飛速發展，企業管理的主要課題開始從如何提高組織內部效率轉向到組織如何適應環境，但是由於那個時代信息溝通的限制，大家的研究視角不同產生了很多看法和思路，從而形成了多種管理學派。
- 第三階段稱爲當代管理理論，從八十年代開始，八十年代以後世界經濟發生了結構性變化，美國的管理界認爲美國經濟正在衰落，原材料經濟和工業經濟脫鉤，原材料開始過剩，全球一體化讓國家需要根據世界經濟制定自己的經濟政策，市場競爭越來越激勵。在這樣的大背景下，波特從競爭戰略角度提出了競爭戰略學說；彼得聖吉從提升企業整體素質角度提出了學習型組織，企業要進行的五項修煉；戴明博士從質量管理角度提出了有名的戴明環；傑克韋爾奇利用六西格瑪理論締造了偉大的通用電氣。總的來說，當代管理理論呈現了五大趨勢，從過程管理向戰略管理轉變，從產品的市場管理向價值管理轉變，從行爲管理向文化管理轉變，人本管理思想更加深入，以不斷地創新追求經營績效的持續改善。
從上面的管理思想史可以發現，每一次當時代的浪潮來臨時，都會產生很多新的管理理論。在時代的浪潮中，有些人因爲發明了新東西稱爲了浪潮的受益者，有些人則是把新東西很好的利用到了某些領域也成爲了浪潮的受益者。說到蒸汽機，我相信很多人都知道瓦特，甚至有人還知道博爾頓，但估計很少人知道這位韋奇伍德。他利用蒸汽機技術，使得人類歷史上第一次出現某種產品供大於求的情況，這個產品就是中國引以爲傲的瓷器。現在Wedgwood這個品牌依然是瓷器界的奢侈品。
從八十年代到現在，時代的車輪不但沒有放緩，反而越來越快，尤其是從2007年喬布斯發佈iphone以後的世界又發生了巨大的變化，智能手機，人工智能，AR/VR，區塊鏈新技術層出不窮，從研發到產業化的轉化越來越快，個人的行爲方式，企業的協作方式也已經發生了很多變化。同時整個世界的勢力格局也在發生變換，中國作爲世界工廠上可以承接歐美的高科技設計，利用已經形成的供應鏈生態優勢生產出產品買回歐美；下可以利用中國的發展經驗，基礎設施建設經驗，把產品和能力輸出給更多的發展中國家。
所以根據前面分析的管理思想史，我認爲我們又站在了一個時代大變革的浪潮上，企業面臨的問題隨着時代又發生了變化，需要一些新的管理思想和指導實踐的管理方法，甚至新的管理技術。如果再只是把中臺看做是簡單的企業IT平臺架構，或者只是一個企業技術部門應該關注的東西，那麼就還沒有深刻認識到中臺對於企業的意義，中臺應該是是數字時代企業管理需要掌握的新技術。
可能有些人會覺得我這個觀點把中臺放的太高了，企業管理是一個非常複雜龐大的體系，有人覺得現有的管理思想，管理方法，以及一些管理技術對於管理一個企業來說已經夠用了，但能夠用一套邏輯一套思想解釋現在和未來所有一切事物的只有自大的宗教。也許未來有人給出了數字時代的新企業管理技術不一定叫中臺，但是對目前數字時代的大部分企業來說，需要一個把數字化技術融入到思想的管理方法。Gary Hamel在他的《The Future of Management》一書中提出：現在你們公司擁有嵌入21世紀互聯網技術的業務流程，使用20世紀中葉的管理流程，但這些都建立在19世紀的管理原則上。
3.如何實現中臺
前面用了不少篇幅來邏輯推演中臺的核心意義。下面來點乾貨，看看如果要構建一箇中臺管理好這些數字化服務，那麼已經改怎麼做？
最終有一堆的數字化服務在線上運營是我們的最終目標，所以要做到很好的運營需要有一套數字化服務運營規範來指導運營。
在運營數字化服務的時候，所有前臺應用都是通過數字請求的方式來獲取的服務的，所以對於企業來說需要具備強大的數字接入能力，根據ThoughtWorks之前的項目經驗，當說到數字接入能力的時候主要要考慮三個層次的問題：請求管理層，安全防護層，API治理層。另外對於這麼多的數字化服務，還需要具備服務治理能力。這兩塊的能力後面會有詳細的介紹。
然後往前推導，是如何把企業的某種能力轉變成數字化服務的呢？需要有一個數字化服務設計規範來指導我們把組織能力設計成服務，然後還需要一個數字化服務研發規範來指導我們把設計最終開發出來。數字化服務的研發和普通的軟件研發有些不同，單服務開發的依賴問題，各個環境部署的集成問題，已經研發中的項目管理問題都需要一個服務研發平臺來提供高效的研發支持。
最後這些數字化服務，數字接入能力，服務治理能力，服務研發平臺都需要建立在一套彈性的數字化基礎設施上。
既然中臺需要這麼多東西，那麼應該怎麼做才能一步步把中臺落地呢？
- 第一步是搭建數字化基礎設施，這是整個中臺的地基
- 然後需要導入數字化服務設計規範，基於DDD，Design Thinking這些方法論，通過一起協同的工作坊方式，讓團隊能夠設計出合理的數字化服務。
- 然後導入數字化服務研發規範，團隊根據研發規範知道如何開發出標準的數字化服務
- 在第三步的同時開始建設服務研發平臺，比如CI/CD流水線，服務設計管理，服務自動化測試等
- 當有的數字化服務研發接近完成的時候就可以開始建設數字接入能力了
- 同時也可以同步建設服務治理能力
- 最後隨着一個服務逐漸研發完成並上線運營，需要導入數字化服務運營規範，指導運營人員進行服務擴展，服務合併，並處理各種線上問題。
下面是ThoughtWorks獨家的服務服務化設計流程，一共分成四個階段：
- 首先是業務方案設計階段，這時候主要是進行高階的業務方案設計，使用商業模式畫布，精益畫布，價值主張畫布等方法分析並識別業務痛點，並給出業務方案和業務架構。
- 然後是產品/服務設計階段，這個階段要分成兩部分進行，一部分是從用戶視角出發進行用戶產品設計，一部分是從系統視角出發，進行服務發現。用戶產品設計會採用Design Thinking方法論，使用Inceptiong工作坊，根據業務方案進行針對性的用戶訪談，根據訪談結果建立用戶畫像，然後梳理用戶旅程地圖，根據用戶旅程進行產品功能設計，並對功能特性進行分類，最後產出產品ROADMAP。服務發現會採用DDD方法論，使用EventStorming工作坊，根據業務流程進行事件風暴，命令風暴，然後尋找領域聚合，探索限界上下文。
- 接下來是交付設計階段，所謂交付設計，就是爲交付做準備的設計。會從需求角度進行用戶故事拆分，設定用戶故事驗收標準，並進行RAIDs分析優先級。從架構設計角度，根據前面劃分的服務進行系統架構設計，外部系統集成設計，根據聚合的命令進行API設計。
- 由於有了交付設計的產出，所以最終進行服務迭代開發也很容易落地。在迭代開發階段採用敏捷和精益開發方法論，需要CI/CD，Devops，自動化測試等工具和實踐的支撐。
下面是在研發數字化服務時團隊需要遵循的規範，其中包含業務梳理規範，服務設計規範，可用性規範，系統集成規範，數據集成規範，應用管理規範。它們爲團隊提供工作方法與完成標準，包括微服務拆分、API接口設計、數據採集與管理、API調用與集成、雲化與容器化部署、性能、系統安全性。這些規範可基於企業已有的規範爲基礎，針對中臺的場景做一些適配。
數字化服務研發平臺需要分成兩部分考慮，一部分是基礎的軟件研發工具，比如代碼倉庫，項目構建工具，持續交付流水線，Devops管理平臺，以及用來管理項目計劃，任務，缺陷的敏捷項目管理平臺。另一部分是專門針對數字化服務的研發工具，比如服務需求管理平臺，服務設計管理平臺，服務契約管理平臺，服務測試平臺，服務架構守護平臺等等。
我們重點介紹一下數字化服務接入能力和服務治理能力，這兩個能力是服務上線運營的關鍵能力。
對於數字接入能力，前面說過主要要考慮三個層次：
- 請求管理層
- 請求預處理，某些業務場景需要針對請求進行一些預處理，比如根據請求的用戶ID來補充用戶基本信息
- 靜態路由，請求管理中最基礎的路由能力
- 灰度訪問，在發佈新功能時一個非常有用的能力
- 多租戶管理，主要是根據不同的租戶進行進行不同的請求處理能力
- 負載均衡，負載均衡其實是一種動態路由，也是請求管理層的重要能力
- 安全防護層
- 請求認證鑑權，確認請求的合法身份
- 權限控制，校驗請求能否訪問所需的資源
- 會話管理，管理請求的會話上下文
- 統一入口，給請求提供統一的入口
- 請求限流，當發生非正常情況時能夠對請求進行限流處理
- API治理層
- API定義，以標準化的格式定義API，讓使用者方便地查找API
- API測試，幫助API使用者在開發接階段進行調試
- API發佈，如何無破壞地發佈或更新API的能力
- API可視/性能，記錄並統計API的性能，監控API的狀態
- API鏈路監控，能夠跟蹤每一次請求的API鏈路
對於服務治理能力，可以參見我的一個文章《當我們在說微服務治理的時候究竟在說什麼》，在那篇文章中我對市面上常見的服務治理相關工具進行了一次系統分析，通過類比城市交通治理我發現，雖然有很多服務治理的框架和工具可供選擇，但是這些工具核心處理的問題一共就4類：網關就是整個整體的守門人日誌採集，這一塊的能力由請求接入能力負責。追蹤工具，服務註冊發現都是用來採集信息的，然後需要監控平臺來展現這些採集的信息，並進行監控和分析。最後根據分析的結果採取治理策略，有的服務快撐不住了要限流，有的服務壞了要熔斷，並且還能夠及時的調整這些服務的配置。
對於中臺架構中的每一塊內容，由於演講的時間限制，所以不可能完全展開了進行深度講解。否則每一塊的具體落地細節都足夠講上一天的。這裏主要想給出一個實現中臺的整體框架，框架中的每一個組成部分都不是隨便拍出來的，而是採用邏輯推演的方式得出。相信隨着大家在中臺領域進行不斷深入的實踐，一定會發現一些新的能力和平臺需要補充的這個框架中來。也歡迎大家隨時和交流建設中臺的經驗和心得，讓我們一起來完善這個數字時代的企業管理新技術。
4.Last but not least：中臺的技術選型
在實現中臺的框架中，不論是各種規範，還是需要的數字能力和數字化服務研發平臺，在具體落地時都會面臨技術選型問題。在進行中臺的技術選型時，參考技術雷達對相關技術條目的成熟度評估，能夠規避一定的風險、進而節省成本。下面是一些例子：
- 19期的Event Storming，就是數字化服務設計規範中可以選用的成熟技術。
- 19期的Four Key Metrics，指的是軟件交付性能的四個關鍵指標(FOUR KEY METRICS):前置時間，部署頻率，平均恢復時間(MTTR)和 變更失敗百分比。可以用在數字化服務研發規範中。
- 19期的ARCHUNIT，這是一個通過源代碼來分析架構，並採用單元測試方式校驗架構是否滿足期望的工具。可以它來構建服務研發平臺中的架構守護平臺
- 19期的LocalStack，使用雲服務時面對的一個挑戰是如何在本地進行開發和 測試。LOCALSTACK 爲 AWS 解決了這個問題。可以是服務研發平臺的一個有用工具。
- 18期的Jupyter，除了將JUPYTER作爲一個分析工具，開發者們還在嘗試一些創新的用法，比如將Jupyter用於自動化測試。新用法可以用在服務研發平臺的服務測試平臺上。
- 18期的Kong, 這是一個成熟的商業框架，它可以滿足大部分的數字接入能力。
- 18期的GraphQL，很多個微服務對於前臺應用來說是痛苦的，因爲它需要請求多個API才能獲取到完整的數據，通過使用GraphQL構建一個輕量的BFF層，就可以容易的解決這個問題，前臺只需要通過一次API調用就能夠獲取它需要的所有數據。
以上就是我在雷達峯會上分享的全部內容，如果你對上面的內容有任何問題，歡迎留下你的評論。