要想做好架構可視化，你必須弄懂這十個關係

從企業級的角度來看，除了幫助我們思考， "說清楚"還有一個重要的作用就是溝通。我們不僅要自己理解架構設計，還要將我們的理解告訴他人，以便有效協作。

然而， 「想清楚」和「說清楚」其實並不容易。其中一個主要原因在於自然語言的模糊性。

咱們中國古代有一個著名的詭辯叫做「白馬非馬」。大意是：如果白馬是馬，黑馬也是馬，那麼就說明白馬就是黑馬，進而可以推導出「白就是黑」，然而這是矛盾的，所以白馬不可能是馬。

這個推理的錯誤在沒有注意「是」字的不同含義。在「白馬是馬」這個命題中，「是」的意思是「屬於」；在「白就是黑」中，「是」的意思是「等價於」。提出這個問題的人混淆了「是」字的不同含義，因此做出錯誤的結論。這是自然語言模糊性的一個典型的例子。而在軟體架構設計中，自然語言天然的不精確性也常常造成問題。

為了解決自然語言的模糊性，就需要將我們的思考和表述進一步「畫清楚」。架構設計中的很多微妙之處，只通過口頭或文字的描述並不能清晰表達，那麼就需要通過架構圖以及一些輔助文字，來更加嚴格地描述。這就是「畫清楚」，也就是我們說的架構可視化。好的架構圖可以避免歧義，提高思考和溝通效率，這就是我們需要進行架構可視化的原因之一。

事實上， 高質量架構設計需要具有嚴格化，抽象化和規範化的特徵。前面說的是嚴格化，那麼抽象化是什麼呢？

架構的治理和設計的本質其實是一個建模過程，而建模就是抽象化的過程。想一下小孩兒的玩具車。玩具車就是真實車輛的模型，它抽取了現實世界中的一部分屬性，如形狀和移動能力，同時忽略了大部分屬性，如真實的大小、材質等等。這就足夠了，因為玩具車就是為了給小孩兒玩而設計的，它抽取的屬性已經滿足這個目的了。這種忽略現實中的大部分屬性，抽取出一小部分屬性來實現特定目的過程，就是抽象。因此建模是一個抽象化過程。而為了實現抽象化，也需要先將模型可視化。

至於規範化，我們會在後面談。總之， 可視化是嚴格化、抽象化和規範化的前提，是我們進行架構治理和設計不可或缺的工具。

建立架構可視化標準

下面我們就來重點聊聊架構規範化的問題，其中最重要的就是建立繪製架構圖的標準。我們看看有哪些要注意的問題。

關係二：示意圖和藍圖

首先，我想強調一下 示意圖和 藍圖的區別。

最近和一個客戶聊。他們在企業層面面臨著系統重複建設、邏輯不一致和數據孤島等常見問題。我建議他們首先做一下企業級的架構梳理。然而，他說他們已經做過了，畫了很多圖，但問題仍然存在。於是我看了一下他們的架構圖，發現基本都是示意圖，而不是藍圖。

那麼，什麼是示意圖，什麼是藍圖呢？我們舉個建築領域的例子。在下圖中，左邊是大家買樓的時候能看到的沙盤模型，右邊是建築施工的圖紙。

沙盤模型就好比示意圖，它能讓你大概了解房子的外觀，滿足購房的需求。但如果要建房子，僅憑這個模型就不夠了。我們需要一份詳細的、準確的圖紙，這就是建築的藍圖。「藍圖」這個詞來自於早期的製圖技術。那時還沒有計算機製圖。為了讓手工畫的圖紙能夠長期保存，人們會用化學方法進行曬圖，處理後的圖紙是藍色的，所以被稱為藍圖。

在架構治理和設計中，儘管示意圖也有其用途，但我發現很多企業缺少的是藍圖。 藍圖和示意圖的關鍵區別就在一個「准」字。也就是說藍圖應該足夠準確。

有人可能會說：我們做企業級的架構，層次比較高，不需要畫得這麼「細」，所以不需要藍圖。這種說法其實是混淆了「準確」和「詳細」這兩個概念。事實上， 準確不代表詳細，詳細也不意味著準確。「準確「指的是在特定的抽象層次上，具有完整性，並且和系統保持一致。比如說，如果繪製企業級的應用架構圖，理論上應該包含企業的所有系統以及它們的關係，不能多，也不能少。但是在這個層面，並不需要描述每個系統內部的具體情況，因此並不「詳細」。這裡之所以說「理論上」包含企業的所有系統，是因為實踐中我們推薦採用「浮現式設計」，因此在某一時刻未必能做到理論上的全局完整性。這一點在後面會談到。

示意圖是為了提供一個宏觀視角，用於探索和規劃未來的發展方向，並且向領導或其他干係人彙報。示意圖並不需要十分準確和規範，只需讓干係人能夠理解就夠了，並且這類圖通常不需要持續更新。反過來，藍圖主要用於系統的實際規劃、開發和演進，需要指導落地實施，因此需要強調準確性和規範性。另一方面，只要系統發生了架構意義上的變化，藍圖就應該進行相應地更新，以便作為進一步演進的基線。

在前面舉的那個客戶的例子中，之所以畫了很多示意圖，仍然無法解決企業中的架構問題，就是因為示意圖的準確程度不夠，還不足以發現具體的問題。

我們今天說的建立架構可視化的標準，主要就是針對藍圖來說的。

關係三：系統和產品

在建立架構圖標準之前，我們還要明確一些常見的概念。例如什麼是系統、子系統、發布單元、模塊、組件和產品。這些概念在業界常常存在不同的理解，有些概念儘管在總體上有類似的理解，但又會存在微妙的區別。作為建立企業級架構標準而言，我們既無必要，也不可能追求業界一致的理解，只需要在企業內部建立一個言之成理的定義，並達成一致就可以了。

為了達到這個目的，我們來分析一下這幾個概念，作為大家在自己企業內建立架構標準的參考。

第一個概念是「系統」。在 IT 領域，系統可能是軟體系統、硬體系統或者軟硬體共同組成的系統。

這裡我們主要談「軟體系統」。在後面我們說到「系統」的時候，如果沒有特別說明，指的都是軟體系統。軟體系統可簡稱為「軟體」。在 IT 發展的早期，軟體被分為「系統軟體」和「應用軟體」。系統軟體通常包括作業系統、編譯系統、資料庫引擎等等；應用軟體則是建立在系統軟體之上，用於解決特定業務問題的軟體，例如保險核心業務系統、辦公自動化系統等等。

然而，後來產生了一些軟體，既不像傳統的系統軟體那麼基礎，也不具有特定的業務含義。例如網絡伺服器、應用伺服器和消息伺服器等等。這些軟體介於傳統的系統軟體和應用軟體「中間」，所以稱為「中間件」。

也就是說， 軟體系統可以分為「系統軟體」、「應用軟體」和「中間件」。其中，應用軟體又簡稱為「應用」。英文是 Application，縮寫為 App。前端應用和後端應用都是應用。如果有人說「咱們開發一個 App 吧」，到底指的是前端應用還是後端應用，要根據上下文判斷。如果有歧義，要及時澄清。

一個系統又可以劃分多個子系統。子系統也是系統，只不過相對於它的「父親」而言，是「子」系統。子系統可以向下進一步分成更細粒度的子系統。

一種特殊的系統是「發布單元」，也就是可以獨立部署和運行的最小單位。我們常說的單體應用、微服務，以及介於單體和微服務之間的各種中間形態，都可以統稱為發布單元。

分析完「系統」，我們再來看看「產品」的概念。這裡的產品，我們特指「軟體產品」。

在軟體工程的早期，並沒有產品的概念。然而，隨著近年來敏捷和精益方法的興起，我們開始強調軟體產品。那麼產品和系統之間的區別是什麼呢？

產品一定是面向價值的。假設我們走進一家西裝店，這家店只賣成衣，不單獨賣扣子。而隔壁可能有一家店專門賣扣子。對於西裝店來說，西裝是它的產品，因為西裝為它創造了價值，而扣子則不是。而對於賣扣子的店來說，扣子是它的產品，因為扣子為它創造了價值。所以同一個事物，是不是產品，取決它是否為企業直接創造價值，或者說，取決於企業的業務模式。

回到軟體產品。一個產品就是一個有明確業務價值的系統，比如說銀行支持貸款的系統可以說是貸款產品，支持資產託管的系統可以說成是資產託管產品。一個產品可以是一個單獨的系統，也可以由其他幾個（子）系統組成。另一方面一個系統未必有明確的業務價值。比如說構成企業中台的系統，相對於最終用戶而言，就未必是產品。一個系統可以被多個產品復用。

關係四：規範畫法和自定義畫法

理清了這些基本概念，就可以制定架構圖的繪製標準了。這時候主要有兩種策略，一種是規範畫法，一種是自定義畫法。還有的策略介於兩者之間。

下圖中，我針對同一個系統給出了三種畫法。

最左邊的圖是用 UML 畫的，每個方框都代表一個發布單元。將發布單元括起來的包代表系統。由於 UML 是 OMG 官方的國際標準，這種方式可以稱之為 規範畫法。

最右邊的圖則是 自定義畫法。一個企業可以不使用國際標準，而是自行定義。例如，有的企業可能喜歡用圓角框表示系統，直角框表示發布單元。他們的依賴關係可能用實線箭頭表示，而不是虛線。由於這是企業自定義的，所以一定要有圖例來解釋各個符號的含義。反之，規範畫法一般不需要顯式地給出圖例，因為符號的含義已經被國際標準所定義了。

回憶一下我們前面提到的示意圖和藍圖。如果你看到一個架構圖不是規範畫法，同時又沒有圖例，那它很可能只是個示意圖，而非藍圖。因為藍圖需要有圖例來保證其語義的嚴格性。

中間這幅圖是 C4 模型。這種畫法不算國際標準，但有專門的主頁介紹，也有許多人使用，我稱其為 民間規範。

企業到底選擇哪種策略，取決於自身的偏好。有些人更喜歡遵循業界標準，因為這樣可以減少溝通成本，更容易吸收前人經驗。有些人則覺得業界標準過於複雜，喜歡建立小而美的自定義標準。這沒有絕對的對錯之分，只要能夠解決企業的問題，並且在企業內部保持統一就可以了。

關係五：架構的維度和粒度

由於系統的複雜性，一個企業建立架構描述標準時，往往要包含多種不同的圖，反應了系統的不同角度，這些圖構成了一個體系。為了構建這樣一個架構標準體系，需要考慮兩個方面：一個是 維度，一個是 粒度。下圖表示了某個企業根據這兩個層面設計的架構標準體系。

維度是指從哪個角度看問題，比如業務架構、應用架構、數據架構、技術架構等。 粒度是指架構的覆蓋範圍，比如企業級的架構，需要從公司領導的視角考慮整個公司的範圍，而室組級，只需要考慮開發室組的範圍。

雖然架構圖很重要，但是僅僅通過圖尚不能把架構完全說清楚，還需要結合表和矩陣。TOGAF 認為， 通過圖、表和矩陣這三種工具就可以清楚地描述架構的各個方面。

其中，圖（diagram）用於直觀地展示同一維度內的各個組件及其關係；表（catalog）可以詳述每個組件的具體屬性；矩陣（matrix）可以展示不同維度之間的關係，例如哪些系統支撐了哪些業務，哪些技術支撐了哪些系統等等。

架構可視化的實施

建立了好的架構描述標準，並不一定能保證這些標準能夠順利實施。下面我們再談幾個在實施過程中需要考慮的問題。

關係六：「企業」架構和「企業級」架構

我們遇到一些企業中負責架構的朋友，常常會問這樣的問題：「按照 TOGAF 的說法，企業架構包括業務架構、應用架構、數據架構、技術架構。但是，IT 部門很難驅動業務部門，我們能不能只做應用架構或技術架構呢？如果能的話，是不是就不算企業架構了呢？」

為了回答這個問題，我們需要區分兩個概念：「企業架構」和「企業級架構」。下圖表示了兩個概念的區別。

「企業架構」強調的是端到端的整體性，即從業務架構到技術架構等各個環節，都覆蓋到了。即使不是整個企業做，只要我們完成了所有層面的架構，那就可以叫做企業架構。而 「企業級架構」強調的是橫向，即跨系統、跨部門、跨團隊的設計，至於做哪一個層面，則可以根據具體情況選擇。

所以， 我們不需要拘泥於定義上的企業架構，而是可以從企業級的架構入手。可以根據企業的具體痛點，決定先做企業級的業務架構、應用架構還是技術架構。然後再逐步擴展的架構的其他層面。

關係七：企業級架構師和團隊級架構師

下面再談一下有關架構組織的問題。

舉一個例子。有一家企業，負責公司架構的同事說他們已經開展了兩年的企業級架構工作，公司的 200 多套系統中，90% 都按照統一的標準繪製了架構圖。於是，我去訪談開發團隊。當我讓開發人員向我出示架構圖的時候，卻發現很多人並不清楚哪裡能找到最新架構圖，甚至不清楚誰是自己團隊的架構師。這意味著架構圖沒有真正發揮作用，這家公司可能只是「運動式」地推廣架構工作。這就不再是技術問題，而是一個組織層面的問題了。

關於組織問題，我今天重點說一下 企業級架構師和 團隊級架構師的角色和責任，見下圖。

企業級架構師站在全局架構的視角，關注企業整體目標的達成。他們負責推動整個組織的架構工作，尤其關注跨系統、跨團隊的協作。他們要制定全局性的架構標準和原則，而不需要深入了解每個系統的具體技術細節，但需在原理上有所理解。所以企業級架構師通常是「技術出身」的。此外，企業級架構師也更強調溝通、協作、影響力等軟技能。

另一方面，團隊級架構師會更專注於實現自己系統的目標。一般要深入了解本系統的技術細節，為本系統設計架構方案。並且，要對全局的架構標準進行落地和反饋，也要協助企業級架構師完成全局目標。在上面的例子中，顯然團隊級架構師的職責沒有明確。

總之，不同層面的架構師的職責既有共性又有差異。企業要為不同的架構師建立不同的能力模型，並落地實施。

關係八：當前架構和目標架構

下面再談一個微妙的問題，就是架構設計的時間點。 沒有時間點的架構圖是沒有意義的。

比如說。我們訪談一些企業的架構師時，常常遇到下面這樣的問題。我們讓架構師拿出一張架構圖，然後問他：這個架構圖是當前架構還是目標架構？這個架構師會猶豫幾秒種，然後說這是當前架構。接著，我們開始看架構圖中的一些細節，發現有些和當前生產環境的實際情況不符。於是架構師又改口說，這是當前架構為主，但又有一些未來要優化的地方。我們說，那就不是當前架構了，應該就是目標結構。可是架構師又會告訴我們，有很多需要優化的部分並沒有在圖中反應，因此說是目標架構圖也有些牽強。接著，我們又問，那麼目前圖中優化的部分，計劃什麼時候完成呢？架構師又會猶豫一下，然後給出一個時間點，比如說未來半年或一年。但很顯然，這只是這個架構師現場「拍腦袋」給出的說法，並沒有經過深思熟慮，也沒有正式向任何一方承諾過。所以，我們發現一個有趣的現象，在很多架構師頭腦中，並沒有架構設計的時間點這根「弦」。

關於時間點，首先我們要分清當前架構和目標架構的區別，如下圖所示。

當前架構反應架構的現狀，總是和當前生產環境的系統架構保持一致。可以作為架構演進的基線。

而目標架構通常又可以分為 開發中目標架構、 近未來目標架構和 遠未來目標架構。其中，近未來目標架構直接指導當前疊代的開發，也就是和當前疊代的目標相一致，要求足夠準確和詳盡。而近未來（例如一年後的目標）和遠未來（例如三年後的目標）則表示未來的大體方向，一般比較粗略。

由於架構會不斷演進（儘管比代碼演進要慢），所以要做好架構產出物的版本管理。開發中的目標架構和當前架構可以在同一個版本倉庫中，用同一個主幹管理。而近未來和遠未來目標架構一般要用單獨的倉庫管理。

不同的公司，也可以根據情況採用不同的管理手段，比如說只有一年後的目標架構，沒有三年後的目標架構。不過最基本的要求是，任何時刻，總可以獲得反應當前生產環境的架構描述。

關係九：前期設計和浮現式設計

關於架構設計的過程，又可以有 前期設計和 浮現式設計兩種策略。下圖表示了兩種策略的區別。

前期設計（Big Design Up Front, BDUF）是指在開發一個大項目的早期就設計出所有架構方案；或者在進行企業架構治理早期，就集中一段時間把所有系統的架構都梳理出來。這其實是一種「瀑布模型」的方式。對於大項目的開發，可能造成基於猜測的架構設計，無法真正設計出合理的架構；而對於企業架構治理來說，很容易陷入「一陣風」的運動式實施，難以取得實際效果。儘管近年來敏捷的思想已經比較普及，但在架構治理領域，有時還會見到這種錯誤。

而 浮現式設計（Emergnet Design），則是在項目進行中，根據優先級，不斷細化架構設計，同時又兼顧架構整體的一種方法。是一種符合敏捷開發理念的方式。

可以打一個比方來理解浮現式設計。比如說我們要畫一張世界地圖。一開始就畫得非常詳細是很困難的，而且也沒必要。那麼，我們就可以先把七大洲的大體邊界畫出來，先讓看圖的人知道有七個大洲這件事，以及大體的位置。然後，我們覺得亞洲最重要，就可以把亞洲的邊界畫清晰一點，並且畫出亞洲主要的國家和大體的國界。接著，我們又覺得亞洲里中國最重要，於是可以把中國的邊界畫清楚，然後把中國的主要省市的大體邊界畫出來。同理，我們可能覺得廣東省最重要，廣東省中廣州市最重要，廣州市中番禺區最重要，依次類推。這樣，過了一年，可能我們把中國最重要的幾個城市畫的比較詳細了，而非洲可能還根本沒有細化。但這已經足夠了，因為已經滿足了我們的需求。同時，七大洲的大圖景也基本呈現了出來，只是等著我們在必要的時候「填空」。隨著時間的推移，我們會看到這張地圖越來越詳細，越來越實用。而不同位置的詳細程度則取決於優先級。給人的感覺，就是這張地圖是逐漸「浮現」出來的。企業架構治理的過程，其實也是這個道理。

關係十：手工治理和自動化治理

最後，我們談談通過手工還是自動化的方式進行架構治理，其實就是使用工具的問題。下圖表示了理想的架構治理和設計工具的一些特徵。

企業架構在八十年代就已經提出了。但時至今日，許多企業在實際落地時仍然面臨困難。原因有很多方面。其中之一恐怕是缺乏合適的工具。作為 IT 行業的我們，不斷為業務提供工具支持，但對於 IT 自身的任務，比如架構設計，卻不一定有趁手的工具。這是個有趣的現象，就是俗話說的「燈下黑」吧。

有些朋友說它們已經使用了自動化工具，比如說使用了 Visio、draw.io 等工具來繪製架構圖。不過，這些只是「繪圖」工具，而不是真正的架構工具。繪圖工具只能畫「圖」，而無法理解圖中表達的架構 知識。所以，僅僅依靠繪圖工具，我仍然把它算作「手工」方式。

真正的架構工具能夠理解架構中多維度的、結構化的知識。藉助這些知識，可以自動化地完成很多工作。例如架構設計驗證，架構守護、架構圖生成、API 管理、代碼生成、架構資產庫管理、版本管理等等。

工欲善其事，必先利其器。目前多數企業中的系統都是數量繁多，關係複雜。開始進行架構治理的時候，可以暫時採用手工方式，長遠來看，一款合適的工具是很有必要的。目前國內外有不少工具可供選擇，我們要在功能、價格、成熟度等方面進行權衡。

以上就是我今天想要和大家分享的一些經驗之談，希望對大家能有所幫助。謝謝！

嘉賓介紹

鍾敬，Thoughtworks 首席諮詢師，數字化轉型與運營團隊 DDD 負責人，在 IT 界從業 20 餘年，先後在中多家中外企業任職，帶領團隊成功地開發與維護了多個系統，並負責公司的敏捷轉型及企業架構工作。擅⻓軟體開發方法學、領域驅動設計、企業架構、敏捷及精益方法，企業研發效能提升等。注重學習和推廣軟體開發的最佳實踐，提倡工匠精神。是 Martin Fowler 《分析模式》的譯者，並參與審校了《領域特定語言》的翻譯。在極客時間開設了《手把手教你落地 DDD》課程。

直播預告

ArchSummit（深圳站）全球架構師峰會將於明日開幕！MySQL 之父、AWS 技術大咖、科大訊飛 AI 研究院副院長、騰訊、位元組技術專家屆時會分享架構演進、大數據、大模型實踐案例，點擊下方預約按鈕，預約主會場直播。