System Diagram

Purpose

A System Diagram gives a team a shared picture of how a system operates. By drawing the components (subsystems, actors, tools), the boundaries (what is inside and outside the system), and the flows between them (information, money, materials, decisions), the group aligns on how things actually work before trying to change them.

At a glance

How to run

1. Define the system (3 min): Name the system and draw the boundary (a large box or circle).
2. Identify components (8 min): Brainstorm the key components inside the system: actors, subsystems, tools, databases, processes. Write on sticky notes and place inside the boundary.
3. Identify external actors (4 min): Who or what interacts with the system from outside? Place these outside the boundary.
4. Draw flows (12 min): Connect components with arrows showing flows of information, money, materials, or decisions. Label each flow.
5. Identify pain points (5 min): Mark where flows break down, are slow, or are unclear.
6. Discuss (3 min): What does this diagram reveal? Where should we focus improvement efforts?

Materials needed

• Large whiteboard or paper
• Sticky notes (different colours for components, external actors, flows)
• Markers
• System boundary drawn in advance

Pitfalls & common mistakes

• Too much detail: Keep it at the system level, not the implementation level.
• Missing flows: Components without connections are orphans — check for missing links.
• No boundary: Without a clear boundary, the diagram keeps expanding.
• Assuming shared understanding: Different people see the system differently. That is the point of the exercise.

Inclusion & accessibility

• Walk through the diagram step by step so everyone follows.
• Use labels on all components and flows for readability.
• Allow participants to suggest components via sticky notes if they are hesitant to speak up.

Variations

• Context Diagram: A simpler version showing only the system as one box with external interactions.
• Data Flow Diagram: Focuses specifically on data movement.
• Ecosystem Map: Broader view including competitors, partners, and market forces.

When NOT to use this

• When the system is trivially simple.
• When a formal architecture diagram already exists and is up to date.
• When the team needs to make a decision, not understand a system.

Source & further reading

• Systems engineering fundamentals
• Donella Meadows, *Thinking in Systems* (2008)
• UML and architecture diagramming traditions