tech

Communicate your Software Design better with C4 Model

June 16, 2024 by Ashwin Leave a Comment

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.

Understand your Stakeholders with a Stakeholder Map

June 1, 2024 by Ashwin Leave a Comment

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.

How To Create Status Reports That Work?

May 11, 2024 by Ashwin Leave a Comment

Status reports are often the most “filtered out” emails, ending up in a folder that never gets opened. But that doesn’t mean the stakeholders are not interested in the status… they just hate the way it is reported!

3-Speed Status Reports

From my experience across a wide range of stakeholders, information is often expected at 3 different speeds.

On-demand (fast) – get the information when they need it, without having to contact anybody
Concise (slow) – get them the information in a way they can easily digest
Details as needed (slowest) – they can go into finer details as needed

Often, preference is given to #1 or #2, with #3 being used for information that they care about (e.g., a big failure or escalation)

About 80-85% of stakeholder expectations are addressed by one of these 3 modes.

As someone responsible for reporting status, like a project manager, it becomes important to address these modes.

How do you do that?

The Reporting Sweet Spot!

Here’s a recommendation that works with most. However, you must understand the expectations and tailor them for any specific needs.

3 recommended ways to report information that is proven to work are:

Information radiators / Dashboards – on-demand, single-page view of status and visualization of key metrics
TLDR Summary – a condensed summary of not more than 6 bullet points that highlight important aspects and key messages
Double-click Reports – a detailed report, not more than 2 pages, that has a double-click of key messages in the TLDR summary

Also, include a specific section that calls out actions for the stakeholder – it can be an approval or have them enable a smooth progress.

Here’s a sample email structure that you can use – covering all of the above:

I hope these tips help you make the status reports useful, once again! Cheers…