#ARCHITECTURAL AND PROGRAM DIAGRAMS HOW TO#
#ARCHITECTURAL AND PROGRAM DIAGRAMS SOFTWARE#
#ARCHITECTURAL AND PROGRAM DIAGRAMS PLUS#

The practical utility of just having a huge whiteboard on the wall that everyone can see with a bunch of different coloured pens that anyone can pick up is enormous. I’m a big fan of remote working in general but with current tools we’ve definitely lost something in this area. Drawing diagrams takes for-fricken-ever so people tend not to do it in meetings. This doesn’t happen (IME) with remote work. One thing I miss about in-office work is that people would spontaneously draw diagrams in meetings. When somebody starts making changes to a diagram in a remote meeting, it’s a sign you’re going to be there for a long, long time. It really lacks the collaborative value of someone walking up to the whiteboard and saying “what if we did this,” not hesitating to make changes because they can do it in ten seconds and then wipe out their changes and redraw the original in few seconds if they want. Best case, someone shows up with a diagram, and it stays up while people talk about different ways of doing it, and after the meeting someone makes the changes that were suggested. It was like a tribe singing the same songs over and over again, trying out variations and evolving the “official” version over time. And everybody did it, so everybody was rehearsing the architecture in their heads and had a basic grasp of it.

The same diagrams would get drawn over and over again, evolving.

#ARCHITECTURAL AND PROGRAM DIAGRAMS SOFTWARE#

But a clean, well-thought-out diagram makes the relationships easy to understand and remember.ĭo you love well-documented software products? We do too.For this reason I love drawing diagrams on whiteboards and absolutely hate taking the step of putting them into a wiki/README/etc.

#ARCHITECTURAL AND PROGRAM DIAGRAMS PLUS#

Some clients like to be able to review work on paper, plus it’s a nice printable for engineers to keep on their desk as a quick reference while working on the project.Īfter moving through these steps, that original whiteboarded draft will look something like this:Ī complex system of databases, servers, and APIs could take hours to explain. Size your diagram to print on a standard 8.5” by 11” piece of paper.Make sure your use of icons is consistent if you’re using the same icon more than once, it should represent the same thing each time.This isn’t just about aesthetics: using color, iconography, and other design elements will help make your diagram easy to understand at a glance. Getting a fresh perspective always makes your work better. After making your initial draft of the diagram, get feedback from your teammates: does the diagram make sense? Are you leaving out any important systems or relationships? On our latest system architecture diagram, our reviewers recommended we add dotted lines to show when we are using a tool to run several functionalities separately. Complexity and details can be added in later diagrams, but this draft is the first of many. At this point, we recommend keeping it simple: this kind of diagram is meant to be a high-level overview of an entire system. Take your whiteboard diagram and recreate it in the design program. If you are already confident with a design tool like InDesign or Figma, great! If not, we recommend a tool like Miro, which is easy to use for non-designers and has a robust icon library. Here’s what one of our recent whiteboard sessions looked like: Write down every element of the system that you can think of, then use lines and arrows to show how they connect to each other. But the diagramming process doesn’t have to be complicated!

#ARCHITECTURAL AND PROGRAM DIAGRAMS HOW TO#

How to diagram system architecture for software products Here’s how we create system architecture diagrams. A good diagram also helps our clients and their stakeholders fully understand how our work interacts with their other existing systems, and gives them the information they need to do further enhancements in the future.

Thoughtful documentation (like a system architecture diagram) is a way to show empathy for other coders by helping them quickly acclimate to complex projects. As part of our final project handoff to Tandem clients, we provide a diagram of the product’s architecture - a visual depiction of the various systems, platforms, and tools that work together to support a software product.Īt Tandem, documentation is more than just a best practice: it’s a way we demonstrate our values.

Architectural and program diagrams