其實，不僅僅是架構師，產品經理也需要了解一些有關架構圖的知識，因為在具體場景下，架構圖可以更直觀地表述信息，進而幫助別人理解系統/業務/功能的結構。那麼，架構圖該怎麼畫？一起來看看本文的梳理。
其實，不僅僅是架構師，產品經理也需要了解一些有關架構圖的知識，因為在具體場景下，架構圖可以更直觀地表述信息，進而幫助別人理解系統/業務/功能的結構。那麼，架構圖該怎麼畫？一起來看看本文的梳理。
架構圖，聽起來好像只跟架構師有關係的一個高級的概念。
通過搜尋引擎，我們可以找到各式各樣的架構圖，功能架構圖，系統架構圖，技術架構圖，數據架構圖……
剛開始接觸，很多小夥伴可能就會覺得摸不著頭腦。這麼多架構圖，之間有啥關係？到底應該怎麼畫？
我就根據自己的學習和理解，來講講應該怎麼畫架構圖。
01
作為產品經理，溝通能力的重要性不言而喻，不管在什麼行業一直都是被強調的。
溝通的本質是傳遞信息，信息的載體可以是文字，圖片，視頻……
圖形相比文字，可以承載更多的信息，更直觀的表達信息。在產品設計場景中，能夠直觀有效的幫助別人去理解系統/業務/功能的結構。
所以繪製架構圖也是我們所必須掌握的一項「技能」。
開頭描述的這麼多種類架構圖，怎麼學，怎麼畫，都要畫麼？
實際上，在製作架構圖的時候，也很難說清楚，這個到底是業務架構圖，還是功能架構圖，還是產品架構圖。
因為在結構上確實體現不出太大區別。
對於一個系統而言，上層是業務應用，底層是技術支撐，都是用來描述系統的情況。
在這裡，我們可以將架構圖分為「業務/系統架構圖」，「技術架構圖」兩類就可以了。
作為產品經理，這裡我們就主要去講述「業務/系統架構圖」的繪製。
技術架構圖我們可以不用畫，但是最好能看得懂，比如系統用了哪些技術框架，技術工具，通過什麼傳輸數據，計算數據等。
可能就有小夥伴說為什麼是兩類？業務、系統、技術不是三類麼？
業務架構圖和系統架構圖，兩者的我的理解是兩者其實是一種東西，偏向不同，一個偏向業務形態/業務流程，一個偏功能模塊/系統之間的關系。
系統架構圖中可以體現業務關係，業務架構圖中也可以體現系統關係。最後如何定義需要根據內容偏向決定。
02
如何畫架構圖？
可以通過兩種方式構建架構圖。
1）靜態展示：系統包含哪些模塊，模塊之間的包含與被包含、上下層級關係。
類比車子結構，包括車輪，車窗，方向盤等。
以這種形式，系統架構圖可以展示當前有哪些系統模塊，上層應用模塊，底層支撐模塊，著重表現不同模塊之間的作用和關係。
對於車子來說，我們明顯能接觸到的有儀錶盤，方向盤，中控台，車座等；內部有發動機，變速箱，傳動軸；外部有車輪，車身，底盤等結構。
2）動態展示：系統之間的的數據流向，機制。
比如打火，發動機工作，踩油門，傳動車輪，剎車等流程。甚至系統可以往外擴展， 加油站，停車場等「系統」之間的關係。
這種形式可以去剖析整個系統模塊間的使用流程，先後順序。系統與外部系統之間的交互機制。
03
再以數據資產目錄舉例。
我可以從不同層次，對用戶使用的，管理員配置的，底層支撐的不同模塊進行靜態展示。
這樣就能清晰的展現這個系統有哪些模塊，這些模塊之間的作用和關係是什麼。
同時，也可以從系統動態的角度，說明系統的機制，數據的存-管-用流程。並說明系統與外部系統之間的關係。
說完了方法，我們仍要注意的是：
- 架構圖在表達上是有優勢的，能突出重點，但是也會忽略細節。切記大而全，什麼都往裡塞，否則就講不清了。
- 不管使用哪種方式。首先需要明確要表達的內容，表達的目的。
- 選擇一個角度，去剖析業務/系統關係。
- 畫架構圖需要因地制宜，不要照抄照搬，解釋不清會鬧笑話的嘞。
本文由 @清小墨 原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議