什麼樣的企業需要中台？

2019 年 12 月 18 日
筆記

這兩年在IT圈裡面最火的一個概念就是中台了，有很多人，很多企業寫了很多文章，做了很多分享，甚至還開發了很多課程在講中台這個話題。但大部分的討論都是在回答What，Why和How的，也就是中台是什麼，為什麼建中台以及如何建中台。

我是ThoughtWorks中台解決方案的負責人，所以過去這兩年也沒少去跑客戶做售前，去現場回答一下What，Why和How這三個問題。通過和這些客戶的溝通，我發現不同的客戶其實對這些問題理解都不完全一樣。

有個客戶的技術部就大幾百號人，為了做中台專門抽了一些精兵強將出來做中台，結果花了1年時間中台開發出來了，但是一線業務根本不願意用。
有個客戶的技術部一共就幾個人，沒有一個開發，系統都是採購過來，然後找我們說要中台，最好能夠採購一個。
還有一個客戶是技術部門的一把手，由於要支撐業務運行，所以想盡辦法擠了一些資源出來準備做中台的規劃和設計，結果剛開始做規劃，業務部門就跳出來列舉了「中台十宗罪」，說技術部門現在連業務都還沒有完全支撐好，還抽調資源去搞什麼中台。

這些場景中的客戶很明顯都對三個問題有自己的看法，我相信很多人也會由於處在不同的行業，不同的公司，不同的職位，而對中台有自己獨特的理解，一千個人有一千個中台。所以這時候我發現有一個中台的問題並沒有人提出，那就是Who的問題，什麼樣的企業需要中台？所以我覺得雖然現在業界內雖然已經有了很多關於中台是什麼，為什麼要中台以及中台怎麼建設的很多理論和實戰經驗，但是如果我們連對需要中台的企業深入的研究和分析，那麼如何保證我們設計並建設的中台是真正能夠幫助到這些企業的呢？要研究需要中台的企業，就需要弄清楚兩個問題：

一個是這些企業處在什麼市場環境下，或者說處在什麼時代中，比如我們稱今天這個時代為數字時代或者智慧時代。
一個是這些企業在市場上是如何劃分的，他們在市場上處在什麼樣的位置，不同位置的企業有什麼不同的訴求。

數字時代的企業劃分

今天我們對於數字時代這個概念已經非常熟悉了，現在不論是媒體還是企業高層動不動張嘴閉嘴都是數字化，很多傳統企業公司甚至為此專門成立了數字化相關部門，有的名字很高大上，叫數字化戰略規劃部，數字化辦公室，還有了一個新職位Chief Digital Officer。那麼究竟什麼是數字化呢，什麼又是數字時代呢？如果把我們現在使用的互聯網技術，通訊技術，大數據技術等等看作是數字時代的特徵，那麼應用這些技術最後不都是實現一個資訊系統嗎，為什麼不繼續使用我們已經熟悉的資訊化？數字化和資訊化這兩個詞究竟有沒有區別？數字化是不是只是一個酷炫的的新詞？

這些問題是我們公司內部討論時，或在客戶現場時經常出現的問題。而且經常討論了半天發現還是找不出來數字化和資訊化的明顯差異。在研究這個問題的過程中，我又重新研究了香農的《資訊理論》，香農對於資訊的定義是：能夠減少不確定性的東西。 我發現在這個定義中並沒有說明是給誰減少不確定性的，比如人類和猩猩在夜晚都可以看到同一片星空，能夠看到恆星的運行軌跡，但是人類可以通過觀察找到規律，減少天體運行的不確定性，而相同的星空並沒有減少猩猩對於天體運行的不確定性。因此，需要有一個主體來識別資訊。基於這點，我們就可以區分出資訊化和數字化的差異了：

在資訊化的過程中，需要由人來識別出什麼是資訊，然後再採用電腦相關技術來對資訊進行記錄和處理。比如我們要資訊化一個採購工作，是不是要先識別在採購的時候採購單里都包含什麼欄位，然後再設計軟體系統去記錄這個採購單並進行後續的傳遞，審批等相關工作。
在數字化的過程中，由於各種數字化轉換技術可以把文字，聲音，照片，影片，甚至行動軌跡轉換成數字，因此就可以做到不需要人來提前識別什麼是資訊了。還是剛才的採購工作，數字化的過程就不再是先識別採購單里有什麼資訊了，而是用數字化技術記錄一個採購員的日常工作，見了誰，說了什麼話，使用了什麼文件，最後是怎麼確認採購完成的。然後再從這些數字化記錄中提取出重要的資訊，根據這些資訊自動創建採購單並完成後續的傳遞，審批等相關工作。

弄清楚了數字化和資訊化的差異，我們也就能夠理解數字化對於商業模式帶來的改變，企業需要在自己的商業場景中儘可能的加入數字採集能力來獲取數據，然後根據數據進行分析識別發現價值，最後可以根據發現的價值快速地調整業務形成閉環。很明顯不是所有的企業都能具備上述的這種完整的閉環能力，所以我們需要看看一個市場中企業是如何劃分的，他們的目標是什麼，又需要具備什麼能力。

梁寧老師在《增長思維30講》裡面把企業劃分成了四類：

草莽玩家：看到一個機會就往裡面沖，速生速死，主要目標是要找到破局點，鎖定資源。所以這類玩家需要開箱即用的數字化能力，不要研發，不要等待，拿來就能用在當前業務上。

腰部玩家：找准生態位並主動投入，主要目標是構建價值增量從而紮根行業，但生態位受生態體系格局影響大。這類玩家已經不滿足開箱即用了，需要有一些針對自己業務的訂製，但是對成本比較敏感，所以需要具備可訂製低成本的數字化能力。

頭部玩家：能夠調動巨量資源，搶佔制高點，主要目標終結一場戰爭，成為市場的霸主。這類玩家由於要終結戰爭，所以對速度要求很高，而且會面對海量用戶，所以需要具備速度快高可用的數字化能力。

頂級玩家：主要目標是跨越大周期，能夠持續做出正確的決定。很明顯這類玩家必須具備強大的學習能力，並且還擁有強大的骨架來反脆弱，所以需要具備學習型反脆弱的數字化能力，能夠根據海量的數據來尋找下一個大周期。

在介紹幾類玩家的時候都提到了數字化能力，那麼對於一個企業究竟什麼是數字化能力呢？在我看來，數字化能力就是基於數字化技術進行業務創新，設計合理的企業架構支撐業務並快速落地交付實現業務的能力。

在找到我們希望進行數字化轉型的企業中，大家的問題都逃不出這三個點：

有的企業是業務方不知道如何進行數字化創新，要麼想法太魔幻，要麼體驗太過時，因此業務部門和開發部門經常打架。
有的是給出了業務需求不知道如何做企業架構設計，很多問題最後都是開發團隊的架構設計不合理。
有的是開發團隊天天加班還是被說研發速度慢，而且上線後經常出現問題。

在這三個問題中中我們發現企業架構設計是最關鍵的重災區，因為它是兩頭的橋樑，好的架構設計可以清晰的說清楚業務問題，可以讓開發團隊很好的理解設計意圖並迅速完成開發支撐業務。所以下面先看看什麼是企業架構設計的正確姿勢，企業架構設計和中台的關係又是什麼樣的，由於不同的企業對企業架構設計的要求不一樣，因此就能夠推演出什麼樣的企業需要中台。

企業架構設計

談到企業架構設計，首先要弄清楚的一個問題是：對於架構設計這個工作來說，究竟什麼才是架構？在建築行業和軟體工程行業都有架構師這個崗位，但是他們的工作場景又看似完全不同，在這兩個究竟是在架構什麼呢？

這個問題困擾了我很久，最終在《系統之美》《複雜》這兩本書里找到了一個合理的解釋，在我們建設一個房子或者一個企業軟體時，雖然一個在物理世界一個在電腦世界的，所面對的都是各自世界的複雜系統。所謂系統，就是由一堆元素和連接關係構建起來的一個整體結構。比如在國家這個系統中政府，企業，個人都是這個系統中的要素，這些要素和他們之間紛繁複雜的連接關係一起構建成了國家這個複雜系統。當我們想要改變一個複雜系統時，系統通過改變要素的特性來改變系統是很困難的，一方面是很多要素難以改變，一方面是由於系統自身的一些特性會讓被改變的元素又變回原來的樣子。因此，先要改變一個系統的唯一辦法只能是改變系統內要素的連接關係，或者引入新的連接關係和新的要素。順這個這個思路，所謂的架構設計，本質就是通過改變一個複雜系統的要素之間連接結構來讓系統更優的生存。

弄清楚架構設計的本質，再看看具體在企業架構領域是如果通過改變系統內要素之間的連接關係來讓系統更優。簡要回溯一下企業架構設計的歷史，發現有三個關鍵的節點：

1987年，John Zachman 創立了全球第一個企業架構理論，其論文《資訊系統架構框架》至今仍被業界認為是企業架構設計方面最權威理論。是其他企業架構框架的源泉。Zachman框架的本質是分類學，通過二維表提問的方式對齊企業資訊。
1996年，美國國防部的US Undersecretary of Defense for Business Transformation工作小組推出C4ISR AF 1.0，C4ISR（Command, Control, Communications,Computers, Intelligence, Surveillance and Reconnaissance）是軍事術語，意為自動化指揮系統。這是DoDAF（Department of Defense Architecture Framework）的前身，2003年8月正式推出DoDAF 1.0，2009年推出DoDAF 2.0，DoDAF 2.0大體上可由八大視圖與實施方法論組成
1995年，國際標準權威組織The Open Group發表了TOGAF（The Open Group Architecture Framework）框架，TOGAF的基礎是美國國防部的資訊管理技術架構，其中最有名且當下使用最廣泛的為TOGAF，號稱福布斯80%的50強都在被HP、IBM、SAP使用。我們現在經常說的業務架構，應用架構，資訊架構，技術架構也都是源自這個框架。

雖然這些架構框架都有不相同的地方，但是我們能夠發現這些框架的共性：框架設計者希望能夠從不同的視角去剖析一個組織（企業，軍隊）的資訊系統架構。所以用現在大家最廣泛使用的TOGAF框架來說，這些業務架構，應用架構，數據架構，技術架構其實就是不同的視角。在不同的視角下，系統呈現出來的要素和連接關係都會有所不同，因此不同視角呈現的結構也會有關聯和支撐。

在架構師的日常工作中，架構設計最終的呈現方式通常都是一個架構設計圖。之所以採用圖的方式就是因為在描述一個系統的元素和連接關係時如果採用線性的文字方式進行描述會很難描述清楚。所以架構設計圖的本質是一種高效傳遞複雜系統結構的資訊傳遞方式。基於這點，一個架構設計圖中最重要的兩個點就是：這個資訊是要傳遞給那些人的，他需要用這些資訊來繼續做什麼？

還是用常見的TOGAF的4A架構來說，

業務架構Business Architecture只是從一個企業的業務視角來去分析有哪些業務元素還有元素之間的連接關係，但是由於企業內外不同的人會關注業務的不同方面，所以完整的業務架構需要針對不同的資訊接受方來組織資訊。 +應用架構Application Architecture在中文語言里的全程應該是應用系統架構，AA需要根據業務架構設計出支撐業務架構的應用系統有哪些，
資訊架構Information Architecture原本的初衷是描述應用系統裡面的資訊模型，資訊模型的關聯關係，以及這些資訊模型是怎麼傳遞的，也就是我們常說的資料庫的設計，之所以從AA中獨立出來是因為資料庫被發明出來了以後，基於關係資料庫，資訊模型越來越複雜，所以需要單獨設計。但是隨著這些年DDD越來越流行，而且各種ORM框架越來越成熟，所以使用DDD方法來設計的時候可以同時獲得AA和IA。
技術架構Technical Architecture的最重要作用就是告知開發團隊設計的AA和IA應該如何落地，具體到有使用什麼硬體，作業系統，軟體，網路如何設計，系統如何部署，如何通訊等等這些和落地相關的細節都是技術架構應該傳遞的資訊。

基於上面的邏輯，我們可以看看中台，DDD，微服務這些火熱的概念都是在解決哪個層面的問題了。 1. 首先說中台，由於中台是企業級能力復用平台，所以中台一般不會對企業的業務架構產生改變，你看阿里搞了中台以後並沒有改變天貓，淘寶，菜鳥這些BU的業務，而是通過業務的橫向分析，找到了可以復用的企業能力，重新設計了支撐企業業務的應用系統，所以中台設計更多的是企業應用系統架構層面的設計，只是相比過去，應用系統設計需要從企業級視角出發，而不是只考慮某個BU就夠了。2. 再說DDD，DDD雖然會從領域（也就是業務）視角進行設計，但是很難用DDD設計新的業務模式，所以DDD是一種根據業務進行分析然後設計出和業務很好匹配的應用系統，一般來說限界上下文就是一個應用系統或者業務模組，由於DDD裡面沒有應用系統落地實現細節，所以也不涉及技術架構的內容。3. 到了微服務設計基本就和落地相關了，所以微服務設計回答的是技術架構的問題。當然應用系統落地除了微服務也有大單體，SOA等其他方式。只是現在由於雲計算基礎設施，微服務技術支撐技術越來越成熟，採用微服務架構設計的技術架構能夠給讓企業在設計應用架構時粒度可以更細，這樣就可以更快的支撐業務架構的變化。