# Business and Technical Context

**In short:** Business context shows which data a system exchanges with people and neighboring systems. Technical context shows the channels and protocols that carry that data. Documenting both, and linking them, helps stakeholders decide.

## Explanation

A system does not work alone. It talks to users and to neighboring systems. arc42 (a template for architecture documentation) describes this in section 3, Context and Scope. It offers two views of the same boundary.

**Business context**

- The goal is that all stakeholders understand which data the system exchanges with its environment.
- The diagram treats the system as a black box. You see only the outside, not the inner parts.
- It names the domain interfaces to each communication partner.
- It should show data flows, not dependencies. An arrow means "this data moves here", not "this depends on that".

**Technical context**

- It covers the technical interfaces that link the system to its environment. These are channels and transmission media.
- Use it to describe protocols or channels.
- It matters because many stakeholders base architectural decisions on these interfaces.
- arc42 suggests a UML deployment diagram for the channels to neighboring systems. See the article UML Deployment Diagram.

**Keeping the views apart, then linking them**

arc42 advises you to differentiate the two views. It also advises you to explain how each domain interface is technically realized. A simple table can do this: one row per business interface, with its channel or protocol.

**Notation**

A C4 system context diagram puts the system in the center, among users and external systems. It is a zoomed-out view. It deliberately leaves out technologies and protocols, so it resembles a business-level view. See the article System Context Diagram.

**Common mistakes to avoid**

- Leaving out an external interface. arc42 says to show all of them.
- Adding excess detail. Keep the context an overview.
- Mixing business and technical content in one diagram.
- Drawing dependencies instead of data flows in the business view.

If several neighbors are alike, you can cluster them using ports.

## Example

An invented online shop. The business context shows a customer sending orders and receiving confirmations. It shows a payment provider receiving payment requests and returning results. The technical context then adds a table.

| Business interface | Channel |
|---|---|
| Order from customer | Web page over HTTPS |
| Payment request | Provider's web API |
| Shipping notice | Daily file drop |

The first view answers "what data moves?". The second answers "how does it move?".

## Trade-offs

Two views mean more diagrams to maintain. The mapping between them must stay current. In return, business readers are not buried in protocol detail. Technical readers still find the channels they need for decisions. A C4 context diagram is simple but leaves out protocols, so you need a second view for them.

Same neighbors seen twice: data flows (business) and channels (technical).

```mermaid
flowchart LR
  C[Customer] -->|order data| S[Shop system]
  S -->|payment request| P[Payment provider]
  subgraph Technical
  C2[Customer] -. HTTPS .- S2[Shop system]
  S2 -. web API .- P2[Payment provider]
  end
```

## Checks

- The business context shows the system as a black box with its domain interfaces to each communication partner.
- Business context arrows show data flows, not dependencies.
- Business and technical context are kept as separate views.
- Each domain interface is explained by its technical realization (protocol or channel).
- All external interfaces are shown, and the context stays an overview.

## Related

- [arc42 Context and Scope](https://arc.fuet.ch/concepts/documentation/arc42-context-and-scope.md)
- [Context View](https://arc.fuet.ch/concepts/vision-stakeholders/context-view.md)
- [System Context Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-1-system-context-diagram.md)
- [UML Deployment Diagram](https://arc.fuet.ch/concepts/modeling-uml/deployment-diagram.md)
- [Context View Antipatterns](https://arc.fuet.ch/concepts/documentation/context-view-antipatterns.md)
- [Refining Complex Context Views](https://arc.fuet.ch/concepts/vision-stakeholders/refining-complex-context-views.md)
- [Port](https://arc.fuet.ch/concepts/modeling-uml/component-port.md)
- [Provided and Required Interface](https://arc.fuet.ch/concepts/modeling-uml/provided-and-required-interface.md)

## Sources

- [3 - Context and scope | arc42 Documentation](https://docs.arc42.org/section-3/) — docs.arc42.org, accessed 2026-11-09
- [System context diagram | C4 model](https://c4model.com/diagrams/system-context) — c4model.com, accessed 2026-11-09