一個公司應該首先建立起戰略，然后尋求建立一個實現該戰略的合適的架構。

為什么重提企業架構

我們之所以研究企業架構，一部分源于之前研究中臺的規劃過程中發現它是一個企業級架構的問題。現在如果大家去看企業架構框架，就會發現大家眾說紛紜，因為越靠近頂層，離戰略越近，離企業界越近，就會越“虛”。企業架構已經被行業應用和發展了二三十年，為什么現在又被重新提起？而且，你會看到，就跟當年大家在談中臺一樣，行業對于企業架構的理解和應用也是眾說紛紜，大家說的都很有道理，但我不知道哪個才是適合自己。

那么這波浪潮到底代表什么，我分成了幾個比較小的問題，比如第一數字化建設中有哪些挑戰？第二，為什么說企業架構是解決問題的正確方式。第三，到底什么是企業架構，什么是企業架構框架，以及為什么說平臺化是數字化轉型。

第一個我們先想想什么叫數字化？雖然這個概念大家都在提，最近我發現好幾位行業大佬在談數字化的問題，我也在寫一個系列叫“白話數字化”，從小白視角去闡述這樣一個概念。那我覺得數字化的概念并不是特別高大上，最早有一個數字孿生的概念，就是如果沒有信息化，沒有網絡的情況下，我們現實世界也是在同樣運轉。那有了信息化、數字化之后，我們發現數字世界里邊做很多的事情要比我們在物理世界要容易的多。我們現在在做直播，那原來在沒有互聯網的情況下，這個形式是什么樣呢？就是線下的聚會、社區的分享。比如我們現在做線上直播，要比把幾千人聚在一起做一個線下的分享要容易的多。像現在我們通過直播交流，我現在在一個非常大的空曠的會議室里，我的物理世界就我一個人，但是在數字世界里邊現在可能有幾百人，甚至幾千人，我們在一起溝通交流，這就是數字世界的魅力。這也是現在為什么大家在談數字化的一個原因。

大家一定會想這個東西不就是簡單的信息化，我的觀點是一脈相承，說白了就是把物理世界的東西搬到數字世界里，但是不像數字孿生。數字孿生可能會太嚴格了，要求兩邊一致。我覺得最簡單，當我們談數字化的時候，就是把我們物理世界的一些東西搬到數字世界，我們做數字化轉型就像把業務搬到數字空間。我們發現數字空間相比物理空間有很大的優勢，比如簡單、突破空間的約束。我們現在直播就是在突破空間的約束，這個在物理世界是很難辦到的。還有突破時間的約束，我們現在很多講的大數據，基于過去的歷史信息做未來的預測，這其實就是在借助時間，在跨越時間的維度。

物理世界的計算單元是我們每個人，我們的知識傳遞主要靠義務教育，需要花前 20 年來做整個知識和信息的傳遞。我們的存儲模式也有限，只能靠一些文字，靠大腦去存儲，我們的算力也有限。這就是物理空間的局限，這就是為什么我們反而希望在數字空間構建世界的原因。但是數字世界是不是一定好？不一定。物理世界物理空間也有它的優勢，比如高保真。這就是為什么我要去見一個客戶，還是要跑到客戶的現場去做，因為我發現在一個會議室里大家面對面的交流，跟我們線上開會議是不一樣的。我現在稍微有一點點不適應，因為我感覺我自己在跟空氣溝通，那這就是數字空間給我們突破了空間約束的同時，帶來的一些損失。

我們先定義一下什么叫數字化。我認為數字化的過程就是把我們物理空間一部分的業務搬到數字空間，讓兩個空間無縫融合。我引自 Thoughtworks 出版的一本書，它里邊給數字化做了一個定義：我們認為數字化轉型不是模糊技術和業務之間的界限，而是用心記錄重新為客戶提供價值，是一個技術重構業務的過程，是業務和技術融合的一個過程。這個觀點至少在行業里大家達成了共識。既然說數字化，那么什么叫數字化建設？就是我們原來的企業可能是純物理空間，純線下的業務，現在要借助數字化世界的一些優勢把物理空間的一些過程、業務，搬到數字世界里。

我們發現在這個過程中，之前很多年的發展都是一個野蠻生長的過程，尤其是互聯網速度帶來的牽引力，讓我們快速的構建了很多企業系統。大家都在講煙囪式的建設，在我來看并不是一個煙囪式建設，可能更像下邊圖片中的這種，現在很多企業也隨著過去 5 年、10 年的發展，現在我們的應用的現狀可能差不多就是這樣一個情況。

所以在數字世界，我們企業如果是這樣的情況，那肯定會碰到很多的困難，比如企業做新的業務，去做任何的變化都會極端的困難，這跟物理世界是一樣的。那現實中，我們是怎么解決的。

如果我們只看右邊這張圖，可能不理解圖中的意思，但是我們很容易找到網上的一些雄安新區的規劃圖，我們發現在這些看起來雜亂無章的建設背后，我們之前要對整個城市和地區做一個整體性的規劃。這個規劃不光是簡單的一張圖，它可能是不同的視角，我在看這個時候，發現它跟我們在做一個企業級的規劃很相似。企業級規劃對應的是我們原來說的系統級別的規劃，相信很多的朋友可能現在更多的是在一個系統，或者一個領域，可能更多的是在系統層面做架構設計。

軟件產品的研發，一旦我們把視野提到企業架構層面，就跟我們把視角從建筑的結構，提升到一個城市的結構一樣，這個時候我們看到復雜性是不一樣的。所以企業架構方法我覺得在物理世界對應的學科應該像我們說的城市規劃，是一個更大、更寬的視角。

過去幾年，我們在研究信息化和數字化建設中發現現在的數字化建設并不是從零開始的。就像雄安新區一樣，可能更像一個舊城改造，是把剛才那張圖里已經建的可能相對雜亂無章的這樣一個情況，通過一個重新的規劃，重建成一個我們想要的樣子。

現在我們在數字化轉型的第一個階段，大家在做一些企業架構的治理，包括業務架構的梳理和應用架構的治理等。那我們來看看到底什么是企業架構？架構這個詞最早是在建筑行業，用我自己的理解，架構就是在一定的環境之中概念和概念之間的關系。

我們看到很多的架構圖，發現最常見的架構都是分四層，每一層里邊有各個塊，塊里邊還有小塊。在我看，它代表的就是我們企業無論是對于業務還是應用的元素，以及這些元素是什么樣的關系，是不同的層次之間的關系，或是包含關系、關聯關系。所以架構很簡單，架構就是在一個上下文，或者表達在一個環境中有哪些概念，以及這些概念有哪些關系。

那什么是企業架構？如果我們了解了架構之后，企業架構很容易理解，那就是當我們去看待一家企業的時候，在這個環境之內，到底有哪些基本概念？以及他們之間的關系是什么？比如我們說的組織關系，也算企業架構關系的一種，比如什么人在這個過程中扮演什么樣的角色，以什么樣的流程，在做什么樣的操作，所以組織架構就是我們這個組織、有哪些人和他們之間的關系。

所以當我們說企業架構的時候，我們就是在看，一個企業里邊的元素和關系。我們在看一個企業架構時候也會以不同的視角去看待這個企業，比如說我們從業務的視角、組織的視角、應用的視角、技術的視角、數據的視角，這就是為什么當我們談企業架構時候，經常大家就會在談什么業務架構、應用架構、技術架構、數據架構，它都是在以不同的視角看待企業里邊不同類型的要素和這些要素之間的關系，這就是企業架構。

前面我們了解了什么是架構、什么是企業架構之后，我們再看看什么是企業架構框架？我發現很多行業里面，大家經常把企業架構跟企業架構框架，就是 EA 和 EAF 這樣的概念混淆。企業架構就是一種架構，把這個企業元素和元素之間的關系能描述清楚，這就是企業架構，企業架構更多代表的是一種結果，而且架構框架如果能產出這樣的一個結果，有很多不同的這個框架和方法，就是工具。

如果我們追訴企業架構的歷史，很多人說是從 1987 年的 Zachman 開始，作為一個企業架構的起點，我們也做了一些研究，通過往前追訴，就是左邊這個 Paper，大家現在可能已經很難查到這個文檔，它都沒有電子版，現在都是影印照片。

我們看到了數字化的必然趨勢，因為在數字世界里，通過技術或者其他方式，可以賦予我們業務更強的威力，而掌控這種數字化帶來的威力是大部分企業要發展的方向。當我們關注這件事情的時候，我們單以系統的視角就不夠了，我們需要把視角提升到一個企業視角，就跟我們在做一個城市規劃，單看一個小區的規劃已經不夠了，需要一個大的視角，然后我們就找到了應對方法，原來企業架構是解決這個級別問題的一個手段。而且這不是新事物，它已經存在 20 多年了，直接拿來用就可以了。

那為什么大家現在又在談企業架構呢？我們發現現在這個節點我們再去應用這些經典或者叫傳統的企業架構方法的時候，感覺有點力不從心。

到底是什么讓我們覺得原來的框架并不太合適？我們需要做一些企業架構框架的演進也好，改進也好，不光我們，如果大家最近關注 TOGAF，它本身也在做企業架構框架的演進，包括最近試圖把敏捷揉入到比如像 TOGAF 這種傳統企業架構框架之內。

第二點是平臺化。為什么說平臺化是數字化轉型現階段的一個重要趨勢呢？我們知道原來最早做企業，可能需要從購買服務器開始，甚至如果再久遠一點，我們需要自己去構建自己的操作系統，但是現在至少在企業外已經有很多的平臺了，無論是云也好，中間件也好，SaaS 也好，我們發現不需要再從零開始了，只需要在金字塔的塔尖構建我們自己的應用就可以。那再往前，我們現在很多的企業，尤其是中大型的企業，覺得外邊的這種行業通用的平臺和工具已經不足以滿足需求了，可能業務線非常的龐大，十幾條業務線，上百、上千個應用，我們希望在企業內開始再去構建自己的這樣的一個平臺。現在國外沒有中臺的概念，國外相對比較對應的概念是企業內部平臺。現在我們國內的很多客戶在遇到新的業務場景，已經在考慮不是又重新構建一個新的煙囪式應用，而是看能不能通過構建一個企業內部平臺，然后再其之上去構建業務應用，慢慢沉淀企業的內部業務能力和業務模式，中臺架構也就隨之誕生了。

我們發現現在的企業環境跟原來 20 多年前的有兩個大的差異：一，技術上已經翻天覆地了，第二現在大家在做的已經是非常靠近業務的、很薄的一層了。最近行業里邊都在爭論低代碼平臺，但是其實就算沒有低代碼平臺，我們去構建一個應用也比 20 多年前要容易的多。現在無論是企業內平臺和企業外平臺，都給我們做了很大的支撐。

我們再看看原來大家在很多地方都在用的 TOGAF 企業架構框架，最早我們去解決中臺和企業架構治理的問題，就是用的 TOGAF。如果我們只看業務架構的部分，發現傳統的經典企業架構，它非常的簡單，這個簡單不是貶義的，因為企業架構框架會涉及到一個使用范圍的問題。如果大家看金融領域，金融領域也有像 BIAN 這種企業架構框架。我們說一個企業架構框架，如果想適用所有企業，它一定會設計的足夠通用和抽象，這樣才能滿足更廣的適用范圍。

但是放到每一個企業應用的時候，你會發現很多的東西用起來特別別扭，需要做很多的工作，比如用傳統的 TOGAF 去構建企業的業務架構，很簡單，你只要能清楚業務架構的核心元模型、有哪些組織、有哪些人，以什么樣的角色，使用什么樣的功能，以什么樣的流程去完成業務就 OK 了。

如果往前去看，先把業務搬到數字化這個過程，保持業務不變，可能只有一條簡單的價值流。從生產制造到銷售，我們可能只賣一個產品，只有一個業務。最早，我們只要在這里邊，把它切分清楚：如何進行獲客是一個系統，中間生產是一個系統，供應鏈是一個系統，營銷是一個系統，我們只要把業務捋清楚了，每一個系統一個團隊。過去二十年應用這些企業架構是 OK 的。

現在是一個什么樣的背景？現在一個企業動輒可能就是三五個事業群，好幾十個業務線，每個業務線里還有成百上千的應用。這個圖只列了三個進行舉例。然后我們發現在不同的業務之間有很多重復的東西，但是如果從整個價值鏈和價值來看，它又不一樣。在這種場景下，我們如何還像原來一條一條去梳理它，構建一個一個應用去滿足它，我覺得這肯定不是在現在這樣一個業務復雜性的情況下可用的工作。

同時很多的企業在業務充分擴展之后，還考慮到復用：不需要每一次都重新去構建平臺。那平臺如何去建設？如果回到傳統的企業架構框架里，雖然它也會引入一些擴展機制，引入一些 SOA，但是它跟平臺還不是一個層面的事情。我們發現現在在數字化整個過程中，面對問題的復雜度要比二十年前要復雜的多。在這樣的一個背景下，當我們如果去做一些企業的數字化規劃，在原來的傳統的企業架構的方向之上，我們能做哪些改進？比如如何處理平臺，如何處理分層，如何處理技術和業務結合，如何處理數據被充分利用的場景？在這個趨勢下，我們是在試圖把一些我們自己的想法和今年的企業架構框架做一些融合，但是這個框架本身也在持續的改進。

現代企業架構框架介紹

現在行業里邊就有很多的同學也在做企業架構框架的研究，那現在這樣的框架能不能解決我們的問題？目前我們設計這套框架的時候，首先第一點就是能復用就復用。我們知道有一個奧卡姆剃刀原則，如無必要，務增實體。所以在傳統經典的企業架構的框架下，有好的概念還是把它承接下來，像我們原來說的 4A 的架構，業務、應用、數據和技術，我們這個大的分類并沒有變化。

什么是業務架構？傳統的企業架構的思路我們覺得是沒有問題的，就是從戰略輸入到業務，以業務為核心，然后去推導應用如何去支撐，技術如何去支撐，數據架構怎么去設計。但這里邊我們看到了很多新趨勢，一是整個企業在分層，原來可能就像剛才那條價值鏈一樣，企業就一層，大家只要按不同的價值階段去切分系統就可以了，相對比較容易一些。現在我們發現業務已經至少分成了兩層，甚至多層。第二就是重，那我們現在想能不能把它變成敏捷化、輕量化，能不能在一個月到兩個月的時間內去做完一個企業架構規劃？

所以今天我也會把業務應用、數據架構和技術架構都講到，但是時間有限，我把業務這塊充分展開，因為我看到行業里邊，大家目前的觀點更多的聚焦在業務架構和應用架構。

評判一個業務架構是不是做的好特別簡單，只要我們找一個不懂這個業務的人來看，給他一份業務架構圖，無論是用什么畫的，他都能看懂業務是什么。因為架構圖，它一定是為了傳遞信息，跟我們去蓋一個樓，施工隊能按照架構圖構建出來一樣。我認為這是評判業務架構設計結果好壞的唯一標準。

應用架構和業務架構有什么區別？我認為最簡單一個回答是業務架構可以沒有任何應用架構，因為一個純物理世界，純線下的業務它是有業務架構的，但是沒有任何的應用架構。那現在如果我們拆解開業務架構，把企業架構問題轉換成四個架構問題。

第一，如何控制業務架構梳理的粒度，為什么？我們看到經典的企業架構在做業務架構時，就一個功能和流程，里邊無限嵌套，但到底嵌套多少層？業務到底是分成什么樣的粒度？場景和業務到底有什么區別？業務是在場景里還是場景在業務里？我們發現很多時候并沒有去做對齊；

第二，現在大家都在講企業分層，比如業務層、中臺層，對于中臺層或者平臺層，最簡單的目的是通過復用來降本增效，那怎么在業務表象背后找到可復用的能力？這是我們碰到的第二挑戰，我們發現傳統經典企業架構也沒有幫我們解決這個問題；

第三，如何復用這些能力，實現業務的快速上線。

這個是在做企業架構治理，尤其是在平臺性企業架構治理里一直困擾我們的問題，那我們怎么解決？

首先，我們也參考了行業里邊的很多的經驗，現在行業里都在講五級建模、六級建模，如果大家往回追訴，這是有些標準和依據的，比如有些行業流程分級這些標準都有存在。

現在在行業里邊大家分層不一樣，但是我認為“分成什么樣”不重要，“分”更重要。

這張圖引自 C4 模型。大家應該了解 C4 模型，它相當于我們在做城市規劃或者在做世界規劃時，一定會有個標尺，我們才能知道我們到底在哪個緯度和哪個粒度上在談論業務。

這里一定要有一個數字世界的標尺，或者業務標尺，那我們首先在傳統企業架構方法之上，把業務的這個標尺建立起來，也就是圖中左邊這些。在這里邊同時對于橫向的能力，我們也可以通過這樣的標尺，跟整個的業務流程進行一個對接，這樣帶來的一個特別大的好處是：很多企業在架構治理過程中，原來大家很難溝通，因為每個人說的東西都不一樣，就是你說的一個場景跟我說的一個場景完全不是在一個維度上，你說的一個功能跟我說的一個功能、你說的一個流程跟我說的一個流程，也都完全不是在一個維度上。大家很難達成共識，就相當于沒有地圖的情況下，我們來談論世界一樣。有了這樣的標尺之后，我們談問題的效率會成倍的提升，這個很重要。

這是我們做的一個案例。可以五層或六層，大家可以基于不同企業的情況去定制。

企業架構里，我們給每一層都找到了一個標志物，確定大家至少在同一個相對的維度上。通過這樣的分解之后，業務就會有條理很多。原來我們去做梳理的時候很難對齊，一旦建立一個標尺之后，無論是用戶流程圖還是價值流價值鏈的梳理，我們都可以很快地讓大家聚焦在同樣一個顆粒度，以同樣的一個維度來思考業務。無論是知識的傳遞和知識的溝通，以及知識的沉淀都帶來了非常大的好處，這給我們至少建立一個業務的共識。對于業務架構進行一個梳理，這個標尺非常重要。

第二個，如何定義共享可復用的能力？如果現在大家去構建比如像中臺或者平臺這樣多層的企業架構的時候，這個問題就可能是困擾大家的問題，也是當時困擾我們的問題。通過前面建立一個這樣一個業務標尺后，我們再去看業務，就可以在不同的維度，不同的縮放程度上對業務進行對比。

有了這樣的標志，讓我們去抽取不同的業務不同的場景下共同的能力也變得更容易。比如我們可以把單個步驟的能力變成一些基礎的能力，把一些可能 L4 級別的能力定義成一級二級能力組件在解決方案層面復用。通過這樣一個標尺和業務的梳理，我們就可以把這些業務放在一個藍圖上進行對比，這樣我們就可以很容易找到哪些能力在不同場景下是完全一樣的，哪些能力在不同場景下相似但有差異，哪些能力在有些場景下有些沒有，這樣的話就可以幫助我們去提煉識別這些可共享可復用的能力。

能找到但如何去識別呢？第一，比如需要進行流程建模。我們需要看不同的業務的表象之后有哪些通用的流程，這些通用的流程就像一個模板一樣，如果大家了解 24 個設計模式，我們原來更多是在代碼層面來去消除一些重復，做一些重構。企業級的中臺在我看來就是在構建企業級的模板模式，在大家不同的流程模式之后找到通用的一致性流程，再通過擴展和繼承的機制來去實現不同業務個性化的需求。

第二，我們發現很多的企業在去比對不同場景業務的時候，更多還是從流程層面，為什么現在大家在講中臺建設，往往會跟 DDD 緊密相關？我經常舉的一個特別形象的例子，就是判斷人的外在行為。每個人都是一個腦袋，兩個眼睛一個鼻子一個嘴，但是每個人都長的不一樣。這就是我們經常做業務時發現每個業務看起來都一樣，但是往后看都不一樣。你說能不能變成一個人？變不了。但是什么是一個好的能力復用的例子？我覺得醫院是一個好的能力復用的例子。醫院沒法通過頭疼、腳疼來去判斷你是什么問題，但是醫院里邊的科室設計就是一個按照知識邊界進行科室劃分的，比如心臟內科、神經內科這些能力是可以復用，比如一個心臟外科大夫他可以給不同的人來去解決心臟外科的問題，所以在醫院內他是一個基于能力構建的中臺結構。那你如何判斷一個外在的行為到底有哪些內在的領域和知識是復用呢？就是通過做檢查，做 B 超，做 CT。

其實 DDD 就是對業務“照 CT”的一個過程，我們對業務進行了一系列的行為、事件的建模，包括領域建模，我們就相當于給業務做了一個 B 超。就像我們說的定單中心、用戶中心，你發現它本身并不是外在的流程和業務，它更像是內部的領域和知識邊界。我們經常說前臺的劃分和中臺的劃分，比如說從應用上的劃分是完全不一樣的。前臺更多是基于價值流階段，給那些人在提供什么樣的價值來去進行劃分。平臺層考慮的是復用，更多要從知識邊界、從內在進行劃分。這就是為什么我們發現平臺性的架構，也給企業架構演進帶來驅動力。我們發現原來只從外邊、只做外科體檢的方式不太起作用，可能需要一些新的工具和手段。

第三，我們最終想要的是針對不同的前臺產生不同的復用，行業常用的方式是通過業務身份建模加擴展機制實現。很多客戶會問自己企業到底有多少層，怎么劃分？但其實是難以劃分，因為理論上一層和多層都可以解決以前的問題，而平臺之所以是個戰略，是需要從頂層去做設計，它不是一個能從痛點進行業務推導的過程。業務架構的輸入一定是企業的頂層戰略，包括平臺戰略也是企業頂層的戰略之一。

通過這樣的一個戰略的輸入，建立業務的標尺，用不同的方法梳理業務，在這個過程中再進行一些可復用的抽取，找到這些流程背后通用的能力，再通過這些能力將標尺和維度與業務進行對應，這就是以平臺為代表的一個企業架構的業務架構。

業務架構未來是什么樣？今天分享的題目是“企業架構的過去、現在和未來”，我們現在已經看到過去談架構更多的是一個瀑布類型，業務戰略輸入、業務輸出、應用輸出、數據輸出以及技術，可能需要六個月至一年的時間。

現在我們發現在數字化背景之下，用數字化技術來重新改造我們的業務，這個過程不再是一個瀑布流程，而是一個不斷迭代甚至融合的過程，這是我們能看到的業務架構的一個特點。我們也在試圖把一些數據的能力，包括數據的場景，技術的能力再融合到整個業務架構設計過程中，我們的方法也在持續的演進。

最后一步就是如何復用。我們認為行業里邊當談能力復用的時候，可定位成三個 Level，第一個就是簡單共享，就是一個能力在這，你和別人都是用一樣的，這就是為什么很多的企業叫管這個叫做共享中心。就是比如我一個查詢定單，你查的跟他的沒有任何區別，我認為這是第一個級別的能力復用。第二我們發現在互聯網企業里邊，很多業務深層擴展機制，可以針對不同的前臺產生出不同的行為，我認為這是第二步。在我的定義里這才叫復用，之前那個叫共享。再下一步是提煉能力，把我們的能力包裝成更抽象、或更大粒度的解決方案。直接告訴我如何做貸款、如何做理財、如何建一個停車場，我認為這樣的復用是中臺層面，或者往平臺的方向演進。

我認為業務架構是最主要的，其他的架構更多是一個支撐。在應用架構里面，怎么判斷一個應用架構畫的好不好？就是給一個應用架構圖，可以知道有哪些應用、有哪些系統，相互之間是什么樣的集成關系，部署在哪。通過這種架構圖，就能夠基本了解清楚。

應用架構里面會遇到哪些挑戰？如果業務架構的難點在粒度和抽象，那應用架構的難點還是在粒度和邊界。應用架構主要是劃分邊界，到底分幾層，有哪些中心、有哪些系統，系統的邊界是什么、關鍵是什么，系統之間有沒有什么集成關系，或者依賴關系。

我們其實是在談“分”和“合”的問題，“分”和“合”的問題就是自治和復用的問題。首先回到最根本：為什么要“分”？因為我們認為從用戶的角度來講是看不到邊界的，他看到的就是業務，就跟一個人一樣，我們剛才拿人舉例子，心臟和肺，但是要知道人內部是沒有清晰的邊界的，很難劃分一個人心臟和肝的邊界在哪，因為大家都是一體相關的。在我們看來，“分”的根本在于認知負載，以及如何通過組織或者架構上的設計來解決團隊負載問題。當一個企業足夠大之后，不可能讓一個人了解所有的知識，類似醫學發展到現在，不可能人人都是扁鵲，什么問題都可以治。每個人的知識負載是有限的，一定要劃分開大家的專業領域知識，才能更深入。

邊界永遠是最難分的，因為本質上就沒有邊界，系統和業務就是一體的。回到企業初創過程中，那時不會做復雜架構，就是一幫人做一個系統，一個系統就是整個業務。此時其實沒有邊界，隨著發展才產生了邊界。對于邊界，同樣要有一個顆粒度，顆粒度就是一個相應的定義。

比如說我們現在的理解，中臺是商業模式的邊界，中心是組織的邊界，微服務是彈性邊界，聚合是業務一致性的邊界。在此過程中，我們就是在給顆粒度建立標尺，同樣顆粒度也需要有一個標準，否則到底多微算一個微服務，每個人都會自己不同觀點，需要大家達成共識。

為什么要去“分”？前提是因為我們要減少知識負載。如何確定應用的邊界？我們現在用的方式是基于原模型里業務架構的輸入。可能采用兩種方式，一種是自上而下，比如通過業務場景這個大粒度，包含現在組織的現狀，這就是為什么每家企業可能做應用架構做企業架構都是不一樣的。每個企業都一樣可能就不需要這么多企業了，因為我們組織不一樣，我們的業務場景不一樣。同樣，因為我們在業務上建立一個標尺和粒度，最細粒度已經到事件級、原子級，我們同樣是可以通過比如像 DDD 子域問題空間，業務架構里的價值流階段，來進行自下而上的邏輯邊界劃分。然后最終我們可能確定了一個物理邊界，就是應用架構邊界。

舉個例子，一般如果我們把企業默認分為兩層的架構。前臺基本上都是基于價值流、價值鏈。但是對于中臺來講，往往是基于知識邊界來進行劃分。就是我們有哪些領域的知識、訂單、用戶、營銷，我們在基于知識來進行劃分，可能一般行業里邊現在通用的做法就是基于 DDD，來做平臺層的基于知識的邊界劃分。

我們再往下講一下就是數據架構，數據架構目前存在比較大的爭議，我比較贊同“把數據架構和應用架構合并”的觀點。在傳統的經典企業架構里，數據架構也是在 TOGAF 8.x 才被引入到 TOGAF 框架里邊。原來為什么沒有獨立的數據架構？是因為我們一個應用就到應用粒度即可，里面如何實現它，怎么設計，不用特別的關注，但是需要有一個倉庫把所有這些東西提到一起，建立數據域。現在隨著我們對于應用架構和業務架構的細化，很多原來在數據架構里邊的知識，比如問題域、子域，這個可能就被移到了業務架構里面，要去分不同的業務系統在處理什么樣的問題，所以數據架構可能就被縮展。

還有一個是目前行業里邊經常混淆數據架構和以數據的視角看待架構這兩個概念。數據中臺不是純數據架構，也包含了數據類的業務、數據類的應用和數據類的技術。數據架構在我們模型里面定義很簡單，因為很多都已經在業務和應用中已經涉及到了。這里我們只定義了數據對象、數據組件和數據服務來去解決這些數據流的問題，后面會考慮把數據源和數據標準加在這里。

對于數據架構的設計過程行業里邊也有很多發展方向，包括 Data Mesh，就是分布式的數據架構。一旦我們認為數據是跟應用一體的，尤其是在微服務架構設計里，你會感覺到數據是跟著應用走的。類似前端經常講的組件化，原來大家習慣談分層，現在其實更多是談組件化。數據一旦跟著應用走之后，那以后未來的數據架構，或者我們這種大數據的場景是不是也是一種分布式的數據場景？如果已經是一種分布式的數據場景，還是不是需要一個集中的倉庫，來去統一的單點的管理這些數據和過程？這個可能也是一個需要考量的點，或者我們可以持續的關注這方面的一些演進。

最后，關于技術架構。技術架構是在這里是相對比較明確的，因為我們經常談技術架構、技術選型，企業級的一些技術選型的標準，技術架構的一些標準。比如我們如何處理高并發，如何處理高可用，如何處理分布式架構，這些都是技術架構要去做設計的。我們在幫很多的客戶在做數據架構，包括基于數據架構和業務架構融合，我們認為傳統的數據架構沒有這種問題，就做一些選型，找一些組件，做一些平臺，需要增加的一點就是希望把數據架構的資產進行沉淀。比如能不能構建一個自助的技術架構設計平臺，就像問答式，你告訴我這個系統是什么樣的？比如是用戶量多少，并發量是多少，訪問量是多少，用的是什么樣的一個架構模式，我能不能自動給你出一個技術架構。

這里我們更多關注的是在富技術時代如何做好平臺型技術的復用，這里面三個主要的問題。第一，如何能系統的分析架構設計的需求。到底有哪些架構的需求，這些需求如何分類？這些里面有哪些模式？基于這些模式到底有哪些現成的不同粒度的解決方案，可能是不同平臺服務或組件甚至方案的組合，這就是一些技術架構的沉淀。那如何通過這些沉淀拿到一個新的系統，或者應用設計的時候，能不能不再從頭去建設？發現很多的企業在做數據架構，每一個系統要從頭到尾來一遍，然后可能大家的技術棧選型，技術方案都不一樣，那么是不是可以在企業層面給大家制訂一些相應的解決方案，甚至可以用一些架構平臺進行沉淀，最終讓前臺或者中臺的應用可以實現自助式，基于一些最佳實踐和方案沉淀的技術架構設計。這是行業正在探索的一些方向。

最后做一個回顧。

首先，我們認為在數字化時代背景下，平臺架構模式被越來越多中大型企業，甚至很多初創企業采用。我們面對的問題可能要比過去十年、二十年要復雜的多。在這種場景下企業架構是解決問題的好方法，但是我們發現它在解決這些新問題有點力不從心，或者有點過于抽象，過于繁重。

目前行業里企業架構是一個新的方向。大家為什么都在談論？因為重新認識到了做企業級治理和規劃的重要性，也在嘗試用這種方法來去解決問題。我們現在正在嘗試 MEAF 設計辦法，且我們認為使用效果較好。

如果從整個方法論來講，設計過程沒有變化，但我們認為未來企業架構的發展方向可能有幾個趨勢。首先是這些架構會不斷融合，未來可能分不清什么叫做技術、業務、數據架構。可能技術就是業務本身，數據也是業務本身，我們發現可能它更像從瀑布到敏捷的這樣的過程。在這里邊我們發現，第一，整個過程一定會更加的輕量；第二，整個過程一定會越來越關注落地性和演進性。在這個過程中，我們發現可能從整個的企業架構端到端的規劃過程中，可能也要變得更敏捷、更持續。現在我們有很多的客戶企業已經可以做到一次這樣的大范圍的架構治理只需要 4 到 8 周的時間。當然是建立在之前已經做過一次比較相對全面的構建過程，每三個月到六個月就要重新審視一下整體架構，甚至建立一個更快的架構的運營和治理的體系。