If you have never encountered the C4 model, I believe it is the best time before continuing the Structured Software Product Management posts because I will be referencing lots of concepts that are identified by the C4 software architecture model. C4 model (http://www.c4model.com) is created for architectural design by Simon Brown; “… as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase.” in his words. Even though Simon Brown created the c4 model for software design; it fills a significant gap for describing and communicating software product management concepts as well.
The model has its shortcomings (e.g., it may not be an excellent approach for microservices-based architectures), but it puts a clear picture of how to design and communicate software architecture.
C4 model defines four abstraction levels for the software design:
- Context
- Container
- Component
- Code
The context level identifies the environment, actors, the external software systems, and the software system. The confusing container name defines the technologies, repositories, application servers, or environments that the components run. The components are the group of codes responsible for a specific task, and the code is the actual code itself.
It is possible to follow a top-down approach while making a greenfield design or a bottom-up one to reach the actual code and design status. There are various tools, even libraries, to map the code on different levels.
The design mainly focuses on the relationship between different actors, software systems, containers, and components. While the context level deals with raw relations, the more detailed levels define the protocols, APIs, etc., for these relations.
For structured software product management, these abstraction layers, the concepts, and the relations are very good fitting and working tools. The software product manager can define the product’s requirements, features, functionalities, and components in a clean and communicable way using the C4 model.
A Software Product Manager mainly works on the first two levels of the C4 model, context and container. The SPM tries to identify the following questions at the first level:
Context Level
- Who will use the software? (actors)
- What will the software do? (Software System)
- With which external systems will the software communicate? (External Software Systems)
- What will the relations between these players be?
Container Level
Container level deals with the high-level architecture and the software’s running or storing environments.
- Will it need application servers, web servers, or database servers?
- Will it run on Linux, Windows, iOS, etc.?
- What kind of databases, environments, and browsers will the code run?
- Will it be a cloud-based solution?
- What will be the main protocols to be used between the containers?
This high-level architecture also allows the SPM to identify the target environments and platforms.
Components Level
As a rule of thumb, the container level defines the boundary of the SPM. The SPM deals with the requirements, decisions, and definitions on the context and container level, and the software architect and the development team focuses on the component and code levels. But there may be necessities where the SPM needs to involve the component levels as well:
- Some of the Important Technical Decisions (ITDs) may be in component level and addressing a specific component. That component may be an essential part of the solution or adds a great advantage to the software.
- The software already exists, and the SPM needs to decide and define enhancements on the existing components.
- Some of the features, relations, communications, protocols, even API details of the components may be important for the product and maybe strategic.
- In most agile development methodologies, “some of” the product management role is owned by the product owner (even they are not the same thing), and the product owner needs to have a deeper understanding of the components as part of the agile team.
- And as the last reason, the company culture and the expectations from the SPM may include technical activities as well.
In short, it is almost for sure that the SPM needs to deal with the component level while defining the requirements or making an important technical decision.
In the next post, I will try to talk about the Important Product Decisions.
The C4 model example diagrams, explanatory text, and slides are licensed under a Creative Commons Attribution 4.0 International License. The originals can be found on http://c4model.com
