#153 - Architecture Modernization: Socio-Technical Alignment of Software, Strategy, and Structure - Nick Tune

[00:01:09] Episode Introduction

Henry Suryawirawan: Hey, everyone. You are listening to the Tech Lead 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 Tech Lead Journal’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 techleadjournal.dev/tip or becoming a patron at techleadjournal.dev/patron.

My guest for today’s episode is Nick Tune. 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 socio-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, empower 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 Wadley Mapping technique. Towards the end, Nick described the idea of Architecture Modernization Enabling Team and gave advice on creating an architecture modernization roadmap.

I hope you enjoy listening to this episode and learn 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 five star rating and review on Apple Podcasts 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.

[00:03:08] Introduction

Henry Suryawirawan: Hello guys, welcome back to another new episode of the Tech Lead Journal 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.

Nick Tune: Thank you. It’s so great to be here. Really appreciate it.

[00:03:31] Career Journey

Henry Suryawirawan: 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.

Nick Tune: 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’d 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-driven design was a real step up from that. So that was really exciting.

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 development. And once we took our ticket and finished that piece of work, we pressed one 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 modernizing 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 realized 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 realized, oh, if you’re going to be a software architect, you also have to think about how the team’s organized as well. You can’t just go changing the software and how that’s organized and expect the teams to all stay the same. I think after Salesforce, I fell into consulting. I’d been writing blog posts and talking at meetups 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.

Henry Suryawirawan: 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?

Nick Tune: Yeah, that’s a really good question, actually. I think I do have some advice. I think I do recognize, 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 way is 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.

Henry Suryawirawan: 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?

[00:09:51] Writing Architecture Modernization Book

Henry Suryawirawan: So I think your consulting role now exposed 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?

Nick Tune: So the problem I wanted to solve with that book was, “Oh, there’s a pandemic. I’m gonna 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 Millett 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, but I thought I wanted to show how these techniques are used in that process of improving how a company works and how that architecture is designed.

[00:11:18] Architecture Modernization

Henry Suryawirawan: So maybe if I can ask about 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 same 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.

Nick Tune: Yeah, sure. I think naming’s always the hardest part. So, you know, a name is two words and the book is like 400 pages. So trying to explain what these 400 pages represent in two words, it’s always difficult. But I think the first word Architecture captures that it’s more than just the software. This is a 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.

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 modernization 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.

[00:13:35] Socio-Technical Architecture

Henry Suryawirawan: 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 socio-technical architecture.” I think this socio-technical has been, you know, flying around these days. Um, and people realize actually how, how important it is. Maybe if we can add on here, what do you mean by socio-technical architecture in the context of the book that you are writing?

Nick Tune: 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-Driven 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 organize 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, 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… cause 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 were all sitting in the same office and you could move people around, you might say, well, we’ll actually, we’ll shape 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 centered towards the team aspect.

Henry Suryawirawan: 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 optimized, right?

Nick Tune: I was thinking actually just wanting to add a clarification for any listeners who might be thinking, Oh, if we just focus on the teams, then 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 a CEO 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.

Henry Suryawirawan: Yeah, thanks for adding that on, right? I think the term socio-technical itself implies they are both, you know, it’s like one thing, right? It’s not like social only and technical only. So I think thanks for adding that.

[00:17:47] Independent Value Stream

Henry Suryawirawan: 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, microservices 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?

Nick Tune: 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 products, 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 a line 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.

[00:19:32] Domain Aligned & Change Coupling

Henry Suryawirawan: Yeah. So I think there are four characteristics 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, you know, 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.

Nick Tune: 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 microservices and you could spin up a new microservice 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 an automated process. You could deploy this thing to production every day. And sometimes when it’s so easy to create a microservice, you’re like, oh, we’re building a new feature. Let’s make a new microservice here. We can have this separate piece of code for this new feature we’re working on, and it will 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 microservices. 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 microservices.

And so the point of domain boundaries is it’s really business analysis. It’s analyzing how your business works, and thinking how do we organize our business into these different areas so that when we’re implementing work, work happens in each area. And then 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, are 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 microservices to implement a new feature, that’s a very high level of change coupling. If those 20 microservices 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? Um, 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 coupling 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 product 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.

Henry Suryawirawan: Thanks for that great example, right? So when you make one change, 20 different microservices, you know, all must change at the same time. And also worst, right? If it involves multiple teams. You have dependencies, you have bottlenecks, 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.

[00:24:11] Business Outcome Driven

Henry Suryawirawan: 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 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.

Nick Tune: So I think the business outcome is important for quite a few reasons, actually. I think on the first level, understanding which business outcomes a value stream supports is going to help you decide what level of modernization 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 ten thousand more signups, for example. And this value stream is going to be a feature that increases the number of signups. Then you know, okay, 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 gonna be super important there. So the outcome helps you to decide what level of effort is gonna 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 are 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 ten thousand 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 were 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. We’ll have to spend more time thinking about better ideas to build rather than just how well we build the software.

[00:27:02] Owned by Empowered Teams

Henry Suryawirawan: 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 requirement to build, right? They should be empowered, which is the third characteristic 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?

Nick Tune: 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 customer’s 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 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 roadmap is important.

[00:28:34] Software Aligned

Henry Suryawirawan: 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.

Nick Tune: 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 is 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 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 fourth attribute is really can a team make changes and deploy those changes as quickly as possible without any dependencies or blockers.

Henry Suryawirawan: Right And then we come back 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 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 we focus a lot on technologies only or the new cool platform or cloud that we wanna adopt. But I think this independent value stream concept and the four key attributes are really, really important to get this modernization right?

[00:31:00] Getting Buy In

Henry Suryawirawan: So let’s assume that we understand all this and we wanna 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?

Nick Tune: 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 modernization, we can deliver five 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 modernizing 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 larger companies, when the legacy is being 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 and prove modernization 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 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 microservices book and he was like, yeah, we should be doing this stuff.

So things like that, I’m a bit taught sometimes these buzzwords can lead us in the wrong direction. We can do microservices 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 microservices 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 Team Topologies. Team Topologies has a lot of great ideas in there on the organizational side, touch on 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, 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 microservices in a few weeks, or if we just rename all our teams to stream aligned 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.

Henry Suryawirawan: 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 why I find to get buy in also I think we may need to educate those leaders to 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, you know, like fixing the legacy and moving it to a new architecture.

[00:35:28] Collaborative Modernization Journey

Henry Suryawirawan: 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?

Nick Tune: 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-Driven Design. And he was facing a situation where the company had like some silos, like quite a top down approach. Product was over here, developers were over here. Things in the company weren’t 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 product, 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 realize IT could help us with this problem.

So the collaborative approach is like that. They serve a few different purposes. The first one is the knowledge. You just understand more about your company, more about what different teams are working on, more about different departments. And you might realize, oh, we could modernize the 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 modernize all that. We can just simplify the whole thing, remove loads of complexity. So it encourages those kinds of learnings.

And the example I wanted to talk about was a recent one, a recent example of this, where we talked about getting buy in for modernization. We did one of these workshops. One of the groups mapped out their whole, one of their whole processes along probably 10 meters 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 spark for the company. I think the CEO popped 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 was 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 realize, yeah, there’s a lot of value here. If we do more of this, we can solve some of our problems more effectively.

[00:38:59] Wardley Mapping

Henry Suryawirawan: 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 and 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 Wardley 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 Wardley mapping and how it is beneficial for us to learn about.

Nick Tune: Yeah, I think Wardley mapping, I did a talk recently about modernization at a conference in Copenhagen. And I said, I think Wardlley mapping is one of the most important techniques. Touches on what we spoke about earlier around prioritization, what level of effort. So the idea with a Wardley 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 a 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 lifecycle. So if something’s in genesis that represents a completely new concept or idea that 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 Wardley 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 Wardley 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 two 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 modernization 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 Wardley map, you need to ask questions like, how quickly do we think that this component will move from left to right across the Wardley 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 a 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 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 Wardley 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 a speed that you’re looking for there.

Henry Suryawirawan: I hope people here could follow, you know, your explanation, right? I think Wardley mapping is always, uh, 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 would be much better. And I have also two other episodes which touch on Wardley mapping a little bit with. Susanne Kaiser, she talks about Wardley mapping, domain-driven design, and team topologies all in one go. Which is a little bit overwhelming at times. And also Dave Anderson as well. So I think this Wardley 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?

[00:45:06] Product Taxonomy

Henry Suryawirawan: 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?

Nick Tune: 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, yeah, 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 the kind of frame I find really useful.

Henry Suryawirawan: Yeah. And if I understand correctly, 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 it makes sense, 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 going to be difficult to really identify and focus your effort.

[00:47:13] Architecture Modernization Enabling Team

Henry Suryawirawan: 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, uh, coming up and doing all this re, uh, re architecture stuff? Or, or like, what does it mean actually, this AMET thing?

Nick Tune: Yeah, it’s a special SWAT 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 modernization enabling team, it builds on the idea of enabling teams from team topologies. 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 modernizing everything, let’s go. Like that mindset shift is huge, right?

I’ve been in companies where the leaders are wanting to modernize. 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 modernization can be difficult, transitioning from just working normally to, okay, 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. I want to have teams that are practicing continuous delivery. So the goal of an AMET 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 modernize, but now they’re starting to ask them to deliver features again. And teams don’t have time to modernize.

So I think the AMET’s job is to try and keep things on the right track to identify what support the 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 AMET will make some decisions and maybe the AMET will steer things in the right direction.

But a good AMET, people working in an AMET, I think they need to realize, 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 modernization journey moving in the right direction.

Henry Suryawirawan: 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 AMET come in and try to decide, okay, maybe we should split these boundaries, you know, this thing. Does it also involve business in the AMET team? Like maybe a little bit more about this AMET.

Nick Tune: Yeah, definitely. Um, 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 AMET, an extended AMET. 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 modernization 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 AMET can definitely do there, is to organize 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 a 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, if you’re proposing we make that a microservice, 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 skillset 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, it’s connected to that, is if you’re going to work in an AMET, I think you need to be committed to trying to improve yourself in both of those areas. Like, yeah, you might’ve been the genius architect who makes all the decisions. You can still work in an AMET 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.

Henry Suryawirawan: Thanks for the plug of adding this coaching, communication skill, and also 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 may be strong at architecture, some may be more on this communication, collaboration. But the concept is also it’s an enabling team, right, from team topologies. It’s not like a central architecture team who makes decisions and, you know, just execute, right? So I think that’s also a really powerful concept.

[00:53:51] Modernization Roadmap

Henry Suryawirawan: 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 roadmap and plan. Any tips, maybe from your consulting experience as well, how can people start building roadmaps? Any gotchas that we need to think about?

Nick Tune: Yeah, I mean, roadmap is always hard, right? A roadmap 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 roadmap, 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 roadmap.

I think going out and talking to teams and understanding what challenges they have and when they might be ready to modernize is important. I think delivery soon is important. Like you don’t need to have a full roadmap 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 playbooks can say, if you’re modernizing something from the old COBOL system to 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 might also have some specific objectives. You might say, we want all teams to have achieved this first step or modernize certain things by a certain, by one year, for example. So you might have, yeah, you might need to check that and check in with the teams. And that’s something that an AMET can help with, like, hey, I see that this team hasn’t started modernizing 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 summarize, I think there probably isn’t going to be one huge roadmap 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, then you put all of those in order of importance on a roadmap. 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 at 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 roadmaps at different levels. So if you’re, if you’re a CTO, who’s got 10,000 engineers working for you, you might have a very high level roadmap 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 date. And then that cascades down to the next level, perhaps your CTOs in each business area or your VPs of Engineering. And they might have their own more detailed roadmap for how their teams in that area will achieve those objectives. So I think the concept of pushing decisions down, it’s something I’ve seen in larger companies and would recommend.

Henry Suryawirawan: Right. And especially if the organization is really large, sometimes there’s this inertia, right. People just fall 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 want to 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.

[00:58:35] 3 Tech Lead Wisdom

Henry Suryawirawan: So Nick, thank you so much for this conversation. I really encourage people to read the book, especially if they want to go embark 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.

Nick Tune: 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. I 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 modernization, 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, um, it’s 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, there’s 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 longterm. If you can say that to like a CEO or a senior business leader and they think to themselves, I trust this person. I don’t understand anything about microservices, 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 a 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 as 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.

Henry Suryawirawan: Wow. So I think it’s really important, yeah. Trust is really really important. And coming back to our initial discussion about socio-technical, right? So don’t forget trust is part of the social. So when you embark organization, you know, re-architecture, right? Don’t forget the social aspect as well.

So Nick, if people love this concept, they want to learn more, maybe reach out to you. Is there a place where they can find you online?

Nick Tune: Yeah. I’m normally, uh, hanging out on LinkedIn these days. I 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, uh, talk about pineapple pizza and that kind of and maybe some modernization sometimes.

Henry Suryawirawan: 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.

Nick Tune: Thank you as well. It’s been a great pleasure.

– End –