⚡️ TL;DR
- Diagrams are helpful visual artifacts to represent complex systems in an understandable way.
- Modelling focuses on defining a source of truth for objects and relationships.
- Modelling has a higher initial cost to create and requires discipline to maintain, but is more consistent and accurate than standalone diagramming.
- Combining diagramming with modelling can be a powerful way to get the benefits of accuracy, consistency, and speed.
↩️ A quick recap on the C4 model
The C4 model is a lightweight framework for documenting software architecture. With a simple set of abstractions and 4 main diagram types, it’s easy to learn, so you can focus on what matters most — your architecture.
Read more about the C4 model in our introductory guide here.
✍️ Why do we diagram?
As they say, pictures are worth a thousand words. Diagrams help us understand complex systems, and it’s scientifically proven that visuals are more memorable than words (read more about the Picture-Superiority Effect).
When it comes to software architecture, diagrams are critical abstractions for how your system works. As systems become complex and teams are carved out to own specific areas, understanding code at scale becomes challenging. Diagrams are critical for sharing context across teams and disciplines. A business stakeholder or PM might not be able to understand code or technical jargon but show them a well-thought-out diagram, and it becomes immediately clear.
🆚 Modelling vs diagramming
There are endless diagram tools today (try searching for “software diagram tools”). Most of these tools are optimized for speed of creation. You jump into the tool, drag and drop many objects, add connections, and share them with your team to make a quick decision. With AI, diagrams are now being auto-generated from code or a prompt in a few seconds (with a few inaccuracies that need to be corrected). These types of diagrams are helpful if your goal is to make architectural decisions quickly in a contained problem area.
Modelling is different because the goal is accuracy. With a model, you define the source of truth of objects and relationships in your architecture. This model can then create different views, such as diagrams, dependencies, and more.
The upfront cost of defining a model is higher compared to regular diagramming. Objects need to be named correctly, have detailed meta-data assigned, and cover the scope of the entire system. We believe there’s a lot of value in doing some manual work at the beginning to ensure your model is accurate. From our experience, plain old modelling with team collaboration is valuable and allows teams to move faster over time.
The initial work to define your model gives you several benefits in the long term:
- Adding objects in a diagram pulls from the model, so you don’t need to create duplicates.
- Changes and edits to model objects are immediately synced across all diagrams and views.
- Structured data allows you to extract insights such as dependencies and risk areas.
- Everyone on your team has a source of truth to reference.
📋 Modelling vs diagramming comparison
🔮 The future of modelling
The question isn’t about whether you should be modelling or diagramming. There’s a time and place for both. Diagrams are helpful when you want to visualize complex ideas quickly. Modelling is useful when you care about accuracy and having a source of truth. Combined, modelling and diagramming can be immensely valuable.
There are plenty of diagram tools to choose from, but there’s been less innovation in model-based tools. Part of that is a by-product of the move fast and break things culture that’s become so prevalent today. And let’s be honest, documentation and manual work aren’t fun (our goal is to bring a bit more joy to this). Lately, we’ve started to see a swing back from a pure focus on speed to accuracy and a bit of rigour. Often, teams realize that they need to slow down once they scale and experience the pain of lack of documentation. Documentation might not be as necessary when you’re an early-stage startup trying to find product-market fit, but once you’ve built something that enough people are using, it becomes critical.
If you’re building software for the long term, having an accurate depiction of your software is really important. Systems are becoming more complex, with microservices, event-based architectures, and AI being widely adopted, and so we anticipate a growing need for teams to supplement their diagramming with model-based tools. Teams need to move fast and responsibly.
🏁 Next up
Now that you have a good understanding of the C4 model, how it compares to UML, and how it can be used to make diagramming more efficient, you’re ready to start your modelling journey in IcePanel.
