C4 Model – bringing your team closer together
Ever wondered how you can bring your team closer together so they align to an idea?
Whilst most businesses place great weight on technology as an enabler in digital transformations, getting the people and the processes right will have a far greater impact on the success of a project. Why? Have you ever tried to cross a river in a canoe with everybody paddling in a different direction? It’s chaos, and gets you nowhere.
This blog post is all about how you can bring people together in your work environment. And I’m not talking about social events, but rather a way of communicating and presenting your idea (however technical it may be) to everyone, regardless of their technical knowledge.
First things first. What is a C4 Model?
Put simply, it’s a model used to describe software architecture. Composed of multiple views or perspectives. The C4 Model enables an individual to deliver a holistic business case geared to the interests of potential stakeholders.
As shown in the above diagram, the C4 Model focuses on four core viewpoints, all of which feed into a fifth ‘step’ in the process. These are as follows:
1. Development view
Illustrates a system from a programmer’s perspective and is concerned with software management.
2. Logical view
Concerned with the functionality that the system provides to end-users.
3. Physical view
Depicts the system from a system engineer’s point of view and is concerned with the topology of software components on the physical layer, as well as the physical connections between these components.
4. Process view
Explains the system processes and how they communicate. It also focuses on the runtime behaviour of the system.
The description of an architecture is illustrated using a small set of use cases, or scenarios.
Why is C4 useful?
Creating software architecture diagrams is somewhat of a lost art, and logical and development views are often separated. I can assure you, this hurts both the individual AND the project.
The main problem is that software architects and developers struggle with how to communicate software architecture. The majority of the diagrams are typically created using an ad hoc “boxes and lines” notation with no clear semantics. In the eyes of a project lead, this should be an immediate red flag.
Without semantics, you’ve already lost the war before the battle even begins. This is because you’ve given no clear roadmap to your idea. Nothing for a stakeholder to get excited about and buy-into.
How does C4 help?
Here is where the C4 model comes into play. It was created as a way to help software development teams describe and communicate software architecture in the following situations:
- During up-front design sessions
- When retrospectively documenting an existing codebase
- The benefits of introducing the C4 model at these stages are far reaching. It makes architecture more accessible to developers, while also being a powerful tool in a team, helping to ramp-up new team members
- Introduce traceability for technical decisions
- Evolve and maintain architecture
It is also a way to create maps of your code, at various levels of detail. A bit like Google Maps, this nifty addition allows you to zoom in and out of an area you are interested in, providing a satisfactory level of information depending on your audience’s technical know-how. It has also brought UX into the design phase, not simply for the user, but the stakeholders who very likely hold the fate of your idea in their clasp.
The image above shows the typical structure of a C4 model. As you can see, it consists of 4 different layers, with each child layer being contained in the parent layer. Let’s talk a bit about each layer separately.
Layer 1. Container
This layer represents a separately deployable “thing”, which hosts code or data that needs to be running in order for the overall software system to work. It’s essentially a context or boundary inside which some code is executed, or some data is stored.
- Server-side web application
- Client-side web application
- Client-side desktop application
- Mobile app
- Server-side console application
- Blob or content store
- File system
- Shell script
Layer 2. Component
Whilst a hugely overloaded term in the software development industry, in this context, a component is simply a grouping of related functionality encapsulated behind a well-defined interface.
Here are some examples:
- If you’re using a language like C#
- A collection of implementation classes behind an interface
- If you’re using a functional language
- A module
- If you’re using a DBMS
- A function
- How those components are packaged is a separate concern
- One component vs many components per DLL, shared library, etc
Layer 3. Class
This is the most in-depth layer and contains the actual code. This is mostly for developers to understand how the component works at a very granular level. The most basic example would be a class in C#.
Using notations with the C4 model
The C4 model doesn’t prescribe any particular notation, so our advice would be that any notation you choose to use, make it as self-describing as possible. All diagrams should also have a key/legend to make the notation explicit.
Want to try your hand at the C4 model?
This four-pronged approach is successful at bringing people together, simply because information on new ideas is presented in such a way that each individual can engage with it. With engagement comes alignment and with alignment comes collaboration and the progression of ideas.
And you can try it too.
There are a lot of tools out there to help you develop your own C4 model for your own application/project. Here is a brief list of the most common ones:
In our next blog post, we will discuss about different ways of representing your C4 model depending on context. Until then, I would like to leave you with a favourite quote of mine:
Language brings with it an identity and a culture, or at least the perception of it.
A shared language says: “We’re the same.”
A language barrier says: “We’re different.”
– Trevor Noah
- “Software Architecture for Developers”, Simon Brown, Leanpub 2017