Category Whitepapers and Guides
In our previous blog post, we discussed what the C4 model is and its purpose within a business environment. We also made note of various tools that will enable you to introduce the C4 model into your own change programs.
This blog will pick up with where we left off, looking at the different ways you can implement the C4 model, depending on context.
Before we begin, here is a brief overview of how the upcoming diagrams work together:
Let’s look at each level separately.
Level one is a System Context diagram. Not only is this a good starting point for diagramming and documenting a software system, it allows you to step back and see the big picture. Start by drawing a diagram showing your system as a box in the centre, surrounded by its users and the other systems that it interacts with.
Detail isn’t important here as this is your zoomed-out view showing a big picture of the system landscape. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details. It’s the sort of diagram that you could show to non-technical people – which makes it really beneficial when talking to stakeholders without an IT background.
Scope: a single software system
Primary elements: the software system in scope
Supporting elements: people and software systems directly connected to the software system in scope
Intended audience: technical and non-technical people, inside and outside of the immediate software development team
Once you understand how your system fits in to the overall IT environment, a really useful next step is to zoom-in to the system boundary with a Container diagram. A “container” is something like a server-side web application, single-page application, desktop application, mobile app, database schema, file system, etc. Essentially, a container is a separately runnable/deployable unit (e.g. a separate process space) that executes code or stores data.
The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It’s a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike.
Primary elements: containers within the software system in scope
Supporting elements: people and software systems directly connected to the containers
Intended audience: technical people inside and outside of the immediate software development team including everybody from software developers through to operations and support staff
The component diagram zooms in and decomposes each container further to identify the major structural building blocks and their interactions. Next, you can zoom in and decompose each container further to identify the major structural building blocks and their interactions.
As the name suggests, this diagram shows how a container is made up of a number of “components”, what each of those components are, their responsibilities and the technology/implementation details.
Scope: a single container
Primary elements: components within the container in scope
Supporting elements: containers (within the software system in scope), people and software systems directly connected to the components
Intended audience: technical people within the software development team
Last, but certainly not least is the Code diagram. This enables you to zoom in to each component to show how it is implemented as code; using UML class diagrams, entity relationship diagrams or similar.
This is an optional level of detail and is often available on-demand from tooling such as IDEs. Ideally this diagram would be automatically generated using tooling (e.g. an IDE or UML modelling tool), and you should consider showing only those attributes and methods that allow you to tell the story that you want to tell. This level of detail is not recommended for anything but the most important or complex components.
The C4 model provides a static view of a single software system but, in the real-world, software systems never live in isolation. For this reason, and particularly if you are responsible for a collection of software systems, it’s often useful to understand how all of these software systems fit together within the bounds of an enterprise.
To do this, simply add another diagram that sits “on top” of the C4 diagrams, to show the system landscape from an IT perspective. Like the System Context diagram, this diagram can show the organisational boundary, internal/external users and internal/external systems. It also takes on a new name – the Enterprise Context Diagram.
Essentially this is a high-level map of the software systems at the enterprise level, with a C4 drill-down for each software system of interest. From a practical perspective, a system landscape diagram is really just a system context diagram without a specific focus on a particular software system.
The C4 model also has a few additional tools up its sleeves…
The dynamic diagram shows how elements in a static model collaborate at runtime to implement a user story, use case, feature and it’s based upon a UML communication diagram / UML collaboration diagram, which is similar to a UML sequence diagram.
However, it allows a free-form arrangement of diagram elements with numbered interactions to indicate ordering.
Using a similar flow to the other diagrams, the deployment diagram allows you to illustrate how containers in the static model are mapped to infrastructure and it’s based upon a UML deployment diagram.
A deployment node is something like one of the following:
It is possible to nest deployment nodes.
You should by now be an expert on diagrams – or certainly have a greater understanding for the C4 model and how it can be deployed in businesses to help document a software system.
Whilst there are other models available, the C4 model has a way of simplifying complex projects and creating a visual tool to help keep stakeholders engaged and your team aligned to the all-encompassing context of what it is you are trying to achieve.
So far, we’ve discussed several diagrams as part of the C4 model and how to implement them. Hopefully, this can be used as guidelines for you to implement within your own business.
As a good exercise, I invite you now to implement your own C4 model of your project. Follow the above guidance to build the relevant levels and once confident, be bold and present it to a broader audience to put your “software architect” skills in motion.