On February 1st, we at Setlog had an introduction to C4 with Kevin Wittek, Technical Lead at GDATA. C4 isn’t an explosive– C4 is a lightweight modeling and documentation language for software architectures.
In various areas of life, e.g. cartography, architecture or electricity, there are standards for modeling things like maps, floor plans or circuit diagrams. These standards are used consistently and in uniform.
In IT there are also various approaches for modeling such as UML (Unified Modelling Language). Although, these have not become as uniform as the examples above, because of height effort for the modeling compared to the benefit. As well, UML offers only a few modeling elements on the more abstract levels.
The lack of having a general standard modeling language for software architecture means that every company and every team uses their own notation to describe architectures. This is why no external parties or even the authors themselves don’t know exactly what is meant by the individual elements, e.g. arrows, after a long time.
We realized this when we had to model the architecture of an electronic cookbook as an example scenario:
We immediately noticed the following points:
- An external party would never understand this model.
- Before going into architectural modeling, the domain should be clear in form of a domain model.
- The terms must be used in uniform. In our discussion, e.g. the simple word “proposal” has led to long discussions about its meaning in the system.
These facts have opened our eyes for the need of a standardized but lightweight modeling language. Especially in view of the fact that we are willing to make our architecture more efficient, we and the specially created architecture team have to document this vision in uniform so that it is comprehensive for everyone.
To accomplish these goals, the modeling language C4 offers a pragmatic and comparatively simple approach. There are four different levels of abstraction. The transition from one level to another is comparable to zooming into a digital map like Google Maps: more and more details become visible.
The four levels of abstraction are:
Level 1: System Context Diagram
Level 2: Container Diagram (not a Docker-Container!)
Level 3: Component Diagram
Level 4: Code
Level 1: System Context Diagram
This level is an overview of a single system with all communication partners. Communication partners mean both user roles and external systems such as e-mail server, Twitter, Slack, etc. The target group for this diagram isn’t only for IT, but also for POs and business. This picture illustrates what such an architecture can look like. For our example application we have also created a system context diagram:
As you can see, every external and every technically unimpressed viewer can directly recognize what kind of system it is and who should communicate with it. This is mainly due to the fact that all elements, especially the arrows, have been labeled clearly.
Level 2: Container Diagram
Next step is to zoom-in to the system with a Container Diagram. The individual autonomously acting elements are listed here and even the rough technology decisions (Web, Rich, Client, etc.), as well as protocols and ports, via which the individual components communicate with each other, are recorded. This picture shows a Container Diagram in detail. Our result (incomplete for reasons of time) looked like this:
Level 3: Component Diagram
The next zoom level is the single view of every in level 2 defined container. With the Component Diagram you define the packages that make up the containers, their responsibilities and their relationships with each other. In this picture you can see an example for such a Component Diagram.
Level 4: Code
On this layer a class diagram or other UML diagrams can be drawn. However, in terms of usefulness it’s like Google Street View – nice to look and some interesting details, but it’s of secondary use for the basic purpose, i.e. the orientation in architecture. At this level it is simply easier to understand the classes and their dependencies directly in the source code.
„The lower the level or level of modeling at which a change is made in the system, the more expensive the adjustment.“
C4 is an interesting and clearly structured approach to model a system architecture at different levels of abstraction. In any case, it can help us to better document the current system for us and externals to provide it as a basis for discussion for future adjustments by the architecture team.
For more information to this method the following links are recommended:
https://c4model.com/
http://static.codingthearchitecture.com/c4.pdf
03.02.2018, Eduard Heinle