Skip to content
Software Architecture Guide

Business and Technical Context

Explanation

Section titled “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

Section titled “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

Section titled “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).

Diagram source 
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

Section titled “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.
Section titled “Related”

Sources

Section titled “Sources”