A Philosophical Lens on Software Architecture
Philosophically speaking, Barry O’Reilly’s The Architect’s Paradox offers a compelling reflection on the relatively new field of software architecture. It’s this philosophical part that I would like to spend some time on in the coming few paragraphs.
The book serves different goals depending on your professional background and interests. If you’re a software architect, it will give you a solid, albeit dense, introduction to philosophy. Along the way, it will get you to reexamine some of the challenges the field has grappled with, inviting you to approach these issues with a new perspective, while equipping you with some essential philosophical tools to think about these matters on your own.
If you, like me, come from a philosophy and business background, it will give you an interesting overview of philosophy as applied to software architecture and what it’s like to reconcile theory and practice, and put together a software design that takes into account complexity, uncertainty, and flux.
In an effort to understand what ‘good’ software architecture looks like in practice, Barry takes a long walk through the history of philosophy, explaining that it’s not some abstract ideal out there that we need to uncover, but that it’s something more dynamic, an approach that requires continuous revisiting, refinement, and exploration.
The Architect’s Paradox: Reconciling Logic and Experience
Having said that, I would like to explore a couple of points that were brought up in the April Tech Leader’s Salon discussion. From my brief chat with Laksh, I think one of the important points about the book is that it positions software architecture as a techno-social problem with repercussions of both a societal and technical kind.
In other words, it seems that a skilled architect would need to have a decent technical foundation and be well-versed in soft skills, including questioning assumptions, problem-solving, and an understanding of the complex and dynamic nature of business environments.
This dual aspect may not be exclusive to software architects, but it is particularly salient in this field because of “the architect’s paradox,” as Barry refers to it. This paradox is due to the fact that the study of logic that led to the creation of computing machines is also the reason why designing software frameworks has become increasingly difficult, pushing the field into a state of crisis.
On the one hand, it is comprised of a very rigid, logical, computational, and analytical component, namely, the code, which follows very defined rules: it either works or it doesn’t.
On the other hand, it includes a more dynamic component that is in constant flux, governed by an uncertain environment, complex relations, a changing context, and different stakeholders.
The distinction between these two types of knowledge goes back all the way to David Hume, who separated “relations of ideas,” which are necessarily true and cannot be otherwise, from “matters of fact,” which require experience to be verified.
This Humean distinction brought headaches for the philosophers that came after him, especially Kant. The German philosopher said that reading Hume forced him to wake up from his dogmatic slumber. So much so that he spent seven years writing the draft of his seminal book Critique of Pure Reason, where he attempts to address the problems that arise from Hume’s account.
The architect is faced with a similar problem to the Humean fork, namely, the halting problem, whereby a program can’t be verified before it’s executed. Says Barry:
“Due to the halting problem, architecture cannot be verified analytically to be correct at inception, and by the time empirical testing can be run on actual code, the architecture is already set and too difficult to change. This places conceptual architecture in a strange world. We know it needs to be verified, but we don’t really know where, when, how, or if, we can show it to be correct.”
The Problem with Structuralism
This paradox brings about all sorts of problems, making it difficult to articulate what the architect actually does, what good architecture looks like, and to agree on a set of best architectural practices. The result is an abundance of schools and models within the field, each claiming that its approach is the best one.
Underlying that paradox is a deeper assumption that all these different schools are not necessarily aware of. Software architecture has unconsciously inherited a philosophy of stable structures, substance, and essence, a view that continues to influence and shape the field today. Structuralism, as it applies to software architecture, is the assumption that a good architecture is based on a specific set of structures and patterns.
Once these patterns are discovered, according to the structuralist view, they can be easily replicated across systems and maybe even contexts. These logical structures and patterns are static, though, and they could quickly fall short and break apart in a business environment governed by flux.
“This invisible, but instantly recognizable, default philosophy makes it possible to accept the engineering paradigm–that software is simply another kind of engineering. By the time the architect has arrived at a set of models created in this way of thinking it becomes obvious that the answers are correct, and the software should be mapped to the models.”
Residuality Theory and Flux
Barry’s work is an attempt to flesh out the philosophical worldview that the software industry inherited, urging tech people to question their assumptions and consider an alternative route.
“The way to combat complexity, real or perceived, is to allow our structural picture of the world to collapse and rebuild it a little differently. This requires a certain degree of humility. The post-structuralist rejection of essence often goes too far, and we must begin with an essence, even if we know it to be naïve, and allow repeated contemplation of a system to produce new concepts, to allow abduction to happen.”
The alternative Barry proposes is residuality theory, influenced by process philosophy, French post-structuralism, and pragmatism, though I won’t dwell on them here.
As applied to residuality, the premise is that the architect is better off starting from very basic and naïve essences, like ‘customer’ or ‘order’, building and stress-testing the system until it reaches the point of criticality, which is the system’s “ability to survive unknown conditions.”
Of course, to reach this point, the system will break time and again, but what remains functional after each round of stress, the residue, would be incorporated into the system, and that which fails would be tweaked again. This, Barry argues, leads to a more resilient system architecture, one better able to survive “unknown unknowns.”
Speaking of naïvety, and on a totally unrelated note, the concept of ‘naïve essences’ brings to mind the iconic song “This Must Be the Place (Naïve Melody)” by Talking Heads. When I looked up the reason behind the parenthetical “Naïve Melody,” it turns out that the tune was developed with a minimalist, less-is-more philosophy, meant to evoke a sense of simplicity and charm.
To get that result, the guitar and keyboard bassline were played by ‘amateurs,’ in that David Byrne and Tina Weymouth switched roles: Byrne played the keyboards instead of his usual guitar, and Weymouth played the guitar instead of her usual bass. A tangent, yes, but there might be something there. And while we’re at it, This Must Be the Place, directed by Paolo Sorrentino, is an excellent movie.
What’s the role of the architect here, though? Well, that’s where the Deleuzian walk comes into play. “For Deleuze, we come to knowledge by repeatedly experiencing something, noting the differences each time.”
In this worldview, a good architect understands a problem by taking walks around it, noticing the slight differences with every round. As I understand it, the goal isn’t to make an analytically informed logical decision to justify the tools and frameworks to be used.
A better way is to adopt a naïve stance when confronting a problem, avoiding the temptation to immediately fall back on specific frameworks, taking walks around the task at hand, and reflecting on the different aspects that arise with each walk.
By doing so, new things would become clearer each time. This, along with the application of carefully introduced stressors, would lead to a more flexible system, much more adapted to flux and uncertainty than the inherently static ones.
As Barry concludes:
“Architecture is therefore about developing this ability to produce software structures, and the first steps toward building this skill are to understand the philosophy that you carry with you, to the point where you can shape it and make it work for you. When you control the model, the model can’t control you. And so, through the embrace of the philosophies of movement, I am finally able to answer Socrates’ question ‘What is Architecture?’ Architecture is decision making in the face of ignorance, the relating of the emergent to the static, the embrace of the world beyond logic and essence in order to design software structures for environments we don’t yet, and may never, understand. To end the book with an answer, rather than aporia, is a triumph in itself.”
View the 2026 Salon Program & Reading List →
