Skip to content
Software Architecture Guide

Software Architecture Basic Concepts

Explanation

Section titled “Explanation”

Architecture as decisions and structure. One widely used definition says the software architecture of a system is the set of design decisions about its overall structure and behavior. It helps stakeholders (people with an interest in the system) understand and analyze how the system will reach its essential qualities. Documenting architecture also means describing its elements and how they relate to each other, aimed at key qualities. That is the structural side. See Software Architecture and Architecture as Set of Design Decisions.

Requirements drive architecture. A system is created or changed to support a business activity. So business needs motivate and drive the architecture. The requirements and driving forces that architects must consider belong in the introduction and goals section of an arc42 document (see arc42 Introduction and Goals).

Quality goals. Quality goals for the architecture are the few that matter most to major stakeholders. They shape fundamental decisions. They are different from project goals, so keep the two apart.

System and boundary. A system sits in an environment. arc42 advises you to demarcate the system explicitly from that environment. The line you draw is the system boundary. See arc42 Context and Scope.

Building blocks. Inside the boundary, the system is split into building blocks. The arc42 building block view shows this static decomposition. The blocks form a hierarchy of black boxes and white boxes. Each level zooms into the blocks of the level above.

Example

Section titled “Example”

A company builds an online shop to sell more products. That business need drives the architecture. The team names two quality goals that matter most to the major stakeholders. They draw a boundary around the shop and show payment providers and customers as its environment. Inside the boundary, they split the shop into a few blocks. They then zoom into one block to show its parts.

Trade-offs

Section titled “Trade-offs”

The facts here cover only the basic terms. Other sources may use these terms differently, and this article does not compare them. Keep quality goals few: the more goals you list, the less each one influences decisions.

Needs drive the architecture; the system boundary separates the building blocks from the environment.

Diagram source 
flowchart TB
  N[Business needs and quality goals] --> A[Architecture]
  subgraph Env[Environment]
    subgraph Sys[System boundary]
      B1[Building block A]
      B2[Building block B]
    end
  end
  A --> Sys

Checks

Section titled “Checks”
  • The document states the requirements and driving forces the architecture must consider.
  • Quality goals are few, tied to major stakeholders, and kept separate from project goals.
  • The system is explicitly demarcated from its environment.
  • The building block view shows the decomposition as a hierarchy of black boxes and white boxes.
Section titled “Related”

Sources

Section titled “Sources”