《哈佛商業評論》中文版推出《數字化運營——新思路應對新周期》提到，企業的數字化升級是一整套體系的進化，從底層架構到業務模型、人才、組織架構，再到制度，乃至于文化等多個層面的升級。
為什么是一整套體系的進化？首先從數字化轉型的本質來說，它是使用科技手段來對數據要素的深度分析和應用而帶來的業務、流程、模式等的創新和變革，這是生產力的創新和變革，從而也就需要組織架構、企業文化等生產關系方面的創新和變革，以適應生產力的要求。信息化是單點信息技術采用帶來的局部效率提升，數字化則要求以數據為驅動、對全局數據的深度洞察和分析，以發現數據之間潛在的聯系和關系，從而開發、創新新的業務或業務模式。因此數據在數字化階段成為基本的生產要素。
數據成為基本的生產要素，單體系統的數據量無法滿足數字化海量分析的需求，無法洞察到不同系統間數據的潛在聯系和關系，所以需要將這些系統數據進行集成，或者采集到數據倉庫、數據湖、大數據平臺等地方，再對數據進行處理和分析等。這是通用的習慣方法，不過這種方式沒有從根本上解決數據的融合問題，帶來了大量的中間數據處理環節和工作量。前些年推行的主數據管理系統（MDM）試圖整合企業內系統間共享的高價值數據，實現數據一致性、標準化等，從而在各個系統之間提供唯一可信數據源。以主數據管理的思想，以主數據為骨架，重構企業數據架構，在新建應用系統或者替換改造存量應用系統時，按照新的數據架構來構建系統，舊系統舊方法、新系統新方法，逐步實現企業級的數據融合。
數據和應用通常是一體兩面，數據融合勢必要求應用架構的調整，比如從單體豎井架構進化為分布式微服務架構。微服務架構和ESB架構雖然都是服務化架構，但兩者解決的問題是不一樣的。微服務解決的是單體豎井系統的分解問題，ESB解決的是系統集成問題。所以可以說ESB重在集成，微服務意在重構。ESB架構是一種系統集成的過渡方案，沒有從根本上解決數據融合問題，所以要實現數據融合，服務化架構選擇微服務架構是合適的，要從數據層進行重構，消除不必要的集成補丁環節。應用的微服務化也便利實現服務級組件的復用和共享，從而為中臺架構構建中臺服務提供了可行方案。應用部署運行在基礎設施之上，基礎設施產生的數據也往往和應用的運行狀況密切相關，是實現應用運行可見性、可觀測性的必備要素。分布式的應用架構需要分布式的基礎設施架構來支撐，比如微服務運行在容器上，容器基于kubernetes實現調度管理，運行在虛擬化或云平臺上，從而實現業務層和基礎設施資源層自動彈性伸縮能力。從而實現了應用融合和基礎設施資源的融合。
應用是業務信息化、數字化的一種表示，數據是業務執行和交互的基礎要素。數據和應用的融合，也意味著業務的融合。通過對業務數據的分析和洞察，發現并找到數據之間的關系和聯系，從而也就找到了業務之間的關系和聯系，從而可以開發、創新新的業務或優化已有的業務，這就是數據驅動業務創新優化。
數據、應用、基礎設施以及業務的融合都是需要技術的支撐，比如說云原生技術體系的支撐，以微服務分布式架構替換單體豎井架構，部署在容器化PaaS云平臺，從而使企業內從基礎設施資源到數據、應用和業務看起來是一個整體，每個應用類似于一個組件，消除了應用之間的集成補丁，可以類比于中國傳統建筑的榫卯結構，無需額外的鉚釘，簡單、堅固并且高效。
業務的融合勢必需要調整組織架構。其實，從基礎設施資源融合，應用的分布式開發和部署，就需要考慮研發的組織架構調整，以適應新的生產力發展要求。不過業務的融合更容易讓企業看到組織架構調整的必要性，只是這需要一個過程，可能會有陣痛。什么樣的組織架構更合適？這個問題比較難回答，不同企業實際情況不一樣，數字化轉型路徑也會有不同，所以組織架構如何調整和融合，如何能更適應自身的實際，可能也需要嘗試和按需調整。可能也是摸著石頭過河的過程，所以自身對數字化和數字化轉型的認知和把握非常重要。別人的經驗不見得適合自己，削足適履只會自己承受痛苦，所以筆者特別不建議動不動就搬什么最佳實踐。一定要基于自身的實際來考慮、來規劃和執行。
系統融合其實還是遵循著企業架構的方法，只不過從原來簡單的單體系統擴展為企業級分布式的復雜系統。這也是中臺架構之所以有需求的一個原因。可以看到系統融合包括基礎設施（包括基礎設施資源、工具組件、安全等）的融合、數據融合、應用融合、業務融合、組織流程融合等幾個方面。系統融合是一種企業架構發展的要求和趨勢，是數字化和數字化轉型整合各項資源、統籌各方面能力、以數據為驅動、統一認知、理順協調好關系、從而按照規劃的路線圖實現企業的目標和目的的要求。
