What software architecture is: the standard definitions and what they share

Why the word needs defining at all

Ask ten experienced engineers what software architecture is and you will hear ten different answers: the boxes-and-arrows diagram on the wall, the choice of cloud provider, the database schema, the split into services, the rules about which code may call which, or simply "the hard decisions". Each answer captures something real, and each, taken alone, misses something. A course that is going to teach architecture therefore has to start by being precise about what it is talking about.

This matters for practical reasons. If a team thinks architecture means "the diagram", it will stop paying attention once the diagram is drawn, even though the system keeps changing underneath it. If it thinks architecture means "the technology stack", it will argue about frameworks while ignoring how responsibilities are divided and how data flows. A good definition tells you what to look at, what to protect and what to discuss with others.

The definitions below come from an international standard, from the Software Engineering Institute (SEI) at Carnegie Mellon University, and from practitioners. They were written for different purposes, but they agree on more than they disagree, and the points where they agree are the core of the discipline.

The standard definition: ISO/IEC/IEEE 42010:2022

ISO/IEC/IEEE 42010 is the international standard for describing architectures. Its current edition, published in November 2022, replaced the 2011 edition. It defines architecture, in close paraphrase, as the fundamental concepts or properties of an entity in its environment, together with the governing principles for that entity's realisation and evolution and for its related life-cycle processes.

Three features of this definition deserve attention. First, it talks about an entity, not only a software system. The 2022 edition deliberately widened the scope so that the same ideas apply to software, systems of systems, products, product lines and whole enterprises. Second, it places the entity in its environment: you cannot understand an architecture without the users, other systems, organisation, laws and budgets around it. Third, it includes governing principles for how the entity is built and how it changes. Architecture is not only a snapshot of structure; it includes the rules that keep the structure coherent as the system evolves, such as "every service owns its own data" or "the domain code never depends on the web framework".

The standard also draws a sharp line between an architecture and an architecture description. The architecture is the set of fundamental properties the system actually has. The description is a work product (documents, models, diagrams, decision records) that expresses it. ISO/IEC/IEEE 42010 is mainly a standard about descriptions: it says what a good description should contain, such as identified stakeholders, their concerns and views that address those concerns. It does not tell you how to design an architecture. Section 1.5 returns to stakeholders and concerns, and Chapter 4 covers views.

The SEI definition: structures, elements, relations and properties

The most widely taught definition comes from Software Architecture in Practice by Len Bass, Paul Clements and Rick Kazman (4th edition, Addison-Wesley, 2021), whose authors worked at the SEI. In their words, paraphrased: the software architecture of a system is the set of structures needed to reason about the system, and those structures consist of software elements, the relations among them and the properties of both.

Each part of that sentence does work. Structures, plural: a system has many structures at once (its code modules, its running processes, its deployment onto machines) and no single one is "the" architecture. Needed to reason about the system: the test of whether something is architectural is whether you need it to answer important questions, such as "Will this survive peak load?" or "Can two teams work on this independently?". Elements are the parts: modules, services, databases, queues. Relations are how they connect: uses, calls, publishes to, is deployed on. Properties are what makes elements and relations behave as they do: a service is stateless, a call is synchronous with a two-second timeout, a database holds personal data and must stay in the EU.

The phrase about reasoning also explains what is not architecture. The name of a local variable, the internal algorithm of a sorting routine or the layout of a settings screen usually do not help you reason about the system as a whole, so they belong to detailed design rather than to architecture. Section 1.2 examines where that line falls.

Practitioner definitions: shared understanding, important stuff and decisions

Practitioners have offered shorter definitions that emphasise people and decisions rather than structures. Martin Fowler has popularised two from Ralph Johnson (one of the four authors of the 1994 Design Patterns book). The first is that architecture is the shared understanding that the expert developers have of how the system is designed. The second, from the same discussion, is deliberately open-ended: Architecture is about the important stuff. Whatever that is. Johnson also suggested that architecture is the set of decisions you wish you could get right early in a project, not because you are more likely to get them right early, but because they are so costly to get wrong.

Grady Booch, one of the creators of the UML, framed it in economic terms: architecture consists of the significant design decisions that shape a system, where significance is measured by the cost of change. That turns an abstract idea into a usable test. Choosing the colour of a button is cheap to reverse. Choosing between a relational database and a document store, or between one deployable unit and forty, is expensive to reverse once data, code and teams have grown around it. Booch also observed that all architecture is design, but not all design is architecture.

These definitions add something the structural ones leave implicit. Architecture lives partly in people's heads; a system whose senior engineers share a clear picture of how it works has a more coherent architecture than one where everyone holds a different picture, even if neither has a diagram. And architecture is shaped by decisions, many of them involving a trade off: choosing one option means giving up the advantages of another. Section 1.6 looks at decisions and trade-offs in detail.

What the definitions share

Read side by side, the definitions converge on seven ideas, and together these make a working definition for the rest of this course.

Three kinds of structure

The SEI's work on documentation, published as Documenting Software Architectures: Views and Beyond (Clements and colleagues, 2nd edition, 2010), groups structures into three kinds, and Software Architecture in Practice uses the same grouping. Knowing the three kinds protects you from the commonest mistake in architecture discussions: talking about one kind of structure while the other person is thinking of another.

Module structures show how the code is divided into units of implementation, such as packages, libraries and namespaces, and how those modules depend on each other. They exist at development time. They answer questions such as: which team can change what without breaking others, and which code can be reused?

Component-and-connector structures show what exists when the system runs: processes, services, clients, databases, and the connectors between them, such as HTTP calls, message queues and event streams. They answer runtime questions: how fast is a request, what happens when one part fails, where is data held?

Allocation structures map software onto things outside the software: onto hardware and cloud infrastructure (deployment), onto teams (work assignment), and onto files and repositories (implementation). They answer questions about cost, operations and organisation: where does it run, who builds it, who is woken up at night when it fails?

One element can appear in all three. A checkout feature is a package in the module structure, a running service in the component-and-connector structure, and a set of containers in a cloud region owned by the checkout team in the allocation structures. The mapping between structures is not always one to one: a single module may be deployed as several services, or several modules may run in one process. That gap is exactly where many surprises hide.

Every system has an architecture

Because architecture consists of structures and the properties they actually have, every software system has an architecture, whether or not anyone designed it on purpose and whether or not it is written down. A spreadsheet macro that grew into a business-critical tool has an architecture. So does a startup's codebase written in a hurry by three people. The question is never whether a system has an architecture, but whether that architecture is fit for its purpose, understood by the people who work on it, and deliberately shaped.

This leads to a useful distinction. The intended (or prescriptive) architecture is what the team believes or has decided the structure should be: the diagram on the wiki, the agreed rules. The actual (or descriptive) architecture is what the code and infrastructure really do. The two drift apart over time unless someone keeps them aligned, and that gap is one of the main sources of technical debt, covered in Section 1.7. An undocumented architecture is not absent; it is merely harder to see, reason about and change safely.

How professionals use the definitions

In practice, experienced architects rarely recite a definition, but they use each one as a lens. The ISO view reminds them to look outward at the environment and to separate what the system is from what the documents say. The SEI view gives them a vocabulary of structures, elements, relations and properties for analysis, and a test ("do we need this to reason about the system?"). Johnson's view reminds them that a shared mental model across the team is itself an asset to be maintained. Booch's view tells them where to spend their limited time: on the decisions that would be expensive to reverse.

A practical rule of thumb follows. When you are unsure whether something is architectural, ask three questions. Would it be expensive or risky to change later? Does it affect several parts of the system or several teams? Does it determine whether the system meets an important quality goal, such as speed, availability or security? If the answer to any of these is yes, treat it as architecture: decide it deliberately, record the reasons, and make sure the people affected understand it.