上一篇我談到中臺架構能夠成為企業數字化破冰者的關鍵就是“合”“分”“聚”三言。而構成中臺的，又是“有業務”的業務中臺，和“有技術”的技術中臺兩語。三言兩語便是看上去紛繁復雜的企業中臺的精髓所在。
企業數字化中臺方興未艾，各種概念、架構和產品層出不窮，說法各異，效果也參差不齊。客戶在各種名詞、概念、技術堆砌中迷茫不已，軟件公司不知如何建設，軟件用戶不知如何選擇。但其實只需要掌握“合”“分”“聚”和“有業務”“有技術”的三言兩語精髓，就可簡單明了的判斷一個所謂中臺產品能達到什么樣的效果。
三言是指：
- 合，指雖然業務系統被拆分成了微服務，但業務和數據必須仍然是集成一體的。
- 分，指將有原來有邊界的各種業務系統拆分為無邊界的微服務集合。每個微服務都保持獨立性，自包含，有自己的生命周期，能獨立迭代和發展。
- 聚，指拆分開了的微服務必須能夠將像搭積木一樣快速組裝應用場景。
兩語是指：
- “有技術”指中臺產品應具備支撐中臺化的必要技術。包括但不限于IaaS,PaaS，Devops, 容器化，分布式，微服務，開發平臺，運營平臺及其它IT工具……。
- “有業務”指中臺中不僅要有技術支撐，更要有大量業務內容可供客戶復用而不是只有技術框架。
接下來我們就來分析一些典型的不完備的“中臺”架構，看看依據三言兩語，它們的問題出在哪里。
1）典型非中臺架構
- 傳統單體架構
可見單體架構的用邊界把完整業務鏈條切分成多個單獨的系統。每個單獨系統內部是集成的，可以稱之為“合”。但因為不可拆分成零部件，也就無法快速組裝。同時雖然提供業務內容，但卻不具備中臺技術，因而它是典型的非中臺。
- 互聯網場景化應用架構
互聯網場景化將完整業務拆分成很多獨立場景，每個場景獨立“深挖”，但場景所處的全業務鏈條不是每個產品設計的考慮范圍。拆是拆開了，至于合和聚，它們的做法是“遇到了再說，反正可以寫代碼調用開放API”。可以說是管拆不管合也不管聚。雖然提供了業務場景，但卻不具備完整的中臺技術。通過開放API和網關雖然可以實現場景集成，但對企業來說更重要的業務集成和數據集成就完全無能為力了。因而它也是典型的非中臺。
2）典型的“半”中臺架構
“半”中臺是指有了基本的中臺架構概念，但只能滿足“有技術”“有業務”兩語中的一個：
- 有技術但無業務內容的半中臺
典型有技術但無業務的半中臺產品具備了完整的中臺化支撐技術，也有一些公共的支撐服務，因而它是技術中臺沒錯。由于沒有業務內容，它只能是半中臺。它將微服務的開發和應用系統的建設完全交給客戶在項目中自行開發。
由于中臺化環境的復雜度、設計復雜度和開發的復雜度都要明顯高于傳統單體式應用，如果缺乏配套的成熟開發工具，其學習成本和復雜度會更高。在沒有可復用業務內容作為可復用資產或案例參考的情況下，初期資源成本和時間成本不僅不會降低，反而會顯著攀升，最終企業還等不到遠期因為復用、組裝、可持續迭代等中臺優勢而帶來的效益提升就會失去耐心或無法承受而放棄。
這類半中臺產品通常脫胎于IaaS或PaaS公共服務體系，它們提供內容的運營管理，但認為業務內容是由租戶自行提供的，它們不負責也不關心。由此產生的中臺產品自然是有技術無內容的半中臺。
- 有業務內容而無技術的半中臺
典型的有業務無技術的半中臺產品已經完成了業務系統的全部或部分的微服務化改造，可以方便的部署到外部的技術中臺上，通過API網關提供業務服務。可以稱之為業務中臺。但由于并沒有內置的技術中臺，它只能向企業交付業務內容而無法將定制開發能力一并交付給用戶。這類只有內容沒有技術的平臺難以支持用戶個性化，一般只能標準化交付，甚至只能以SaaS方式提供服務而不能本地化部署。這種半中臺企業要么只能用，不能改，要么個性化定制代價高昂，或者很難跟其它業務系統在流程和數據層面集成。
同時也可以看到，這種架構與傳統單體式應用架構非常相似，只不過把原來的單體大系統拆成了業務更加聚合的中心化服務。雖然它解決了“拆”和“聚”的問題，但由于缺乏與技術中臺的整合，各個中心與外部業務系統之間從流程和數據上看仍然是孤立的，需要依靠外部工具或者定制開發來完成整合。正所謂拆了大煙囪建了小煙囪，形似而神散。得了微服務的形而失了集成一體化的神，總體是得不償失的。
這類半中臺產品大多脫胎于SaaS服務或者傳統企業管理軟件的SaaS化改造。它們長期專注于企業業務內容的開發或業務運營，大量應用外部技術平臺而缺乏自身技術的積累。因此只能交付現有業務內容，卻無法將個性化定制能力一并交付。用戶無法獲得軟件的自主控制和自主創新能力，使得企業數字化中臺建設難以持續發展。故而稱之為半中臺。
3）典型的“偽”中臺架構分析
“偽”中臺是指，具備了中臺的外表，但其實并不能真正做到可“分”，可“合”，可“聚”的三言。
- 偽中臺之可聚可合不可拆
典型可聚可合不可拆偽中臺具有一定的欺騙性。它的內核仍然是緊耦合單體結構形式，保留了業務集成性，但并未完成微服務化改造。它只是把原本封閉的業務功能以API形式開放出來，利用界面構建工具，在API層面將某些功能組織成一組界面，看上去像是可配置的微服務。用戶能夠利用界面工具定制個性化界面，但內部邏輯仍然是黑盒子，無法定制，也無法自由的將各種業務能力分拆組合。所以是表面可“聚”，內部可“合”，但最為關鍵的“拆”卻沒有實現。有的利用外部技術中臺實現了云化部署，有的甚至只能以傳統的單體方式部署。所以它只能是偽中臺。
這類偽中臺通常脫胎于傳統專業企業管理軟件和ERP軟件。由于積重難返微服務化改造困難，為了趕上微服務中臺化的潮流，只能用開放API，提供可定制界面的方式偽裝成微服務。企業用戶僅僅獲得了表面上的場景定制能力，而沒有最關鍵的業務共享復用和定制能力，可以說是換湯不換藥，總有一天還得推翻重來。
- 偽中臺之可拆可聚不可合
典型的可拆可聚不可合偽中臺已經實現了微服務分布式互聯網化等許多中臺的構成要素，業務能力來自于可獨立部署和運行的微服務，也確實可以通過API組合快速創建業務場景。但是企業只能實現場景整合，不能在流程和數據層面實現集成一體化的整合。這是因為這些微服務來源復雜，除了通用API之外，它們在規劃、設計、開過過程中沒有統一的規范和標準。很多微服務只知道怎么調用API，不開放源碼，也不開放內部數據。即使有部分開放，也各是各的標準。因此企業根本無法深度整合它們實現企業業務的集成一體化，從而脫離了企業數字化中臺重要的“合”。所以它也只能是偽中臺。
這類偽中臺通常來自于云市場服務。云市場上架了很多開箱即用的業務組件，企業可通過API整合它們。但是這些業務組件來自于不同的開發者，云市場并未標準化和規范化這些業務組件，自然也就五花八門。可以想象一下，一個企業采購了很多零部件，而這些零部件規格各異，材質不一，質量不同……依靠這些零部件怎么可能組裝出可靠可持續的產品呢？
上面討論了一些不完備的中臺架構形式，那完整的中臺架構又是什么樣呢？這一篇先用完整的架構圖做一個預告，下一篇我將深入討論一下完整的中臺架構。敬請期待。
完整的中臺架構
這將會是很長的一個系列。我會持續的把我這十多年在企業數字化過程中思考、架構、方法和技術，以及我團隊所研發的企業數字化中臺構建平臺發布出來。相信對業界是有著重要的借鑒意義的。
如果您對企業中臺架構、企業數字化轉型和產業互聯網感興趣，請關注我的訂閱號或頭條號，并期待后續更新。
