The business environment is dynamic and complex: markets change, new regulations appear, technologies evolve. And systems we design must operate within this complexity. That's where Residuality Theory of Architecture starts from.
The theory was developed by Barry O'Reilly and was presented at multiple conferences. One of the talks was on GOTO 2025 Residues: Time, Change & Uncertainty in Software Architecture.
The main idea:
Randomly stressing an architecture produces architectures that are more likely to survive unexpected events in their environment.
Let's go into more details:
🔸 Software is rigid and ordered, business environment is complex and fluid.
🔸 Unpredictable events can destroy the architecture. Such events are called stressors.
🔸 Parts of the system that stay functional after the stress are called residues. The number of residues defines the system's future state.
🔸 A complex system has a limited number of states that it is able to reach. These states are called attractors.
🔸 The number of attractors is much less than the possible number of stressors.
🔸 The number of attractors is defined by the following parameters:
- N - number of services or modules.
- K - number of connections or integrations between the services.
- P - probability of some behavior based on APIs, specs, contracts and policies.
🔸 The higher N and K, the more attractors the system can reach.
🔸 The main tool to define attractors is stressor analysis: generate a list of undesired events, define how our system will react, identify what will be broken, and add missing elements to the architecture.
🔸 The more attractors and residues we define, the more resilient our final architecture is.
The theory is good, and I like that the author tries to make software architecture domain more scientific. But in practical terms, this theory can be described as a structured form of 'design for failure'.
One more thought about this talk: the main assumption is that business context is dynamic and software is rigid. But in the era of AI, it looks like this assumption may become wrong as our software becomes more and more dynamic. It means that the number of attractors will increase and in addition to APIs and contracts we will need new types of constraints and boundaries to make software resilient.
#architecture #resilience