Context Diagram

Purpose

The context diagram provides a shared understanding of what the system is, who uses it, and what it connects to. It is the starting point for any architecture discussion and ensures all stakeholders agree on scope and boundaries.

When to Use

Create a context diagram at the very start of any project — during discovery or early alpha. It should be the first architecture diagram produced.

How to Build

Start by drawing your system as a single box in the centre of the diagram. Label it clearly with the system name and a one-line description.

Identify all the people (actors) who use the system. Draw them around the outside with labels describing their role.

Identify all external systems that your system interacts with. Draw each as a box with a clear label.

Draw lines between your system and each actor/external system. Label each line with the nature of the interaction.

Keep it simple — a context diagram should fit on a single page and be understandable by anyone in 30 seconds.

Tips

Follow C4 model conventions: system in the centre, people at the top, external systems around the edges.
Use colour coding consistently.
Include a brief description on each element.
Show the direction of data flow on relationship lines.
Keep it to one page — more detail belongs in container or component diagrams.

Common Mistakes

Including too much internal detail — the context diagram should show the system as a black box.
Omitting external systems the solution depends on.
Not labelling relationships.
Making it too complex with more than 10-12 elements.
Forgetting to include human actors.

Government Context

In UK government, context diagrams are essential for GDS service assessments and spend control submissions. They should clearly show cross-government shared platforms (GOV.UK Notify, Pay, Verify) and dependencies on other departments. For security accreditation, the context diagram helps identify trust boundaries and data flows crossing security domains.