Residuality theory to design more resilient software
An introduction to residuality theory: stressing a naive architecture to discover the resilient systems that remain.
Residuality theory in software architecture! By Barry O’Reilly. I’ve been introduced to this way of thinking about software through this introductory PDF document: Residuality Theory: An Innovation in the Design of Complex Software Systems. And the fascinating talk Barry gave at Code BEAM Lite Stockholm 2026: Barry O’Reilly’s talk at Code BEAM Lite Stockholm 2026.
It provides a basis for designing software that is more resilient, less fragile. It falls just in time isn’t it? The more I explore it, the more I feel like home. The other traditional architectural frameworks have always felt off and never felt like “this is it”. Because it mostly always relied on technicalities and always felt a bit disconnected from what the industry needs.
The general idea of residuality is you start with a naive architecture, you apply random stressors to it, which really stresses your structure and you get what’s left: residues. This is the stuff that survived the stressors. These residues are interconnected, but are systems on their own, and these interconnected residual systems are now your new architectural structure.
It’s rooted in complexity theory and biology and doesn’t uses probability, the main game is to come up with stressors that are intentionally highly diverse and random. That’s how you handle what might crash against a complex system.
The idea is “simple” (god knows what I mean by that) but the whole process is rather advanced (it targets complex systems), it goes as far as analysis and investigation of the structures inside the residues themselves using design structure matrices, and incidence matrices for stress impact analysis across residues flows and groups of functions. Then you consolidate the residues. And you iterate all that using various training sets and testing sets, to produce different architectures candidates (technique borrowed from Machine Learning).
So it really is an architect thing but at the same time as a developer it has helped me to come up with stressors that have made my features more resilient… I think. So I guess there’s a little bit of residuality here at play.
The empirical validation test to compare a naive architecture and a residual one, to see if it works is:
Ri = (Y - X) / S
Where:
- Y = core of the residual architecture (number of new unseen stressors survived or successfully handled with lower cost)
- X = same, but for the original naive architecture
- S = total number of new unsee stressors
- Ri = the residual index. Ri > 0 empirically proves that the residual arch has better resilience than the naive one.
Anyway, it’s interesting, take a look.