Barry O'Reilly, founder of Black Tulip and inventor of Residuality Theory, is challenging how we think about software architecture. As author of Residues and The Architect's Paradox, O'Reilly argues that the software industry has lost its mathematical foundations—and that's causing our architectures to fail when faced with real-world uncertainty.
The Problem: We're Lost
O'Reilly describes the software industry as "lost." Unlike building architects who can justify every structural decision with mathematical rigor, software architects often rely on gut feelings and unexamined patterns. When asked "Why three components instead of two or four?", most developers struggle to provide concrete justification.
"We had this very mathematical beginning with Turing and von Neumann," O'Reilly explains. "But somewhere in the 1960s, we lost contact with mathematics and started having conjecture. People said 'I think everything's made of objects' or 'I think everything's made of services,' but the mathematics was gone."
The result? Terms like "coupling" and "cohesion" that everyone uses but few can rigorously define. Architectural decisions based on instinct rather than science. Systems that work … until they don't.
The Origin of Residuality Theory
The breakthrough came when O'Reilly was asked to train hundreds of architects at a major tech company. The request was simple: "Teach them to do what you do." But O'Reilly realised he couldn't articulate his own process.
"I had no idea how I did what I did," he admits. "I knew I had instincts I could trust, but how could I describe that in a concrete way to teach someone else?"
This led him to study uncertainty itself, and ultimately complexity science. He discovered that senior architects weren't designing from facts; they were thinking about where uncertainty would push the system and where it would crack under pressure.
O'Reilly formalised these insights through a PhD, subjecting his ideas to rigorous academic scrutiny. The result: Residuality Theory, a scientific approach to architecture that brings software development back to its scientific roots.
What Is Residuality Theory?
Traditional engineering assumes you can gather all information about an environment and design accordingly. This works for mechanical systems where physics is predictable. But business software operates in environments of fundamental uncertainty.
Residuality Theory flips the script. Instead of trying to predict what will happen, it focuses on how architecture responds when the unexpected occurs:
The core process:
- Start with a naive architecture - Your initial design sketch
- Apply stressors - Imagine what could disrupt the system (competitor drops prices, regulations change, market shifts, random events)
- Identify the residue - What's left after the stressor hits? What breaks? What survives?
- Redesign for better failure modes - Adjust the architecture so it cracks in controlled, manageable ways
- Repeat with multiple stressors - Build up a system that can withstand various forms of pressure
The goal isn't to prevent all failures—it's to achieve criticality: an architecture that holds up even when exposed to things that weren't in the original specification.
Stressors: Training Your Architecture
O'Reilly emphasises thinking beyond technical failures. Yes, consider disk crashes and network outages. But also ask:
- What if a competitor drops their price?
- What if regulations change overnight?
- What if a completely random global event shifts customer behaviour?
"Use random words, random ideas from newspapers," O'Reilly suggests. "By getting good at tracing how external events affect your architecture, you develop the knowledge that veteran architects have after 25 years, but much faster."
Veteran architects confirm this approach: "This is what we do. We just don't have fancy words for it."
The Contagion Analysis: Making Coupling Visible
After identifying residues, O'Reilly uses matrix-based contagion analysis (inspired by aerospace engineering at Boeing and NASA) to:
- Document all relationships between stressors and components
- Catch invisible coupling that only shows up in production
- Identify true cohesion (components that live and die together under stress, not just conceptual grouping)
- Make architectural discussions concrete: "Show me in ones and zeros what you're scared of"
This mathematical approach removes the fluffiness from architecture conversations and provides objective measures of coupling and vulnerability.
Why It Matters: Satisfying Software
The ultimate satisfaction? "When you come back a year later and they say 'This thing happened that nobody could have predicted, but the software still ran,'" O'Reilly explains.
That's the promise of Residuality Theory: software that survives "off-spec"—situations outside the original specification. It's about building systems that are antifragile, that continue functioning when the world changes in unexpected ways.
O'Reilly has trained over 600 people in these techniques, and reports are coming in from around the world: systems holding up under unpredicted stress, teams able to say "we told you so" when the architecture proves resilient.
The Challenge to the Industry
O'Reilly's work represents a paradigm shift. It's not about following patterns or best practices blindly—it's about returning software architecture to its mathematical foundations while embracing the uncertainty inherent in complex systems.
"We need to be less convinced, less rhetorical, and more scientific," he argues. "Say less, but make what we say sharper and more rigorous."
Learn More
Watch the full conversation: Barry O'Reilly on Residuality Theory - Deep dive into the philosophy, mathematics, and practical application of these revolutionary ideas.
Master the technique: Join Barry O'Reilly's Introduction to Residuality Theory workshop in Paris, March 16-18, 2026. Over three days, you'll build real systems using these principles and see firsthand how mathematical rigor transforms software architecture.
Register for the Paris Workshop →
Read the books:
- Residues - The theoretical foundation
- The Architect's Paradox - Practical applications and the war on architectural fluffiness