画企业架构图这事儿，我见过太多人一上来就打开Visio，对着空白画布发呆半小时，然后从网上随便找个模板往里面填部门名称。结果画出来的东西，要么像一张组织架构图，要么像一张系统拓扑图，老板看了直摇头，IT看了说看不懂，业务看了说这不是我们。问题出在哪儿？出在你根本没搞清楚企业架构图到底要解决什么问题，就直接跳到了“怎么画”这一步。架构图不是给外人看的装饰品，它是给内部人用的作战地图——你连要去哪儿打仗都没想清楚，画出来的地图自然没人认。

先别急着打开工具，第一步是确定这张图的“观众”和“目的”。这听起来像废话，但90%的人栽在这上面。如果你是画给CEO看的，他要的是“公司怎么赚钱、钱怎么流动、关键节点在哪”；如果你是画给技术团队看的，他们要的是“系统之间怎么交互、数据往哪儿走、哪里是单点故障”；如果你是画给新员工看的，他们要的是“我在这家公司里处在什么位置，我的上下游是谁”。同一家公司，三种观众，画出来的图完全不一样。所以动笔之前，先问自己三个问题：谁看这张图？他看完之后要做什么决定？我现在掌握的信息够不够支撑他做这个决定？如果第三个问题的答案是否定的，那你缺的不是画图技巧，是业务调研。

确定好观众和目的之后，下一步是收集素材。这里我要泼一盆冷水：你脑子里的企业架构，和你实际跑起来的企业架构，大概率是两回事。我见过一家做跨境电商的公司，架构图上画着“订单系统”和“库存系统”是分开的两个模块，结果一查实际代码，订单模块直接查库存表，俩系统的数据库是同一个。这种“图上分离、实际耦合”的情况太常见了。所以画图之前，你得去跟业务部门聊，跟开发聊，跟运维聊，把真实的业务流程、系统依赖、数据流向摸清楚。别怕麻烦，这一步省下来的时间，后面会以十倍的成本还回来。你可以用简单的表格先列出来：业务能力有哪些、支撑的系统有哪些、数据在系统之间怎么流转、哪些是核心链路、哪些是边缘模块。

素材收集完，别急着画，先画一张“草图版”的架构图。这个阶段不用管美观，不用管对齐，甚至不用管逻辑顺序，就是把所有收集到的信息摊在纸上。我习惯用便利贴或者白板，把每个业务模块、每个系统、每条数据流都写下来，然后开始拼图。这个过程特别有意思，你会发现很多之前没意识到的问题：比如订单流程里居然有三个系统都在处理支付回调，比如客户数据存在四个不同的地方，比如某个核心系统居然没有备份。这些问题在画草图的时候都会暴露出来。草图的价值不在于“画得对”，而在于“暴露错”。你暴露的问题越多，说明你对企业的理解越深，画出来的正式版架构图才越有价值。

草图理清楚之后，才开始考虑分层。企业架构图最常用的分层方法是“业务架构-应用架构-数据架构-技术架构”四层模型。业务架构在最上面，画的是业务流程、组织能力、价值流；应用架构在第二层，画的是有哪些应用系统、它们之间怎么交互；数据架构在第三层，画的是数据实体、数据流向、数据存储；技术架构在最底层，画的是基础设施、中间件、网络。这里有个常见的误区：很多人把四层画在一张图里，结果图密得像蜘蛛网，谁看了都头疼。我的建议是，如果你只画一张图，那就画“业务+应用”两层，这是老板最关心的；如果你要画完整的企业架构，那就分开画四张图，每张图聚焦一层。别贪心，一张图画清楚一件事，比一张图画四件事但什么都看不清强得多。

画图工具的选择，其实没那么重要。我用过Visio、Lucidchart、甚至用PPT画过。工具的核心功能就三个：画框、画线、加文字。真正决定架构图质量的，不是工具，而是你的“构图逻辑”。这里分享一个我常用的构图原则：从左到右代表流程顺序，从上到下代表层级关系。比如业务架构图，左边是客户入口，中间是核心业务流程，右边是支撑流程；应用架构图，上面是前端应用，中间是核心业务系统，下面是基础服务。这样画出来的图，读者一眼就能看出“什么东西在前、什么东西在后、什么东西在上、什么东西在下”。别小看这个习惯，很多新手画图喜欢从中间开始画，结果越画越乱，都不知道线往哪儿连。

线条和连接关系，是架构图里最容易画砸的地方。我见过太多架构图，线条密密麻麻，交叉来交叉去，看着像一碗面条。这里有两个实用技巧：第一，尽量用“总线式”布局代替“点对点”连接。比如五个系统都要调用同一个认证服务，别画五条线都指向认证服务，而是画一条总线，标注“所有系统通过API网关调用认证服务”。第二，能用“数据流”说明的，别用“调用关系”说明。有时候两个系统之间没有直接的接口调用，但它们共享同一个数据库，这时候画一条虚线，标注“共享数据库”就够了，不用画实线箭头。记住，架构图上的每条线都代表一种关系，你要让看的人一眼就明白这条线是什么意思，而不是让他猜。

画完之后，别急着提交，先做一轮“自我审查”。我有个习惯，画完图之后，我会假装自己是一个刚入职的新员工，从左上角开始，沿着图的路径走一遍，看看能不能走通。比如我看到“客户下单”这个框，往下看有没有对应的“订单系统”，订单系统旁边有没有“支付系统”，支付系统下面有没有“银行接口”。如果走到某个节点突然断了，或者要跳来跳去才能找到下一个节点，那说明这个图还有问题。另外，检查一下命名是否统一。比如你在业务架构里叫“客户管理”，在应用架构里叫“CRM系统”，在数据架构里叫“客户表”，这三者之间要建立清晰的对应关系。最好的做法是在图上直接标注“业务能力-应用系统-数据实体”的映射关系，让看的人一目了然。

记住一条铁律：架构图是活物，不是死文档。企业架构每季度都在变，系统在升级、流程在优化、组织在调整，你的架构图如果半年不更新，基本就废了。我建议你每次画完图之后，在图上标注一个“版本日期”，并且设定一个更新周期——比如每季度至少检查一次，每次有重大变更时必须更新。同时，把架构图的源文件放在团队共享的网盘或知识库里，别只存在你自己电脑里。你画这张图的终极目标，不是展示你的画图技巧，而是让整个团队对“企业是怎么运转的”达成共识。如果这张图能做到这一点，哪怕画得丑一点，它也是一张好图；如果做不到这一点，画得再精美，也只是个贵重的摆设。从零到一，画一张能用的图，比画一张好看的图，重要得多。