Skill Hub — Architecture

System Context Mapping

Define what a system does, what it depends on, what depends on it, and where the integration boundaries lie.

What this skill is for

This skill produces a clear, bounded description of a single system within its environment. It answers: what is this system's responsibility, what does it need from other systems, what do other systems need from it, and where are the integration boundaries? The output is used during design, onboarding, incident response, and change impact analysis to prevent scope creep and boundary confusion.

When to use this skill

You are designing a new system and need to define what it will and will not do.
You are onboarding a development or operations team and they need to understand system boundaries.
An incident spans multiple systems and no one can agree which system is responsible for the failure.
You are planning a change to one system and need to know which other systems might break.
You are documenting a legacy system whose original architects have left the organization.

Real work situations

Example 1: SAP MDG as master data hub

A company uses SAP MDG to govern material and customer master data. The system context map defines that MDG receives creation requests from SAP S/4HANA (via workflow), enriches and validates them, and distributes golden records to S/4HANA, Salesforce, and the data warehouse. The map shows that MDG does not perform transactional processing, does not store historical pricing, and does not send data to the logistics platform. This boundary prevents a project from incorrectly asking MDG to handle shipment tracking data.

Example 2: Custom pricing engine on SAP BTP

A development team builds a custom pricing engine on SAP BTP that calculates complex regional discounts. The system context map defines that the engine receives product and customer data from S/4HANA via OData, receives competitor price feeds from an external market data service, and returns calculated prices to S/4HANA and a mobile sales app. The map explicitly states that the engine does not update master data, does not handle currency conversion, and does not store historical prices. This prevents scope creep during enhancement requests.

Example 3: Data warehouse in a mixed landscape

A SAP Datasphere instance serves as the enterprise data warehouse. The context map shows that it receives replicated data from S/4HANA CDS views, master data from MDG, and sales forecasts from Salesforce. It provides reporting to Power BI, self-service analytics to business users, and aggregated feeds to a planning system. The map records that Datasphere does not receive real-time transactional events, does not write back to S/4HANA, and is not the system of record for any master data. This boundary prevents operational teams from expecting real-time operational reporting.

Example 4: Integration middleware after a merger

After a merger, SAP Integration Suite becomes the central integration layer. The context map defines that it routes messages between S/4HANA, the acquired company's ERP, Salesforce, and logistics platforms. It performs protocol translation, message mapping, and basic error handling. It does not store business data long-term, does not perform business logic validation, and does not serve as a backup for failed downstream systems. This clarity prevents the integration team from being asked to implement data archiving or business rule enforcement.

Inputs required

The system name, version, and primary purpose (one sentence).
List of systems that send data or events to this system (upstream dependencies).
List of systems that receive data or events from this system (downstream dependencies).
Human actors who interact with the system (users, administrators, data stewards).
Data flows: what data enters, what data leaves, and what data is stored.
Integration mechanisms: APIs, events, files, database links, message queues.
Known boundary disputes: areas where other teams have asked this system to do something outside its scope.

Questions to ask

If this system were removed tomorrow, which business processes would stop and which would continue?
Which data does this system create, which does it receive, and which does it only pass through?
What is the one thing this system does that no other system in the landscape does?
Which requests from other teams have you rejected because they were outside this system's scope?
What is the slowest or most unreliable integration point, and what happens when it fails?
Who is responsible for this system when it is healthy, and who is responsible when it fails?
What would a new developer get wrong about this system's boundaries in their first week?

Working method

Name the system and state its primary purpose. One sentence. If you cannot state it in one sentence, the system's scope is probably undefined.
Identify the system in the center of a context diagram. Draw or describe the system as a single box. Everything else is outside.
Map upstream systems. List every system that sends data, events, commands, or requests to this system. For each, note the data, the mechanism, and the frequency.
Map downstream systems. List every system that receives data, events, or responses from this system. For each, note the data, the mechanism, and whether the delivery is synchronous or asynchronous.
Map human actors. List users, administrators, and operators who interact with the system. Note what they do and what they expect.
Define what the system does not do. Explicitly list responsibilities that are commonly assumed but outside scope. This is the most valuable part of the map.
Map data at rest. Note what data the system stores, how long it retains it, and whether it is the system of record for that data.
Identify integration boundaries. For each interface, note the protocol, the data format, the ownership, and the error handling approach.
Validate with stakeholders. Review the map with the system owner, upstream and downstream system owners, and operations. Correct misattributions.
Publish and maintain. Store the map where developers, operations, and project teams can find it. Review when the system changes or when boundary disputes recur.

Decision rules

If a system both sends and receives data from another system, draw two separate arrows, not one bidirectional line, because the failure modes differ.
If an integration uses a shared database or file system, classify it as a high-coupling boundary that requires explicit ownership.
If a human actor performs a function that could be automated but is not, note it as a manual boundary, not as a system capability.
If the system stores data but is not the system of record, note the actual system of record and the synchronization mechanism.
If a boundary is disputed between two teams, record both views, flag the dispute, and escalate to architecture governance.
If the context map contains more than 15 external systems, consider decomposing into subsystem context maps.
If an upstream system is external or SaaS, note the SLA, support channel, and escalation path explicitly.

Deliverables

System Context Map — Diagram or structured text showing the system at the center with upstream, downstream, and human actors.
Boundary Definition Document — Text description of what the system does, what it does not do, and why.
Interface Summary — Table of all integration points with direction, data, mechanism, and ownership.
Data Responsibility Matrix — Table of data elements stored, with system of record, retention, and synchronization notes.

Templates

System Context Map (Text format)

## System: <Name>

### Primary purpose


### Upstream systems (send to this system)

| System | Data / Event | Mechanism | Frequency | Owner |
|--------|--------------|-----------|-----------|-------|
| SAP S/4HANA | Material creation request | MDG workflow trigger | On demand | MDM Team |
| Salesforce | Customer update event | Event Mesh | Real-time | CRM Team |

### Downstream systems (receive from this system)

| System | Data / Event | Mechanism | Frequency | Owner |
|--------|--------------|-----------|-----------|-------|
| SAP S/4HANA | Golden material record | IDoc | Batch, hourly | MDM Team |
| Data Warehouse | Master data snapshot | OData extract | Daily | Data Team |

### Human actors

| Actor | Action | System area |
|-------|--------|-------------|
| Data Steward | Review and approve master data changes | MDG workflow inbox |
| MDM Administrator | Monitor distribution errors | MDG error log |

### What this system does NOT do

- Does not perform transactional processing (sales, procurement, production).
- Does not store historical pricing or contract terms.
- Does not send data directly to the logistics platform.
- Does not replace source system validation; it adds governance layer validation.

### Data at rest

| Data element | System of record | Retention | Notes |
|--------------|------------------|-----------|-------|
| Golden material master | This system (MDG) | 10 years | Archival after 2 years of inactivity |
| Customer master | This system (MDG) | 10 years | GDPR deletion workflow required |

### Integration boundaries

| Interface ID | Direction | Protocol | Data format | Error handling | Owner |
|--------------|-----------|----------|-------------|----------------|-------|
| IF-001 | Inbound | OData | JSON | Retry 3x, then alert | Integration Team |
| IF-002 | Outbound | IDoc | EDIFACT | Queue and retry | Integration Team |

Quality checklist

The system's primary purpose is stated in one sentence.
Every upstream and downstream system is named with specific data and mechanism.
At least three "does NOT do" items are listed to clarify boundaries.
Every integration point has a defined error handling approach.
Data at rest is listed with system of record and retention.
The map has been validated by the system owner and at least one adjacent system owner.
Human actors are included, not just systems.
No boundary dispute remains unflagged or unresolved.

Common mistakes

Mistake: Drawing the system context map as a network diagram without defining boundaries. Consequence: The diagram shows connectivity but not responsibility, and incident response teams still argue about ownership.
Mistake: Omitting what the system does not do. Consequence: Scope creep is inevitable because every adjacent team assumes the system can absorb new responsibilities.
Mistake: Treating a shared database as a clean integration boundary. Consequence: Changes by one team break another team's queries, and no one knows who is responsible.
Mistake: Creating the map once and never updating it. Consequence: New integrations, retired systems, and changed data flows make the map misleading.
Mistake: Including only technical systems and ignoring human actors. Consequence: Manual steps, approvals, and data steward actions are invisible, leading to automation proposals that ignore human checkpoints.

Agent instructions

When using this skill, an AI agent must:

Start with the primary purpose. Do not produce a context map until the system's one-sentence purpose is confirmed.
Use the text template. Generate the System Context Map in the exact Markdown template format. Include all sections: upstream, downstream, actors, does NOT do, data at rest, integration boundaries.
Be specific about mechanisms. Do not write "integrated with SAP." Write "receives material master via IDoc from SAP S/4HANA, batch hourly."
Explicitly list negative boundaries. The "does NOT do" section is mandatory. Ask the user for common scope creep requests if they cannot list them.
Flag missing ownership. If any integration point lacks an owner, flag it and ask for assignment.
Do not invent systems. If the user describes a system but cannot name adjacent systems, list placeholders and ask for confirmation.
Link to Atlas for integration patterns. If the system is part of an SAP landscape, reference SAP Integration Architecture and Event-Driven Architecture for pattern guidance.

Related skills

Capability Mapping — Map the business functions that the system supports.
Solution Architecture Review — Review a design against the boundaries this map defines.
Interface Ownership — Define ownership for each integration boundary.
Change Impact Analysis — Assess how changes affect the mapped boundaries.

Related Atlas pages

SAP Integration Architecture — Patterns and constraints for SAP system boundaries.
Event-Driven Architecture — How event patterns affect system context and coupling.
API Contracts — How API agreements define integration boundaries.
Data Contracts — How data agreements constrain what crosses system boundaries.

Verification status and limitations

This skill is a public working interpretation of system context mapping practice. It is not official C4 model, UML, or ArchiMate documentation. It focuses on the lightweight text-based context map suitable for project and operational use. It does not cover detailed container or component-level decomposition. Use it as a boundary-clarification tool for teams that need to agree on system responsibilities, not as a comprehensive modeling methodology.