Skip to content
Software Architecture Guide

Software Architecture Definition

Explanation

Section titled “Explanation”

There is no single definition of software architecture. The sources here describe it in three ways.

Design decisions about structure and behavior. The Software Engineering Institute (SEI) says a system’s architecture represents the design decisions about its overall structure and behavior. This view treats architecture as a set of choices. The article Architecture as Set of Design Decisions covers this idea further.

The important stuff. Martin Fowler, citing Ralph Johnson, says architecture is about the important stuff, whatever that is. The phrase admits that what counts as important depends on the system.

Shared understanding. Johnson also describes architecture as the expert developers’ shared understanding of the system design. Here architecture lives in people’s heads as well as in documents.

An older, looser SEI wording. An early SEI article described architecture as the organizational structure of a software system. That structure includes components, connectors, constraints and rationale. Components are the parts of a system. Connectors are the links between them. Constraints are limits the design must respect. Rationale is the reasoning behind the choices.

What the definitions share. All of them focus on the overall shape of a system, not on every detail. They differ in where they place it: in decisions, in importance, or in people’s understanding.

Example

Section titled “Example”

A team builds an online shop. One member lists the decisions made: split the system into a catalog part and an order part, and set how they exchange data. That matches the SEI view. Another member says the architecture is whatever the team agrees matters most, such as keeping orders safe. That matches the “important stuff” view. A third member says it is what the experienced developers all understand about how the shop is built. That matches the shared-understanding view.

Trade-offs

Section titled “Trade-offs”

Each wording has a cost.

  • “The important stuff” is flexible, but it does not say what is important. Teams must decide that themselves.
  • “Shared understanding” captures what people know, but it can be lost when the experts leave, unless it is written down.
  • “Design decisions” is concrete enough to record and review. It can miss knowledge that nobody has written down as a decision.
  • The early SEI wording lists parts to describe, but it is loose about where the boundaries lie.

Checks

Section titled “Checks”
  • The document states which definition of architecture the team uses, such as design decisions about overall structure and behavior.
  • The document describes the system’s components, connectors, constraints and rationale.
  • The document makes clear which parts of the system the team treats as important.
Section titled “Related”

Sources

Section titled “Sources”