logoalt Hacker News

More common mistakes to avoid when creating system architecture diagrams

51 pointsby billyp-rvatoday at 11:51 AM20 commentsview on HN

Comments

icedchaitoday at 3:39 PM

The biggest mistake is not knowing your audience.

Is the diagram for marketing? A sales proposal? A business person using the product? Technical peer?

If you don't know this, you don't know if you have the right level of detail.

show 1 reply
orthoxeroxtoday at 1:44 PM

The most common mistake I've seen is not agreeing on what arrows represent: control or data. Does A-(customer data)->B mean A asks B for data or A sends customer data to B?

Of course, sequence diagrams make it clear with two separate arrows when control and data flow in different directions, but a lot of diagrams are of the "plain old boxes and arrows" variety.

show 4 replies
dawnerdtoday at 2:05 PM

This is just an advertisement for their service.

In my 20 years in this field I can easily count on one hand the times a diagram like this has been useful. I’ve seen more cases where they were clearly created to satisfy some exec that wanted to see it and never updated again.

zabzonktoday at 1:01 PM

Couple of comments:

> This can be as simple as adding a type suffix to a resource name (e.g. Orders Table, Results Bucket)

Don't encode types in names. And I disagree somewhat that the names are really needed at all.

> Making a “master” diagram

I think such a diagram is useful but obviously each top-level "box" in it doesn't need to contain all sub-components.

show 2 replies
raw_anon_1111today at 2:52 PM

My thought process is that a diagram should stand on its own and should be understandable by non technical business people. I always have callout notes as stickies on the diagram explaining what it does.

datadrivenangeltoday at 1:16 PM

Diagrams are communication tools, and are best done with a target and goal in mind. The C4 framework is good for addressing multiple levels of abstraction and different types of viewers. The business execs don't need the level of detail that someone debugging the system does.

ashwinnair99today at 12:47 PM

The worst ones are diagrams that look clean but hide all the decisions that actually matter. A messy diagram that shows the real tradeoffs is more useful than a pretty one that lies

show 2 replies
kingforadaytoday at 1:45 PM

Their master diagram example in #3 contains a #2 mistake with an unconnected resource (the stripe account). Maybe a double validation of why the master diagrams can be hard to maintain.