Skip to content
Software Architecture Guide

System Idea

Explanation

Section titled “Explanation”

A system idea is the first overall picture of how a system could work. The arc42 template has no section with this exact name. Its closest match is the solution strategy (see the article Solution Strategy). That section summarizes the fundamental decisions that shape the system’s architecture.

What goes into it

  • Top-level structure. The decisions include how to split the system at the highest level. Teams often do this by choosing an architectural pattern or a design pattern. These are proven, reusable solutions. (See Architectural Pattern vs. Design Pattern.)
  • Reuse in context. A pattern achieves certain qualities for a given problem in a given context. Reuse helps only when the context fits.
  • Reasons. Each decision should be motivated by the problem statement, the quality goals and the key constraints. The strategy should also say how the key quality goals will be reached.

Showing the idea

The building block view in arc42 starts at level 1, a whitebox view of the whole system. It includes an overview diagram that refines the context view. Such a diagram is one way to make the idea visible to others. (See Architectural Overview Diagram and Context View.)

Looking at trade-offs

Architects are expected to identify and communicate trade-offs between designs, along with the risks of each. A system idea should therefore state what it gains, what it costs and which risks come with it.

Example

Section titled “Example”

A team builds an online booking tool. Its main quality goal is that many people can book at once. A key constraint is a small team. The team writes a short idea: split the system into a web front end and a booking service, using a well-known pattern for that split. Each choice gets a one-line reason tied to the goal or the constraint. The team also notes the main cost and risk of the split.

Trade-offs

Section titled “Trade-offs”

Reusing a proven pattern saves effort, but it only fits if the problem and context match. Every design gains some qualities and gives up others. Naming those trade-offs and their risks early makes the idea easier to discuss and challenge.

Checks

Section titled “Checks”
  • The solution strategy summarizes the fundamental decisions that shape the architecture.
  • The top-level decomposition names the pattern used, if any.
  • Each strategic decision is tied to the problem statement, quality goals or key constraints.
  • The document states how the key quality goals are achieved.
  • Trade-offs between designs and their risks are identified and communicated.
Section titled “Related”

Sources

Section titled “Sources”