直接講觀點，我認為「中臺」 概念沒有反應這件事情的本質，我希望把它命名為「指揮官體系」。企業需要的是指揮官體系，大家熱議的中颱的本質對於企業而言真正需要的其實是指揮官體系。從今天開始，忘記「中臺」， 記住「指揮官體系」這五個字。
2023年在it圈裡對於中颱的討論絕對是最熱的話題之一。 對於各個企業來說， 看著別人討論的中颱那麼好，到底是什麼？自己要不要做？ 是否適合自己？對自己的價值是什麼？有沒有風險？這些問題彙總在一起， 對於各個企業的cio/cto來說，形成了不小的困擾。以下內容不針對任何公司、任何人，請勿對號入座。
希望本篇短文回答以下最關鍵的三個問題。
什麼是中颱；
中臺是否適合自己，如何決策；
建設節奏。
開始正文以前，看乙個網上的搞笑故事就知道中颱的建設現狀了。
這個故事背後隱含的是大家對於中颱的理解眾說紛紜， 甚至乙個大雜燴都包在一起， 就叫做中颱了，我總結為一花一世界， 一人一中臺，。我做的下面這張ppt可以概略了解中颱的幾種提法以及相關的幾個出處。
言歸正傳， 下面直奔主題， 簡單直接回答這三個問題。
中颱是企業的作戰指揮體系，中颱是企業的「指揮官體系」。
中颱是怎麼熱起來的，是企業在遇到大環境變差、競爭激烈並且希望有新技術幫助自己贏得市場的背景下提出的。大家看到很多文章都說我們現在處在乙個vuca時代，vuca是指組織將處於"不穩定"(volatile)、「不確定」(uncertain)、「複雜」(complex)、和"模糊"(ambiguous)狀態之中。
而vuca的概念最早就是美軍在20世紀90年代，引用來描述冷戰結束後的越發不穩定的、不確定的、複雜、模稜兩可和多邊的世界。在2023年9月11日恐怖襲擊發生之後，這一概念和首字母縮寫才真正被確定。隨後，「vuca」被戰略性商業領袖用來描述已成為「新常態」的、混亂的和快速變化的商業環境。
基於中臺概念提出時面對的的vuca環境， 首先我這裡要把從技術、架構的角度定義的中颱要徹底排除出去。 為什麼要這樣？ 取決於你用中颱幹什麼： 是要乙個架構？技術？還是要企業的成功？ 我的回答很明確： 是助力企業的成功，就是在vuca時代贏得市場。
在中國，從架構技術落實中颱的第乙個公司是蘇寧。當年蘇寧建設中颱的出發點是解決後端的sap、前端的wcs效能差，不能很好支援業務快速發展的問題，目標明確。在這個目的驅動下，將功能從sap、wcs中解耦出來，同時在建設過程中考慮了融合線上線下的架構、服務的重用。
蘇寧從12年開始啟動中臺建設，13年上半年就初步建設完成，這一過程投入巨大。中國有這種決心的企業並不多，或者有這決心也沒有這資金實力。這個建設成功的中颱有什麼作用呢？舉乙個例子：在2023年阿里蘇寧相互入股，蘇寧中臺系統接入天貓的過程只用了7個工作日。 當時蘇寧中臺研發中心的小夥伴們連續工作7天，就完成了對接天貓的工作，。 從這裡可以看出中颱在架構、技術方面的價值。大家如果感興趣，可以參考我在16年在qcon分享的文章： 傳統企業如何轉型網際網路？蘇寧六年技術架構的演進總結
所以中颱要建設成為乙個面向市場競爭，連線、協同企業內部能力的作戰指揮體系，也就是指揮官體系，從而幫助企業快速響應市場變化，贏得市場。大家如果關心，可以了解一下美軍的c4isr系統（
指揮官體系的核心能力包含兩點：
由使用者體驗驅動內部運營管理不斷完善；
由資料驅動內部運營管理不斷完善。
在這種指揮官體系的管理下，企業會越來越體現出這兩個特點：協同、進化。
在明確定義了中颱是什麼之後，我們進入下乙個問題。
首先中颱是用來開源的，不是用來節流的，所有出於省錢目的的需求都不應該建設中臺。對比美軍的c4isr系統，它的目的是打贏戰爭，不是節省成本。以開源為目的，我的觀點是：企業到了一定規模，還是要投資未來、建設中颱的，但不需要一上來就從架構視角去整合服務。而且，對於大多數公司來說，是一定不能這樣，因為這不是建設中颱的根本目的。
a：不一定。中臺建設的目的是從業務視角出發，建設能夠快速響應市場的指揮官體系。如果從架構視角出發的消除煙囪和上面的目標匹配， 就可以做；如果不匹配，就不需要做。
q：中颱能完全交給乙方做嗎？
a: 不能。你聽說過雇傭軍主導乙個帝國戰役的嗎？中臺建設注定是甲方主導的。甲方自己沒有想清楚，千萬別啟動，否則就是勞民傷財。具體的平台和工具可以交給乙方公司做，前提是適合自己的公司。美軍也沒有什麼都自己建設，照樣全世界打勝仗。
建設的節奏是至關重要的決策，節奏對了中颱就是助力企業發展、讓企業上乙個台階的平台；不對，就是把企業拉下水的大坑。
上面提到了，中颱是企業的指揮官體系，這是乙個由使用者體驗和資料來驅動內部運營管理不斷完善的體系，所以具體建設節奏應該從這裡入手。
首先要搭建一套關注使用者體驗的資料體系，這非常重要。如果管理者看不到企業經營管理活動各個環節使用者的體驗資料，何談指揮決策？有了這些資料，內部管理才能公升級為不僅僅管控，還能實時指導經營決策，基於使用者體驗資料驅動內部管理持續完善。
然後， 在單個業務單元（事業部）內，由使用者體驗資料驅動內部經營體系更完善，讓協同更順暢，這是建設事業部級別的指揮官體系。這可以模擬軍隊裡乙個軍種（比如陸軍）的作戰指揮體系更完善了。
最後，如果企業已經公升級到下乙個階段，開始建設企業級別的指揮官體系。就如同美軍現在的水平，擁有能夠支援多軍種實時協同作戰的c4isr體系。在這個階段，可以並行考慮企業級別的架構解耦、服務重用。不過千萬不要本末倒置了，完全奔著架構優化去做了，最後一定是一地雞毛。
還要提醒一點：一定要找到中臺建設的金主。要算清楚財務賬：投入多少？回報多少？回報週期多長？企業級別的中颱建設投入一定不會小，不要有花小錢辦大事的不切實際的想法。 更好的方式是整體規劃、長期投入、 從小處著手，看清楚產出價值的時候堅決大手筆投入。
從業務發展的視角看：天下無「中臺」，只有「指揮官體系」；
從架構技術的視角看：架構解耦、服務重用，要大談中颱。
希望這篇文章能夠幫助大家在面對具體的問題時分清這兩個視角， 選擇正確的視角解決問題。用架構技術視角建設專業的技術平台支援指揮官體系；用業務視角建設「指揮官體系」，幫助企業快速響應市場變化，在激烈的市場競爭中勝出！
大道至簡，中颱是啥
目錄這麼多年，經歷了這樣的場景 乙個概念的出現背後其實是有巨大的商業利益競爭，有些時候只是新瓶裝舊酒，把乙個比較土的概念換個華麗的說辭讓你感覺比較fashion 中臺這個詞和架構這個詞有異曲同工之妙，可能你想搞清楚這個概念前就已經被各種字首詞弄暈了，例如你只是想知道架構是什麼，撲面而來的是 這時候你...
讀《大道至簡》的體會
這本書算是很經典的軟工方讀物了吧，它沒有講任何程式設計的技巧，反而是講的程式設計應具有的一些思想，這本書旨在對讀者在程式設計上的思想進行啟發。來講一下我受到了哪些啟發吧，首先就是這本書中強調很多次的 程式 演算法 結構 其中根本就沒有提到 就說程式設計反面，並不是那麼重要，因為程式設計的目的就是解決...
大道至簡的演算法 字首樹
trie 發音為 try 或字首樹是一種樹資料結構，用於檢索字串資料集中的鍵。這一高效的資料結構有多種應用 自動補全 拼寫檢查 ip 路由 最長字首匹配 t9 九宮格 打字 單詞遊戲 方法將在下文實現.字首樹主要有三個操作 插入 搜尋 字首匹配。1 插入 描述 向 trie 中插入乙個單詞 word...