Guidelines for making clear architecture diagrams

I'm the founder of a startup that makes a diagramming software for engineering team called Eraser.

If you want a codified set of rules that you can mechanically apply, I would look at UML and C4. However, I'd argue that the frameworks are overkill for the vast majority of engineering diagram use cases.

For the general scenario where you're just trying to communicate a technical concept clearly without spinning your wheels a lot, here are a few tactical things I'd recommend:

1. Pick the right diagram type for the job. Sequence diagrams are great for API documentation, ERDs are great for database schemas, flow charts are great for user flows, data flows and logical flows.

2. Use icons where possible. A database icon, a S3 bucket icon, a cylinder shape are all a lot more expressive and easier to grok than a rectangle with text inside that says "database".

3. Focus on the nodes, groupings, and connections. That's really all there is to a diagram if you break it down. If you just make a list of nodes, groups, and connections that you want to represent, the diagram will almost just draw itself.

4. If you're looking for a quick way to start jump start a diagram or looking for inspiration, try AI tools to see how far they can get you.

Might seem obvious, but “don’t try to express everything one diagram” is some of the best advice I could give.

I like the idea of breaking down by Viewpoints and Perspectives, from the book Software Systems Architecture.

https://www.viewpoints-and-perspectives.info/

As far as guidelines, I have spent time looking as well an never came away with a good answer. One useful website for comparing some of the best tools is https://text-to-diagram.com/. My personal favorite is D2. Still lacking a few layout features that I want, but it gets me 90% of the way there. The syntax is great for projects big to small, and it strikes the perfect balance between "create a diagram fast" and "feature rich". But in terms of actual guidelines, I would agree with another user that C4 actually tries to lay out some sort of guidelines.

I like the C4 Model as a guide on the different levels of abstraction that you might need for your system.

There are few standards and there is also definitely some art to it. If you include too much detail, it's confusing and busy. If you include too little, it may not convey anything useful. You should also really need to know your audience. Is it a potential investor, a B2B customer, or another engineer? All these may ask for "architecture diagrams" and mean something totally different.

There is. UML diagrams for software, Archimate or C4 diagrams for architecture, value stream for process performance. But depending on the audience you may end up needing to use simple box and line diagrams and they work well too. Draw.io is probably the best drawing tool out there and has enough libraries of shapes to get you started.

After years of using Visio/Plant UML, or similar products that allow you to write clear charts, I am enjoying the freedom of constraints that Excalidraw gives you. It feels a lot more like whiteboarding somehow. Now they have an AI gen feature to kickstart your chart as well. Give it a try. In terms of types of diagrams I create, it's mostly flow or sequence diagrams, but they are not super clear cut.

- Be very mindful of the "level of recursion" you are trying to express - i.e. how many trees to include when it should be a forest.

- Look into the C4 model - that is great for expressing architecture.

- Have a Miro board with multiple versions and working charts.

- Make at least one that reflects the full process, and one chart that reflects the relationships between components.

- Keep it simple, and avoid creating DoD style monstrosities. if you find yourself in that situation it means either you are mixing up recursion levels, or are not very clear on the purpose of the chart and the audience.

- Boxes and arrows are enough

- I personally have benefited from UML style charts, others hate them.

- Domain Driven Design and Event Storming style maps are also very clear way to express things.

- Most importantly - remember that an architecture is not a static thing, but a living, changing and ever-evolving thing. Like a garden.

Also an engineer doing software. The best book I’ve found for this is “Documenting Software Architectures” by Clements et al. It’s a lot but it shows different reasons to use different styles of diagrams and when they are appropriate. For instance, when it comes to creating diagrams for certain stakeholders versus others or when the system is structured in a certain way, certain diagramming techniques would be better than others.

Keep it simple and use https://c4model.com/

~25 years ago ... I would have UML or, more classically, an ERD or even a flow chart

The only diagrams I have seen in the last decade or two, though, have been Visio (or a similar tool) meant to explain the product's functionality (including where and how it scales) to customers, PS folks, etc

https://icepanel.io/

The best i've ever used.

Conventions exist but they're mostly crap (eg. UML).

Along the KISS principle, boxed elements with connecting lines are the best (simplest, most universally understood, least amgbiguous). In mathematical terms they are an 'undirected graph', a 'directed graph' is the same but with directionality ("arrows") on the links between nodes. https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) The standard toolkit since at least 1991 for defining these in software is https://graphviz.org/

If you need to show the interaction between elements over time in a distributed or complex system, the standard is the message sequence chart https://en.wikipedia.org/wiki/Message_sequence_chart. The best (ie. most long term stable) tool for this be https://www.mcternan.me.uk/mscgen/ which is graphviz-inspired.

There are a plethora of latter-day derivatives such as web-native versions, stylized versions, etc. but these are all functionally irrelevant if you want to be clear, portable and maintainable. Lists of them are frequently posted to HN. The basic workflow is "want to communicate something", "define in text" (which can be done by code), "have image generated", optionally go back and refine.

The core problem with using web based services, as less experienced / more youthful respondents will suggest, is that they appear and disappear like the javascript frameworks they tend to be built on and thus are a poor match for nontrivial projects with potential medium to long term maintenance and availability requirements. The core problem with Visio and Visio-inspired solutions is that they are WIMP https://en.wikipedia.org/wiki/WIMP_(computing) based and thus tend to require manual clicking and placement which is tedious at best and totally unsuited to any at-scale / automation-related requirements.

There are also advanced features of these tools which can create complex diagrams like tabular protocol structure diagrams or database structure diagrams, clickable versions, color highlights, and SVG interactive diagrams.