by Guillermo Quiros
A hands-on guide to drawing System Landscape diagrams that make your entire software portfolio visible at a glance.
Need the full picture first? Open the C4 model hub and come back here for the System Landscape deep dive.
What Is a System Landscape Diagram?
A **C4 System Landscape diagram** shows all the software systems within a given enterprise boundary and the relationships between them. It is the highest-level view in the C4 model — broader than a System Context diagram because it places multiple systems on the same canvas.
Where a Context diagram zooms in on one system and its immediate neighbours, the Landscape diagram zooms out to show the whole estate. If you are an enterprise architect, a CTO trying to explain portfolio complexity, or a team that owns several interconnected systems, the Landscape diagram is the view you reach for first.
The C4 model does not treat the System Landscape as a numbered level (it sits outside Levels 1–4). Think of it as a prerequisite step: draw the landscape once to establish scope, then draw individual Context diagrams for each system that needs deeper explanation.
System Landscape vs System Context
The two diagrams look similar at first glance — both show systems as boxes with relationships between them. The key difference is scope.
| Dimension | System Context (Level 1) | System Landscape |
|---|---|---|
| Focus | One system and its external dependencies | All systems in the enterprise |
| Audience | Engineers and stakeholders for that system | Executives, architects, anyone needing the big picture |
| When to draw | Every system that needs explanation | Once per organisation or business domain |
| Level of detail | Medium: shows all actors and external systems touching the target | Low: systems are boxes, relationships are labelled lines |
A practical rule: if you are drawing a diagram and you find yourself adding more than four or five external systems around your central box, you may have accidentally started drawing a Landscape. Step back and consider whether you need a Landscape first.
Elements of a System Landscape Diagram
A System Landscape diagram uses a small vocabulary. Every element maps directly to something in the C4 notation.
Software Systems
Each box represents a distinct software system — something a team owns and deploys. You do not show containers, components, or code at this level. The box just needs a name and a one-line description of its purpose.
Group systems by business domain or ownership boundary when the estate is large. Grouping makes the diagram readable even when there are twenty or thirty systems on the canvas.
People (Actors)
Include the main user groups and external actors that interact with the estate. Keep it to archetypes — "Customer", "Internal Staff", "Partner API Consumer" — rather than listing every individual role. Too many actor boxes at this level creates noise without adding clarity.
Relationships
Draw a line between two systems or between a person and a system when there is a direct integration, data flow, or dependency. Label the line with the protocol or the nature of the dependency ("REST API", "event stream", "file transfer"). Avoid lines that represent organisational relationships or reporting chains — those belong in org charts, not Landscape diagrams.
External Systems
Systems that your organisation does not own but that touch your estate belong on the canvas too: payment processors, identity providers, third-party analytics platforms. Mark them visually as external — in C4 notation, a lighter background or an explicit label keeps them distinct from internally owned systems.
When to Draw a System Landscape
Not every organisation needs a System Landscape diagram, but three situations make them almost essential.
Onboarding at scale. When an engineer joins a large organisation, a single diagram that shows where their system sits within the broader estate shortens the "orientation tax" from weeks to days. The Landscape gives them the map before they need the territory.
Identifying hidden dependencies. Teams often build integrations informally, and those integrations accumulate over time without ever appearing in any diagram. Drawing a Landscape forces the conversation: every line you draw represents an integration you are committing to document. In practice, the drawing session itself surfaces dependencies that nobody remembered were there.
Architecture governance. If your organisation reviews proposed changes at an architecture board or RFC level, a Landscape diagram is the shared reference that makes review conversations concrete. "We are adding a new dependency from the Payments system to the Notifications system" lands differently when both people can point to the boxes on a shared canvas.
How to Build a System Landscape Diagram
A Landscape diagram is useful only when it is kept current. The following approach treats the diagram as a living artefact rather than a one-time deliverable.
Step 1: List every system you own
Start with a flat list of all software systems in scope. Do not filter yet — write them all down. Sources include your deployment pipeline, your infrastructure provider's service catalogue, and your incident management tool's list of services.
Step 2: Add external dependencies
For each internal system, list the external systems it depends on. Payment gateways, SaaS tools, identity providers, and partner APIs all belong here. Add them to the canvas with a visual distinction from internal systems.
Step 3: Draw relationships
Connect systems that exchange data, calls, or events. Resist the temptation to show every possible integration. Focus on primary flows — the ones that would cause an incident if they broke. Secondary or historical integrations can live in documentation rather than on the diagram.
Step 4: Add key actors
Place the primary user groups on the canvas and connect them to the systems they directly use. Keep to three or four archetypes maximum at this level.
Step 5: Validate with team leads
Walk through the diagram with the lead engineer or architect for each system. The goal is to catch missing systems, missing integrations, and incorrect labels. A thirty-minute review per domain is usually enough.
Step 6: Decide what to expand next
After the Landscape exists, decide which systems warrant a System Context diagram (Level 1). Typically the systems that are most complex, most critical, or most frequently misunderstood are the best candidates for deeper zoom.
Common Mistakes
Including too much detail. If a line on your Landscape shows specific API endpoints or database tables, you have gone too deep. Keep labels short and descriptive.
Only drawing internally owned systems. A Landscape that omits external dependencies is incomplete. The payment processor or the third-party identity provider belongs on the canvas even if your team cannot change it.
Letting it go stale. A Landscape that no longer matches reality is worse than no Landscape — it misleads the people who rely on it. Assign ownership for keeping it current and review it whenever a new system is added or decommissioned.
Drawing it instead of a Context diagram. If your team needs to explain the boundaries of a single system, draw a Context diagram, not a Landscape. The Landscape is not a substitute for Level 1 — it is the level above it.
System Landscape and the Rest of the C4 Model
The Landscape diagram does not replace any of the four C4 levels. It supplements them by providing a roof over the hierarchy.
A complete documentation set for a complex organisation might look like this:
- One System Landscape diagram showing the full portfolio
- Context diagrams (Level 1) for three or four critical systems
- Container diagrams (Level 2) for the systems that benefit from a structural breakdown
- Component diagrams (Level 3) only for areas of high internal complexity
- Deployment diagrams (Level 4) for systems where runtime topology matters
The Landscape is the entry point. It gives every reader a shared frame of reference before they dive into any system-specific view.
Frequently Asked Questions
How many systems should appear on a Landscape diagram?
There is no fixed limit, but diagrams with more than fifteen to twenty systems become hard to read without visual grouping. If your estate is large, consider drawing separate Landscape diagrams per business domain rather than one all-encompassing canvas.
Is the System Landscape diagram part of the official C4 model?
It is documented by Simon Brown alongside the four core levels but is not numbered as a level itself. Think of it as a companion diagram — it uses the same notation and sits at a higher zoom level than Level 1.
Do I need a System Landscape before drawing Context diagrams?
No. Many teams draw Context diagrams first and add the Landscape later when they need the portfolio view. The order depends on what the immediate audience needs. If you are explaining a specific system, start with the Context diagram. If you are explaining the whole estate, start with the Landscape.
How often should the Landscape be updated?
Treat it like infrastructure documentation: update it when the topology changes. In practice, that means reviewing it whenever a new system is added, an old one is decommissioned, or a significant integration changes. Quarterly reviews work well for most teams.