What do we need to visualize architecture for and do we really need it?
Visualization of software architecture is often a neglected element in enterprises. This results in the fact that often providing a new solution or developing an existing one is very complicated. Not having insight into the whole context of the system, it is difficult to suggest how it can be built or even expanded. It is also much more difficult to introduce new people into the project.
What do we really need to visualize architecture for:
- To have a system navigation map
- To present the structure of the system (not only the solution itself, but also its environment)
- To provide a common understanding or purpose
Complicated architecture visualization
We know that sometimes, even though we have documentation of the solution and the architecture itself, it is often outdated. What it comes from? The point is that it was usually a very complicated process, requiring knowledge of specific notations like UML, which is not always understood by everyone and besides, let’s face it – this notation is slowly becoming forgotten. There are also architecture modeling languages such as ArchiMate but to use it in large enterprises we also need to be sure that it will be understood not only inside the company but also in related entities such as suppliers of other software related solutions.
Using complicated notation can therefore bring more problems than benefits.
How can we solve this problem?
To resolve this problem
To solve this problem, the C4 model was created, which thanks to its simplicity allows us to operate on one level of abstraction, shows the components of architecture from this level of abstraction and the interactions between them.
C4 Model elements
As part of the C4 model, we can distinguish:
As we mentioned C4 notation is very simply and we can prepare diagram using elements presented below:
C1 – System Context diagram
This is the first, most general diagram at a high level of abstraction. It presents the context of one system showing actors and all dependencies. As we can see there are no details about implementation like technology stack, protocols etc..
C2 – Container diagram
Using container diagram, we are able to show exact parts of whole solution. On this diagram we can see name of element, responsibility, technology stack and interaction between parts of solutions.
Using our diagram from c4model.com site we can see that for example Customer can use Web application to visit bank site or mobile app to view account balance, make payments etc. Also, we can see that Mobile app and Singe-Page Application use API to communicate with database element and other banking systems.
C3 – Component diagram
Using component diagram, we zoom into individual container. Inside this diagram we show components with their name, responsibility, technology stack and interactions. For example, we can show mobile app which call API using REST calls (JSON/HTTPS) to Sign In Controller. Then Sign In Controller calls Security Component to read data from Database. Also, on these diagrams we can see that mobile app is written in Xamarin, controllers are using Spring MVC and database uses Oracle Engine.
C4 – Code diagram
C4 is the latest diagram we can use to show our architecture. On this diagram we can show how classes should look using for example UML notation or entity relationship diagram. This level is optional because it’s hard to update – as we know there are still some changes in software like new features, refactoring, bug fixing etc..
C4 modeling tools
For C4 modeling we can recommend tool called Structurizr which can be found here: https://structurizr.com/ . It will allow you to prepare diagrams very quick using simple drag and drop elements.
C4 model allows us for simple architecture modeling. Thanks of this tool we are able to keep our architecture diagram/documentation up to date which is really important and shouldn’t be neglected. For more details about C4 model please take a look at c4model.com or contact with us.