Why is the C4 model not enough today?
What is the C4 model and why do you need it?
The C4 model was created 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. (Source: https://c4model.com/)
It’s not just a diagram.
The C4 model can be used as a common language in an R&D organization which provides a clear picture about the architecture for any of the participants in the organization effort, even non-technical participants.
When do you need CCCR and not C4?
If the developers work with infrastructure and operations in a self-service configuration and deal with the cloud and not only with the software code, then CCCR is the right model for you.
Understanding the architecture in the world of many microservices among the various cloud services is required and necessary for development personnel who, with the help of this language, will be able to take part in improving and building the architecture in a more orderly and convenient way.
Start with the first C: Context
The Context diagram allows you to step back and see the big picture.
Draw a diagram showing your system as a box in the center, surrounded by its users and the other systems that it interacts with.
The second C: Container
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-focused diagram that is useful for software developers and support/operations staff alike.
The third C: Component
The Component 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.
The R: Resources
Finally, you can zoom in to each component to show how it is implemented as resources (cloud resources, pipelines, automations, functions, and so on).
Ideally, this diagram would be automatically generated using tooling (for example: https://www.cloudcraft.co/ for AWS or Inframap for Terraform code), and you should consider showing only those attributes and methods that allow you to present the right flow for the user and data in the infrastructure.