google-site-verification=ELxx8BxZxh0FRvrpsz3X3djO2LXa4N0xnq_ADRpt8wA Emergent Architectures and Beating the Monolith - Loving Legacy

Episode 28

Emergent Architectures and Beating the Monolith

What does it mean to support, extend or even replace a monolith and should we even try? This time I explore the landscape as it is now - when we feel under pressure to "do microservices" yet we have something that works but is perhaps too much of a monolith for us to work with effectively.

This quote from the end of the episode perhaps sums it up:

"Emergent architecture is used for understanding and extending complex systems, which have arrived at their state through an unknown path."

NOTES

https://richardwbown.com/build-now-vs-build-later-upfront-design-vs-implementation-costs/

https://richardwbown.com/beating-the-monolith-understanding-modern-software-delivery/

https://www.bol.com/nl/nl/f/domain-driven-design/9200000002151217/

https://richardwbown.com/defining-the-bounded-context-is-the-key-to-flow/

https://thenewstack.io/what-we-can-learn-from-twitters-outages/

QUOTES

01:25 - "emergent architecture is a smart way to say we built something and once we had a plan, but now we have to change it" [RB]

01:52 - "Documentation is of use in order for software archeologists to discover the business motivations for why we're built that way in the first place" [RB]

02:22 - "This is the very definition of the sunk cost fallacy. Those that have invested so much financially, emotionally, and reputationally, that they must double down on that approach until it's either universally accepted or until it's dead in the water. This approach, I call the "Abyss of Obsession", and it's a social construct" [RB]

03:19 - "it's important to dream big. We're all capable of it, and software is the perfect scaffolding for these dreams" [RB]

04:46 - "If you've ever tried to reverse engineer a system, then you will know that a complex system is exactly that, often intractable" [RB]

05:39 - "what you see from typical software projects is that either zero sum or significant upfront planning or design is made" [RB]

06:46 - "I call this cost to first 'gotcha'. The moment where we think, oh no, we forgot this fundamental thing" [RB]

08:07 - "Do not let our ideas become code." [RB]

09:41 - "Emergent architecture means that things change. We can be resilient to change, not just with how we build our applications physically, but also by expecting things to need to change." [RB]

10:30 - "This is why a legacy system is really every system we ever build" [RB]

11:03 - "I believe that just like a good domain model, we already have enough or perhaps too many words to describe the patterns that we see in enterprise systems and architecture." [RB]

12:02 - "Emergent architecture is used for understanding and extending complex systems, which have arrived at their state through an unknown path." [RB]

Transcript
Richard Bown:

Hello and welcome to Loving Legacy.

Richard Bown:

This is episode 28.

Richard Bown:

I'm Richard Bown your host, and this time I'm talking about emergent

Richard Bown:

architectures and beating the monolith.

Richard Bown:

It's been a while since I recorded myself just talking about

Richard Bown:

things and to tell the truth.

Richard Bown:

I've been thinking long and hard about this next step.

Richard Bown:

I've been working on a course which will teach technical leaders why all of their

Richard Bown:

effort to gain clarity and control of software development and delivery is

Richard Bown:

essentially wasted unless some effort is spent to acknowledge how software

Richard Bown:

gets built outside of all the frameworks and techniques that we are bombarded.

Richard Bown:

This means consuming a lot of those frameworks, ideas and techniques

Richard Bown:

myself, and then putting some words together to form a common understanding

Richard Bown:

of what we're trying to achieve.

Richard Bown:

Ironically, for some, you might recognize this as a fundamental

Richard Bown:

principle of domain-driven design, defining a domain language, and then

Richard Bown:

modeling a solution using that language.

Richard Bown:

Okay, so let's dive in.

Richard Bown:

In Sam Newman's building Microservices second edit.

Richard Bown:

It's all about building distributed systems.

Richard Bown:

Pretty much any system is a distributed system right now goes the argument.

Richard Bown:

So should we all be setting out explicitly to build

Richard Bown:

microservices based architectures?

Richard Bown:

Many seem to think so and have invested heavily both in the technology

Richard Bown:

platforms to support this as well as the skills and learnings that

Richard Bown:

allow successful implementation.

Richard Bown:

However, is this a one size fits all?

Richard Bown:

emergent architecture is a smart way to say we built something and once we had

Richard Bown:

a plan, but now we have to change it.

Richard Bown:

This is therefore the definition of pretty much any software

Richard Bown:

ever a monolith can appear.

Richard Bown:

It's just a block of code, and we will find that difficult

Richard Bown:

to break down any further.

Richard Bown:

Usually due to design decisions made before or during its assembly,

Richard Bown:

a monolith could even appear nominally in a microservice, although

Richard Bown:

that would probably mean that it wasn't a microservice anymore.

Richard Bown:

Documentation is of use in order for software archeologists to discover

Richard Bown:

the business motivations for why we're built that way in the first place.

Richard Bown:

They're a great starting point to understand how your software

Richard Bown:

developed to the point it is now.

Richard Bown:

The history of software development is littered with the bones of great

Richard Bown:

technological frameworks and ideas that have briefly set the world a

Richard Bown:

light only to disappear Agonizingly slowly , as the zealots of the

Richard Bown:

ideology continue to clinging on to the investment they have made.

Richard Bown:

This is the very definition of the sunk cost fallacy.

Richard Bown:

Those that have invested so much financially, emotionally, and

Richard Bown:

reputationally, that they must double down on that approach until

Richard Bown:

it's either universally accepted or until it's dead in the water.

Richard Bown:

This approach, I call the "Abyss of Obsession", and it's a social construct.

Richard Bown:

having been there myself with ideas, designs, and architectures, I feel I

Richard Bown:

must talk them through with peers until we reach either an understanding that

Richard Bown:

could work or a feeling that it couldn't.

Richard Bown:

Any ideas that persist after this peer group round housing will eventually

Richard Bown:

start to take seed in our minds.

Richard Bown:

This will be our famous thing we think, and we get ahead of ourselves

Richard Bown:

in believing that we've solved the world's software problems.

Richard Bown:

If you're not familiar without feeling yet, then I think you probably need

Richard Bown:

to find a better class of software developers to hang around with and

Richard Bown:

just dream a little bit bigger.

Richard Bown:

Usually this kind of discussion happens in the pub after a few ales.

Richard Bown:

But it's important to dream big.

Richard Bown:

We're all capable of it, and software is the perfect scaffolding for these dreams.

Richard Bown:

Okay, so saying we implement something using this technique and it works.

Richard Bown:

Then we start to enter this abyss of obsession and we are most

Richard Bown:

likely not to return for a while.

Richard Bown:

We are a submarine disappearing to the Mariana's trench of ambition.

Richard Bown:

This applies as much to architecture frameworks as it does process frameworks

Richard Bown:

like Agile, as it does technologies.

Richard Bown:

We have a hammer and everything looks like a.

Richard Bown:

. Okay, so taking obsession around frameworks, technologies, and processes.

Richard Bown:

As read, we should be careful when accepting new ideas and new words

Richard Bown:

and concepts into our vocabulary.

Richard Bown:

The monolith doesn't actually exist as in as much a microservice

Richard Bown:

doesn't actually exist.

Richard Bown:

These are abstract ideas, or we can build our imperfect models

Richard Bown:

of the world and attempt to implement them and learn as we go.

Richard Bown:

What we end up with in software design, development and

Richard Bown:

delivery is a complex system

Richard Bown:

According to Dave Snowden's Canne Framework, a complex

Richard Bown:

system is the unknown.

Richard Bown:

Unknowns cause and effect can only be deduced.

Richard Bown:

In retrospect, there are no right answers.

Richard Bown:

Instructive patterns can emerge if the leader conducts

Richard Bown:

experiments that are safe to fail.

Richard Bown:

Can Evan cause this process probe sense?

Richard Bown:

If you've ever tried to reverse engineer a system, then you will know that a complex

Richard Bown:

system is exactly that, often intractable.

Richard Bown:

They are the result of forgotten rules.

Richard Bown:

One can design a system as well as you like, but if you've forgotten

Richard Bown:

a crucial rule until later in the process, then often the amount of

Richard Bown:

work to completely redesign the system to accommodate the fundamental

Richard Bown:

thing you've forgotten is too cost.

Richard Bown:

I've tried to graph this effect and I will link an article which shares these graphs.

Richard Bown:

We map cost of implementation versus cost of design, and we call design

Richard Bown:

anything in this case that isn't coding, testing, deploying, or supporting the

Richard Bown:

code directly via incidents, et cetera.

Richard Bown:

The cost of design therefore could encompass anything that is seen as

Richard Bown:

thinking about the system, refinement sessions about architecture.

Richard Bown:

Workshops, presenting facts or findings, learning new techniques.

Richard Bown:

Anything which falls into the category of talking about rather than doing

Richard Bown:

what you see from typical software projects is that either

Richard Bown:

zero sum or significant upfront planning or design is made.

Richard Bown:

If no upfront planning is made, then the project starts amidst a

Richard Bown:

flurry of activity, coding, design, experiments, trial and error, depending

Richard Bown:

on the ambition of the project.

Richard Bown:

This might be the right way to go.

Richard Bown:

No, upfront cost means jumping in, iterating quickly, and

Richard Bown:

learning as it moves forward.

Richard Bown:

Some design means that decisions perhaps around technology platforms

Richard Bown:

architecture have been made, and we perhaps know an outline of our

Richard Bown:

system design before we start coding.

Richard Bown:

Significant design means mapping out exactly how our system is going to look.

Richard Bown:

and proceeding on that basis.

Richard Bown:

This means that building is optimized, but we might end up building the

Richard Bown:

wrong thing for any approach.

Richard Bown:

The only time we can validate our assumptions is when we get

Richard Bown:

our system in front of the people it's supposed to be serving.

Richard Bown:

When we receive that initial feedback, we can iterate our design and depend on

Richard Bown:

how flexible our initial architecture is.

Richard Bown:

This will come with a variable cost.

Richard Bown:

I call this cost to first "gotcha".

Richard Bown:

The moment where we think, oh no, we forgot this fundamental thing,

Richard Bown:

and often software systems lurch from gotcha to gotcha until perhaps

Richard Bown:

they either fulfill their initial brief or requirements and become

Richard Bown:

useful to the customer or they fail.

Richard Bown:

But no system is ever completely free of gotcha's because users can always

Richard Bown:

think of things that we can't as system designers or builders and software being.

Richard Bown:

Being flexible and software engineers also being prone to

Richard Bown:

fall into the abyss of obsession.

Richard Bown:

No change is too great for our system.

Richard Bown:

No matter what approach we take initially, we will always be faced with a dilemma.

Richard Bown:

Should we extend this legacy system to include new functionality

Richard Bown:

or should we just write a new.

Richard Bown:

Therefore legacy is a social trap even more than it is a technological trap.

Richard Bown:

This is the very basis of emergent architecture and why we'll never

Richard Bown:

actually beat the monolith.

Richard Bown:

It's not something to be beaten.

Richard Bown:

It's something to be used when appropriate.

Richard Bown:

It's something to be used as any other tool in your toolkit.

Richard Bown:

often as programmers, we don't set out with anything in mind

Richard Bown:

other than a purpose for our work.

Richard Bown:

The rest of the discussion, the design architecture technologies and the

Richard Bown:

things that we use to build our ideas upon are often only abstract concepts

Richard Bown:

which we use to share our ideas.

Richard Bown:

Once they are made flesh in whatever tech we choose, they inevitably change.

Richard Bown:

Do not let our ideas become code.

Richard Bown:

This is why I have a somewhat ambivalent attitude to diagramming

Richard Bown:

tools and ways to turn ideas into code.

Richard Bown:

Things like the C4 framework are good at a high level, but these are

Richard Bown:

merely conceptual boxes of things.

Richard Bown:

Any detailed design driven from flittering ideas are usually

Richard Bown:

not proven to be helpful.

Richard Bown:

We will, at some point, have to compromise on these ideas, and usually at that

Richard Bown:

point we'll work too hard to modify our original design to accommodate change.

Richard Bown:

Then perhaps it's not even helpful.

Richard Bown:

The same happens when we consider any design paradigm, purely idiomatic.

Richard Bown:

If you read the Blue Book by Eric Evans on domain-Driven Design,

Richard Bown:

you'll find the premise of it is one.

Richard Bown:

For most software projects, the primary focus should be on the domain and

Richard Bown:

the domain logic, two complex domain designs should be based on a model.

Richard Bown:

For me, there is nothing to argue with here.

Richard Bown:

Understand what you're trying to achieve and then deliver a model of it.

Richard Bown:

Also talking the same language as the users, but it's surprising how often we

Richard Bown:

are drawn to focus on techniques or sub techniques rather than the bigger picture.

Richard Bown:

That's understandable because to form thoughts like this takes

Richard Bown:

a lot of hard work and time, and it's only conceptual work.

Richard Bown:

It's not a useful day to day for an engineer or engineering leader.

Richard Bown:

Even practical techniques are the things that we fall back on

Richard Bown:

and utilize, remembering to use.

Richard Bown:

And remembering why we're using them is good to always keep in mind.

Richard Bown:

Emergent architecture means that things change.

Richard Bown:

We can be resilient to change, not just with how we build our

Richard Bown:

applications physically, but also by expecting things to need to change.

Richard Bown:

To be aware that circumstances outside our control may intercede

Richard Bown:

to make us have to change.

Richard Bown:

One of the conclusions we must be able to draw now from the Elon

Richard Bown:

Musk evisceration of engineering at Twitter is that the system was

Richard Bown:

certainly well enough engineered to survive significant tampering.

Richard Bown:

It's still running.

Richard Bown:

Despite a few blips and outages, things are changing.

Richard Bown:

The architecture is adapting and growing.

Richard Bown:

The rest is supposition but all we can do is base an understanding on what

Richard Bown:

we feel and experience as customers.

Richard Bown:

Whatever we choose as a starting point.

Richard Bown:

Know some or lots of design, our decisions are always going to be

Richard Bown:

called into question, but new people challenging our ideas of technology,

Richard Bown:

fitness, for purpose and business direction are always going to appear.

Richard Bown:

Therefore, our starting point doesn't really matter, and by

Richard Bown:

extension, where we are now with our systems doesn't really matter.

Richard Bown:

This is why a legacy system is really every system we ever build.

Richard Bown:

If we truly value it and we want it to be better for our customers, then we must

Richard Bown:

treat every system in whatever state, age, or technology with the same reverence.

Richard Bown:

It's only dependent upon relevance in the market and relevance to the customers.

Richard Bown:

I propose a framework of the best practices that allow us to stay grounded

Richard Bown:

to our customers' needs as closely as possible, while reusing all the terms

Richard Bown:

that any good engineering organiz.

Richard Bown:

are already familiar with.

Richard Bown:

I believe that just like a good domain model, we already have

Richard Bown:

enough or perhaps too many words to describe the patterns that we see in

Richard Bown:

enterprise systems and architecture.

Richard Bown:

What is missing is a good Rosetta Stone that enables us to speak

Richard Bown:

the same language across ideas.

Richard Bown:

If we can reuse rather than reinvent terms and agree on a language, then perhaps we

Richard Bown:

edge closer to a common understanding of what it means to build great software.

Richard Bown:

This is where novels like the Phoenix Project or the

Richard Bown:

Unicom Project, are so strong.

Richard Bown:

They place these facts in a story as techniques to try and help us

Richard Bown:

understand where we want to go.

Richard Bown:

And this is something that we can all do.

Richard Bown:

Storytelling with practical examples from your business, working out how the

Richard Bown:

stories of your systems need to change in order for you to deliver the right

Richard Bown:

value to your customer at the right time.

Richard Bown:

Fundamentally, this is all we can hope to achieve from software engineering

Richard Bown:

. Engineering anything is about

Richard Bown:

Something that a customer will pay money for or utilize.

Richard Bown:

Therefore, we define software engineering as building the

Richard Bown:

right software for a customer.

Richard Bown:

Emergent architecture is used for understanding and extending complex

Richard Bown:

systems, which have arrived at their state through an unknown path.

Richard Bown:

Try to learn how you got where you are now through analysis,

Richard Bown:

reading, talking to engineers and customers, finding out the history.

Richard Bown:

Only then will you be able to plot a path to where you need to be next.

Richard Bown:

Your frameworks, technology choices, et cetera, either constrain

Richard Bown:

or enable its path and should also inform you of your future.

Richard Bown:

I hope I've given you something to think about in this episode.

Richard Bown:

I'll be covering more around this in the future, so, If you enjoy this, then

Richard Bown:

please like and subscribe to the podcast.

Richard Bown:

And, feel free to share it with your friends and colleagues, and also feel

Richard Bown:

free to reach out to me if there's anything you'd like to talk about

Richard Bown:

legacy systems engineering, or the future of emergent architecture.

Richard Bown:

Until next time, this is Richard Bown wishing you goodbye and good luck.

About the Podcast

Show artwork for Loving Legacy
Loving Legacy
What are legacy software systems and why are they so fascinating?

About your host

Profile picture for Richard Bown

Richard Bown

DevOps Engineer | Software Designer | Writer