← Systems Analysis: APIs, Integrations and Data
Lesson
System boundaries: the context diagram and integrations
Draw a system's context diagram — what is inside, who and what is outside, what data goes along each arrow and how — and build an integration register from it.
Where our system ends
Where our system ends
A context diagram shows the system as one central block surrounded by external participants: people and systems. Arrows are data flows labeled with what is passed; no internal modules or tables. Its roots: structured analysis and C4's System Context level.
Boundary rule: a party is external if we don't control its code or release schedule and agree on a contract with it. So the courier service, run by another Romashka team, is external to the order service.
Arrows follow the data. If the provider itself sends the payment result to our address (a webhook), the arrow runs from it to us. A webhook is a synchronous HTTP call, like a REST request, but started by the external system, so it's drawn solid; dashed lines are broker events.
Each arrow becomes a row of the integration register: from → to, what, style, initiator, frequency or volume. The register belongs to the system specification, with the boundaries, system requirements, NFRs and data model.
Integration styles (more in unit 4):
• synchronous request — we wait for a reply;
• event via a broker — we report and move on;
• webhook — the external system calls our address over HTTP;
• batch export — a file on a schedule.
ISO/IEC/IEEE 29148, the international specification framework, replaced the BA course's IEEE 830. Russian government projects use GOST 34.602-2020 (the Russian standard for a technical specification).
How to build a context diagram
- 1Boundary
Name the system and its boundary
- 2Participants
List the people and external systems that exchange data with it
- 3Arrows
Draw the arrows in the direction of the data
- 4Labels
Label what is passed and how
- 5Register
Move each arrow into the integration register
Integration register (excerpt)
| From → to | What | Style | Initiator |
|---|---|---|---|
| App → order service | order, cancellation | synchronous REST | customer |
| Order service → provider | payment, refund | synchronous REST | order service |
| Provider → order service | payment result | webhook | provider |
| Order service → notifications | status change | event via the broker | order service |
Lesson notes
Where our system ends
A context diagram shows the system as one central block surrounded by external participants: people and systems. Arrows are data flows labeled with what is passed; no internal modules or tables. Its roots: structured analysis and C4's System Context level.
Boundary rule: a party is external if we don't control its code or release schedule and agree on a contract with it. So the courier service, run by another Romashka team, is external to the order service.
Arrows follow the data. If the provider itself sends the payment result to our address (a webhook), the arrow runs from it to us. A webhook is a synchronous HTTP call, like a REST request, but started by the external system, so it's drawn solid; dashed lines are broker events.
Each arrow becomes a row of the integration register: from → to, what, style, initiator, frequency or volume. The register belongs to the system specification, with the boundaries, system requirements, NFRs and data model.
Integration styles (more in unit 4):
• synchronous request — we wait for a reply;
• event via a broker — we report and move on;
• webhook — the external system calls our address over HTTP;
• batch export — a file on a schedule.
ISO/IEC/IEEE 29148, the international specification framework, replaced the BA course's IEEE 830. Russian government projects use GOST 34.602-2020 (the Russian standard for a technical specification).