What Is Software Architecture?

Four dimensions of architecture

The architecture of a system is more than its structure. Fundamentals of Software Architecture frames it as four intertwined dimensions:

graph TD
A["Software Architecture"] --> S["Structure<br/>(architecture style)"]
A --> C["Architecture characteristics<br/>(the -ilities)"]
A --> D["Architecture decisions<br/>(the rules)"]
A --> P["Design principles<br/>(guidelines)"]

• Structure — the architecture style (layered, microservices, event-driven…).

• Characteristics — the success criteria the system must meet (availability, scalability, …).

• Decisions — the hard rules for how the system is built (e.g., “only the business layer may access the database”).

• Design principles — guidelines rather than rules (e.g., “prefer asynchronous messaging between services”).

• Structure answers what shape is the system? — the topology of components and how they’re partitioned.

• Characteristics answer what must it do well? — the operational and structural qualities (the “-ilities”) that determine success or failure independent of features.

• Decisions are the long-lived constraints that, once made, are costly to walk back.

• Design principles are softer guidance that teams apply case by case.

Together these define the intent of a system. You can read all the code and still not know the architecture, because the architecture lives in these cross-cutting choices, not in any single module.

A spectrum, not a wall

The classic question “is this architecture or design?” is better answered as a spectrum measured by the cost of change. Head First Software Architecture frames the same idea as a sliding scale: the further left a decision sits, the more it ripples across the whole system and the more expensive it is to undo.

graph LR
A["Architectural<br/>(hard to reverse)"] --> B["Style & topology"]
A --> C["Sync vs async"]
A --> D["Data ownership"]
E["Design<br/>(easy to reverse)"] --> F["Class structure"]
E --> G["Naming"]
E --> H["Local algorithms"]
A -.cost of change.-> E

Choosing event-driven over a monolith, or splitting one database into many, sits on the architectural end — reversing it touches every team. Renaming a method or reordering parameters sits on the design end. Most decisions fall in between, and the architect’s skill is sensing which end a given decision is closer to before committing.

Every decision is a trade-off

There are no best practices in architecture — only trade-offs. Choosing microservices buys independent deployability at the cost of operational complexity; choosing strong consistency buys correctness at the cost of availability. Fundamentals of Software Architecture captures this in its First Law of Software Architecture: everything in software architecture is a trade-off — and a corollary: why is more important than how.

The architect’s job is therefore not to find the “right” answer but to:

1. Identify the forces — the characteristics that actually matter for this system (see identifying architecture characteristics).
2. Weigh the trade-offs explicitly rather than defaulting to fashion or habit.
3. Record the why so future teams understand the constraints they inherited (see architecture decision records).

See also

• Architecture vs design — where the line really sits.
• Architecture characteristics — the “-ilities” that drive structure.
• Thinking in trade-offs — the core mental discipline of the role.

Related topics