Why C4 Starts with System Context Diagrams: A Step-by-Step Guide

1. Why Start with a System Context Diagram?

The C4 model provides four hierarchical diagrams—system context, container, component, and code—each telling a different story about the same system. The recommended starting point is the system context diagram .

Place the software system being described in the center, surrounded by the people who use it and the other software systems it interacts with. Technical details such as protocols and data formats are deliberately omitted at this level.

This perspective has two key characteristics:

Focus on people and software systems, not technology. The diagram depicts actors and systems, not low-level technical details.

Accessible to both technical and non-technical audiences. Business analysts, product managers, and operations staff can all understand and discuss this diagram.

2. Questions a System Context Diagram Answers

The value of a system context diagram is concentrated in four questions:

What is the software system we are building (or have built)? — Defines the central box.

Who uses it? — Identifies the people on the left side.

What are those different types of users doing with it? — Clarifies user roles and goals.

How does it fit into the existing system landscape? — Identifies external software systems on the right side.

Answering these four questions produces the skeleton of the diagram.

3. Scope and Content

Scope: A single system context diagram focuses on one software system . It shows the people and other software systems related to that system. To describe multiple systems, draw multiple diagrams.

Content: Only two types of elements plus relationships:

People

Software systems

Relationships between them

3.1 How to Draw People

People are the users of the software system. They are typically distinguished by role—customer, administrator, operations staff—but can also be represented as concrete personas.

Each role needs only two pieces of information: name and a short description .

An important principle: draw only "functional" users —those who use the system to achieve a business goal. Whether to include system administrators or operations staff depends on whether the system provides dedicated functionality for them. For example, if there is an admin UI, include administrators; if operations only read logs and run scripts, they need not appear. The diagram serves only the story you want to tell. If different stories are needed for different audiences, draw multiple diagrams.

3.2 How to Draw Software Systems

There are two kinds: the system being described and the external systems it interacts with. Each requires only a name and a short description .

3.3 How to Draw Relationships

Relationships are drawn as unidirectional arrows , each accompanied by a brief description of what the relationship does.

Emphasizing "unidirectional" and "with description" prevents a tangle of ambiguous lines where every viewer interprets the connections differently.

At the system context level, relationship descriptions can be high-level, omitting protocols, data formats, and other technical details . Those details belong in more detailed diagrams.

4. Simple but Valuable: Five Reasons to Draw It

Because the diagram is simple, one might ask why bother. There are five reasons:

Make scope and context explicit, leaving no room for assumptions. A single diagram shows what is inside the system boundary, what is outside, and who depends on whom.

Visually show where a new system fits into the existing landscape. When integrating with a legacy system, the diagram quickly reveals which "territory" the new system will touch.

Provide a common starting point for technical and non-technical people. Discussions and new-hire onboarding can begin with this diagram.

Identify who to talk to about cross-system interfaces. A glance at the diagram tells you which external system owner to contact for integration details.

Serve as the starting point for all other C4 diagrams. Container, component, and code diagrams are successive zoom-ins from the system context diagram.

The diagram is also a handy analysis tool . During requirements gathering, drawing a system context diagram ensures everyone shares a common understanding of "what is inside the system boundary and what is outside." Achieving this consensus is more effective than any lengthy document.

Who needs to see it? Almost everyone involved in building and maintaining the system—technical and non-technical, inside and outside the engineering team.

Is it worth adopting for all engineering teams? Yes. Recommended for all engineering teams.

5. Step-by-Step Example: Online Banking System

To illustrate, consider a bank engineering team tasked with building an online banking system. We start with the system context diagram.

5.1 Draw the System Itself

First, draw a box representing the online banking system—the subject of this context diagram.

5.2 Add the People Who Use It

Identify the users. In this example there is one user type: personal banking customers —people with one or more bank accounts who want to view balances and make payments online.

Add them to the diagram with a relationship arrow pointing to the online banking system.

5.3 Add Other Software Systems It Integrates With

Identify external software systems the online banking system must interact with.

The bank has operated for decades and already owns customer and account data. The online banking team does not build the bank, the customer database, or the transaction database—they merely provide an online entry point for existing customers.

The bank already has a core banking system exposing APIs. The online banking system uses this API to access account data and execute transactions. Add this system to the diagram.

5.4 Add Email Service

The system will likely need to send emails—multi-factor authentication, fraud alerts, transaction success/failure notifications.

The team does not want to rebuild an email sending service. The bank already has a cloud contract with AWS and uses Amazon SES elsewhere, so the online banking system uses that as well.

Add this to the diagram; the system context diagram is now complete.

5.5 Completed Diagram

The finished diagram conveys three key messages:

Personal banking customers use the online banking system to view account information and make payments.

The online banking system uses the bank's existing core banking system, which stores the bank's business data and handles core banking operations such as payments.

The online banking system also uses Amazon SES to send emails to customers for purposes including multi-factor authentication and fraud alerts.

Despite the information density, the diagram contains only one central box, one user, and two external systems. This is the essence of a system context diagram— clarify the scope first, push details to later diagrams .

6. Notation and Element Types

The C4 model is notation-agnostic—tools and drawing styles are not prescribed.

The example uses the following notation:

Person : stick figure with name + short description inside.

Software system : rounded rectangle with name + short description inside.

Relationship : unidirectional dashed arrow with a brief description of the relationship's purpose.

Diagram title : standardized as "System Context View: System Name" to clearly tell the reader what the diagram depicts.

Each element also carries a small type label— [Person] for people, [Software system] for software systems. Explicitly labeling element types eliminates the common ambiguity in architecture diagrams where viewers wonder whether a box represents a system or a container. This upfront labeling saves extensive verbal explanation.

1. The C4 Model for Visualising Software Architecture, Chapter 3