The widespread popularity and extensive use of Microsoft's PowerPoint is a testament to its reliability and effectiveness. Many of us have spent countless hours in the tool.
Even if it primarily a presentation tool it's often used as a general drawing tool and for create everything from a dazzling company presentation to an architectural sketch for a building — and almost everything in between.
It's easy to understand and use. We're all familiar with their basic drawing tools like the box and line tool etc, making us productive within minutes.
In many ways, it's the computer version of a Swiss army for getting some visuals done quickly.
Trying to describe the complexity of a system architecture to someone else can be challenging. Visual diagrams are often the most effective way to convey this information.
However, when using a general drawing tool like PowerPoint, there are certain features that are lacking for accurately representing system architectures.
It's usually a bad idea to describe too much in one diagram; the more we describe in a single diagram, the harder it becomes to understand and follow.
As we squeeze in more details, we also mix the overall architectural views with technical details such as what protocols are used to transfer data, what technical components are used to implement a subsystem in our architecture, etc.
The problem with this is that these details usually cater to different types of readers. The overview views are often very useful for business uses and architecture, while the more technical details are critical for developers and low-level architectures.
The C4 model addresses the issues and describes four levels of diagrams, with instructions and examples of what details should be in each and what type of reader they are mainly for.
As we split diagrams into different levels, we created a hierarchy of diagrams. It is crucial to link them together, enabling seamless navigation between them and facilitating readability and understanding.
In a general drawing tool like PowerPoint, objects are not reusable. If we change the name of a component in one diagram, we have to manually update it in all other places. This lack of reusability can lead to inconsistencies and extra effort.
Furthermore, general drawing tools do not provide a way to query diagrams for deeper insights. For example, it's not possible to easily identify all dependencies to a specific component across multiple diagrams or list all databases and the components that interact with them.
To address this limitation, people often resort to creating separate lists in applications like Excel to accompany their diagrams, adding extra complexity and maintenance overhead.
General drawing tools are super versatile, making it hard to maintain a shared style and form across multiple diagrams. At first, that might not feel like a problem. However, diagrams with different looks and feels are more challenging to read.
Icons are often used to let readers quickly see and understand what a component represents, such as a database, a queue, etc. Here, however, we have a similar problem. It takes a lot of work to impose a set of icons that should be used.
We then spend a lot of time aligning things, trying to make it look similar to an earlier diagram. We spend a lot of time finding the right set of icons over and over again.
There are various specialized tools available for describing and documenting system architectures. These tools range from advanced enterprise architecture tools to lightweight options like Revision.
When selecting a tool to supplement a general drawing tool, it's important to choose one that retains the ease of use and productivity that made the general tool popular. The ideal tool should be easily understandable for both readers and creators, allowing for quick productivity.
Revision is a specialized tool for creating system architecture diagrams that are easy to read and create. The tool offers a range of specialized features to enable users to create diagrams efficiently with minimal effort.