架构图该怎么画？
其实，不仅仅是架构师，产品经理也需要了解一些有关架构图的知识，因为在具体场景下，架构图可以更直观地表述信息，进而帮助别人理解系统/业务/功能的结构。那么，架构图该怎么画？一起来看看本文的梳理。
架构图，听起来好像只跟架构师有关系的一个高级的概念。
通过搜索引擎，我们可以找到各式各样的架构图，功能架构图，系统架构图，技术架构图，数据架构图……
刚开始接触，很多小伙伴可能就会觉得摸不着头脑。这么多架构图，之间有啥关系？到底应该怎么画？
我就根据自己的学习和理解，来讲讲应该怎么画架构图。
01
作为产品经理，沟通能力的重要性不言而喻，不管在什么行业一直都是被强调的。
沟通的本质是传递信息，信息的载体可以是文字，图片，视频……
图形相比文字，可以承载更多的信息，更直观的表达信息。在产品设计场景中，能够直观有效的帮助别人去理解系统/业务/功能的结构。
所以绘制架构图也是我们所必须掌握的一项“技能”。
开头描述的这么多种类架构图，怎么学，怎么画，都要画么？
实际上，在制作架构图的时候，也很难说清楚，这个到底是业务架构图，还是功能架构图，还是产品架构图。
因为在结构上确实体现不出太大区别。
对于一个系统而言，上层是业务应用，底层是技术支撑，都是用来描述系统的情况。
在这里，我们可以将架构图分为“业务/系统架构图”，“技术架构图”两类就可以了。
作为产品经理，这里我们就主要去讲述“业务/系统架构图”的绘制。
技术架构图我们可以不用画，但是最好能看得懂，比如系统用了哪些技术框架，技术工具，通过什么传输数据，计算数据等。
可能就有小伙伴说为什么是两类？业务、系统、技术不是三类么？
业务架构图和系统架构图，两者的我的理解是两者其实是一种东西，偏向不同，一个偏向业务形态/业务流程，一个偏功能模块/系统之间的关系。
系统架构图中可以体现业务关系，业务架构图中也可以体现系统关系。最后如何定义需要根据内容偏向决定。
02
如何画架构图？
可以通过两种方式构建架构图。
1）静态展示：系统包含哪些模块，模块之间的包含与被包含、上下层级关系。
类比车子结构，包括车轮，车窗，方向盘等。
以这种形式，系统架构图可以展示当前有哪些系统模块，上层应用模块，底层支撑模块，着重表现不同模块之间的作用和关系。
对于车子来说，我们明显能接触到的有仪表盘，方向盘，中控台，车座等；内部有发动机，变速箱，传动轴；外部有车轮，车身，底盘等结构。
2）动态展示：系统之间的的数据流向，机制。
比如打火，发动机工作，踩油门，传动车轮，刹车等流程。甚至系统可以往外扩展， 加油站，停车场等“系统”之间的关系。
这种形式可以去剖析整个系统模块间的使用流程，先后顺序。系统与外部系统之间的交互机制。
03
再以数据资产目录举例。
我可以从不同层次，对用户使用的，管理员配置的，底层支撑的不同模块进行静态展示。
这样就能清晰的展现这个系统有哪些模块，这些模块之间的作用和关系是什么。
同时，也可以从系统动态的角度，说明系统的机制，数据的存-管-用流程。并说明系统与外部系统之间的关系。
说完了方法，我们仍要注意的是：
- 架构图在表达上是有优势的，能突出重点，但是也会忽略细节。切记大而全，什么都往里塞，否则就讲不清了。
- 不管使用哪种方式。首先需要明确要表达的内容，表达的目的。
- 选择一个角度，去剖析业务/系统关系。
- 画架构图需要因地制宜，不要照抄照搬，解释不清会闹笑话的嘞。
本文由 @清小墨 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议