Making Infrastructure a First-Class Citizen in the C4 Model

The C4 Model is one of my preferred architecture modeling frameworks.

It is hierarchical, readable, audience-aware, and pragmatic. It works extremely well with development teams because it optimizes for communication instead of formalism.

I use it regularly at work.

But over time I’ve started feeling that one part of the model no longer scales well with modern cloud-native systems:

Infrastructure architecture.

This post is not a critique of C4. Quite the opposite. C4 solved a major problem in software architecture documentation.

But infrastructure has changed dramatically since the model was introduced.

And I think modern systems now need infrastructure to become a first-class architectural concern instead of remaining mostly attached to Deployment Diagrams.

The Problem

In many modern systems, infrastructure is no longer an implementation detail.

It directly shapes:

• security

• reliability

• scalability

• compliance

• cost

• blast radius

• operational ownership

• incident response

Today, infrastructure decisions include things like:

• Kubernetes topology

• VPC segmentation

• cloud accounts and organizational boundaries

• private networking

• managed services

• service mesh policies

• autoscaling behavior

• multi-region strategies

• compliance zones

• workload isolation

• IAM and trust boundaries

These are not merely “operations concerns.”

They are architectural concerns.

Yet in the current C4 model, most of this information ends up squeezed into a Deployment Diagram.

The result is usually one of the following:

• overloaded diagrams

• mixed audiences

• unclear ownership

• poor navigability

• diagrams that become obsolete quickly

• infrastructure and software concerns blended together

The Deployment Diagram becomes a catch-all view for everything runtime-related.

And in large cloud-native systems, that simply does not scale well.

The Core Observation

The original C4 hierarchy models software extremely well:

But modern architecture also needs to answer another set of questions:

• Where does the software run?

• Which infrastructure boundaries constrain it?

• Which managed services does it depend on?

• Which runtime actually executes it?

• Which compliance zone contains it?

• What is the failure blast radius?

• Which networking boundaries isolate it?

• Which operational platform owns it?

These are architectural questions too.

But currently they do not have their own dedicated modeling hierarchy.

Proposal: A Parallel Infrastructure Axis

Instead of endlessly expanding Deployment Diagrams, I think infrastructure should have its own parallel architectural axis.

Something like this:

The important idea is this:

So instead of mixing both into one canvas:

• software diagrams model software

• infrastructure diagrams model infrastructure

• explicit relationships connect them

Why This Helps

1. Clearer Separation of Concerns

Today many deployment diagrams mix:

• software structure

• cloud topology

• networking

• runtime behavior

• deployment details

• security boundaries

into one giant diagram.

Separating concerns makes each diagram easier to understand.

A software architect may care about service boundaries.

A platform engineer may care about cluster topology and networking.

A security team may care about trust zones and IAM domains.

These are different views.

2. Infrastructure Has Its Own Hierarchy

Infrastructure itself now has architectural structure.

For example:

AWS Organization
 └── Production Account
      └── eu-west-1
           └── Payments VPC
                └── EKS Cluster
                     └── Payments Namespace

That is a real architecture hierarchy.

And it affects the system as much as the software decomposition does.

3. Better Cloud-Native Modeling

Modern systems rely heavily on managed infrastructure:

• Kubernetes

• service meshes

• managed databases

• queues

• cloud IAM

• API gateways

• observability platforms

These are not passive deployment targets anymore.

They actively influence runtime behavior.

For example:

• retry semantics

• scaling behavior

• network isolation

• resiliency patterns

• security posture

• data residency

• failover boundaries

All of these are architectural characteristics.

4. Better Mapping Between Software and Runtime

Instead of relying on spatial placement inside a Deployment Diagram, relationships become explicit.

Examples:

Payment API       runs_on              EKS Cluster
Payment API       exposed_through      API Gateway
Fraud Worker      consumes_from        Kafka
Payment System    constrained_by       PCI Zone

This creates a much more navigable architecture model.

A Missing Piece: Mapping Views

One thing I realized while thinking about this:

If software and infrastructure become separate axes, we still need a way to connect them cleanly.

So I think a third category is needed:

Mapping Views

Examples:

This avoids overloading either side.

Important Constraint: Keep It Lightweight

I do not think this should become another heavyweight enterprise architecture framework.

One of the biggest strengths of C4 is simplicity.

So the infrastructure axis should remain pragmatic and selective.

A good rule might be:

Meaning:

• security

• reliability

• scalability

• operability

• compliance

• cost

• failure isolation

Not every Terraform resource deserves to appear in architecture diagrams.

This Is Not a Replacement for C4

I see this as an extension of the model, not a replacement.

Traditional Deployment Diagrams are still perfectly fine for:

• smaller systems

• monoliths

• simple deployments

• low operational complexity

But for modern cloud-native platforms, infrastructure has become too important to remain a secondary deployment concern.

Tentative Name

A few names I’ve been considering:

• C4+I

• Infrastructure Axis for C4

• C4 Infrastructure Extension

• Runtime Architecture Axis

Still undecided.

Open Questions

I’d love feedback from others working on large-scale distributed systems.

Some questions I’m still thinking about:

• Does infrastructure deserve its own hierarchy?

• Should runtime/platform architecture be modeled separately from software architecture?

• Would this improve clarity or just introduce more diagrams?

• How would you define the abstraction boundaries?

• Would this overlap too much with ArchiMate or other EA frameworks?

• What would be the minimal useful version of this idea?

Curious to hear what others think.