架构图画了三个月，业务方还是看不懂：问题不在画工

架构评审会上最尴尬的时刻，往往不是被挑出错，而是业务方看了三分钟，然后问一句："所以这个跟我们有什么关系？"

这时候常见的反应是回去把图画得更细、更全、更漂亮。但问题几乎从来不在画工。它在于这张图从一开始就没有确定读者是谁。

一、你画的是「系统全景」，他们要的是「我的业务怎么跑」

架构师习惯从系统出发组织信息：有哪些系统、谁调谁、数据往哪流。这套组织方式对做集成、做选型的人极其有用，对业务负责人则几乎无效——因为它没有回答对方脑子里那个问题：我这条业务线，从客户下单到收款，中间经过哪些环节，哪一环最容易卡？

同一套事实，换一个组织轴（按价值流而不是按系统），业务方立刻能读懂。图不用重画，是叙事顺序要换。

二、一张图承载了四层信息

最常见的"看不懂"，是把业务活动、应用系统、数据实体、部署节点全塞进一张图。作者画的时候有先后顺序，所以自己看得懂；读者面对的是最终成品，没有那个顺序。

一个粗暴但有效的判断标准：如果你需要讲解超过 90 秒，别人才能开始提问，那这张图承载的信息就超标了。拆成两张，各自回答一个问题，总时长反而更短。

三、图上全是系统名，没有业务语言

"MDM 同步至 CRM，经 ESB 落 ODS"——这句话里没有一个词是业务方日常使用的。他们说的是"客户信息改了之后，什么时候能在报表里看到"。

这不是要求架构图变得不专业，而是给不同读者的图要用不同的词表。同一个组件，在业务视图里叫"客户主数据"，在应用视图里叫"MDM 系统"，在技术视图里才出现具体产品名。三张图，三套词，指向同一个东西。

四、画完没有「所以呢」

大量架构图停在"现状是这样"。但读者真正要的是判断和行动：哪里有问题、有多严重、下一步动哪里。

一个成本很低的改法：在现状图上叠一层标注——用颜色或角标标出"重复建设""单点依赖""数据来源不唯一""无owner"。图还是那张图，但它从描述变成了论证。评审会的讨论质量会立刻不一样。

一个可操作的做法：先写读者，再画图

动笔之前先填这张表，填不出来就说明还不该画：

注意最后一列：四个读者，四张图。试图用一张"全景图"同时服务四类人，结果通常是四类人都用不上。

上评审会前的检查清单

1. 这张图的唯一读者是谁？能说出具体岗位吗？
2. 它回答的是哪一个问题？能用一句话写在标题里吗？
3. 图上的词，读者日常会用吗？有没有混进另一层的术语？
4. 不讲解的情况下，读者能否在 90 秒内提出第一个有效问题？
5. 图上有没有标出"哪里有问题"，还是只有"是什么"？
6. 看完之后，读者知道下一步该做什么决定吗？

写在最后

架构图的价值不在于完整，而在于让特定的人做出特定的判断。一张只回答一个问题、但读者当场就能接上话的图，比一张覆盖全公司却没人敢提问的全景图有用得多。

下次被要求"画一张全景架构图"的时候，值得先问一句：这张图打算给谁看，看完要做什么决定。这个问题问清楚了，图往往会小一半，也有用一倍。