#212 - The Architect's Paradox: Embracing Uncertainty in Software Architecture - Barry O'Reilly

[00:01:42] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I’m very excited to meet Barry O’Reilly. He’s a kind of like someone who is into architecture, a lot of experience. Barry is also partly a researcher. So Barry, welcome to the show and thank you for this opportunity.

Barry O’Reilly: Thank you, Henry. Great to be here.

[00:02:00] Career Turning Points

Henry Suryawirawan: So Barry, before we start diving into architecture and all that, maybe if you can share a little bit about yourself, telling us about your career turning points that you think we all can learn from you.

Barry O’Reilly: Yeah. So I, um, I’ve been in the business for a very long time, almost 26 years or something like that. I’m originally a pure mathematician who graduated at the end of the last century. So it was finance or computing. And luckily, I chose computing. I worked very early on in my career, started to work as an architect, just by luck, which is a big part of an architectural career.

So in one of the very early projects I worked in, the lead architect needed to take some time off and I had to take over. Mostly within the Microsoft stack. And then several years later I went to work for Microsoft, was eventually a chief architect on the European level, did a lot of cool stuff with IOT and large distributed systems in the cloud.

And when I was there, I led the global architecture, solution architecture community. So I’d spent a lot of time teaching and thinking, what is architecture? How do we move this to the next level? And most importantly, how do we adapt architecture for this world of cloud which we’ve created, but we don’t really have the answers to those questions yet. If you go back 15 years, what does it mean to be an architect in the cloud? Nobody knew.

And so a real turning point in the work I do now was asking the question, you know, how do we create architects? What do we teach them? What do they need to know?

We have a bunch of really old ideas that seem a little bit outdated. And our developers are telling us that they’re very outdated and they don’t want to work like this anymore with lines and boxes and schedules and repositories full of diagrams.

And that was a real turning point. I think for me, I started to ask the question, what is this architecture thing? What is it that I do?

At one point they said to me, just teach people to do what you do. And I had to answer them and say, you know, I don’t know what I do. None of us know what we do. So I asked a whole bunch of architects, senior architects that I work with, what do you do? Uhh.. we don’t know either. So I had to do a lot of digging to figure that out.

And I started to realize that the thing that made the difference between us and senior architects who were actually doing well, delivering, seem to know what they were doing, even if they couldn’t describe it, that the difference was uncertainty, that we had a much easier time dealing with situations, business situations where no one really knew what was happening. And stakeholders would come and say, look, we don’t really have requirements. We don’t know what we want. We’re not even sure what this problem is. And this would cause, in that case, a lot of developers would say, hey, we’re not doing anything. You haven’t told us what you want. You haven’t told us what to build. You don’t know what your features you want or what problem you’re trying to solve. So you’ll go away and come back when you know what you want. Whereas the architect will step in and say, right, we can still do something here. We can do something with this, this information.

And that took me into a discussion about what is uncertainty and how do we deal with it? And is there a scientific basis for dealing with uncertainty? As you step into that, as a mathematician you immediately turn to probability and Bayes and all of that and that doesn’t work. None of it works. If that worked, we’d have figured it out decades ago and you end up realizing that there’s something else going on here. And that took me into a completely different discipline, which is the complexity sciences, which, you know, it has a very strong relationship to mathematics. So it was, it is an easy place to start looking. And what I started to do was I started to read up on those ideas. I started to pull them in and describe my own practice in those terms.

That caught the attention of a lot of people. A lot of people thought, hey, this is cool. Can you talk more about this? I was sort of nervous about it. Because I didn’t want to get up on a stage and say, hey, look, do this. And everything will be fine because that doesn’t feel right, okay? No, in our industry, it’s perfectly acceptable to get up on a stage and say, do this and everything will be fine. People will just nod and they believe you and they do whatever you say. But I wanted to take it a bit further than that. So I talked to a whole bunch of people, eventually went back to university. And when I went back to, I went and I decided to do a PhD. I said, I have these ideas. And I want proof, either proof that they work or proof that they don’t work. And if they don’t work, then why? Why don’t they work?

And I developed a bunch of ideas around how we should be doing architecture, which we’ll talk about, I’m sure, but the ideas like random simulation and stuff that I kind of borrowed and reformed from the complexity sciences to suit our world, which it turns out is very, very different than the world of other engineers. And I just wanted to see, is this real? Or is it just a bunch of things that sound good? Because there’s an awful lot of things in our industry that sound good. And the ideas about architecture that I and the rest of the industry were in the process of abandoning at that point. They all sounded good at one point, but no one done any work to prove that they actually worked. And I didn’t want to just do another loop of the hamster wheel. So I decided to go back and prove that this actually held or didn’t.

And that’s the point I’ve come to now. That journey has been fantastic and I’ve done it out loud. The whole time I’ve been working and I’ve been getting up on stages at conferences and saying, hey, look, this seems to be, the right direction. What do you think of this? And I’ve taught a lot of architects along the way how to do this. The result of that has been in the last year, I’ve released two books, which are kind of side quests from my PhD, which I should have finished by now, but I keep writing books instead of the actual dissertation. That’s brought us up to the present day where these ideas are kind of starting to really get noticed in the industry and a lot of people are excited about them. So it’s a pretty cool time right now.

Henry Suryawirawan: Thank you for sharing your story, right? So in preparation of this conversation, actually I did have a look at your previous talks, right, in the conferences. I also read your book. I must say that it is really fascinating reading this new paradigm, I would say, about architecture, right? And I think it’s quite interesting if you just follow the way you explain things, right? I find it quite novel. And looking forward to actually have a good discussion with you today.

[00:10:02] The Architect’s Paradox

Henry Suryawirawan: And you said that you published two books. One is The Architect’s Paradox and the other one is The Residuality Theory, right? So maybe let’s start with The Architect’s Paradox. When you mentioned about paradox, what do you mean? Can you explain a little bit?

Barry O’Reilly: Yeah. So The Architect’s Paradox is this unfortunate trap that was built for us. To be honest, we built it ourselves, but we didn’t realize it was there. And the paradox is this, that in order to invent a computer and to invent software, you have to think in a very, very rigid, logical way. And you have to be really consistent in that logic. You have to really know what you’re doing. So you get people like, Alan Turing, von Neumann, Alonzo Church, right? They really knew their logic. They were really focused on it, and they had to be to create software.

And when you really focus in on logic, you accidentally adapt a way of looking at the world, right? You try to see logic in everything. We’re working with computers and chips and software and registers and all of these things and functions and we’re thinking in pure logic. And then eventually the machines get so powerful that we realize we can solve a whole bunch of human problems and business problems with these systems. And you look out into the real world away from the machine. And you see that there’s people and they’re doing stuff and they’re trying to get stuff done and they have all these things called emotions and they have social groups that are trying to achieve something. There’s markets. Everything’s moving.

And we look at this and we try to analyze it and the only tool we have, the only thing we focused on is logic. And so we try to logically describe how the business works. We try to logically make our stakeholders talk about requirements in a way that’s consistent, in a way that satisfies our needs as logicians. And it completely collapses at that point because you cannot grasp the complexity of a social organization with logic. You can only reduce it, you can only make it smaller. And everything that we’ve done in the history of our industry from requirements engineering to user stories to the mapping and modeling of domains, it’s all been about reducing things to a point where we can access them with logic.

And this causes frustration for our stakeholders. They don’t like it. So that’s why they run away when they see us in the corridor and they’re, oh, no, I’m going to be forced into another one of those difficult conversations where they make me feel stupid because I can’t answer questions in a logical way. And it limits our ability to accept things. And it means that what happens is that we have the logic down, we can build the machines, we can make the machine do exactly what we wanted to do. But we can’t translate between the real business world and the machine. Because we’re applying logic in the wrong place.

And this was a problem. This has been a problem since the beginning. Well, since computers got powerful enough to start being used in complex human systems like large businesses, things like that. And our approach to this has always been to force our stakeholders to force that complexity to be still, and say, look, no, don’t talk, just tell us requirements. Those requirements have to be smart. They have to be atomic. They have to be sharp. They have to not contradict each other. If you describe your world in a way that follows the laws of our world, then we can make a computer work for you. And it keeps collapsing.

And we know from the statistics, from the standard chaos report and all of those other reports that we’re not doing this particularly well. And we knew since the late sixties that we weren’t doing this particularly well. But no one has ever raised the question before. Hey, is it the way we think? Is it the way we think that’s the problem? And now the Agile movement to its credit 25 years ago started making some noise and said, hey, you know, this rigid, stiff way of looking at the world is hurting us more than it’s helping us. And we need to get rid of this. They got rid of all the immediate aspects of this like the steering, that the idea that there’s a waterfall process as repeatable. That’s all part of the architect’s paradox.

What the Agile movement missed was the fact that when we build conceptual models of the business, the same paradox is there. We’re still using logic. So the problem with the Agile movement was it just wasn’t extreme enough. It should have thrown the baby out with the bath water but it didn’t. Tried to keep the baby. The baby got upset and that’s where we are today. It’s a very, very difficult thing to separate ourselves. For some, it’s a difficult conversation to have because we’re so entrenched in this logical way of thinking about the world that to move away from it, to think a different thought seems impossible.

One of the bits of feedback I got on the book was from a very senior developer in the UK. He was one of the sort of pre readers and he said, this is great stuff but the risk is that you’re kicking away the crutches from developers. They are going to feel like they have nothing left, nothing to hang on to. And that’s kind of dangerous. It can make people feel a little bit nervous. And so I guess that’s the price of progress is that we will have to feel a little bit nervous, a little bit out to sea while we have these discussions. But I think it’s important. Because architecture is, as we say, it’s on the cusp of being rejected wholesale by the industry. It has been a tough 10 years for the concept of enterprise architecture. There needs to be a new, we have a new way of thinking around these things. And that means sort of looking inwards and maybe reflecting a little bit and facing up to some hard truths.

Henry Suryawirawan: Yeah, so the way you explain that, I think people here who listen, right, understand the paradox where you’re coming from, right? So I think most of the software developers, we are trained to think in logic, right? Even like, for example, given a certain input, it always comes out with the same output, right? Those kind of stuff. But we know that every time we build software, there’s always something that makes the software fragile, not easy to evolve, right? And for that reason, right, many software projects actually statistically considered fail. Either they cannot be delivered on time, the scope keeps increasing, right, and all things like that.

[00:15:54] Barry’s Definition of Architecture

Henry Suryawirawan: So I think it’s really interesting the way you brought it up as a paradox. And I think before we go into more details about the inner things, right? Maybe in your definition, what is architecture? Because when you mentioned in the beginning, you asked so many architects, what do you do? So many people don’t have the same definition, I guess. Sometimes they also don’t know how to describe it. But in your definition, maybe if you can, what is your definition of architecture?

Barry O’Reilly: So my definition of architecture is decision making in the face of ignorance. And for us, what that means is that as an architect, you know, you’re expected to make decisions about the structure of a software application. That’s a definition in itself that some maybe older enterprise architects don’t agree with, because they think that they should move away from the technology and just deal with business problems. And I don’t share that view of architecture at all. Architecture needs to be very close to the technology.

And so an architect is a very advanced programmer in my world. What we have to do is make decisions about the structure of the software but we don’t know what’s going to happen in the future. And the function of that structure is to make sure that the application survives into an unknown future. So we have to make decisions about things that we don’t yet know about. And that is what architecture is. And that’s what leads us into a lot of problems.

So how do you solve that problem? Well, one way to solve that problem is to get better at knowing what the future is. And that leads to a whole lot of snake oil to be honest. People saying I can tell you the future, I know what’s going to happen. I’ve seen this before. Or it can lead to some people giving up and saying that there is no point in architecture, because we don’t know what we’re going to happen in the future. So let’s just wait for the future to happen and then rip everything down and rebuild it. And that historically hasn’t given us good architecture. That gives us bad architecture. It might give us confidence but it doesn’t give us good architecture, good structures.

And so a lot of the challenges in how do we handle this fact that we don’t know what’s going to happen in the future. And what we’ve tried to do, so a bunch of very smart people got together in a place called Garmisch in Germany, 1968, these NATO conferences, and they said, hey, why are we, why do we suck at this? Why does everything keep going wrong? And they said, it’s because we’re not good enough. What we’re doing right now, which is we’re sort of trying to copy other engineering disciplines, because we don’t have an identity yet as software people, and we still don’t. And so what we try to do is we try to bring in that engineering paradigm into software. And every time we failed, we said, well, we must not be good enough at engineering. So we have to engineer harder. And that means we have to be more explicit about requirements. We have to be more accurate with risk predictions and all of these things.

And we tried to copy or steal the clothes off of real engineers. And what we’ve never really had the conversation. Well, what if what we’re doing isn’t really engineering? What if it’s something way, way harder than what engineers have to do? I usually say, you know, people who build cars, the architects who design cars, they have it easy, right? Because they’re working with aluminum and gravity and rubber and fuel. And the physical properties of those things don’t keep changing, right? They’re stable and static and everything is still and they can work safe in the knowledge that aluminium will behave in 10 years from now in much the same way as it behaves today.

As architects, we’ve got to work with concepts like customer and order and markets and demand and all of this stuff, but none of it stays still. And so that would be trying to design a car in an environment with variable gravity and variable properties of aluminium and different types of fuel. And it’s much, much more difficult what we’re expected to do. And when you try to then apply the logic of the paradox to that environment, it all just gets very, very messy. And that leads to all kinds of speculation, but eventually it ends up at this rigid waterfall like thing that we call enterprise architecture which eventually the industry starts to push back on. Because we we know and we see and we feel in our projects every day that this approach doesn’t work. It doesn’t give us the results we need.

Henry Suryawirawan: Yeah. So I think a lot of people also mentioned about this, right? We borrow the discipline, maybe, the practices from other engineering, right? But most of those engineering, you know, it’s more like a physical thing, be the civil engineering, machinery and things like that. But software has its own unique properties, I guess, right? So one good thing is like it’s very easy to start, you can mold it as and when you like. You can deliver it really quickly. But at the same time, those properties probably is also the challenge how we deal with them, right? Because, for example, if you want to change or evolve your software, sometimes it’s very tricky, right? Because the business complexity changes.

[00:20:24] The Challenges of Time and Change

Henry Suryawirawan: And you mentioned that also, architecture typically don’t survive a few things, right? So you mentioned just now about uncertainty, right? We don’t know what the future will look like. The business keeps changing. The concepts may be changing as well. Like you might have customer today defined as this, but maybe in the next month or so, the definition might change. New business line appears and things like that. And also there are two other properties which is time and the change. So if you can explain us about these few things, right, why they make architecture so much more challenging?

Barry O’Reilly: Yeah. The big problem we have in architecture that you’ll see as soon as you ask an architect, show me your architecture, they’ll show you something very static as a set of lines and boxes in a nice diagram or scribbled on a whiteboard, one of those two. What you’ll see is that it’s a snapshot. It’s a picture of the architecture in one particular moment. And everyone knows if you’ve had more than a few years of experience, you know that this architecture will not look like this one year from now. It will not look like this two years from now. It will definitely not look like this five years from now. That’s something that’s very curious, isn’t it? Because why don’t we have that? Why is that not part of our diagram? Why is it not part of our plan?

And the reason that time is relevant is because things change over time. And the reason that our architectural tools and our diagramming and our way of thinking doesn’t embrace that change over time is because of the uncertainty. It’s because we don’t know what’s going to happen. And so what we kind of do is sweep it under the rug and so we said, look, I’ll give you a lovely two dimensional UML diagram of what’s going to happen when we put it into production. But we won’t talk about the change. We won’t talk about the fact that everything is going to move. We won’t talk about the fact that today we have identified a particular kind of customer with a particular set of properties. And in five years, we’ll have dozens of different kinds of customer and they’ll all have different properties and they’ll all react in different way. They’ll be in different countries with different languages and different ways of identifying them and different legal frameworks around them that makes us need to know other properties about them.

And these things are swept under the rug, because it’s just too difficult. It’s not that it’s too difficult because if I’m building a business without software, it’s easy for me to think about these things. It’s very easy for business people to say, hey, you know, we have a customer today because we’re in this one country, there’s one jurisdiction, there’s one product, but the future is going to look different. How do we make sure that we’re able to deal with that? And the business is very good at making sure that we can step this up. We can make sure that we don’t close it. We don’t need to be ready for this massive global multi customer world tomorrow, but we need to make sure that we don’t close the doors to that. So for business people, that’s easy. At least this is natural thinking for them.

For us, it’s very, very difficult because we think so rigidly and so logically. And we, what we do is we close doors with our software. We say, this is the customer object. This is what it looks like forever. And if it changes, then we’re going to have to rip everything out and put it all back together. And that becomes really, really difficult for us. And so one of the things that software does for a business is it actually slows the business down. It makes it much more rigid. You have to codify what’s actually happening. And that’s why we have so much frustration sometimes between business stakeholders and tech people, because we can’t move at their speed if we think in this particular way.

Henry Suryawirawan: I think that explanation is quite common, right? Maybe in a startup, scale up, those kind of situation, right? You will tend to hear that software becomes a bottleneck, right? The team cannot deliver faster, right. The software cannot cope with the business changes and things like that. And I think when you explain about that, right, I kind of think about the way software engineer or architect solves this problem is to create modeling and abstraction, right? We try to distill the requirement that we hear from the business and try to come up with some models, the boxes, the diagrams and things like that.

[00:24:09] The Danger of Software Abstractions

Henry Suryawirawan: And I know in your book, you explain this is probably one of the danger, the risk of trying to come up with something that is too rigid, structure and things like that. Maybe tell us a little bit, why this kind of paradigm where we want to build more abstraction and modeling doesn’t actually survive.

Barry O’Reilly: Yeah, so this is something that comes from mathematics. And so I came out of university as a naive, pure mathematician. And abstraction, when I studied, your ability to work with abstraction was praised, rewarded, encouraged. And when you come into a business, then you’re looking at all the things that are moving around. You try to put a label on some things. And so, well, that’s a customer and that’s a customer and that’s a product. And you know, that’s a product if we squint a little bit. You know, it might be closer to a service or, you know, but let’s call it a product, because then we only have two words to deal with instead of three and abstraction is good. And we want to make the world smaller and we want to hold it still. And if you study mathematics or computer science, you’ll get extra points for your ability to build these beautiful abstractions. And we can fall in love with abstractions.

And one thing that you’ll see very common with developers and architects across the world is they come up with an abstraction. They love it. They fall in love with it and they’ll fight you if you try to change it. They are like, no, we will not change. This is a customer object or this is what we mean by message. And what happens is that we’re trying to isolate what is a customer. And this goes right back to Plato and Aristotle, where they talk about trying to identify the essence of something. What is the essence of customer? Can we capture this essence? Can we hold it still?

Plato, of course, he believed that there’s this heavenly realm that exists outside of the Earth. We can’t see it. And it contains these perfect forms. And somewhere in that heavenly realm, there is a perfect customer. And the way to find out what the perfect customer is, is to just think about it rationally and you will eventually come up with a perfect customer. When you do that, you’re wise. This is rejected, of course, by his own student, Aristotle. But we carry that with us. And we have this concept within object orientation of the class, which we define. That’s that perfect heavenly realm which doesn’t actually exist. That’s the perfect customer, customer class. And then you have customer objects which are the real world copies of that running in memory.

So this behavior kind of carries over into. And this also leads us to to try and and conceptualize and abstract over things and make it efficient all the time. That leads to us thinking things like security is something that is a property of every project. And that leads us to thinking that there is some magical heavenly security that’s the same in every single project. And so you end up with an industry that thinks that security is the same, whether you’re building an app to share pictures of your lunch or an app that runs inside a nuclear power station. They both have security. It’s the same word, it’s the same thing. It’s absolutely not the same thing. And these abstractions are an attempt to make it easier for us. But they actually ended up making things much, much more difficult.

Human history or the history of knowledge tends to be a search for abstractions where we stumble around getting things wrong until one day we suddenly find an abstraction like Newton did, which really works for us. And then we get hung up on it for a couple of centuries. We haven’t really got there in software. The abstractions that we use are still, they’re very dangerous to us in very volatile environments. There is no solution to this problem, right? Because humans have to think in abstraction. It’s oddly because we can’t… you have to have the word cat your head. You can’t memorize the name of every single cat that you meet on earth and refer to them as individuals. You have to be able to say cat. But you also have to be prepared. If you go to the zoo as a kid for the first time and see a lion, you have to be prepared to rapidly adjust your idea of what is a cat. Because it can be very, very different all of a sudden. And in software, we have this obsession with these abstractions, these essences. What we don’t have sometimes is the humility that these abstractions die very quickly.

And so an abstraction is never still. The problem we have is that to build software, you need it to be still. And so we kind of convince ourselves that this is customer. Now we’ve arrived. This is what it’s going to be. What’s needed really is a humility that this abstraction that I’ve come up with will not survive in the wild. Occasionally some abstractions do survive for a very long time, but we don’t know which ones from the outset.

And, you know, you see these problems all the time with these huge kind of ERP installations from large companies. That’s a set of abstractions from somewhere else. And as someone said, these abstractions will definitely work for you and it will cost this much. And then you buy the platform and you say, but we need to change a few of these abstractions. And suddenly, it’s a five year project. It’s 500 million and no one’s happy. And that’s the constant failure of abstraction that leads to this kind of misery within software architecture and there’s no solution to it. We have to think like this. We’re kind of pre-programmed to think like this. But all that’s needed is the realization that this will crumble constantly. And there are some things we can do to protect ourselves against that inevitable crumbling. We can’t get it to be still. And that’s the big issue for us. Because we’ve got to write the still static software for this constantly moving world.

Henry Suryawirawan: So I think I laughed when you mentioned about, you know, we try to think of the perfect abstraction and we fight with each other, right? And I think you mentioned also a few famous philosophers, right? The scientists also, right?

[00:29:41] Understanding Our Architecture Philosophy

Henry Suryawirawan: And I think it’s a good segue to go into this philosophy of architecture because in your talks, in your books, right, you mentioned about this study of philosophy that you did and how to actually apply that into software engineering and architecture, right? So why exactly philosophy? And I think you also kind of explained that we all actually have a philosophy in the way we build software. But we just don’t know about it or unconsciously know about it. So tell us the importance of understanding this philosophy

Barry O’Reilly: Yeah, so as part of a PhD, which I’ve been doing, you have to write a chapter that says this is my philosophical view of the world. This is how I believe the world works. And you have to do this because you’re going to design an experiment that’s going to have a result. You’re going to interpret those results in a particular way and it has to be consistent. So you have to interpret those. You design your experiment, you run your experiment, you interpret your results all through a philosophical lens. There’s no escape in that. Everyone has to do that. And so it’s very important upfront to say, this is how I think, this is how I look at the world.

And so I was given this project and, oh my God, what is this nonsense? And my wife who’s a scholar, she said, ah, you need to read this and then this and then this. And I said, oh, this is overwhelming. And I got really interested in it in the end, a little bit too interested in it and went a bit too far. There’s like, this has to be seven pages. I got to like 200 pages. I thought maybe I’ve gone too far again with this idea.

And I started to realize that once I started to get, what it gave me was a vocabulary. I started to understand that, hey, a whole lot of these discussions that we’ve been having in software for the entire length of my career are philosophical in nature. We think we’re on the cutting edge. We think we’re the cool hip kids doing all this new stuff. But there was two old men in a square in Athens had this exact argument two and a half thousand years ago and they were smart enough to say, we’d better just leave it. We haven’t really got there yet.

And I started to realize was that I had a philosophy and that philosophy wasn’t coming from a study of philosophy. It was coming from my pure mathematics, my computer science education. And that philosophy was coming from my professors and they didn’t know where their philosophy was coming from either. The vast majority of them didn’t know where they got it from. And they were inheriting their philosophy from a number of thinkers at the turn of the last century. So people like Gottlob Frege in Germany, logicians, Bertrand Russell, Ludwig Wittgenstein, people who were very, very focused on logic as being at the center of everything. And so these philosophers, they created the platform for Turing and von Neumann to take the steps they needed to take. And so we have this invisible philosophy that comes from a bunch of different thinkers, a bunch of different trends across the millennia, that causes us as computer scientists to software engineers to think in a very particular way.

And what I started to realize was that when I talked to engineers and I scraped at the surface a little bit and ask them some awkward questions. And the ones who didn’t get upset and actually answer the questions with would reveal that there’s a similar set of ideas in all of us. We’ve all inherited the same way of thinking, this default philosophy that believes in this heavenly customer, and constantly seeks it. That believes that there’s an “if A then B” relationship constantly everywhere. That believes at the end of the day that an organization of people connected to each other, doing very human things to we call a business that it can be reduced and modeled in the same way that we talk about circuit boards, in the same way that we talk about classes and objects and all of these things. And the way that we act and the way that we behave around our stakeholders, the way that we form conceptual models and software is a reflection of that inbuilt philosophy that we all carry.

And I realized that as I was teaching the ideas in residuality, which are kind of radical. They ask you to throw out a whole lot of old ways of thinking. As I was asking people to do that, I noticed that they would struggle sometimes. There were things they didn’t want to let go of. And I said, this is deeper than just a tool or knowledge of how something works. This is philosophical. So I’m asking them to change philosophically how they look at the world. But the vast majority of developers can’t even describe, and I couldn’t, how they look at the world philosophically. So you’re asking someone to change something that they don’t know is there. And that is incredibly difficult.

And so I gave a talk, about this, because I find this fascinating. I got, in the book, I say like, I’m a software engineer who got lost in the wrong part of the library. And I spent a couple of years there and really got into these ideas and these thoughts. And eventually, I started to talk about it. And I talked about it at an architecture conference. At the architecture conference, they said they were really interested. And I thought this is really interesting stuff. And there was a computer science professor who came on directly after me. And he was absolutely shell shocked, is I had never heard anything like this. How dare you rip up the rule book.

And then I went to, I spoke at a developer conference. Not a huge developer conference, a small one. And I thought this is a big risk but they’re going to throw chairs at me. They’re going to hate this. This is boring. But I find that they were really interested as well. And then I did an even bigger developer conference, NDC in Oslo last year. And I thought, they said, can you come and give a talk? I said, yeah, okay. I’ll give my philosophy talk. And I figured they’ll put me in a room far at the back. There’ll be four, mostly older people there. No one will care. You know, it’ll be fun. I got there and they put me in the big room, the keynote room. So there’s these four people are going to be and there’s like 400 chairs of poor people. This is going to be a disaster. And the room filled and there were people standing at the back and standing in the aisles. And I was absolutely terrified. But this is too many developers to hear about, coming to listen to philosophy. Most of them are going to be drastically disappointed that this has got nothing to do with code, really.

And it turns out that they loved it. And I thought, well, there’s a real hunger out there for new thinking, new ideas, cause everyone sees the gap, right? There’s a gap between programming and architecture. We know that the old ways don’t fill it. We don’t have anything to fill it with. The only way to fill that gap is to just throw yourself in at the deep end and suffer for a few years until you’ve sort of figured it out. And so there’s a real hunger for developers who want to take that step up to architecture. How do we do this? And they’re very open to the idea that you just have to kind of change how you think and how you look at things a little bit and suddenly you can solve new problems.

The response at that conference then gave me the idea that, hey, those 200 extra pages that I have lying around, maybe that should be a book. And so that’s what I’ve been doing for the last couple of months instead of the work that I’m actually meant to be doing. So that’s how I arrived at the fact that philosophy is a very, very important question for us as software architects and that it’s a very good starting point for someone who wants to take that journey from, especially if you’re a very senior developer, I guess is your audience.

And then you’re saying, what’s the next step? And the next step isn’t more algorithms. It isn’t getting better at Leet. It isn’t getting better at Kubernetes. It’s a much more inward reflective journey which will allow you to solve problems that are actually a little bit outside the machine but still very much related to the code and the compiler.

[00:37:05] Residue as the Unit of Software Architecture

Henry Suryawirawan: So I think when you mentioned about default philosophy, I think we all have it, maybe inherited from the study, from the books, right? From the logical thinking, that we taught ourselves maybe as well. I also follow your talks, right? So I think it’s quite refreshing the way you kind of think about architecture. And I think it’s not something that straightforward naturally we think about, right? So I think this is also a good discussion in terms of what do you think as the unit of architecture. Because many people, if you ask architecture, they have different answers, right? They could relate to like monolith, microservice. They could relate to something like domain driven design. They could relate to something like evolutionary architecture, event driven architecture. So many different architectures out there. But the way you actually describe in your philosophy architecture, maybe architecture has a different kind of unit. So maybe now is a good time to actually introduce us to this concept of residuality.

Barry O’Reilly: Yeah. So if we go back to the ancient Greeks, which is where I always start this story, cause it makes more sense. They looked at the world, and for them, you know, this is two and a half thousand years ago, there were a lot of mysteries. There were a lot of things we know today that they didn’t know. And they would look at things and ask questions. What is it? What is it made of? And they would look at these things and they say, well, what if it’s made of water? One of the sort of reliant is one of the first Greek philosophers called Thales, who came up with this idea. It’s what if everything is made of water? That’s obviously ridiculous. If we look at that now, everything is not made from water, what a stupid idea. But it’s not the idea, it’s not the conclusion that he came to that’s important, it’s the thought that what if we look at the world as if it’s all made of one thing, as if there’s some kind of arché, they called it some kind of building block that everything is made of. And he came up with water and he’s obviously wrong, but that instinct started a way of thinking that changed the world for us in the West.

There were other thinkers who we’ll come back to. One called Heraclitus and he said everything is made of fire. Everything’s on fire. Everything’s moving and changing all the time. That’s very much influenced with ideas from the East which is going to turn out to be much more useful to us as architects. And eventually then they have this one guy, Democritus, who comes along and says, what if everything’s made of tiny, tiny little particles called atoms? And that’s an idea that stuck around for thousands of years, and we’ve all learned that in high school.

And what we get from that journey is that when we all assemble and agree temporarily that there is this one thing that everything else is made out of, it makes a discipline possible. It makes a science possible. And so as soon as we come up with the idea of the atom and we coalesce around that idea. We get physics and then you have the idea of the cell. Suddenly you have biology. And the molecule gives us chemistry.

And then it’s software. We have this constantly shifting picture, right? So someone says it’s the machine. It’s the punch card. It’s this function. It’s the procedure. It’s the module. It’s this actor, the service, the object, the microservice, so it gets very tiring. It changes every couple of years.

And so we’re very much in that sort of earth, fire, wind, water phase of what’s everything made off. We don’t know, let’s make something up and see what happens. And we still haven’t really got to agree up to result there. I mean, the service has been revolutionary for us. I think it’s given us cloud computing. It’s given us network computing. But we’re not quite settled yet.

And in terms of architecture, then we have to ask the question, what is the unit of architecture? And what I find is that all of these units restrict our conversations about architecture, because if you combine it with this need to conceptualize, what we try to do then is identify these magic objects in the world. Customer, order, product, all of these things, and we immediately try to map it to some kind of base unit, a service, an object famously, which we wasted decades on mapping all of these things. And for architecture, I find that this can actually limit us, even if it’s very, very necessary.

And so what I managed to do was to create a new kind of unit, which I call the residue. And the residue isn’t a single thing. It’s a little collection of things and it’s a delta. It’s a little bit different than all of the other residues around it. So the thing that demarcates is difference. And these residues basically our architecture as it collapses. And so what we’re interested in is describing our architecture not as this static two dimensional picture, but as a series of collapses. So as we assume with humility that the architecture I’ve designed, the concepts that I’ve used are going to collapse, no matter what happens. There’s uncertainty. As we move into the future, my architecture collapses. When it collapses, the important question for me as an architect is it’s not to go, ah, dang, I was wrong. That should have been a better concept, let’s start again. The question for me as an architect is, when it collapses, what do we do? How do we get out of the hole? How do we keep running?

And so what we do is we randomly simulate our architecture with stress. And we say, make it collapse. And when it collapses, we observe it. And we say, ah, if we’d added this little thing, if we’d done this from the start, it wouldn’t have collapsed, but we haven’t built anything yet, so let’s add it now that we know. And what we do is we try to provoke constant collapse in our conceptual model of the world before we commit to an architecture.

And so we take our ideas, so I have an idea in my head after I speak to a customer for a few minutes. You have a customer that looks like this, you have orders that look like this, you have products that look like this, you have billing and everything that looks like this. Let’s try and break every single one of those concepts in as many ways as we can, randomly breaking them.

And as the models collapse, every time the model collapses, we have to find a way to make sure that that collapse, if it happened in real life, would be comfortable for us. And every time we discover something that we can do that makes that collapse comfortable, we assemble that in a residue and we set it in a little pile. And at the end of our work, we have maybe hundreds of these residues and that describe how our architecture is going to look, how it’s going to collapse in different tries or legs in a future that we’re not quite certain about.

What this does is because of the internal mathematics of complex systems and the rigidity of software. So there’s a big gap between the number of possible states in a software application and the number of possible states in a human system. The human system is orders of magnitude, many orders of magnitude bigger. And we can leverage that distance between these two things to make sure that, because the human system will keep returning to the same points over and over again, something called attractors in complexity science, we can actually manipulate the attractors in our software through these residues to get a system that we can prove is more likely going to survive in unknown conditions.

And this is a huge step for architecture. It’s an entirely different way of thinking. There’s a lot of concepts there that probably just flew over the heads of most people. It’s too many concepts. It’s something that you need to take a bit of time, read and listen to the talks. The ideas that I’m talking about here, are easily as awful as object orientation, right? And we take a whole university term to suffer through that. So this is about the same level of intensity.

But what happens is that we can actually mathematically show that I have designed an architecture more likely to survive unknown unknowns in the future than what we originally started with just by stressing my model, just by stressing my concepts through random simulation. And once we get to the end of that journey, we realized that what we have is this arché is foundational building block of an architecture. It’s called a residue. It doesn’t look like a service or an object or anything like that. It’s more about a related number of components and how they act in a particular situation. So it’s a collection of little deltas.

And if you read the books, you’ll see there’s philosophical reasons why that all fits together very nicely. So it’s an enormous subject. I think one of the things I’ve heard is someone said that, you know, the only way you’re going to get these ideas to succeed is if you can explain it like I’m five. And I said to them, this is absolutely not something that five year olds should be doing. So I don’t think that’s the right way to go. A five year old can’t do object orientation either. Yeah so it’s, there’s a lot going on there. I understand that it’s quite confusing. I’ve managed to put it together in the talks on YouTube in a way that’s quite logical. It brings one concept in after the other. I don’t think I succeeded in the last three minutes of doing that, to be honest.

Henry Suryawirawan: Yeah, definitely, it’s a fascinating thing, right? There’s so many concepts and like embed a lot of philosophical thinking as well. So I think the way that you explain it in a long talk is better, definitely. But I think it still invites us to actually dig deeper, right? I think the thing that I can summarize maybe from the way you explained just now, right?

Instead of thinking architecture as a one solution, right? You should think in terms of multiple kind of options, which you call residue, right? And each residue is a result of some things that change in which you mentioned architecture collapse, right? And they collapse because certain stressor, right?

It could be business change. It could be some kind of cloud computing suddenly exists, right? So certainly the way you design software is different. So maybe there are lots more paradigm that comes. And that’s why maybe architect needs to think in terms of multiple residues, right?

A series of residues such that we can come up with maybe an evolution or a plan in which if something changes, you can kind of like pick the residue that you have thought about. And maybe that architecture is not so bad, right? It can still survive whatever changes that you have thought through before.

[00:46:31] Practical Way of Applying Residuality

Henry Suryawirawan: So definitely for people who are interested in this kind of thinking, I invite you to read Barry’s book and also watch maybe the past talks. And definitely hearing about this, what do you think are some takeaways for us? Definitely learn more about it, but what are some other practical things that you think we can do?

Barry O’Reilly: So there are two books out there now. One is called Residues and that’s very much based on how you practically attack an architecture with these ideas. And that involves stressing your architecture. So you start off with a naive architecture, which we all do. So by the time a customer gets to the end of their second sentence, we’ve already designed something in our heads. And you just start stressing, you start asking questions. What if a customer isn’t, doesn’t always look like this? What if an order changes? What if we have new products? What happens if my assumptions about the world are wrong? And they’re constantly changing.

And what you naturally get out of that is lots and lots of these residues, these architectures that are slightly different and you’re very, very interested in how architecture collapses. Not so much in what it’s made off. Not so much in what’s the perfect way to do this. Not so much in solving a particular problem, but how does this thing collapse? How does it break? Where are the crumple zones that I need to put into this architecture to make it stand up? To make it survive over a longer period of time?

On a very high level, humility, you’re not going to get this right ever. It’s always going to be wrong. And with that, pessimism. Okay, this is wrong. It’s going to go wrong. How is it going to go wrong? What ways can I make this thing break? And that will allow you to formulate and capture what’s happening in your head as an architect.

The really interesting thing about these ideas is I’ve taught this. I mean, I taught this to 600 people last year. When I talk to really senior architects, people who’ve been around for a while and, you know, have the scars to prove it and have built some big stuff, they will say that this, what you’re describing here is exactly what we do. This is where you arrive at, when you’ve had a few decades, when you’ve seen a few things, this is how you start to think.

Now we all think like this, but we all have different words for what we do. And if someone asks, what is it that you do exactly? The question I got, we can’t explain it. We don’t know. But this is it. This is what we do. It’s this random stressing that doesn’t have to come from the mouth of a stakeholder, doesn’t have to be related to probability or to proper engineering. It’s more about the ability to consistently stress your conceptual model until you feel happy with it. And in the case of residuality, you stress it until you get to a point where you can’t break it anymore. And that’s when you’re ready to start implementing.

[00:49:03] The Goal of Architecture is Criticality

Henry Suryawirawan: So if I get right, you mentioned it as a criticality, right? The point where you think this is.

Barry O’Reilly: Yeah, so what I normally say is that the goal of a programmer is correctness, right? We have to write code that’s correct. It executes the same way every single time. It gives us the same results, the same inputs every single time. For an architect, the goal is criticality, as you say. And criticality is the ability of a system to survive things that aren’t in a specification, things that hasn’t been designed for. And I call this off-spec architecture, which is a big part of our jobs. We have to design a system that survives off spec. And criticality is a property that exists in biology. And it’s a function of the number of components and the number of links between the components.

So if you have a biological system, which is very simple, very small number of components and links, what we would call a monolith. That system is generally not critical, because it’s considered weak. It’s only got a few components. So if you hurt one of them, the creature dies in biology. Or the system crashes, the monolith crashes. On the other side, you have your microservices, right? So you’ve got a very high number of components, a very high number of links. And if you have a biological system like that, if you had one, it would be very hard to kill it in one go, because it has so many pieces and so many links, it’ll find new ways to survive.

And our brains are like this. They have so many components and so many connections that you can get a, you know, you can get a bang in the head and a bit of your brain stops working and another bit of your brain will pick up the slack and cover it for you. And that’s sort of part of the goal of criticality.

But the problem is that you can get to a point where you have too many components and too many links. And the system then collapses under the weight of its own management. So in biological systems that turns up in one way as cancer. There’s too many connections, too many things, too much can go wrong. In another way as insane energy needs. It’s like you have all these components, right? It’s very hard to kill you. You’re gonna have to eat all day every day to keep the energy in that system. And it makes the system very, very vulnerable.

Microservice people have already realized this, right? The big problem with microservices is it is hard to kill the entire system at one go. But when something goes wrong, it takes like three weeks to figure out what happened. And you’ve got to sit reading logs in the middle of the night and say, what happened? Why did it go wrong? We don’t know. And the system will collapse under the weight of managing itself. For us, that’s the cost of operations going up.

So criticality is this magic line in between the two where you have the right balance of components and links. And residuality, these ideas that we’re talking about, all this focus on philosophy, the point of all of this is to be able to drive our systems to that point of criticality where the system has the right balance of components and linkage to survive off spec, but not so many that it’s over-engineered, that it collapses under the weight of its own management.

This is a very important thing for us because generally the way we do this is we just guess at it. And this gives us a sort of a very pragmatic and very structured way of getting to have we actually achieved criticality in the system or have we gone too far, have we all overshot. And so this protects us from two very dangerous things. The first is over-engineering, which we love. And the second is under-engineering, which we have a tendency to start building systems without really exploring the conceptual models that we work with.

[00:52:17] Bridging the Gap Between Architecture and Stakeholders

Henry Suryawirawan: Thanks for explaining that. So what about takeaways for non-technical people? Maybe those business stakeholders or people who always complain that the software engineering team or the architects cannot come up with some solution that is stable and can survive over time.

Barry O’Reilly: Yeah. So this is one of the strange side effects of my work. I started talking about these things and I thought, well, architects should come and listen to me. And then I would go to companies and developers were coming as well, and they were really interested in what I was saying. Well, that’s good. That’s interesting. And as time went on, I started to notice Agile coaches turning up and I was like, Oh, do you know, do you know who I am? Do you know what I’m going to talk about? This is really not interesting. And then more and more managers were turning up, but business people who had nothing to do with software started to turn up and listen to my talks.

I’ve noticed that these ideas are really popular with them. Because once they start to understand this idea about the default philosophy of software architecture, they start to understand that uncertainty is at the core of this and that requirements and nailing down all of these old waterfall engineering ideas and being more strict isn’t the right answer, that there needs to be more looseness, essentially. And it’s a different kind of agility that you start to get when you architect like this. It starts to get really easy to communicate with architects and with business people.

And I’ve actually coached senior executives in this is how you manage your architects. This is why they’re so weird. This is how they think. This is how you talk to them to get the most out of them. This is why they get frustrated with you a lot of times. And a lot of it is about getting them to understand this organizational complexity and the structure and order of the machines we work with are two so wildly completely different things that they cause all kinds of contradictions and problems.

And then this leads to a rebuilding of bridges between architecture and development, between architecture and the executive function, between stakeholders and business people. And getting them to understand that it’s not as simple as it looks. These ideas actually trigger a lot of thinking. When business people realize that what we do as architects is closer to what they do in this uncertainty, but that we are kind of limited by our education, by this logical way of looking at the world. And getting them to understand that opens up a lot of doors.

Henry Suryawirawan: Thank you for introducing this concept. I think I can see some encouraging signs , right, where maybe the architect, the software engineering team, and the business stakeholders, they can empathize with each other, right? So business stakeholders can understand why software sometimes is not so easy to actually evolve and change. And also for software engineers and architects to know that why business is complex and keeps changing, right? We always complain if, let’s say, you know, your requirement is not up to what you described a few months ago, for example, right? And why we need to change things. So I think hopefully there’s one day that we can align and kind of like empathize each other and we can come up with a much better software and architecture altogether.

[00:55:09] 3 Tech Lead Wisdom

Henry Suryawirawan: So Barry, it’s been a pleasant conversation. Before I let you go, I have one last question that normally ask for all my guests. I call this the three technical leadership wisdom. So think of it like advice that you want to give to us. Maybe if you can share your version of three technical leadership wisdom.

Barry O’Reilly: Okay. So the first one, I’ve stolen from a TV character, called Logan Roy. I don’t know if you’ve seen the TV show Succession. Logan Roy is a billionaire media magnet. A very angry man, but very successful man, very shrewd. And he’s trying to teach his children. Because he’s very old, he’s trying to teach his children how to take over his business. It doesn’t go very well. It takes four seasons and they all hate each other. And he says in one scene that really stuck in my head, that had me screaming “yes!” at the TV. He’s talking to his daughter. He’s trying to teach her how to live in this world where everything is chaos. And he said, this is the rule, you know.

Everything, everywhere is moving, always and forever. And that is the first piece of wisdom that every architect needs to grasp immediately. And that’s the difference between architecture and programming. Everything, everywhere is moving always and forever. If you learn that and if you understand that as an architect, everything gets easier. And as you see in the book, the tragedy is that we waste half our careers trying to do what every other architect has ever done, hold it all still. If you try to hold it still, it will eventually wash you away.

The second thing, in order to be able to succeed with that, is to advise everyone who wants to be an architect to learn how to and to practice thinking for yourself. Thinking for yourself is probably the most important skill you can have as an architect. You cannot just think like everyone else, because you’ll end up looking at problems that you have to solve that are unique to your context, to your customer, to your environment, and you’ll try to solve it with someone else’s thinking. Lifting and shifting someone else’s ideas is not thinking. It’s not architecture.

And we get, in this industry, because there’s so much insecurity, we get really trapped easily in dogma. We want to believe in something. We need to believe in something. And we believe in these things a little bit too much, a little bit too often. There’s an excellent book called Lateral Thinking by Edward de Bono that teaches you how to really think outside of dogma, outside of narrow confines that I recommend to all architects.

And the third thing, and this is probably the most important, is that it has to be fun. You have to think this is fun. If you come into architecture as a developer and you’re upset because everything keeps moving, and everything keeps changing, and it won’t stay still, and you can’t develop your perfect customer object, and you’re blaming everyone else, and you make your stakeholders feel like, well, you know, the reason that you can’t do this is because you’re bad at this. If it’s not fun, then don’t do it. It’s, architecture is really, really difficult. And there’s a certain kind of person, who’s possibly a little bit twisted like me, who thinks that I’d love it whenever everything’s moving and changing and it’s crazy and it won’t stand still and nothing works and it’s frustrating, I actually think that’s fun.

And I’ve noticed that the people who’ve been really, really successful as architects in their careers, they also think it’s fun. And they get bored if everything’s easy and predictable and it’s a CRUD app and I wonder why am I here? You know, we want it to be messy. We want it to constantly move. And it’s really important that you find architecture fun. And if it’s not fun, then being an engineer is a perfectly acceptable career. And a rewarding career is good work. But trying to make architecture like engineering is where all the suffering begins. So having fun is probably the most important thing that any of us could do in our careers, I think.

Henry Suryawirawan: Wow. Lovely wisdom, right? So definitely everything is moving. Everything is chaos, right? So think laterally, right? So think outside the box. Think for yourself. And the last thing is, you know, make it fun, right? So you don’t want to suffer because of all the changes that is happening without you controlling it.

So Barry, for people who love this conversation, they want to reach out to you, connect with you or ask you more questions. Is there a place where they can find you online?

Barry O’Reilly: Yes, I’m very active on LinkedIn, which I think a lot of people might’ve seen already. I do all of my thinking out loud for better or worse. Mostly on LinkedIn these days because, it’s become the most stable social media platform for doing these kind of things. I’m also on Bluesky, but I’m more often… LinkedIn allows more sort of long form conversations and articles and things like that. I’m sure you’ll share the links. There are books and there are videos that go into detail on the kind of technical details on residues and how those things work. I’m on stage constantly all over the place. So there’ll be an opportunity to come and see me talk and talk to me if anyone wants to do that across most of the globe, across the next year or so.

Henry Suryawirawan: Yeah, very nice. So I think if people are interested in what we just discussed, I highly recommend Barry’s books and also talks, right. And conferences, if you can check out his presentation live, definitely highly recommend that. So Barry, thank you so much for your time. I’m sure we all learned something new about architecture today.

Barry O’Reilly: Thank you.

– End –