techleadership | Meet Ashwin

As engineers and tech leads, we often underestimate the need for our software design to be understandable.

The simpler the design, the higher its utility and purpose.

The C4 model is one of the popular and proven ways to visually communicate your design to a wide range of audiences. Its beauty is the “drill down” method, making it usable by technical and non-technical audiences.

What is a C4 Model in Software Design?

C4 models are a hierarchical abstraction of software systems, achieved through a set of diagrams. They are designed to be notation and tool-independent, which can be applied to almost all type of systems.

It is an “abstraction-first” model, that reflect how software architects and developers think about building software.

C4 stands for:

System Context
Container
Component
Code

In ascending order of granularity, each of these diagrams gives a more detailed view of the software system that’s being built.

What are the C4 Model Abstractions?

4 levels of abstraction are at the core of a C4 Model.

Software system – the highest level of abstraction of any system that has some utility (e.g., a maps application)
Containers – a software system is made up of one or more containers (e.g., applications, data stores, etc.)
Component – each container is made up of several components (e.g., relational data store, NoSQL data store, etc.)
Code – finally, each component is implemented by software code using a tech stack (e.g., MySQL, DynamoDB, etc.)

Each of these abstractions is represented as C4 diagrams.

C4 Model Diagrams

System Context Diagram

The system is visualized as a single box which is at the center
This diagram shows how the system interacts with its environment and users
Focus is on the people and interacting systems, not on technology or tools
Everyone, irrespective of their technical acumen, must be able to understand this diagram

Container Diagram

A container view represents various applications that constitute the system
This diagram can show the major technology choices and how the containers interact with each other
It is intended for a technical audience, but anyone with a need to know how the system works can use this diagram

Component diagram

In this diagram, the container is decomposed into structural building blocks and their interactions
Each component’s responsibilities, interaction with other components, and technical details are called out here
Software architects and developers are the primary intended audiences
It is not recommended for all teams, so use it only if you think it adds value

Code diagram

Represents how each component is implemented as code – using UML diagrams, ER diagrams, etc.
Usually generated using IDE or UML modeling tools
This level of detail is normally required only for complex components

In summary, C4 diagrams improve the communication efficiency of your software design. The level of detail and type of diagrams is contextual to the system under design.

Understanding your stakeholders is essential for any project’s success. Stakeholder maps offer a visual way to make it happen.

Who is a Stakeholder?

A stakeholder is someone who has a vested interest in the outcome of a project or a program.

Not all stakeholders are the same.

They come with a variety of needs and expectations.

As a tech leader, you must:

Identify them
Analyze and learn about them
Map them based on their interests
Prioritize and manage

One useful tool to do this is a stakeholder map.

What is a Stakeholder Map?

A stakeholder map is a visual matrix that identifies and categorizes stakeholders based on 2 dimensions – influence and interest.

Influence is the degree to which a particular stakeholder can impact the execution and outcome of a project. For example, a project sponsor is someone with a high influence, who can drive key decisions.

Interest, on the other hand, is about how much a stakeholder is impacted by the project outcome. For example, if you are building an HR application, the end-users in the HR team have high levels of interest.

Once you have established this, the stakeholders can be mapped on a matrix.

High influence, High interest – stakeholders that must be managed closely, as they can steer the direction and outcome of the project
High influence, Low interest – these are key leaders in the organization who may not be directly interested in the outcome of the project, but must be kept happy (no escalations, firefighting, etc.)
Low influence, High interest – these are folks usually part of the project team or the intended end-users. They have a high interest as the outcome with have a direct impact on them but often their influence is limited
Low influence, Low interest – these are enablers or other enterprise bodies, who are not directly involved in the execution or outcome. But they may expect to be “kept in the loop”

Here’s a sample stakeholder map for a project. Do note the categorization is highly opinionated, it can vary for every project or initiative.

How do you create a Stakeholder map?

There is no single way to create a stakeholder map and it highly depends on your organization’s culture and operations.

However, here is a 5-step blueprint that works in most cases.

Start with the purpose of your map
Brainstorm and build the stakeholder list
Determine each stakeholder’s level of involvement
Determine their interest and goals in the project
Create a stakeholder map and establish an engagement plan

In summary, a stakeholder map helps you understand the landscape, know the stakeholder interests, and create an engagement plan that works.

Communicate your Software Design better with C4 Model