At first glance, the idea that philosophy and software architecture might be connected can sound a little strange. Yet a few months ago, I had the opportunity to attend a truly transformative course on software architecture—one that opened up an entirely new perspective for me, and a new way of understanding software as a means of supporting human processes.
In previous articles, we have already explored the difference between—and the importance of—the Problem Space and the Solution Space. But what are the implicit and explicit questions we ask when we start a new project? Defining what we consider a problem and what we accept as a solution always implies a worldview—one that is often unconsciously philosophical.
Many of you may be wondering, just as I did when I first encountered this line of thought, how it is possible to rethink the way we do our job—designing software architectures—so fundamentally. The answer is both simple and surprising: we must go back to first principles and ask ourselves questions such as “How do I see the world?”, “How do I approach problem-solving?”, “What do I consider a problem?”, and “What do we collectively define as a problem versus a solution?”. Once we start thinking this way, philosophy naturally enters the picture.
A Shift in How We Think About Software Design
The course was taught by Barry O’Reilly, the author of a new interpretation of software architecture known as Residuality Theory. An excellent introduction can be found in the video referenced at the end of this article [1]. While the theory has strong philosophical roots, it is by no means purely abstract—its foundations are supported by rigorous mathematics, and I highly recommend watching the talk.
Ordered and Disordered Systems
Modern approaches to problem-solving and software architecture often reveal a significant gap between theory—what is described in books—and practice—what actually happens in the real world. This disconnect largely stems from the fact that software and business belong to fundamentally different categories of systems.
Software is an ordered system: it is governed by precise, formal rules that must be respected for the system to function correctly. Business, on the other hand, belongs to the realm of disordered systems: systems where rules are neither fixed nor fully predictable, and where the conditions of the game change continuously.
This distinction reminds me of a quote I once read in a mountaineering magazine, attributed to no specific author:
There are at least two kinds of games: finite games and infinite games. A finite game is played to be won; an infinite game is played to continue the play. Players in a finite game operate within fixed boundaries, while players in an infinite game play with the boundaries themselves.
Software clearly belongs to the category of infinite games. After all, software exists to address business problems—or at least, that should be its purpose.
If our solutions are based solely on technological considerations—important as they are—they will remain valid only as long as the business context remains stable. The moment market conditions change and the rules of the game shift, a system that cannot adapt quickly becomes irrelevant.
History offers plenty of cautionary examples. Blockbuster failed to recognize the disruptive nature of Netflix’s business model, which eliminated late-return penalties and fundamentally changed customer expectations. By the time Blockbuster attempted to adapt, it was already too late. Kodak and Nokia tell similar stories: technological excellence alone was not enough to survive a changing world.
Decision-Making in Software Architecture
Let us take a closer look at how architectural decisions are typically made. At their core, these decisions are driven by three distinct problem domains:
- The technical problem: How will the system scale? How resilient must it be? What are the time constraints for delivering the first version? A highly recommended reference here is Fundamentals of Software Architecture [2].
- The team problem: What kind of team are we working with? Is it a fully autonomous, cross-functional team, or are there dependencies on external teams?
- The business problem: How does this project generate value for the organization that commissioned it? This is often the most critical question—and the one we must understand first.
We make decisions across these dimensions every day, yet we rarely ask ourselves a crucial follow-up question: “Why do I believe this decision is the right one?”. As Software Architecture: The Hard Parts [3] makes clear, there is no single correct answer—only trade-offs among multiple options, each with its own strengths and weaknesses.
According to Barry O’Reilly, this is precisely where philosophy becomes relevant. When we ask these questions, we are implicitly asking, “How does the world work?”—and that is, at its core, a philosophical inquiry. Applied to software architecture, this becomes a reflection on our design philosophy, our team philosophy, and our philosophy of value creation.
Philosophy as a Foundation for Software Architecture
One of the key lessons I took away from a recent philosophy course is that philosophy is less concerned with what you believe to be true and far more concerned with why you believe it. This aligns remarkably well with two fundamental principles of software architecture:
- First Law: Everything is a trade-off.
Corollary: If you think you have found a solution with no trade-offs, you simply have not identified them yet. - Second Law: The “why” matters more than the “how.”
When we talk about software architecture, we are therefore talking about our beliefs: how systems should be designed, how teams should collaborate, and how value should be delivered. Ultimately, software succeeds only if it delivers meaningful value.
What makes software architecture particularly fascinating—especially for those of us who practice it daily—is that it is no longer primarily about writing code. Tools like Copilot can generate code faster and often better than we can. Architecture is about decision-making, understanding trade-offs, and anticipating how those decisions will shape the system over time.
One of the most valuable philosophical insights is the recognition that every problem can be viewed from multiple perspectives. Translating this mindset into our daily work allows us to design more resilient and adaptable systems.
Consider performance optimization versus simplicity, delivery speed versus scalability, monoliths versus microservices. Every architectural choice represents a conscious trade-off. Our responsibility as architects is not just to make these decisions, but to clearly understand—and communicate—what we are gaining and what we are sacrificing.
Philosophy teaches us that the goal is not to find the right answer, but to ask the right questions. This idea echoes Eric Evans’ emphasis, in his seminal “blue book,” on establishing a shared language between technical teams and business experts. Software architecture is not about discovering the perfect design—it is about asking better questions to explore the problem space and navigate the solution space effectively.
Embracing Complexity
Software architecture is not only about technology—it is also about people. During design, we must align diverse perspectives and goals; after delivery, we must ensure that systems continue to support collaboration and value creation. Philosophy helps us explore how people work together and how collective understanding emerges.
Perhaps most importantly, philosophy teaches us to embrace complexity. The world is complex, problems are complex, and solutions are inherently complex. There are no simple answers—only informed trade-offs. Reapplying a solution that worked well in a previous project is rarely sufficient. Instead, we must be guided by deeper reflection to understand the unique nature of each context.
In this sense, philosophy helps us remain adaptable thinkers rather than rigid solution-repeaters.
Philosophy and Architecture: The Roots of Design Thinking
My interest in philosophy predates this course, so when I encountered a program that explicitly connected philosophy and software architecture, I was eager to participate. Through his doctoral research in complexity science and software design, Barry O’Reilly proposes an approach that challenges traditional methodologies and questions long-held assumptions about system design.
The starting point is something often overlooked in software development: the philosophical assumptions that shape our decisions. Every time we face a problem, we implicitly rely on these assumptions—even if we are not consciously aware of them.
Rethinking the Role of the Software Architect
From this perspective, the role of the software architect extends far beyond technical system design. Architects must act as strategic thinkers, working with complex mental models and balancing competing forces such as flexibility, scalability, simplicity, and long-term sustainability.
Architectural decisions do not emerge solely from experience or best practices, but from how architects interpret context and reason about change.
Conclusion: Philosophy as a Tool for the Future of Software
O’Reilly’s message is clear: if we want to design better systems, we must examine the foundations of our thinking. Only by understanding how we perceive the world and make decisions can we create architectures that are not only functional today, but sustainable tomorrow.
Philosophy is not an optional supplement to software development—it is an essential tool for navigating an increasingly complex landscape. By integrating logic, intuition, and creativity, software architects can redefine their role and actively shape the future of the systems they design.
References
[1] An Introduction to Residuality Theory – Barry O’Reilly, NDC Oslo 2023 (video)
[2] Mark Richards, Neal Ford – Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media, 2020
[3] Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani – Software Architecture: The Hard Parts. O’Reilly Media, 2021