Architecture is, as we say, it's on the cost of being rejected
wholesale by the industry. It has been a tough ten years
for the concept of enterprise architecture.
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, with schedules and repositories full of
diagrams. At one point they said to me to
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, the senior
architects that I work with, what do you do?
We don't know either. So many people don't have the
same definition, and sometimes they also don't know how to
describe it. But in your definition, what is
your definition of architecture? My definition of architecture is
decision making in the face of ignorance.
As architects, we've got to work with concepts like customer and
order and markets and demand and all of this stuff that none of
it stays still. 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
satisfies our needs as logicians.
And it completely collapses at that point because you cannot
grasp the the complexity of a social organization with logic.
And this causes frustration for our stakeholders.
They don't like it. We have this obsession with
these abstractions, these essences.
What we don't have sometimes is the humility that these
abstractions die very quickly. The problem we have is that to
build software, you need it to be still.
I taught this to 600 people last year, and it turns out that they
loved it. There's a real hunger out there
for new thinking, new ideas, because everyone sees the gap,
or there's a gap between programming and architecture.
And the goal of a programmer is correctness.
We have to write code that's correct.
For an architect, the goal is. Hello everyone, welcome back to
the new episode of the Packly Journal Podcast.
Today. I'm very excited to meet Barry
O'Reilly. He's 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. Thank you, Henry.
Good to be here. So Barry, before we start diving
into architecture and all that, maybe if you can share a little
bit about yourself to telling us about your curriculum points
that you think we all can learn from you.
Yeah, so I, I've been in the business for a very long time.
I was 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've 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
architects 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 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 spent a lot of time teaching and thinking, and what
is architecture? How do we move this to the next
level? And, and most importantly, how
do we adapt architecture for this world of cloud which we've
created? But we don't really have the
answer to those questions. If you go back 15 years, what
does it mean to be an architect in the cloud and nobody knew?
And so a real turning point in the work.
I do know I was asking the question, you know, how do we
create architects? What do we teach them?
What do they need to know? And 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, with 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 to
just teach people to do what you do.
And they 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, the senior
architects that I work with, what do you do?
I know 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, the
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, and stakeholders would come and say,
look, we, 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, you haven't told us what
you want. You haven't told us what to
build. You don't know what your, 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, 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 base and
all of that. And that doesn't work.
None of it works. If, 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 the complexity sciences, which, you know, has a
very strong relationship to mathematics.
So it was, it was an easy place to start looking.
And what I started to do was I started to read up and those
ideas, I started to pull them in and describe my own practice in
those terms. And 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 I thought that that
doesn't feel right. 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, you
know, I went and I decided to do a PhD and 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 about 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.
I didn't want to just do another loop of the hamster wheel.
So I 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,
I've been getting up on stages at conferences to say, 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. And 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. And so it's a pretty cool time
right now. This episode is brought to you
by Swim IO, and I'm excited to have its CTO and cofounder Omer
Rosenbaum with me today to tell you more about Swim.
Hi Henry, very nice to meet you and thank you for having me.
So tell us a little bit more, what is swim.com?
At Swim, we want to help companies understand their code
bases. We combine static code analysis
with generative AI to create comprehensive documents that
help you navigate the code base. As an engineer myself, I
wouldn't want engineers to spend so much time understanding
existing code. I would want them to spend time
creating and building new stuff. When you have code that has
accumulated over decades, and especially in legacy languages
that not many people are adapted nowadays, then the problem is
even bigger. Swim dot IO is specializing into
helping mainframe developers to understand their code base.
Why mainframes? We actually didn't start there.
Kabul had been by some people obsolete for a few years, and I
discovered that it's not really obsolete, not at all.
There are more than 800 billion lines of cobalt code that are in
production and they drive lots of the business in the world.
And we got more and more requests.
From. Customers to help them
understand the legacy code basis that was written decades ago and
get accumulated over a very long period of time.
So from your customers so far, what are the some of the success
stories that you can share? So we worked with an analyst who
shared with us that it took them a year to document a single
mainframe application, and using SWIM they were able to document
a similar application in a matter of hours.
So saving that amount of time enables them to focus on other
tasks. Thanks, Amir for sharing with us
about SWIM today. To learn more about SWIM, check
out their website at swim dot IO.
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.
And you said that you published 2 books, one is the Architect's
paradox and the other one is the residual theory, right?
So maybe let's start with the Architect's paradox.
When you mention about paradox, what do you mean?
Can you explain a little bit? 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, Alfonso
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,
what you try to see logic in everything.
We are working with computers and chips and software and
registers and all of these things and functions, and we're
thinking pure logic. And then eventually the machines
get so powerful that we realized 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, they're trying to achieve something.
There's markets, everything's moving.
And we look at this and we try to analyse 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 modelling 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.
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 had 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 your computer work for you.
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 60s 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 Now the agile
movement to its credits 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, the the idea that
there's a waterfall process that's repeatable.
That's all part of the architects paradox.
What the agile movement missed was the fact that when we build
conceptual models of the business, the same paradoxes
there, we're still using logic. So the the problem with the
agile movement was that it just wasn't extreme enough.
It should have thrown the baby out with the bathwater, but it
didn't. It tried to keep the baby.
The baby got upset. And that's where we we are
today. It, 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 in the book was from a very
senior developer in the UK who 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're 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 ten 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, facing
up to some hard truths. 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 with the same
output, right? Those kind of stuff.
But we know that every time we build software, there's always
something that make 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.
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 mention 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? So my definition of architecture
is decision making in the face of ignorance.
And for us, what 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 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 that 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 that 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 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 field, 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're trying to copy or
steal the clothes of of real engineers.
And what we've never really had the conversation, what if what
we're doing isn't really engineering?
What if it's something way, way harder than what engineers have
to do usually? Say, you know, the people who
build cars, the architects who design cars, they have it easy,
right? Because they're working with
aluminium 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, 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. 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 it 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. 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 your evolve your software.
Sometimes it's very tricky, right?
Because the business complexity changes 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. If you can explain us about
these few things right, Why they make architecture so much more
challenging? Yeah, the the big problem we
have in in architecture and 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 white board, 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 because 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 say, look, I'll give
you a lovely 2 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's 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 in different legal frameworks around them.
That makes us need to know other properties about that.
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, 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, that 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, it'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 it 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 that you have to codify what's
actually happening. And that's why we have so much
frustration sometimes between business stakeholders and and
said to people because we can't move at their speed if we think
in this particular. Way, I think that explanation is
quite common, right? Maybe in a start up scale up
those kind of situation, right? You will tend to hear that
software becomes a bottleneck, right?
The team cannot, 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. 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?
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 wait, 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 our
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're not. No, we will not change.
This is a customer object, or this is what we mean by message.
And what happens is that we 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 when 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, the real world copies of that running in
memory. And so this behavior kind of
carries over into and this also leads us 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 CM in every single
project. And so you end up with an
industry that thinks that security is the CM.
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 end 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 an abstraction.
It's because we can't. You have to have the word cat in
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 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 someone said these
abstractions will definitely work for you and it will cost
this much. And then you buy the platform
and you say what we need to change a few of these
abstractions and suddenly it's a five year project that's 500
million and no one's happy. And that's the constant failure
of the 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 make the still static software for this
constantly moving world. So I think I left when you
mentioned about, you know, we tried 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? 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. 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 thought, oh, this is
overwhelming. And I got really interested in
it in the end of it, a little bit too interested in it and
went a bit too far. They say, like, this has to be 7
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 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 2 old man in a
square in Athens had this exact argument 2 1/2 thousand years
ago. And they were smart enough to
say we'd better just leave it. We 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 Figgia 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
the 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 asked them some awkward questions, and
the ones who didn't get upset and actually answered the
questions would reveal 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 which we call a business.
That it can be reduced and modelled.
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 all that ways
thinking. As I was asking people to do
that, I noticed that they would struggle sometimes.
There's things they didn't want to let go off.
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 they talked about it at an
architecture conference. At the architecture conference,
they said they were really interested.
They 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 actually, I
never heard anything like this. How dare you RIP up the rule
book. And then I went to, I spoken to
developer conference, not a huge developer conference, a small 1.
And I thought, this is a big risk where they're going to
throw chairs at me, They're going to hit this, this is
boring. Because I found that they were
really interested as well. And then they did an even bigger
developer conference, NDC and Oslo last year.
And I thought they said, can you come and give a talk?
I said, yeah, OK, I'll give my philosophy talk.
And I figured they'll put me in a room far at the back.
There'll be 4 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 in.
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 they loved it.
And I thought, well, there's a real hunger out there for new
thinking, new ideas, because everyone sees the gap where
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 we 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, the response of that
conference then gave me the idea that, hey, those 200 extra PhDs
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 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 and which I guess is your audience.
And you're saying, what's the next step?
And the next step isn't more algorithms.
It isn't getting better at leaked, 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 on the compiler.
So I think when you mentioned about both philosophy, I think
we all have, it may be inherited from the study, from the books,
right, from the logical thinking that we thought 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 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 micro service, 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 it's a good time to actually introduce us to this
concept of residuality. Yeah.
So if we go back to the ancient Greeks, which is where I always
start this story, does it make more sense?
They looked at the world. And for them, you know, this is
2 1/2 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'd say, well, what if it's made of water?
One of the sort of renowned as one of the first Greek
philosophers called Talas, who came up with this idea, it's
what if everything is made of water?
That's obviously ridiculous. So 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 arcade, they called
it, some kind of building block that everything is made of.
And he came up with water and he was obviously wrong.
But that instinct started a way of thinking that changed the
world for us in the West. There were other thinkers.
We will 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, the 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 in software we have this constantly shifting
picture, right O someone says it's the machine, it's the UNCH
card, it's this function, it's the procedure, it's the module,
it's this actor, the service, the object, the the micro
service. So it gets very tiring.
It changes every couple of years and we're so we're very much in
that sort of earth, fire, wind, water, fears of what's
everything made of. 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, we have to ask the
question, what is the unit of architecture?
And what I found 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 deemisly
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 are basically
our architecture as it collapses.
And So what we're interested in is describing our architecture
not as this static 2 dimensional picture, but as a series of
collapses. So we assume with humility that
the architecture I've designed, the concepts that I've used, are
going to collapse no matter what happens.
And 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, dying. 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, 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. Noi 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 was going to look, how it's going to collapse
in different trouser and eggs 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've 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 realize that
what we have is this arcade, this 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 very
philosophical reasons why that all fits together very nicely.
So it's 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 5 and I said to them that 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 5 year olds 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, which
brings 1 concept in after the other.
I don't think I succeeded in the last three minutes of doing
that, so to be honest. Yeah, definitely.
It's a fascinating thing right there 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 talks is
much better definitely, But I think it's still invite us to
actually dig deeper, right? I think the thing that I can
summarize maybe from the way you explain just now, right, instead
of thinking architecture is A1 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 yeah, collapse because of a
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?
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. So definitely for people who are
interested in this kind of thinking, I invite you to
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? So there are two books out
there. No 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 the high
architecture collapses. Not so much in what it's made
of, 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 high, very high level?
Humility, You're not going to get this right ever.
It's always going to be wrong. And with that pessimism, OK,
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, look, 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 when 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. Is 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.
So I, if I get right, you mention it as a criticality,
right, the point where you think?
Yeah, yeah. So what what I normally say is
that the goal of a programmer is correctness.
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 specification thinks
it hasn't been designed for. And I call this off spec
architecture, which is a big part of our jobs.
But we have to design a system that survives off spec and
criticality is appropriate 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 are one of them, the
creature dies in biology or the system crash, or 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, 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 when the system then
collapses under the weight of its own management.
OK, 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 in seeing energy needs.
It's like you have all these components where it's very hard
to kill you. You're going to have to eat all
day every day to keep the energy in that system.
And it makes the system very, very vulnerable.
Micro service people have already realized this.
It's the big problem with micro services is that it is hard to
kill the entire system at one go.
But when something goes wrong, it takes like 3 weeks to figure
out what happened and you've got to sit reading logs in the
middle of the night and 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 lying 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 2 very dangerous things.
The first is over engineering, which we love, and the second is
under engineering, which we we have a tendency to start
building systems without really exploring the conceptual models
that we work with. 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. 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, though. 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 kneeling 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 and 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, 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 educations, by this logical way of looking at the world and
getting them to understand. That opens up a lot of doors.
Thank you for introducing this concept.
I think I can see some encouraging signs, right?
Where maybe the architect, software engineering team and
the business stakeholders, they can empathize with each other,
right? So business stakeholders can
understand why software sometimes it's 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 describe 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.
So Barry, it's been a pleasant conversation.
Before I let you go, I have one last question that normally I
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.
OK, so the first one I've stolen from ATV character called Logan
Roy. I don't know if you've seen the
TV show Succession. Logan Roy is a billionaire,
media magnets, 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, then, 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 and 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,
it won't stay stale and you can't develop your perfect
customer object and you're blaming everyone else and you
make your stakeholders feel like we 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, 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 up,
you're like, 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 can do in our careers, I
think. 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?
Yes, I'm I'm very active on LinkedIn, which I think a lot of
people might have seen already. I do all of my thinking outlawed
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 blue sky, 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. Now 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. Yeah, very nice.
So I think if people are interested in what we just
discussed, I highly recommend various books and also talks
right in the conferences. If you can check out here's
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. Thank you.