在從事數字化轉型的實踐過程中，我們發現，企業數字化轉型總是離不開關于企業架構的討論。

所謂轉型，其實是轉的企業整體，是對企業組織、業務、技術形態的系統化重塑，數字化項目可以通過局部試點迭代演化，但是必須是在特定的頂層設計框架下循序漸進地執行。

數字化轉型的本質不是it外包或技術研發，而是管理咨詢與實施。

數字化轉型的對象是企業，也不是某個技術設備或it系統。

因此，討論數字化以及開展數字化轉型工作，必須以“企業架構”為抓手，把“架構”作為一張地圖，變設計邊做，直至達到所期待的轉型戰略目標。

架構關乎決策!

沒有架構，就找不到轉型的方向。同時，缺少架構支撐也很難有效洞察到轉型中真正的本質問題。

沒有架構的it設計，就像脫韁的野馬，遲早會失去控制，很多項目到最后都會變得“南轅北轍”。

通過架構可以告訴我們，技術和業務，以及企業的經營戰略目標，到底是一種什么樣的影響鏈路或支撐關系。

通常來說，企業架構包含四個層面的含義，分別是業務架構、應用架構、數據架構以及技術架構。

其中，業務架構對應業務域的需求邏輯，主要描述數字化系統所支撐的業務場景。

業務架構中規定了為達到某個業務目標的具體業務流程，所有的業務相關者的全責關系，也在業務架構中有所指明。

簡單講，業務架構可以回答我們到底為什么(why)要做數字化轉型。

而應用架構、數據架構、技術架構屬于信息域，表示如何實現業務域需求的it建設框架邏輯，信息域的結構其實回答的是如何做(how)數字化轉型的問題。

數據架構是支撐業務流的數據模型、數據流關系，以及相應的數據處理邏輯，從數字孿生的角度來說，數據架構是和業務架構的直接映射對象。業務架構中的要求，都在數據架構中直接反映。

從業務架構到數據架構，就是業務需求到數據需求的關系。

而類似地，應用架構是指軟件應用方面的需求，技術架構是支撐軟件應用的物理層技術組件需求，二者共同來完成數據架構定義的內容。

不同架構之間彼此互為約束。在建設任何數字化項目時，只要滿足特定的架構遵從，就能保證需求不跑偏。

值得注意的是，無論是業務架構還是數據架構、應用架構，都是企業級的需求設計環節，而非項目級的。

一旦提到架構，一定是在談論一個比較“宏觀”的視角，也正是基于這個原因，架構的背后是跨組織、跨業務、跨場景、跨周期、跨領域、跨系統，換句話說，一定是一個“開放”的技術生態。

很多時候，企業在構建一個數字化系統時，就要在這個架構的邊界內來完成，很多it系統之間的關系以及系統之間的數據流邏輯，也都是受制于架構的約束。

因此，架構除了指明方向，定義需求之外，還能幫助我們理解一些日常看似困惑的軟件體驗：

比如，很多在線業務明明可以在一個系統中“順序”操作完成，但是經常需要很麻煩地登錄不同的終端，分別填報不同部分的信息來實現。

從用戶體驗的角度來說系統亟需整合，優化服務流程，但是為什么現狀是冗余的呢?

背后的原因并非是軟件設計者或者開發者的局限，而是業務流(業務架構)的約束所致。如果業務域不能得到優化，那么信息域做再多的改進也是無用甚至徒勞的。

從架構的視角，我們更加深刻地理解，為什么說數字化轉型其實轉的是業務，而不僅僅是技術手段!業務，才是最后一公里關注的問題，也是一切數字化活動開啟的緣起!