The first word, architecture, captures that it's more than
just the software. This is modern architecture.
Architecture is a phrase that touches on the software, the
business side, and the team organization side.
Modernization is a word that represents taking something that
has some outdated thinking in it.
It could be outdated technologies, it could be
outdated ideas, and also the organizational side.
So modernization doesn't just mean technologies.
Hey everyone, my name is Henry Surya Virawan and you're
listening to the Technically Journal podcast, the show where
I'll be bringing you the greatest technical leaders.
Practitioners and thought leaders in the industry to
discuss about their journey, ideas and practices that we all
can learn and apply to build a highly performing technical team
and to make an impact in your personal work.
So let's dive into our journal. Hey everyone, you're listening
to the Technically Journal Podcast, the podcast where you
can learn about technical leadership and excellence.
From my conversations with great thought leaders in the tech
industry, if you haven't, please subscribe on your favorite
podcast app to get notified for future episodes.
Also subscribe to Techlegional's various other contents on
LinkedIn, Twitter, Instagram, YouTube, and Tiktok.
And if you have been enjoying this podcast and its contents,
support my work by either buying me a coffee at techlegional dot
dev tip or becoming a patron at techlegional dot dev patron.
My guest for today's episode is Nick Chun.
Nick is a Principal consultant and the author of Architecture
Modernization. In this episode, we discussed
how organizations can successfully go through an
architecture modernization journey.
Nick began by defining architecture modernization and
discussing the social technical aspects involved.
He then introduced the concept of an independent value stream
and its four key characteristics which are domain alignment,
business outcome driven. Empowered Teams and Software
alignment. Nick also shared tips on how to
get buy in for a modernization journey, why it is beneficial to
do it collaboratively, and explained in depth the wordly
mapping technique. Towards the end, Nick described
the idea of Architecture Modernization enabling team and
gave advice on creating an architecture modernization road
map. I hope you enjoy listening to
this episode and learned several tips on how to do a successful
architecture modernization. If you enjoy listening to this
episode, please share it with your colleagues, your friends
and communities and leave a 5 star rating and review on Apple
Podcast and Spotify. Your small help will help me a
lot in getting more people to discover and listen to this
podcast and I really appreciate it.
So let's now go to my conversation with Nick.
Hello guys. Welcome back to another new
episode of the Tech Regional Podcast.
Today I have Nick tune here and we're going to talk about his
new upcoming book, Architecture Modernization.
So happy to have you here, Nick. I'm looking forward to talk all
about modernization because I think many companies are
struggling as well to deal with their legacy or improving their
architecture. So welcome to the show.
Thank you. So great to be here.
Really appreciate it. Nick, I always love to ask my
guests to first share about yourself, right?
Maybe if you can tell us more a bit about your background,
highlights, turning points that we all can learn from you.
Yeah, sure. Happy to share some thoughts.
Got my first job 15 years ago in IT working as a software
developer. Very early in my career.
I had some good mentors, mentors who were always passionate about
learning new stuff, and they got me into Domain Driven Design
quite early in my career. In like the first six months of
my career, I've been exposed to Domain Driven Design and that
was the first thing that I really got excited about.
This idea of building software in a way that is as well suited
to the business problem you're solving as possible.
That was quite different from all the other stuff I'd learned
before that you know, like object oriented, like duck
extends, Bird, all that basic stuff.
Domain during design was a real step up from that.
So that was really exciting. And then a couple of years later
I moved to London, got to work for a company doing continuous
delivery and that was another magical moment for me.
I deployed to production on my first day of working at the
company. I worked with a senior engineer.
We did some pair programming, we did some test driven
developments and once we took our ticket and finished that
piece of work, we pressed 1 button deployed to production.
So those two things happened in the first couple of years of my
career. So you know, great start, a lot
of positive influences there And then I think those were the two
things I looked for in the rest of my career.
And probably the next turning point came when I worked at
Salesforce I think. So I was hired by Salesforce, a
team in London to help modernising some legacy systems
and I'd written a book about Domain Driven Design with my
friend Scott and they wanted someone with Domain Driven
Design experience to help them. And what I realised the turning
point was we could refactor the old legacy systems and reshape
it to be more domain aligned. But however we shaped the
software, there was always going to be multiple teams working in
every code base. And I realised, oh if you're
going to be a software architect you also have to think about how
the teams organised as well. You can't just go changing the
software and how that's organised and expect the teams
to all stay the same. I can go after Salesforce.
I fell into consulting, I've been writing blog posts and
talking at meet ups and companies started contacting me
directly. And that's where I'm currently
at the moment as a consultant, mostly operating as a
facilitator and advisor. I don't make a lot of decisions
nowadays. My job is more to help other
people make decisions. I quite enjoy that.
This episode is brought to you by Miro.
As you will hear in this episode later about architecture,
modernization, collaborative discussion, event storming,
worldly mapping and so on, to find a tool that can support
doing those activities while also supporting collaboration
and creating the necessary artifacts can be quite a
challenge. One tool I find that allows us
to do so effectively and in a fun way is Miro Miro.
At a first glance, it might seem just like a simple digital
whiteboard, but Miro's capabilities.
Run far beyond that. It's a visual collaboration tool
where the whole team can build on each other's ideas and create
something innovative together from anywhere.
Brainstorming and strategic planning becomes easier when
it's visual and accessible, and it all can happen across teams
in mirror you can quickly start collaborating within 90 seconds
without having everyone registered as a mirror user
before. There are also more than 300
predefined templates you can use to kickstart your collaboration
within seconds. So the next time you're looking
for a digital tool to support your brainstorming, designing,
planning, and online collaboration, do give Mirror a
try. You can Sign up today at
mirror.com Podcast miro.com Podcast and your first three
mirror boards are free forever when you signed up Now.
And now let's get back to our episode.
Thanks for sharing your story. I think very, very interesting,
right? Not many people got the chance
to start their career being exposed to good practices,
right? So from your side, you were
exposed to TDD and continuous delivery, pair programming, XP
stuffs and all that. I think that's really, really
fantastic, right? For people who didn't have the
luxury in their beginning of career to get exposed to all
this. Maybe do you have some tips for
them? How can they upskill themselves?
Or you know, like do the best practices, even though maybe
their environment doesn't support that.
Yeah, that's a really good question actually.
I think I do have some advice. I think I do recognise, like I
was really lucky to have those positive influences.
I did choose the companies I wanted to work for.
I did see that they were doing good things and I tried to, I
applied for those companies. But I was, it was mostly luck
that I had those experiences. But what I would say, I think
the thing that comes to my mind the most when you ask that
question is, I would say for most people it's about believing
that actually this can work. Like I was speaking to a company
a couple of years ago about continuous delivery and they're
like this stuff all sounds great, but have you ever seen
any company really doing that? And I'm like, yes, in my second
ever job we were doing that. So I'm not criticizing those
people. I just think if you've been used
to working a certain way, it seems to be very difficult to
see like, oh a completely different ways possible.
So I think my advice would be just challenge yourself to
believe that something else is possible and it can work even if
it doesn't work. And I think that's a good
attitude in your career. I still have that now.
I'm still like maybe one day DDD and continuous delivery will be
the old thing and people will say why are you still doing that
stuff? So I'm always worried that yeah,
the way I'm currently seeing things might be obsolete at some
point. Yeah, I think keep believing is
definitely true and keep an open mind, right?
Because sometimes we are used to the habits and maybe the
cultural things in the organization and we kind of like
shut down to other even though it's best practice from
industry. But yeah, it just didn't work
here. Maybe that kind of mentality,
right? So I think your consulting role
now expose you to many different, you know,
organizations, maybe challenges and you wrote this book,
Architecture Modernization. Before we dive deep into the
topics of the book, I just want to understand what made you
wrote this book, right. So is there any specific
problems that you want to solve by writing this book?
So the problem I wanted to solve with that book was, oh, there's
a pandemic. I'm going to be stuck at home on
my own. Let's write a book.
So that was the first problem. It solved keeping me busy, but I
think the reason I chose that book and those topics was so I
wrote a book before with Scott Millet 10 years ago, and I
always wanted to write another book, but I felt like I'm going
to wait. I want to wait until I've got
something useful to talk about enough experiences that would be
different to the old book and useful in some way.
So I just reflected on my work as a consultant.
What is it I've been doing over the last years?
And I think probably most people in tech will have many
experiences like this where we've got like a legacy problem,
right? Old systems get out of date.
The longer things exist, the more problematic they become.
Every company always wants to go faster.
And so I thought I'd talk about the kind of work I do from that
perspective. I could have written a book
about Domain driven design and event storming.
I thought. I wanted to show how these
techniques are used in that process of improving how a
company works and how their architecture is designed.
So maybe if I can ask about the title itself, right?
Why do you call it architecture modernization?
What do you refer as architecture modernization?
Because there are so many terms being used for maybe some kind
of effect, right, maybe re architecture or software
modernization or cloud modernization and things like
that. Why specifically like
architecture modernization, maybe if you can define that,
yeah, sure. I think naming's always the
hardest part. So you know, a name is 2 words
and the book is like 400 pages. So trying to explain what these
400 pages represent in two words is always difficult.
But I think the first word, architecture, captures that.
It's more than just the software.
This is modern architecture, as I talked about before, those
influences in my career around the domain focus.
How do you shape a system aligned to the business domain?
How do you enable an architecture?
How do you design a system that enables continuous delivery?
And that touches on the team aspect as well.
So I thought architecture was the right description.
That's the kind of terminology I use in my work.
Architecture is a phrase that touches on the software, the
business side and the team organization side.
And I think modernization is a word that represents taking
something that has some outdated thinking in it.
It could be outdated technologies, it could be
outdated ideas. So modernisation doesn't just
mean technologies, it might be when we built this system, we
built some abstractions into our system.
Like an example from my book is a company called Vinted.
It built like a platform and the platform was based on the idea
of this company will be active in one vertical in one market.
So the whole system had abstractions based on that idea.
And then as the company grew and the business model evolved, now
they were acting in multiple markets.
And so that's also modernizing as well.
It's modernizing old abstractions based on old
business models. And also the organizational
side, I think modern practices is something that people would
recognize. So continuous delivery, for
example, I would say that's a modern practice.
So modernization would mean moving from approaches that
don't support continuous delivery to approaches that do
support continuous delivery. Right.
This is what I find really unique about your book, because
I'm sure many people would have assumed that architecture is
just technology thing or maybe there's a new tools, new
platforms, new whatever, right? And we just apply it.
But I think in your book you cover a lot of things, not just
technology, right? If I can maybe read one of the
quote that I have here, modern architecture is more than just
technology and patterns, it is a social technical architecture.
I think this social technical has been, you know, flying
around these days and people realize actually how how
important it is. Maybe if you can add on here,
what do you mean by social technical architecture in the
context of the book that you are writing?
Yeah, sure. So I guess the first point, I
would just say the reason I wrote the book from that
perspective is because I was known for domain during design.
I would be contacted by companies who are saying things
like we've started this cloud migration or cloud
transformation and people have picked up the technologies, but
they're struggling with domains and how to organise teams.
And there doesn't seem to be much else out there on that
topic. So I felt that's why I would
focus on those things. Like I'm super excited about
tech as well. I think modern technologies and
they do enable you to move faster.
So I think that is important. I'm not saying, you know, tech's
just an implementation detail, don't worry, do all this DDD
stuff. It's just I think tech has been
covered well by other people. So I focus less on that in the
book and more on the other stuff.
And so I think Socio Technical is capturing both the importance
of how do you, because when you architect a system, it will
affect how the teams work, right?
It will decide where the dependencies are in a system,
and I think it's about that joint optimization.
You might be able to create loosely coupled software, but
you might have an organization structure that is determined by
other factors, like could be geography.
You might have one team in London and one team in Berlin,
for example, and you might decide, well, we want to keep
those teams together. So we'll compromise on the
software so that the teams get to own parts of the software.
Whereas if those teams are all sitting in the same office and
you could move people around, you might say well we'll
actually we'll shake the software in a different way.
So I think it's just that joint optimization.
One of the activities I do in my work is I have this like slider
and I just ask people what's more important on this side.
It's a well designed architecture and on this side
it's teams that can work independently and are motivated.
And most people actually say the team bit is more important than
the architecture, but not all the way.
It's like the average position is maybe slightly off center
towards team aspect. That's very interesting, right?
Because, yeah, I mean, on paper we all think that we should
optimize more for teams and all that.
But in practice, I find many people stuck into the technology
part more, right. So I think that's why all these
topics about socio technical is always exciting at least for me,
right? How Actually organization,
structure and also architecture, they all should be jointly
optimised, right? I was thinking actually just
wanted to add a clarification for any listeners who might be
thinking, oh, if we just focus on the teams then we we might
have problems in the software and that's correct.
I wouldn't want to go too far the other way and say it's all
about the teams because then we start creating more legacy
software. We stop trying to create quality
software and that sometimes is a position that leadership takes
like you know someone at ACEO level who doesn't appreciate the
importance of investing in good quality practices, creating well
tested software that can be evolved and changed easily.
So whilst in tech we might be more to the tech side, yeah, on
the business they're more to the team side and they under invest
in the tech side. So you know, different groups
have different perspectives on that and I think that's why the
joint optimization is important, trying to get everyone aligned
on finding this balance between technical sweet spot and
organizational sweet spot. Yeah, thanks for adding that on.
Right. I think the term social
technical itself implies they are both, you know, it's like a
one thing, right? It's not like social only and
technical only. So I think thanks for adding
that. So interestingly in your book
you also start from the business point of view, right?
It's not the tech as the architecture and you know micro
services and things like that. They actually started from the
business point of view and you say that RE architecture or the
architecture modernization should actually gives the
business the competitive advantage so to speak, right.
And you start by having this building block of modern
architecture starting with independent value stream.
So tell us more what do you mean by this and maybe we can dive
deep a little bit more on this independent value stream.
Cool. So the concept of independent
value streams, so basically a value stream is a pipeline of
work. It's a very simple concept
actually. I think everybody works in a
value stream. It's the sequence of activities
you go through to identify new features you want to build, new
improvements to your product all the way to building it, testing
it and deploying it into production.
So I don't think value streams are anything new.
I think the reason I talk about value streams as the building
blocks of architecture is that the concept of value stream
touches on it's aligned to a part of your business.
It has clear business objectives like contributes to product,
North Stars or Key KPIs. It's a boundary for a team.
So each value stream is owned by a team and the team should be
able to deploy the software for their value stream independently
and do continuous delivery. So I think the value stream as
the basic concept is just a reminder to have that business,
organizational and software perspective.
It's like it's an abstraction that encompasses those things.
So if we're talking about a value stream, that implies I'm
thinking about the business side, the team side and the
software side. Yeah.
So I think there are 4 characteristics that you
mentioned in this independent value stream, right?
And I think let's start with the first one, which is domain
aligned, since you're also the experts in Domain Driven Design,
right? You said that we need to have a
well defined domain boundaries, right?
I think I assume when people think about value stream right,
they all think about okay. There's a requirements, an idea?
And you develop it, you test, you deploy and that's it, right?
That may be just limited to just one team, but I think when you
say domain aligned right, we also have to think from the
maybe high level business overview kind of thing.
Why do you think having this well defined domain boundaries
is so critical? And tell us also this concept
about change coupling, which I believe in many organizations
this might accidentally happen. Cool.
So yeah, those two points are very interrelated.
I can tell you've been reading the book well, so
congratulations, you've done a good job there in understanding
that and explaining it back to me.
So the first bit is the domain boundaries, and that can be
quite important. If you don't have good domain
boundaries, you'll end up with change coupling.
So maybe I can start with an example.
I worked in the UK government a few years ago and they had an
awesome platform for building micro services.
And you could spin up a new micro service in a couple of
hours, right? You could have it all the way to
production in a couple of hours almost.
There was a manual step that had to be signed off.
But basically in terms of technologies, it was a automated
process. You could deploy this thing to
production every day. And sometimes when it's so easy
to create a micro service, you're like, oh, we're building
a new feature, let's make a new micro service here.
We can have this separate piece of code for this new feature
we're working on and it'll be decoupled from all the other
stuff. Let's do that.
When you make architectural choices on that kind of gut
instincts, it might work in the short term.
But then as the system grows and you add more features, you get
to the point where to implement this next feature, we now have
to change four or five micro services.
And I was talking to a company recently.
You might not believe me, but they told me to implement one
kind of feature we have to touch 20 or maybe even more micro
services. And so the point of the main
boundaries is it's really business analysis, it's
analysing how your business works and thinking how do we
organise a business into these different areas so that when
we're implementing work, work happens in each area.
And the benefit of doing that is you can align your software with
those boundaries. And so the general idea is we
want to create that loosely coupled software and the domain
boundaries help us to think about how might we think about
our business in a loosely coupled way.
Should we have like a separate search and recommendations or
should it be all part of the same thing like on a business
level of those two things together or separate?
And then the concept of change coupling is kind of what I was
talking about before. If you have to change 20 micro
services to implement a new feature, that's a very high
level of change coupling. If those 20 micro services are
all owned by the same team, it might not be so bad.
But usually, change coupling is highly problematic when you're
changing different parts of the system and there's multiple
teams involved. So you know how it goes, right?
You've got a feature, you have other teams, you have to
implement some piece as well. So you need to have shared
meetings. You need to design the
architecture together. Which team will build which
piece? Before you can finish your
piece, another team has to finish their piece, but they
haven't finished their piece on time.
Why? Oh, they've got some other
priorities that they're working on, so they can't do what you
need them to do. So the Change Cup thing is all
of that stuff trying to avoid having to coordinate teams.
I think in a realistic setting we can't avoid that.
Otherwise every team would be just building their own
completely separate products. And it would be, you know, in a
modern context we build products that bring together lots of
different capabilities. So there always is some change
coupling. We just want to make the best
effort to minimize as much as possible and think explicitly
where are we happy to have some coupling and change coupling,
and where might we make an effort to avoid it?
Thanks for that. Great example, right.
So when you make one change 20 different micro services, you
know all must change at the same time and also worst right?
Where if it involves multiple team, you you have dependencies,
you have bottleneck, you have coordination and don't forget
also misunderstanding right? Like for example they all are
not aligned on what kind of things they need to deliver.
Also I like the point where you mentioned that we have to do a
business analysis, right? It's not like change coupling,
it's just like a technology analysis or software design
analysis right? It's actually a business
analysis. Which put us to the second
attribute which you'd mentioned that independent value stream
should have business outcome driven and you touch on about
North Star or the KPI tell us more why this business outcome
driven is so critical in this independent value stream.
So I think the business outcomes is important for a quite a few
reasons actually. I think on the first level,
understanding which business outcomes a value stream
supports, it's going to help you decide what level of
modernisation will be necessary here.
If a value stream is connected to your top business outcomes,
like I don't know, maybe your company's trying to increase
revenue by 10 million in the next year.
And to do that you need to get 10,000 more sign ups for
example. And this value stream is going
to be a feature that increases the number of sign ups.
Then you know, OK, this is a crucial value stream, putting a
lot of effort in here, keeping it decoupled, making sure the
team can innovate quickly, that's going to be super
important there. And so the outcome helps you to
decide what level of effort is going to be important.
And I think the outcomes are also important in terms of
allowing teams to make more decisions.
Like the old approach is you give developers some
requirements documents and they will turn that into the software
that they think you're asking for.
A more modern approach and this is one of the things I mean by
modernization is actually the team themselves deciding.
We know that 10,000 more signups is an important metric we're
trying to achieve. And it's up to the team
themselves to decide what will be some approaches that we can
use to achieve that. And that might involve the team
actually doing some user research, even the developers
talking to users. I know that might sound scary to
some people, but I've seen it working when I worked in the UK
government. We had that going on, and we had
junior developers in the team who would go to the user
research lab with the user researchers and get some
feedback directly from the citizens we're building the
software for. So I think the outcome approach
enables that enables the whole team to be more involved in
choosing what they're going to work on, what solution to build
rather than just how to implement it.
And I think if we look at the way tech's going, the way AI is
enabling more productivity, maybe that's going to be a trend
that goes even further because more of the software creation
is, I don't know, automated or the experience has improved.
People are more productive, will have to spend more time thinking
about better ideas to build rather than just how well we
build the software. Right.
So, yeah, it's very important I think to understand the business
outcome, right. And the North Star, the KPI
which you also just now discussed, it should be executed
by the team who are not just given a requirements to build,
right. They should be empowered, which
is the third characteristics in this independent value stream,
right. So they should have an
empowerment and they should be able to achieve the outcomes, so
they know the what, but the how. Maybe it's up to them to decide.
So a little bit more maybe on this concept of empowerment
because. I think this might be modern to
some software companies or software teams out there, right?
Yeah. So I think that continues where
we talked about before. I would say there's two aspects
to it empowered to decide what you want to build, and then
empowered to actually make changes and deploy your
software. So yeah, the example I was
talking about in the UK government, that kind of falls
under the umbrella of what people are calling continuous
discovery these days. Where as a team you're doing
your discovery together. User research, your developers,
your UX researchers, your product people.
Everyone's involved in learning about the customers problems and
deciding what should we build. Obviously that might not be
possible for every team. If you're building an internal
platform that other teams use, then it's not quite as possible.
But I I still do think it's good to understand if you're building
for an internal team, what are they trying to achieve.
And yeah, so I think having empowerment to define your own
road map is important. Right.
And the last attribute that you mentioned is about software
alignment, right? So I assume this software
aligning with your domains, right, which some people also
touch on. You know the concept about
Conway's Law. So tell us more why this is
important, software alignment and the value stream concept,
right, and why sometimes people do get this wrong.
I think it's important because companies usually want to go
faster, right? They're always looking for ways
to how can we improve our product faster?
We talk about legacy systems slowing us down or we'd like to
deliver this new feature this month, but the legacy's hard to
work with, so we're going to have to deliver it next month or
the month after. So yeah, what people want most
of the time is they want to build a better product, but they
want to build it faster. And so for a team to be able to
do continuous delivery, they need to be able to take a piece
of work, take a requirement from their backlog, implement it in
the software, and then deploy that software.
If a team owns the software and has the means to deploy it
themselves, then you've removed all the dependencies from the
process and therefore the things that can slow A-Team down.
So if you've read the book Accelerate, they talk about one
of the metrics, which is I think it's the lead time.
Yeah, lead time for changes. Basically, where how long does
it take from committing some codes to your branch to it being
in production? And if a team owns every step of
that, then there's nothing to slow them down if they have to
talk to another team, or if you want to deploy your software.
But another team's working in the same code base and you have
to get their permission. And they might say, oh, we we
want to deploy as well, but we haven't quite finished the
feature yet, so let's deploy next week instead.
All those things can slow you down.
So the 4th attribute is really can a team make changes and
deploy those changes as quickly as possible without any
dependencies or blockers? Right.
And if we come back to the business outcome thing, right,
the team, every time they release software, they increment
the value to the value stream, right, which I think ultimately
would improve the business outcomes as well.
So I find this a concept independent value stream really
powerful. So I think this will be the key
chapter for me when I read your book, right.
So I think architects, sometimes they focus a lot on technologies
only or the new cool platform of cloud that we want to adopt.
But I think this independent value stream concept and the
four key attributes are really, really important to get this
modernization right. So let's assume that we
understand all this and we want to start the journey, right.
I think that's always the challenge and the challenge you
mentioned a couple of times, right, business company wants to
move fast but they have legacy then the tech will say yeah we
need time to refactor and re architect oh sorry, we don't
have the time, we don't have the funding.
So maybe the first question is how to get the buy in right?
How to get the buy in? Yeah, always a difficult one.
Well, not always. I guess the easiest approach is.
You just keep waiting and waiting, let the software get
worse and worse until the whole business is complaining that
everything's taking so long and you're like, there's nothing we
can do about this apart from rewriting the system.
So that's how a lot of these situations happen.
Until the pain is so bad, nobody's really willing to
invest in it, unfortunately. But that doesn't mean we should
just accept that. If we believe that modernizing
the system can bring some business value, then I think
it's important that we try and articulate those benefits.
And there's there's a few strategies there, right?
I think understanding what the business is trying to achieve is
the first step because then you can try and turn it into a
proposal. If you invest in this, then
you'll get these business benefits out of it.
At the moment we're delivering one new feature a month.
If you invest in this modernisation, we can deliver 5
new features a month for example.
Something along those lines, obviously more tailored to your
organization specifics. And I think really what makes
the most difference is actually proving it.
So I'm always encouraging people just to try and start small
somewhere. If you can actually demonstrate
an example of modernising a small part of your system and
getting some value from that. And it's much easier to say
we've done it once. If you give us more funding, we
can do more of this in other parts of the system that you're
looking to improve. So if you can do it that way, I
think that's always nice. You can demonstrate with
progress. But obviously in in larger
companies when the legacy's been built up over decades, it's not
always possible to do that. And yeah, in those experiences.
My experience has been mostly, yeah, things get really bad.
The CTO gets fired, a new CTO comes in, and that CTO has got
like a year to start delivering some changes.
Improve modernisation is going to work.
I think it can, It can work in other ways.
When I worked at Salesforce, for example, I think one of the
things that really triggered Salesforce like the the global
CTO of the whole Salesforce. So you know, he's overseeing
like thousands of engineers across the world.
I think he read Sam Newman's micro services book.
And he was like, yeah, we should be doing this stuff.
So things like that, I'm a bit, sometimes these buzzwords can
lead us in the wrong direction. We can do micro services for the
wrong reason. But sometimes it's actually a
buzzword that can get people excited.
And you can use that to start explaining, Oh yeah, these micro
services things are actually pretty good.
If we invested in those, we could get some of those benefits
Sam's talking about in the book. In the last couple of years
we've also seen teams apologies. And teams, apologies has a lot
of great ideas in there on the organizational side, touch and
architecture too. And I think a lot of companies
have decided, yeah, we'd like to apply that in our company.
I think it's reached like the CEO level, the senior leadership
level. So sometimes those buzzwords can
help you to get ideas across. Obviously, there's some definite
risks in that approach. People might be expecting a
quick silver bullet. Oh, if we just build a couple of
micro services in a few weeks or if we just rename all our teams
to streamline teams, we're going to get some benefits.
So the buzzword solution, the buzzword approach definitely has
its risks. But in terms of getting that
initial spark and excitement, helping people to see that?
The industry has moved on. There are different ways of
doing this. I think that can help you to get
started and then as a leader you've got to try and keep
people excited but also be realistic about what's possible.
Yeah, I find this buzzword driven.
Whatever, right? It's also very dangerous, right?
People tend to just see on the paper, oh, this looks good.
This is how the things get implemented, right?
But they don't understand the rationale, the principles,
right? Which I think what I find to get
by also I think we may need to educate those leaders who really
understand the concept, just like for example, independent
value stream just now. I think it's really, really
crucial, right, So that they don't just see it as fixing the
legacy and moving it to a new architecture.
And the other thing that you mentioned in your book is that
you really advocate a lot about you know, collaborative
architecture practices and not making it as an IT silos.
Why do you think this is important?
How we can do it, you know, more collaboratively before starting
this modernization journey. Yeah, it's very easy to wave
your arms and say collaborate more, right?
Oh yeah, If we just collaborate, everything will be great.
So I'm very careful not to say that.
I think if you just get a bunch of people together, throw them
in A room without a clear purpose.
It's probably not going to work out too well.
So I think collaboration with specific purpose using specific
techniques can be very effective.
And one of the techniques I use a lot is event storming.
Event storming is a way to either map out the current state
of your business or the future state of your business.
And actually this goes back to the previous point about getting
buy in. So I was working with a company.
A new CTO came in. He'd heard about domain during
design. And he was facing a situation
where the the company had like some silos like quite a top down
approach. Product was over here,
developers were over here, things in the company 1
operating as well as people would like to.
So people recognize there was a problem.
So with event storming we got people together and this is
quite a common pattern I do in my work.
We got people together and we mapped out their process, how
their business works. With Event Storming, you can
invite anyone to the workshop. So we had products, developers,
sales, marketing, customer support, mapping out their
processes together along the wall.
And then as a result of that you just learn a lot of things like,
oh, the sales team have a process with 180 steps involving
multiple spreadsheets and people just had no idea that was going
on in the company. The sales teams were like, we
just got to get our job done as best as we can.
We didn't realise IT could help us with this problem.
So the collaborative approach is like that.
They serve a few different purposes.
The the first one is the knowledge.
You just understand more about your company and more about what
different teams are working on, more about different departments
and you might realise, oh, we could modernise that old legacy
system. But actually if we can get that
process down from 180 steps and three spreadsheets to like 20
steps and no spreadsheets, the software solution will be much
simpler. We don't need to modernise all
that, we can just simplify the whole thing, remove loads of
complexity. So it encourages those kind of
learnings and the example I wanted to talk about was a
recent one, a recent example of this where we talked about
getting BIND for modernisation. We did one of these workshops
and one of the groups mapped out their whole one of their whole
processes along probably 10 metres of wall space.
And with the event storm they had split it up into these
different possible domains and subdomains, and these had been
defined together by the whole group collaboratively.
And that was a spot for the company.
I think the CEO was Pop coming into the workshops and having a
look. The COO was there, the CTO was
there and they were all like, yeah, we've we've not really
done this before. This is quite impressive to see,
this amount of knowledge, these amount of insights, things that
people had no idea what's happening, solutions that can
solve problems we've had for months or years that no one
realized were possible because they weren't talking.
And that can be one of those catalysts, one of those sparking
moments where people realise, yeah, there's a lot of value
here, if we do more of this, we can solve some of our problems
more effectively. Yeah.
So I find some collaborative session that I attended also
brought the same experience, right?
Oh, we didn't know such things exist or we didn't know that
actually there are so many, you know, inefficiencies or waiting
time in bottlenecks, right. So sometimes this all could
appear as well. So I think maybe using some of
the well known techniques like event storming or even like
value stream mapping itself is also quite common in some of the
you know teams that I work with and the other one quite recently
popular is called the wordly mapping.
So maybe if you can give a little bit of a gist.
I know the concept itself maybe will take some time to explain,
but maybe if you can give us a gist what is wordly mapping and
how it is beneficial for us to learn about.
Yeah, I think wardly mapping. I did a talk recently about
modernisation at the conference in Copenhagen and I said I think
wardly mapping is one of the most important techniques
touches on what we spoke about earlier around prioritisation,
what level of effort? So the idea with the wardly map
is you start with your customers and you figure out what user
needs do they have, what problems is our product solving?
So it might be. We build an app where people can
sell their old items, maybe like an eBay kind of thing, and then
you map out the capabilities your company needs to enable
that. So you need a marketplace where
people can sell the products. You need the capability to ship
a product. You need to be able to do
payments like all the services in your system and how they fit
together. So that's the first part.
And once you've done that, what you then have to do is decide
which stage of evolution does each of these components fit in.
So evolution begins with Genesis.
So evolution represents how advanced is a concept in terms
of its life cycle. So if something's in Genesis
that represents a completely new concept or idea is just coming
out in the world, for example, like imagine when the iPhones
came out for the first time and it was a whole brand new thing.
People hadn't seen it before. Like, wow, that's amazing.
This is on the left of a worldly map.
As things become mature and standardized, they end up as a
commodity. A commodity is something that
people just take for granted. It's the same for every company.
If you want to stream something on Netflix or Amazon Prime, a
lot of the UI looks the same, right?
You search what you're looking for, it's become very
standardized. We just expect it to work in a
certain way. And so with a wordly map, you
map each of the parts of your system into these different
stages of evolution. And that helps you to identify
how important is it. So if something's a commodity,
you know that we can't really improve that as a company
because there's nothing else to improve here.
We can't add any new improvements there.
So the main objective there is how can we continue to provide
that for the lowest possible costs?
Maybe if we can put like 2 developers on that just to keep
it running, that will be enough. We don't need a team of 10
people on it continuously adding new features because the
customers just won't value that in any way.
And on the other side, when you get more towards just coming out
of Genesis into the second stage, custom built, that's a
phase where your idea is starting to become accepted.
You start to see that this concept.
Does have value and there's a lot of potential to
differentiate. So that's where you want to put
a lot of your time and effort, being able to innovate quickly,
adding new features in that part of your system.
So the Wardley mapping can help you to have those conversations
on a business and technical level, what's the business
importance of each component? And then you can start making
architecture and modernisation decisions based on that.
But there's one key detail I haven't talked about yet, which
is everything's evolving. So when you build a Wardy map,
you need to ask questions like how quickly do we think that
this component will move from left to right across the Wardy
map. You might say, for example, oh,
this component here, it's only halfway across the Wardley map.
Therefore, it's still quite a new idea.
There's still chance to add new features and improve this and
differentiate ourselves as a company.
So you might think, well, that must be a really important thing
to focus on. But someone else in the group
might say, actually we think that in just one year from now
this will be all the way across the commodity because all of our
competitors are building the exact same thing.
So you know, actually in one year from now it will be a
commodity. So this isn't a long term thing
we focus on. We just need to invest in this
for one year and then it will move into kind of like a
maintenance mode where we just keep maybe adding small tweaks
and bug fixes and improvements. So yeah, to summarize, the wall
lead map helps you to understand how evolved your components are
in terms of your industry, how much opportunity there is to get
a business value from each of those components.
And then with that knowledge you can actually make your
architecture decisions based on the business value.
You can do that collaboratively and it's a great way again to
get that buy in because if your business leaders are saying this
is where we focus, this is going to be our custom built product
phase for the next five years, then you can say well.
Seems like we need some modernization in that area then
to be able to go at the speed that you're looking for there.
Right, I hope people here could follow your explanation right.
I think wordly mapping is always like for me whenever I read it.
It takes a couple of iterations to actually fully get it and
especially if you haven't done it before right?
Maybe doing it with someone who has experience with it.
Be much better. And I have also two other
episodes which touch on worldly mapping a little bit, Suzanne
Kaiser, she talks about worldly mapping, domain driven design
and team topologies all in one goal which is a little bit
overwhelming at times and also Dave Anderson as well.
So I think this worldly mapping seems to be appearing more and
more frequently. I would suggest listeners to
have a look and understand how it is going to be beneficial,
maybe not just for your modernization, but also to
actually understand your business landscape and
competitive advantage that you have, right.
So the other thing is about product taxonomy.
So you mentioned in the modernization preparation,
right? You need to come up with product
taxonomy. So this is a very interesting
term for me. Maybe if you can explain a
little bit what do you mean by coming up with product taxonomy.
Yeah, so basically the idea of a product taxonomy is a way to
view your overall architecture. Like how do you describe your
overall system? If people are familiar with
business capability maps, it's that kind of idea.
It's the overall view of your system and all the capabilities
and how they fit together. And the example I use in the
book here is a product taxonomy. I'm not saying you should
definitely use that, but in my experience that's a useful
format because it's focused on business outcomes.
So you can look at this as a company and say what are our
different products and which value streams are part of each
product and which value streams are part of platforms that are
supporting multiple products. So I think the important thing
here is it's not that different to other types of diagrams.
I think I just like to have a product focus because the
product represents the interaction with the customer.
The product represents, here's what customers are paying for.
So I find it really useful to be able to look at an architecture
and see it from that perspective.
When I look at a certain part of the system, I'd like to know,
yeah, what product is that supporting exactly and what
customers are getting value from that.
So that's. Kind of framing I find really
useful. Yeah.
And if I understand correctly you, you don't just refer to
like tangible products, right? But this could also mean like
internal, you know, services or platforms at least you identify
who are the customers of that product, right?
It could be internal, external. And I think when I read that
chapter right, I think in the sense right, Because if you
don't have this well defined, again coming back to the well
defined boundaries, right? Which also means the well
defined services and all that. I think it's gonna be difficult
to really identify and focus your effort.
So let's imagine that we have done all this, all the
preparation and we need to execute.
Now it's time to execute. You mentioned this thing called
architecture modernization enabling team.
So tell us more about this right.
What is this team? Is it like a special SWAT team,
you know, coming up and doing all this RE architecture stuff
or or like what does it mean actually this MF thing, yeah,
it's a special SWOT team. They go around the company and
if anyone's not trying hard enough then those people
disappear. So basically the idea of an
architect modernisation enabling team, it builds on the idea of
enabling teams from teams. Apologies, but the purpose of
these teams is, I would say if I start from the problem and then
talk about the team, the problem that I see is it's not easy to
go from. We're building features in a
monolithic system to hey, we're modernising everything, let's go
like that. Mindset shift is huge, right?
I've been in companies where the leaders are wanting to
modernise, but the developers have been working legacy systems
for so long that you know, it's just a complete, complete
mindset shift. So for reasons like that,
getting started with modernisation can be difficult.
Transitioning from just working normally to OK Now my job is to
think about how can we improve every part of the system and how
we work. So the purpose of an enabling
team is to support that process. In a modern architecture, as I
talked about, we want to have teams that are more empowered,
want to have teams that are practising continuous delivery.
So the goal of an AMAT is to help the teams to get to that
level. It's to identify what problems
are the teams facing. Maybe they're not sure where to
get started, or maybe they've heard about Domain Driven Design
and they're getting confused by all these jargon words like
ubiquitous language and bounded context.
Or maybe it can be things like, yeah, the leadership team has
given teams some space to modernise, but now they're
starting to ask them to deliver features again and teams don't
have time to modernise. So the I think the AIM At's job
is to try and keep things on the right track, to identify what
support do people need, what problems are popping up, and to
keep things moving. It's not intended to be like a
team that makes decisions. It's not like the old approaches
where the architects would design the system and the teams
go build it. But there is some of that I
would say when an organization is immature at the start of a
journey, maybe the Aimet will make some decisions and maybe
the Aimet will steer things in the right direction.
But a good aim at people working in, an aim at, I think they need
to realise, you know, when do I step forward, when do I step
back, when do I try and help A-Team and when do I step in and
say this team's not working, we need to change something, you
know, It's finding that balance very difficult, very skillfully
I would say. But yeah, the goal is mostly to
support teams and to keep the modernisation journey moving in
the right direction. So if I may ask further, who
should comprise this team, right?
Because let's say, imagine I'm sure many, many companies have
this legacy right monolith database, monolith service or
whatever that is. Like, how would this Amap come
in and try to decide, OK, maybe we should split this boundaries.
You know, this thing, does it also involve business in the
Amap team? Like maybe a little bit more
about this Amap? Yeah, definitely.
But the composition of the team can vary according to your
organization's unique challenges, and also different
people can be more involved and less involved in the team.
You might have a core aim at, an extended aim at some people who
are doing this full time every day, and some people who come in
and out as needed. So the pattern isn't intended to
be something extremely prescriptive.
There is some flexibility there. I would say with a modernisation
journey, as we talked about before, there's a lot of
decisions that will have a business impact for example.
And so having some product people in there where you can
make some joint decisions, for example, the company wants to
build a new feature, it's a significant piece of work.
Should we build it in the old monolith to get it to market as
quickly as possible or should we build it in the new system that
we're still figuring out and it might take longer.
So having those different perspectives in there can be
important. I think going back to your point
about, yeah, how do we take this old system and split it up into
boundaries. I think one thing the AMEC can
definitely do there is to organise sessions like event
storming for example. Let's map out the business,
think about how we'd split the business up and then we can
start thinking about how we might align the boundaries in
the software to that. But what you touch on there is
actually something much more significant in terms of, yeah,
who makes the decision. So I think an Amet should be
skilled in architecture. An amet does need to have strong
architecture skills. The Amet wants to help the
group, but an amet person needs to know, is this group going in
the wrong direction here? Do I need to step in here and
say actually you're proposing we make that a micro service, but
we're quite for various reasons that won't work.
It's not a good approach. So stepping in and actually
either guiding the group in the right direction or making a
decision is sometimes necessary. That's what I was talking about
before. So I would say that someone like
an architect who works in the Amet.
I would say the dream skill set is someone who's super awesome
at architecture, but he's actually really skilled at
coaching and working with people as well.
He's doing both of those things. Not easy to find.
Not everyone's going to be perfect at both of those things.
So if you can find the right balance in the team, maybe some
people who are more technically good, some people who are more
good at coaching, you can balance it out by having
different voices in the group. And I think the other point is
connected to that is if you're going to work in an Amex, I
think you need to be committed to trying to improve yourself in
both of those areas. Like, yeah, you might have been
the the genius architect who makes all the decisions.
You can still work in an A map if you really try hard to
improve your facilitation and coaching skills.
Like just because you aren't good at those things now doesn't
mean you can't achieve those things.
So yeah. Thanks for the pluck of adding
this coaching communication skill, you know, so like
stakeholder management influencing, right?
I find it's very. Difficult probably to find this
person, but yeah, like you mentioned, right.
Don't just give up. Maybe you can put a few people
together, some maybe strong at architecture, some might be more
on this communication collaboration.
But the concept is also is an enabling team, right from team
topologists. It's not like a central
architecture team who makes decision and you know just
execute, right. So I think that's also really
powerful concept. The other thing I would like to
ask modernization, I mean if you're lucky, right, it takes
maybe a year, but most of the time it may take more than.
A year, right? And also depending on complexity
and how old the legacy is or for example, your business has grown
so much and you have to modernize certain aspects of the
technology so that it scales with the new demand and things
like that. So we need probably to build a
road map and plan. Any tips, maybe from your
consulting experience as well, How can people start building
Rd. maps? Any gotchas that we need to
think about? Yeah, I mean, Rd.
Maps is always hard, right? A road map is a prediction about
how you think the future is going to work out.
And we know that the future never works out as we planned
to. But on the other hand, we can't
just say, well, we can't predict the future, so let's not have a
road map. That's not possible either,
because how do people know that they're moving in the right
direction? How does someone know that in a
few months from now, some other teams are going to be depending
on the work we're doing? So some level of planning is
important. It will vary according to the
context, so I think identifying dependencies is important and
making sure those things are defined well on the road map.
I think going out and talking to teams and understanding what
challenges they have and when they might be ready to modernise
is important. I think delivery soon is
important, like you don't need to have a full road map before
you start delivering stuff. I think you know you want to be
delivering as soon as possible, really getting the feedback,
feeding that back into your plans.
And I think a modern modernization isn't something
that's normally defined centrally.
So when I worked at Salesforce for example, there was the
concept of like playbooks, basically different teams could
modernize when they wanted to. It was up to the teams to decide
when do we modernize, how much modernization work do we do this
month or next month. And the, the playbooks can say
if you're modernizing something from the old COBOL system to a a
Java API on AWS, here's the playbook you can follow.
So then you can do it yourself. You know, you might want to do
it this quarter, next quarter. It's up to your team when you do
that. But you you might also have some
specific objectives. You might say we want all teams
to have achieved this first step or modernise certain things by a
certain, by one year for example.
And so you might have, yeah, you might need to check that and
check in with the teams. And that's something that an
Amit can help with. Like, hey, I see that this team
hasn't started modernising yet. What's stopping you?
What help do you need? Maybe they're just a bit scared
because they've got some complex legacy.
So yeah, to summarise, I think there probably isn't going to be
one huge road map that describes everything.
I mean, you know, if you want the easy answer, the easy answer
is you design your target architecture, your entire target
architecture, You decide how we're going to migrate each
piece from the current to the future and you put all of those
in order of importance on a road map like that's the old
waterfall approach. It's a simple solution, but it
doesn't really work in practice. So I think firstly having an
understanding of what does each team need, there might be as
well parts of the current system that will require an
organization restructure. So I think there's different
levels here. So it's Salesforce for example,
you had like a team, a group of teams, a group of group of teams
and then you can have different decision making at different
levels. The key thing I wanted to get
across is depending on the size of your organization, you might
have Rd. maps at different. Levels.
So if you're if you're CTO who's got 10,000 engineers working for
you. You might have a very high level
road map where you just say I'd like to see this amount of
progress by these points or I'd like to see us off this old
infrastructure by this certain dates and then that cascades
down to the next level perhaps you're.
CT OS in each business area or your VPS of engineering, and
they might have their own more detailed road map for how their
teams in that area will achieve those objectives.
So I think the concept of pushing decisions down is
something I've seen in larger companies and would recommend.
Right. And especially if the
organization is really large, right?
Sometimes there's this inner share, right?
People just falls into the habit or maybe they have features to
deliver, right? They are just overwhelmed.
And also don't forget the risk right?
If you wanna refactor, especially to align with the
domain boundaries, sometimes you really need to refactor the
workflow itself. Sometimes you know, like one
atomic transaction could be multiple and that creates a lot
of risk and complexity and data migration, things like that.
So I don't think many people fancy that.
And yeah, having it driven from the top probably is also one
alternative that people should think about.
And yeah, like you said, deliver value early, don't wait until
one year and wait for the result, right.
Sometimes there could be surprises that it didn't work as
what you planned. So, Nick, thank you so much for
this conversation. I really encourage people to
read the book, especially if they want to go and buck the
journey of architecture modernization.
I have one last question for you, which I call the three
technical leadership wisdom. You can think of it like advice
that you want to give to the listeners here.
So maybe if you can share some for us.
Yeah, sure. I think the first thing I would
like to suggest is using techniques like event storming.
If you're making software decisions of any kind, really,
just having the domain experts knowledge, having more domain
knowledge about the domain you're working in, having
different perspectives from the people you work with in the
company, it's so useful get so much value from these.
I see people getting so much value from these sessions.
So I think trying out things like event storming if you
haven't done it. I would really recommend it.
I think the second one will probably be around the concept
of enabling teams and facilitation.
I think those aren't maybe used enough.
So yeah, think about the challenges you're facing, if not
related to architecture modernisation, then what else
might it be and how could you form an enabling team to try and
help the idea to get some traction?
Keep moving it forward, Yeah, so enabling teams are quite useful
concepts. And the third one.
The third one I would probably say is another one of those arm
waving things like collaboration.
But I would say trust is one of the biggest differentiators of
people who get success and people who don't.
So some companies I work with as a very disconnect, very big
disconnect between on the tech side and the business side.
Tech people have a lot of legacy.
They've got a lot of problems in the code level and they're
struggling. They have to improve it because
it's just so difficult to work with.
But then when you talk to the business leaders, they just
think all the tech people are geeks who want to use the latest
technologies. So I think as a technical
leader, if you can build trust with business leaders, if you
can go to a business leader and say we should stop building
features for three months and that will make us put in a much
healthier position for the long term.
If you can say that to like ACEO or senior business leader and
they think to themselves. I trust this person.
I don't understand anything about micro services, but I know
that this person is trustworthy, so I'm going to support this
decision. I think that's the key.
I think being able to convey ideas in business language and
have conversations with business stakeholders very often.
That's the differentiator. You could have two architects
proposing the same ideas saying the exact same words.
One might get accepted and one might get rejected simply
because you was a person. Aren't trusted.
You don't have as much credibility in the company.
So I think, yeah, I think building that trust up and down
is, is a big differentiator. Wow.
So I think it's really important.
Yeah, trust is really, really important.
And coming back to our initial discussion about social,
technical right. So don't forget, trust is part
of the social. So when you embark organization,
you know the architecture, right?
Don't forget the social aspect as well.
So Nick, if people love this concept, they won't want to
learn more, maybe reach out to you.
Is there a place where they can find you online?
Yeah, I'm normally hanging out on LinkedIn these days, find
most of my conversations on that.
I'm also on Mastodon as well, limiting myself to two social
networks at the moment. So yeah, I'm always happy to
talk. About pineapple pizza and that
kind of stuff and maybe some modernisation sometimes.
Right. So I'll make sure to put that in
the show notes. Thank you so much for your time.
So for people who want to embark on architecture modernization,
again highly recommended to read this book.
So thanks again, Nick. Thank you as well.
It's been a great pleasure. Thank you for listening to this
episode and for staying right until the end.
If you highly enjoyed it, I would appreciate if you share it
with your friends and colleagues who you think would also benefit
from listening to this episode and if you're new to the
podcast. Make sure to subscribe and leave
me your valuable review and feedback.
It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page at techlitjournal dot dev website,
including the full transcript, interesting quotes, and links to
the resources mentioned from the conversation.
And lastly, make sure to subscribe to the show's mailing
list on techlitjournal dot dev to get notified for any future
episodes. Stay tuned for the next Techly
Journal episode, and until then, goodbye.