Context Diagrams
The system as one box, with its users and external systems.
4 to work through
-
beginner
A 40-engineer SaaS product has a context diagram with six external systems on it. Roughly how many outbound dependencies does a product that size actually have, how would you count them without guessing, and what does the real number change?
3 min answer -
beginner Multiple choice
A team draws their payment provider inside the system boundary on their context diagram because the provider's SDK runs inside their own service. During the first incident the on-call engineer spends 20 minutes trying to restart something the team does not own. What does the boundary line on a context diagram actually mean?
3 min answer -
beginner
Why is the system context diagram usually the most valuable single diagram, and what is most often left off it?
2 min answer -
intermediate
What belongs on a context diagram that most teams leave off?
2 min answer
3 terms in this topic
Context Diagrams
The system, its users and everything it talks to — the cheapest, most durable and most under-used architecture artefact.
practiceOutbound Dependency Census
Deriving the list of systems a product depends on from four independent machine-readable registers instead of from memory, then deciding which of the…
conceptSystem Context Boundary
The line separating what a project owns and can change from what it must integrate with and accept as given.
1 artifact you would hand over
Neighbouring topics
Architecture Communication
General material on communicating architecture.
Architecture Diagrams
Choosing an audience and refusing to mix levels of abstraction.
C4 Model
Context, container, component and code as four separate diagrams.
Sequence Diagrams
Ordered message exchange, and walking the failure of each arrow.
Data-Flow Diagrams
Following the data across trust boundaries rather than the calls.
Deployment Diagrams
What runs where, in which zone, behind which boundary.
Communicating Threat Models
Making risk legible to people who will fund or accept it.
Writing Decision Records
Context, alternatives and consequences, written once and never edited.
Technical Proposals
A written argument circulated before the decision feels made.
Architecture Reviews
Reviewing early enough to influence rather than to veto.
Presenting to Executives
Decision first, cost, risk, and what happens if we do nothing.
Presenting to Engineers
Mechanism, alternatives rejected, and what you are unsure about.
Explaining Trade-offs
Naming what was given up, and the condition that would change it.
Handling Disagreement
Arguing from consequences, and escalating in the room.
Negotiation
Trading on interests rather than positions, with priced options.
Documentation Practice
Keeping documents close to the code and honest about staleness.
Presentation Skills
Structure, pacing and the slide that carries the decision.
Written Communication
Writing that survives being read without you in the room.
Facilitation
Running a design session that reaches a decision.