Note
This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.
IMPORTANT
TLDR
Key Themes Across Definitions
- Structure and Components (system organization and relationships).
- Principles and Constraints: (design governance).
- Significant/Important Decisions: (importance measured by cost of change).
- Multiple Views/Perspectives: (various stakeholder perspectives define the required architectural characteristics).
- Reasoning and Understanding: (team alignment).
- Economics: (change impact).
Standards-Based Definitions
ISO/IEC/IEEE 42010:2022 (Current International Standard)
Fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes https://www.iso.org/standard/74393.html
Influential Book Definitions
Mark Richards and Neal Ford’s ”Fundamentals of Software Architecture”
(https://learning.oreilly.com/library/view/fundamentals-of-software/9781492043447/)
Presents a definition built on four components:
- Structure: the type of architecture style (or styles) the system is implemented in (such as microservices, layered, or microkernel)
- Architectural characteristics: define the success criteria of a system, which is generally orthogonal (unrelated) to the functionality of the system.
- Architecture decisions*: define the rules for how a system should be constructed
- Design principles: is a guideline rather than a hard-and-fast rule - example: development teams should leverage asynchronous messaging between services within a microservices architecture to increase performance
Len Bass, Paul Clements, and Rick Kazman “Software Architecture in Practice”
(https://learning.oreilly.com/library/view/software-architecture-in/9780136885979/)
The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.
This definition emphasizes structures (plural) and the ability to reason about the system. The authors explicitly note this stands in contrast to definitions that talk about “early” or “major” decisions, as it’s hard to determine what makes a decision “major” until later.
Ford, N., Parsons, R., & Kua, P. (2022). Building Evolutionary Architectures, 2nd Edition
(https://learning.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/)
Core Definition
Evolutionary architecture is defined by three key attributes:
- Guided Change: Architectural goals are made explicit through Fitness Functions—automated, measurable checks (akin to unit tests) that continuously validate desirable system qualities (e.g., performance, security, modularity).
- Incremental Change: The architecture has to supports small, frequent adaptations instead of large-scale, disruptive rewrites. (example of architectural decision in this context, that supports incremental change: “the original service can run alongside the new one as long as other services need it”)
- Multiple Dimensions: Evolution occurs across various axes (functional, structural, operational, security, etc), each governed by its own Fitness Functions.
Implications for Software Architecture
Within an evolutionary architecture, software architecture is defined as:
The set of structures, rules, and automated checks that collectively ensure the system can evolve in a controlled, measurable way over time.
Thought Leader Definitions
Grady Booch (IBM Fellow, Co-creator of UML)
(https://en.wikipedia.org/wiki/Grady_Booch)
Architecture represents the significant design decisions that shape the form and function of a system, where significant is measured by the cost of change.
Booch’s definition links architecture directly to economics and emphasises that:
- “All architecture is design, but not all design is architecture”
- Every software-intensive system has an architecture: “some are intentional; a few are accidental; most are emergent”
Martin Fowler
In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called architecture.
Fowler also defines architecture as: “The decisions that are hard to change later” and emphasizes these are the decisions “that you wish you could get right early in a project.”
Additionally: “Architecture is those decisions which are both important and hard to change.”
Framework-Specific Definitions
TOGAF (The Open Group Architecture Framework)
(https://www.opengroup.org/togaf) TOGAF provides two complementary definitions:
- “A formal description of a system, or a detailed plan of the system at component level to guide its implementation”
- “The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time”
TOGAF embraces but extends the IEEE 1471/ISO 42010 definition.
4+1 Architectural View Modal
(https://en.wikipedia.org/wiki/4%2B1_architectural_view_model) (https://medium.com/javarevisited/4-1-architectural-view-model-in-software-ec407bf27258)
The “4+1” architectural view model is a software architecture description that organizes a system’s design into five concurrent views: four primary views and a fifth “plus one” view that illustrates the others. The four views are:
- Logical(functionality for end-users),
- Process (concurrency and run-time behavior),
- Development (software organization in the development environment), and
- Physical (mapping software to hardware). The fifth view, the Use Case or Scenario view, provides examples to illustrate and validate the other four views and show how the system fulfills requirements.
Key Themes Across Definitions
Analyzing these documented definitions reveals several consistent themes:
- Structure and Components: Nearly all definitions reference system structure, components, and their relationships.
- Principles and Constraints: Many emphasize principles governing design and evolution.
- Significant/Important Decisions: Multiple definitions focus on decisions measured by their significance or cost of change.
- Multiple Views/Perspectives: Standards like IEEE 1471 and frameworks like 4+1 emphasize that architecture requires multiple viewpoints.
- Reasoning and Understanding: Several definitions emphasize architecture as enabling reasoning or shared understanding.
- Economics: Modern definitions increasingly link architecture to the cost of change.
Hot take: high cost of change can be caused by code fragility - fragile sections/modules of a system are not what the software architecture of a system is, but bad architectural decisions can contribute to fragility in systems.