Skip to content
Software Architecture Guide

Software Architecture

Explanation

Section titled “Explanation”

There is no single agreed definition of software architecture. Several sources describe it from different angles.

Elements, form and rationale. An early model splits architecture into three parts: elements, form and rationale. Elements are processing, data or connecting elements. The rationale explains why the architecture looks the way it does. It rests on system constraints, which usually come from requirements. So the “why” is part of the architecture, not only the structure.

The standard view. The standard ISO/IEC/IEEE 42010 separates two things. The architecture is the fundamental concepts or properties of the thing being described. The architecture description is a work product made of artifacts that document it. The 2022 version widens “system” to an “entity of interest”. That can be a system, software, an enterprise or something else. See the article ISO/IEC/IEEE 42010 Architecture Description Standard.

The important stuff. One well-known view says architecture is about what is important, whatever that turns out to be. The same source also describes it as the shared understanding that expert developers have of the system design.

Building blocks and decisions. A software architecture curriculum describes architecture through building blocks, their interfaces and relationships, and through decisions with system-wide consequences. It makes architects responsible for meeting requirements and creating the architecture design.

Architecture and design. Architecture is design, but not all design is architectural. The architect decides where architectural design ends and detailed design begins.

Why it matters. Architectural choices are costly to change. A poor architecture contributes to the growth of cruft, meaning messy leftovers that make software harder to modify.

Example

Section titled “Example”

Imagine a small online shop. The team decides that ordering, payment and stock are separate parts. They also decide how those parts exchange data, and they write down why. These choices are architectural, because changing them later would touch the whole system. The color of a button is detailed design. The architect decides where that line falls.

Trade-offs

Section titled “Trade-offs”

Because definitions differ, teams may talk past each other. One person means structure, another means key decisions, another means shared understanding. Agree on a working definition early. The line between architecture and detailed design is a judgment call, so it can move from project to project.

Checks

Section titled “Checks”
  • The document states the rationale behind the architecture, not only its structure.
  • The document separates the architecture itself from the description that documents it.
  • The document names the main building blocks, their interfaces and relationships.
  • The document states where architectural design ends and detailed design begins.
Section titled “Related”

Sources

Section titled “Sources”