Data-Flow Diagrams
Following the data across trust boundaries rather than the calls.
4 to work through
-
intermediate
A data-flow diagram in your compliance pack was drawn eight months ago and is signed off. A reviewer asks how you know it is still accurate. What would you change about how it is produced, and what would you keep doing by hand?
2 min answer -
intermediate
A platform must demonstrate to a reviewer where personal data goes. Which diagram serves this, and what must it include that a component diagram does not?
2 min answer -
advanced
A regulator asks where a specific customer's personal data is held. Which artefact answers that and what must it include?
2 min answer -
advanced
Your signed-off data-flow diagram shows personal data leaving the EU through exactly one named processor. A platform team then adds a tracing agent that captures request bodies on error, and its collector exports to a log store in another region with 400-day retention. What happens, step by step, and what stops it?
3 min answer
3 terms in this topic
Data Flow Diagrams
Where data goes, who holds it and which boundaries it crosses — the artefact that answers privacy, residency and threat-modelling questions.
conceptData Lineage View
A view showing how data moves and is transformed through a system, independent of the components that do the moving.
practiceDiagram Provenance
A line on every diagram stating what it was generated from, when, and when it will next be refreshed, so readers can weigh its accuracy instead of as…
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.
Context Diagrams
The system as one box, with its users and external systems.
Sequence Diagrams
Ordered message exchange, and walking the failure of each arrow.
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.