1 00:00:00,040 --> 00:00:05,320 The first word, architecture, captures that it's more than 2 00:00:05,320 --> 00:00:08,880 just the software. This is modern architecture. 3 00:00:08,960 --> 00:00:12,080 Architecture is a phrase that touches on the software, the 4 00:00:12,080 --> 00:00:14,880 business side, and the team organization side. 5 00:00:15,400 --> 00:00:20,280 Modernization is a word that represents taking something that 6 00:00:20,320 --> 00:00:22,400 has some outdated thinking in it. 7 00:00:22,440 --> 00:00:25,360 It could be outdated technologies, it could be 8 00:00:25,360 --> 00:00:28,480 outdated ideas, and also the organizational side. 9 00:00:28,480 --> 00:00:32,000 So modernization doesn't just mean technologies. 10 00:00:36,760 --> 00:00:41,920 Hey everyone, my name is Henry Surya Virawan and you're 11 00:00:41,920 --> 00:00:45,480 listening to the Technically Journal podcast, the show where 12 00:00:45,480 --> 00:00:47,720 I'll be bringing you the greatest technical leaders. 13 00:00:48,120 --> 00:00:51,560 Practitioners and thought leaders in the industry to 14 00:00:51,560 --> 00:00:55,800 discuss about their journey, ideas and practices that we all 15 00:00:55,800 --> 00:00:59,320 can learn and apply to build a highly performing technical team 16 00:00:59,800 --> 00:01:02,000 and to make an impact in your personal work. 17 00:01:02,680 --> 00:01:11,160 So let's dive into our journal. Hey everyone, you're listening 18 00:01:11,160 --> 00:01:13,680 to the Technically Journal Podcast, the podcast where you 19 00:01:13,680 --> 00:01:15,920 can learn about technical leadership and excellence. 20 00:01:16,400 --> 00:01:18,920 From my conversations with great thought leaders in the tech 21 00:01:18,920 --> 00:01:22,400 industry, if you haven't, please subscribe on your favorite 22 00:01:22,400 --> 00:01:25,040 podcast app to get notified for future episodes. 23 00:01:25,400 --> 00:01:28,280 Also subscribe to Techlegional's various other contents on 24 00:01:28,280 --> 00:01:31,800 LinkedIn, Twitter, Instagram, YouTube, and Tiktok. 25 00:01:32,400 --> 00:01:35,240 And if you have been enjoying this podcast and its contents, 26 00:01:35,480 --> 00:01:39,080 support my work by either buying me a coffee at techlegional dot 27 00:01:39,080 --> 00:01:44,280 dev tip or becoming a patron at techlegional dot dev patron. 28 00:01:45,520 --> 00:01:47,760 My guest for today's episode is Nick Chun. 29 00:01:48,240 --> 00:01:51,840 Nick is a Principal consultant and the author of Architecture 30 00:01:51,840 --> 00:01:55,240 Modernization. In this episode, we discussed 31 00:01:55,320 --> 00:01:58,120 how organizations can successfully go through an 32 00:01:58,120 --> 00:01:59,880 architecture modernization journey. 33 00:02:00,400 --> 00:02:03,560 Nick began by defining architecture modernization and 34 00:02:03,560 --> 00:02:06,080 discussing the social technical aspects involved. 35 00:02:06,560 --> 00:02:09,840 He then introduced the concept of an independent value stream 36 00:02:10,000 --> 00:02:13,240 and its four key characteristics which are domain alignment, 37 00:02:13,680 --> 00:02:16,960 business outcome driven. Empowered Teams and Software 38 00:02:16,960 --> 00:02:20,160 alignment. Nick also shared tips on how to 39 00:02:20,160 --> 00:02:24,080 get buy in for a modernization journey, why it is beneficial to 40 00:02:24,080 --> 00:02:27,360 do it collaboratively, and explained in depth the wordly 41 00:02:27,360 --> 00:02:30,720 mapping technique. Towards the end, Nick described 42 00:02:30,720 --> 00:02:34,280 the idea of Architecture Modernization enabling team and 43 00:02:34,280 --> 00:02:37,600 gave advice on creating an architecture modernization road 44 00:02:37,600 --> 00:02:40,160 map. I hope you enjoy listening to 45 00:02:40,160 --> 00:02:43,640 this episode and learned several tips on how to do a successful 46 00:02:43,640 --> 00:02:46,840 architecture modernization. If you enjoy listening to this 47 00:02:46,840 --> 00:02:49,840 episode, please share it with your colleagues, your friends 48 00:02:49,840 --> 00:02:53,440 and communities and leave a 5 star rating and review on Apple 49 00:02:53,440 --> 00:02:57,080 Podcast and Spotify. Your small help will help me a 50 00:02:57,080 --> 00:03:00,440 lot in getting more people to discover and listen to this 51 00:03:00,440 --> 00:03:02,640 podcast and I really appreciate it. 52 00:03:03,120 --> 00:03:05,440 So let's now go to my conversation with Nick. 53 00:03:08,080 --> 00:03:09,480 Hello guys. Welcome back to another new 54 00:03:09,480 --> 00:03:11,280 episode of the Tech Regional Podcast. 55 00:03:11,280 --> 00:03:14,280 Today I have Nick tune here and we're going to talk about his 56 00:03:14,280 --> 00:03:16,720 new upcoming book, Architecture Modernization. 57 00:03:17,000 --> 00:03:20,160 So happy to have you here, Nick. I'm looking forward to talk all 58 00:03:20,160 --> 00:03:23,040 about modernization because I think many companies are 59 00:03:23,040 --> 00:03:26,000 struggling as well to deal with their legacy or improving their 60 00:03:26,000 --> 00:03:27,600 architecture. So welcome to the show. 61 00:03:28,360 --> 00:03:29,640 Thank you. So great to be here. 62 00:03:29,640 --> 00:03:32,560 Really appreciate it. Nick, I always love to ask my 63 00:03:32,560 --> 00:03:34,520 guests to first share about yourself, right? 64 00:03:34,520 --> 00:03:37,640 Maybe if you can tell us more a bit about your background, 65 00:03:37,640 --> 00:03:39,800 highlights, turning points that we all can learn from you. 66 00:03:40,680 --> 00:03:42,880 Yeah, sure. Happy to share some thoughts. 67 00:03:43,120 --> 00:03:47,520 Got my first job 15 years ago in IT working as a software 68 00:03:47,520 --> 00:03:50,280 developer. Very early in my career. 69 00:03:50,320 --> 00:03:54,240 I had some good mentors, mentors who were always passionate about 70 00:03:54,240 --> 00:03:57,880 learning new stuff, and they got me into Domain Driven Design 71 00:03:57,880 --> 00:04:00,520 quite early in my career. In like the first six months of 72 00:04:00,520 --> 00:04:03,640 my career, I've been exposed to Domain Driven Design and that 73 00:04:03,640 --> 00:04:05,840 was the first thing that I really got excited about. 74 00:04:05,840 --> 00:04:12,760 This idea of building software in a way that is as well suited 75 00:04:12,760 --> 00:04:14,720 to the business problem you're solving as possible. 76 00:04:15,160 --> 00:04:17,399 That was quite different from all the other stuff I'd learned 77 00:04:17,399 --> 00:04:22,200 before that you know, like object oriented, like duck 78 00:04:22,200 --> 00:04:24,880 extends, Bird, all that basic stuff. 79 00:04:24,880 --> 00:04:26,880 Domain during design was a real step up from that. 80 00:04:26,880 --> 00:04:29,720 So that was really exciting. And then a couple of years later 81 00:04:29,720 --> 00:04:32,760 I moved to London, got to work for a company doing continuous 82 00:04:32,760 --> 00:04:35,760 delivery and that was another magical moment for me. 83 00:04:35,840 --> 00:04:38,040 I deployed to production on my first day of working at the 84 00:04:38,040 --> 00:04:40,520 company. I worked with a senior engineer. 85 00:04:40,600 --> 00:04:42,960 We did some pair programming, we did some test driven 86 00:04:42,960 --> 00:04:46,000 developments and once we took our ticket and finished that 87 00:04:46,000 --> 00:04:49,320 piece of work, we pressed 1 button deployed to production. 88 00:04:49,880 --> 00:04:52,360 So those two things happened in the first couple of years of my 89 00:04:52,360 --> 00:04:54,320 career. So you know, great start, a lot 90 00:04:54,320 --> 00:04:58,480 of positive influences there And then I think those were the two 91 00:04:58,480 --> 00:05:00,840 things I looked for in the rest of my career. 92 00:05:01,000 --> 00:05:03,760 And probably the next turning point came when I worked at 93 00:05:04,080 --> 00:05:07,600 Salesforce I think. So I was hired by Salesforce, a 94 00:05:07,600 --> 00:05:11,440 team in London to help modernising some legacy systems 95 00:05:11,480 --> 00:05:14,520 and I'd written a book about Domain Driven Design with my 96 00:05:14,520 --> 00:05:17,360 friend Scott and they wanted someone with Domain Driven 97 00:05:17,360 --> 00:05:21,240 Design experience to help them. And what I realised the turning 98 00:05:21,240 --> 00:05:26,120 point was we could refactor the old legacy systems and reshape 99 00:05:26,120 --> 00:05:29,640 it to be more domain aligned. But however we shaped the 100 00:05:29,640 --> 00:05:33,960 software, there was always going to be multiple teams working in 101 00:05:33,960 --> 00:05:36,480 every code base. And I realised, oh if you're 102 00:05:36,480 --> 00:05:40,320 going to be a software architect you also have to think about how 103 00:05:40,320 --> 00:05:43,240 the teams organised as well. You can't just go changing the 104 00:05:43,240 --> 00:05:46,520 software and how that's organised and expect the teams 105 00:05:46,520 --> 00:05:50,560 to all stay the same. I can go after Salesforce. 106 00:05:50,560 --> 00:05:53,480 I fell into consulting, I've been writing blog posts and 107 00:05:53,480 --> 00:05:55,960 talking at meet ups and companies started contacting me 108 00:05:55,960 --> 00:05:58,320 directly. And that's where I'm currently 109 00:05:58,320 --> 00:06:03,920 at the moment as a consultant, mostly operating as a 110 00:06:03,920 --> 00:06:07,840 facilitator and advisor. I don't make a lot of decisions 111 00:06:07,840 --> 00:06:09,720 nowadays. My job is more to help other 112 00:06:09,720 --> 00:06:12,160 people make decisions. I quite enjoy that. 113 00:06:13,120 --> 00:06:15,600 This episode is brought to you by Miro. 114 00:06:16,040 --> 00:06:18,560 As you will hear in this episode later about architecture, 115 00:06:18,560 --> 00:06:21,920 modernization, collaborative discussion, event storming, 116 00:06:22,040 --> 00:06:25,320 worldly mapping and so on, to find a tool that can support 117 00:06:25,320 --> 00:06:29,000 doing those activities while also supporting collaboration 118 00:06:29,120 --> 00:06:31,800 and creating the necessary artifacts can be quite a 119 00:06:31,800 --> 00:06:34,480 challenge. One tool I find that allows us 120 00:06:34,480 --> 00:06:39,080 to do so effectively and in a fun way is Miro Miro. 121 00:06:39,760 --> 00:06:43,000 At a first glance, it might seem just like a simple digital 122 00:06:43,000 --> 00:06:45,320 whiteboard, but Miro's capabilities. 123 00:06:45,640 --> 00:06:48,920 Run far beyond that. It's a visual collaboration tool 124 00:06:48,920 --> 00:06:52,480 where the whole team can build on each other's ideas and create 125 00:06:52,480 --> 00:06:55,040 something innovative together from anywhere. 126 00:06:55,640 --> 00:06:58,480 Brainstorming and strategic planning becomes easier when 127 00:06:58,480 --> 00:07:02,480 it's visual and accessible, and it all can happen across teams 128 00:07:02,480 --> 00:07:06,680 in mirror you can quickly start collaborating within 90 seconds 129 00:07:06,680 --> 00:07:09,440 without having everyone registered as a mirror user 130 00:07:09,440 --> 00:07:12,080 before. There are also more than 300 131 00:07:12,080 --> 00:07:15,480 predefined templates you can use to kickstart your collaboration 132 00:07:15,480 --> 00:07:18,680 within seconds. So the next time you're looking 133 00:07:18,680 --> 00:07:22,040 for a digital tool to support your brainstorming, designing, 134 00:07:22,160 --> 00:07:25,080 planning, and online collaboration, do give Mirror a 135 00:07:25,080 --> 00:07:27,120 try. You can Sign up today at 136 00:07:27,120 --> 00:07:32,760 mirror.com Podcast miro.com Podcast and your first three 137 00:07:32,760 --> 00:07:35,760 mirror boards are free forever when you signed up Now. 138 00:07:36,400 --> 00:07:38,320 And now let's get back to our episode. 139 00:07:38,840 --> 00:07:41,240 Thanks for sharing your story. I think very, very interesting, 140 00:07:41,240 --> 00:07:43,520 right? Not many people got the chance 141 00:07:43,520 --> 00:07:46,840 to start their career being exposed to good practices, 142 00:07:46,840 --> 00:07:48,160 right? So from your side, you were 143 00:07:48,160 --> 00:07:51,560 exposed to TDD and continuous delivery, pair programming, XP 144 00:07:51,560 --> 00:07:53,320 stuffs and all that. I think that's really, really 145 00:07:53,320 --> 00:07:55,720 fantastic, right? For people who didn't have the 146 00:07:55,720 --> 00:07:58,720 luxury in their beginning of career to get exposed to all 147 00:07:58,720 --> 00:08:00,640 this. Maybe do you have some tips for 148 00:08:00,640 --> 00:08:03,200 them? How can they upskill themselves? 149 00:08:03,200 --> 00:08:05,920 Or you know, like do the best practices, even though maybe 150 00:08:05,920 --> 00:08:07,520 their environment doesn't support that. 151 00:08:08,360 --> 00:08:10,720 Yeah, that's a really good question actually. 152 00:08:10,840 --> 00:08:14,080 I think I do have some advice. I think I do recognise, like I 153 00:08:14,080 --> 00:08:17,000 was really lucky to have those positive influences. 154 00:08:17,360 --> 00:08:20,200 I did choose the companies I wanted to work for. 155 00:08:20,200 --> 00:08:23,640 I did see that they were doing good things and I tried to, I 156 00:08:23,640 --> 00:08:27,080 applied for those companies. But I was, it was mostly luck 157 00:08:27,360 --> 00:08:30,960 that I had those experiences. But what I would say, I think 158 00:08:30,960 --> 00:08:34,039 the thing that comes to my mind the most when you ask that 159 00:08:34,039 --> 00:08:38,039 question is, I would say for most people it's about believing 160 00:08:38,039 --> 00:08:43,520 that actually this can work. Like I was speaking to a company 161 00:08:43,520 --> 00:08:46,520 a couple of years ago about continuous delivery and they're 162 00:08:46,520 --> 00:08:50,360 like this stuff all sounds great, but have you ever seen 163 00:08:50,360 --> 00:08:54,640 any company really doing that? And I'm like, yes, in my second 164 00:08:54,640 --> 00:08:58,520 ever job we were doing that. So I'm not criticizing those 165 00:08:58,520 --> 00:09:00,360 people. I just think if you've been used 166 00:09:00,360 --> 00:09:04,800 to working a certain way, it seems to be very difficult to 167 00:09:04,800 --> 00:09:08,240 see like, oh a completely different ways possible. 168 00:09:08,240 --> 00:09:12,640 So I think my advice would be just challenge yourself to 169 00:09:12,640 --> 00:09:16,080 believe that something else is possible and it can work even if 170 00:09:16,080 --> 00:09:18,120 it doesn't work. And I think that's a good 171 00:09:18,120 --> 00:09:20,360 attitude in your career. I still have that now. 172 00:09:20,360 --> 00:09:24,040 I'm still like maybe one day DDD and continuous delivery will be 173 00:09:24,040 --> 00:09:26,760 the old thing and people will say why are you still doing that 174 00:09:26,760 --> 00:09:29,320 stuff? So I'm always worried that yeah, 175 00:09:29,720 --> 00:09:32,960 the way I'm currently seeing things might be obsolete at some 176 00:09:32,960 --> 00:09:36,680 point. Yeah, I think keep believing is 177 00:09:36,800 --> 00:09:39,120 definitely true and keep an open mind, right? 178 00:09:39,120 --> 00:09:41,800 Because sometimes we are used to the habits and maybe the 179 00:09:41,800 --> 00:09:44,520 cultural things in the organization and we kind of like 180 00:09:44,520 --> 00:09:47,080 shut down to other even though it's best practice from 181 00:09:47,080 --> 00:09:49,400 industry. But yeah, it just didn't work 182 00:09:49,400 --> 00:09:50,920 here. Maybe that kind of mentality, 183 00:09:50,920 --> 00:09:53,640 right? So I think your consulting role 184 00:09:53,640 --> 00:09:55,520 now expose you to many different, you know, 185 00:09:55,520 --> 00:09:58,640 organizations, maybe challenges and you wrote this book, 186 00:09:58,640 --> 00:10:01,640 Architecture Modernization. Before we dive deep into the 187 00:10:01,640 --> 00:10:04,440 topics of the book, I just want to understand what made you 188 00:10:04,440 --> 00:10:06,800 wrote this book, right. So is there any specific 189 00:10:06,800 --> 00:10:09,000 problems that you want to solve by writing this book? 190 00:10:09,680 --> 00:10:13,240 So the problem I wanted to solve with that book was, oh, there's 191 00:10:13,240 --> 00:10:15,880 a pandemic. I'm going to be stuck at home on 192 00:10:15,880 --> 00:10:18,080 my own. Let's write a book. 193 00:10:18,080 --> 00:10:21,680 So that was the first problem. It solved keeping me busy, but I 194 00:10:21,680 --> 00:10:26,760 think the reason I chose that book and those topics was so I 195 00:10:26,760 --> 00:10:29,520 wrote a book before with Scott Millet 10 years ago, and I 196 00:10:29,520 --> 00:10:32,600 always wanted to write another book, but I felt like I'm going 197 00:10:32,600 --> 00:10:34,440 to wait. I want to wait until I've got 198 00:10:34,440 --> 00:10:37,480 something useful to talk about enough experiences that would be 199 00:10:37,480 --> 00:10:40,440 different to the old book and useful in some way. 200 00:10:41,120 --> 00:10:43,880 So I just reflected on my work as a consultant. 201 00:10:44,240 --> 00:10:46,360 What is it I've been doing over the last years? 202 00:10:46,360 --> 00:10:49,600 And I think probably most people in tech will have many 203 00:10:49,600 --> 00:10:52,600 experiences like this where we've got like a legacy problem, 204 00:10:52,600 --> 00:10:54,920 right? Old systems get out of date. 205 00:10:55,440 --> 00:10:58,960 The longer things exist, the more problematic they become. 206 00:10:58,960 --> 00:11:01,080 Every company always wants to go faster. 207 00:11:01,600 --> 00:11:05,520 And so I thought I'd talk about the kind of work I do from that 208 00:11:05,520 --> 00:11:07,200 perspective. I could have written a book 209 00:11:07,200 --> 00:11:09,640 about Domain driven design and event storming. 210 00:11:10,160 --> 00:11:11,840 I thought. I wanted to show how these 211 00:11:11,840 --> 00:11:15,000 techniques are used in that process of improving how a 212 00:11:15,000 --> 00:11:18,120 company works and how their architecture is designed. 213 00:11:18,920 --> 00:11:21,680 So maybe if I can ask about the title itself, right? 214 00:11:21,720 --> 00:11:23,840 Why do you call it architecture modernization? 215 00:11:23,840 --> 00:11:26,240 What do you refer as architecture modernization? 216 00:11:26,240 --> 00:11:28,920 Because there are so many terms being used for maybe some kind 217 00:11:28,920 --> 00:11:31,680 of effect, right, maybe re architecture or software 218 00:11:31,680 --> 00:11:34,480 modernization or cloud modernization and things like 219 00:11:34,480 --> 00:11:35,800 that. Why specifically like 220 00:11:35,840 --> 00:11:38,360 architecture modernization, maybe if you can define that, 221 00:11:39,280 --> 00:11:40,920 yeah, sure. I think naming's always the 222 00:11:40,920 --> 00:11:44,560 hardest part. So you know, a name is 2 words 223 00:11:44,880 --> 00:11:48,880 and the book is like 400 pages. So trying to explain what these 224 00:11:48,880 --> 00:11:52,200 400 pages represent in two words is always difficult. 225 00:11:52,680 --> 00:11:57,760 But I think the first word, architecture, captures that. 226 00:11:57,800 --> 00:11:59,840 It's more than just the software. 227 00:11:59,840 --> 00:12:04,520 This is modern architecture, as I talked about before, those 228 00:12:04,520 --> 00:12:08,040 influences in my career around the domain focus. 229 00:12:08,440 --> 00:12:10,800 How do you shape a system aligned to the business domain? 230 00:12:11,320 --> 00:12:13,320 How do you enable an architecture? 231 00:12:13,440 --> 00:12:16,200 How do you design a system that enables continuous delivery? 232 00:12:16,360 --> 00:12:18,360 And that touches on the team aspect as well. 233 00:12:18,360 --> 00:12:21,000 So I thought architecture was the right description. 234 00:12:21,000 --> 00:12:23,080 That's the kind of terminology I use in my work. 235 00:12:23,480 --> 00:12:26,600 Architecture is a phrase that touches on the software, the 236 00:12:26,600 --> 00:12:29,400 business side and the team organization side. 237 00:12:29,880 --> 00:12:34,360 And I think modernization is a word that represents taking 238 00:12:34,360 --> 00:12:37,240 something that has some outdated thinking in it. 239 00:12:37,280 --> 00:12:40,200 It could be outdated technologies, it could be 240 00:12:40,200 --> 00:12:44,040 outdated ideas. So modernisation doesn't just 241 00:12:44,040 --> 00:12:47,840 mean technologies, it might be when we built this system, we 242 00:12:47,840 --> 00:12:49,920 built some abstractions into our system. 243 00:12:49,920 --> 00:12:53,680 Like an example from my book is a company called Vinted. 244 00:12:53,920 --> 00:12:57,160 It built like a platform and the platform was based on the idea 245 00:12:57,160 --> 00:13:00,720 of this company will be active in one vertical in one market. 246 00:13:01,280 --> 00:13:03,880 So the whole system had abstractions based on that idea. 247 00:13:04,360 --> 00:13:08,400 And then as the company grew and the business model evolved, now 248 00:13:08,400 --> 00:13:10,440 they were acting in multiple markets. 249 00:13:10,480 --> 00:13:12,680 And so that's also modernizing as well. 250 00:13:12,680 --> 00:13:15,640 It's modernizing old abstractions based on old 251 00:13:15,960 --> 00:13:18,520 business models. And also the organizational 252 00:13:18,520 --> 00:13:22,680 side, I think modern practices is something that people would 253 00:13:22,680 --> 00:13:24,960 recognize. So continuous delivery, for 254 00:13:24,960 --> 00:13:27,000 example, I would say that's a modern practice. 255 00:13:27,000 --> 00:13:30,680 So modernization would mean moving from approaches that 256 00:13:30,680 --> 00:13:33,480 don't support continuous delivery to approaches that do 257 00:13:33,480 --> 00:13:35,920 support continuous delivery. Right. 258 00:13:35,920 --> 00:13:38,200 This is what I find really unique about your book, because 259 00:13:38,360 --> 00:13:41,440 I'm sure many people would have assumed that architecture is 260 00:13:41,440 --> 00:13:44,800 just technology thing or maybe there's a new tools, new 261 00:13:44,960 --> 00:13:47,480 platforms, new whatever, right? And we just apply it. 262 00:13:47,800 --> 00:13:50,120 But I think in your book you cover a lot of things, not just 263 00:13:50,120 --> 00:13:52,800 technology, right? If I can maybe read one of the 264 00:13:52,800 --> 00:13:55,640 quote that I have here, modern architecture is more than just 265 00:13:55,640 --> 00:13:58,760 technology and patterns, it is a social technical architecture. 266 00:13:59,000 --> 00:14:01,280 I think this social technical has been, you know, flying 267 00:14:01,280 --> 00:14:04,120 around these days and people realize actually how how 268 00:14:04,120 --> 00:14:06,640 important it is. Maybe if you can add on here, 269 00:14:06,640 --> 00:14:08,720 what do you mean by social technical architecture in the 270 00:14:08,720 --> 00:14:10,680 context of the book that you are writing? 271 00:14:11,480 --> 00:14:14,120 Yeah, sure. So I guess the first point, I 272 00:14:14,120 --> 00:14:17,600 would just say the reason I wrote the book from that 273 00:14:17,600 --> 00:14:21,360 perspective is because I was known for domain during design. 274 00:14:21,360 --> 00:14:24,040 I would be contacted by companies who are saying things 275 00:14:24,040 --> 00:14:28,000 like we've started this cloud migration or cloud 276 00:14:28,000 --> 00:14:31,840 transformation and people have picked up the technologies, but 277 00:14:31,840 --> 00:14:35,080 they're struggling with domains and how to organise teams. 278 00:14:35,400 --> 00:14:37,960 And there doesn't seem to be much else out there on that 279 00:14:37,960 --> 00:14:40,040 topic. So I felt that's why I would 280 00:14:40,040 --> 00:14:43,080 focus on those things. Like I'm super excited about 281 00:14:43,080 --> 00:14:46,360 tech as well. I think modern technologies and 282 00:14:46,360 --> 00:14:47,880 they do enable you to move faster. 283 00:14:47,880 --> 00:14:50,880 So I think that is important. I'm not saying, you know, tech's 284 00:14:50,880 --> 00:14:53,760 just an implementation detail, don't worry, do all this DDD 285 00:14:53,760 --> 00:14:56,120 stuff. It's just I think tech has been 286 00:14:56,120 --> 00:14:58,920 covered well by other people. So I focus less on that in the 287 00:14:58,920 --> 00:15:00,400 book and more on the other stuff. 288 00:15:00,880 --> 00:15:05,200 And so I think Socio Technical is capturing both the importance 289 00:15:05,240 --> 00:15:08,720 of how do you, because when you architect a system, it will 290 00:15:08,720 --> 00:15:10,240 affect how the teams work, right? 291 00:15:10,240 --> 00:15:12,920 It will decide where the dependencies are in a system, 292 00:15:13,480 --> 00:15:15,600 and I think it's about that joint optimization. 293 00:15:16,000 --> 00:15:19,120 You might be able to create loosely coupled software, but 294 00:15:19,120 --> 00:15:23,440 you might have an organization structure that is determined by 295 00:15:23,440 --> 00:15:26,160 other factors, like could be geography. 296 00:15:26,160 --> 00:15:30,080 You might have one team in London and one team in Berlin, 297 00:15:30,080 --> 00:15:33,120 for example, and you might decide, well, we want to keep 298 00:15:33,120 --> 00:15:36,640 those teams together. So we'll compromise on the 299 00:15:36,640 --> 00:15:40,560 software so that the teams get to own parts of the software. 300 00:15:40,960 --> 00:15:43,320 Whereas if those teams are all sitting in the same office and 301 00:15:43,320 --> 00:15:45,960 you could move people around, you might say well we'll 302 00:15:45,960 --> 00:15:48,160 actually we'll shake the software in a different way. 303 00:15:48,520 --> 00:15:50,560 So I think it's just that joint optimization. 304 00:15:50,840 --> 00:15:55,720 One of the activities I do in my work is I have this like slider 305 00:15:56,160 --> 00:15:59,320 and I just ask people what's more important on this side. 306 00:15:59,320 --> 00:16:02,440 It's a well designed architecture and on this side 307 00:16:02,440 --> 00:16:05,920 it's teams that can work independently and are motivated. 308 00:16:06,360 --> 00:16:09,640 And most people actually say the team bit is more important than 309 00:16:09,640 --> 00:16:11,720 the architecture, but not all the way. 310 00:16:11,720 --> 00:16:15,760 It's like the average position is maybe slightly off center 311 00:16:15,760 --> 00:16:19,080 towards team aspect. That's very interesting, right? 312 00:16:19,080 --> 00:16:22,360 Because, yeah, I mean, on paper we all think that we should 313 00:16:22,360 --> 00:16:24,440 optimize more for teams and all that. 314 00:16:24,720 --> 00:16:28,280 But in practice, I find many people stuck into the technology 315 00:16:28,280 --> 00:16:30,760 part more, right. So I think that's why all these 316 00:16:30,760 --> 00:16:34,200 topics about socio technical is always exciting at least for me, 317 00:16:34,200 --> 00:16:35,840 right? How Actually organization, 318 00:16:35,840 --> 00:16:38,440 structure and also architecture, they all should be jointly 319 00:16:38,440 --> 00:16:41,080 optimised, right? I was thinking actually just 320 00:16:41,080 --> 00:16:43,520 wanted to add a clarification for any listeners who might be 321 00:16:43,520 --> 00:16:47,840 thinking, oh, if we just focus on the teams then we we might 322 00:16:47,840 --> 00:16:49,880 have problems in the software and that's correct. 323 00:16:49,880 --> 00:16:52,600 I wouldn't want to go too far the other way and say it's all 324 00:16:52,600 --> 00:16:55,680 about the teams because then we start creating more legacy 325 00:16:55,680 --> 00:16:58,480 software. We stop trying to create quality 326 00:16:58,480 --> 00:17:03,560 software and that sometimes is a position that leadership takes 327 00:17:03,560 --> 00:17:07,800 like you know someone at ACEO level who doesn't appreciate the 328 00:17:07,800 --> 00:17:11,800 importance of investing in good quality practices, creating well 329 00:17:11,800 --> 00:17:14,839 tested software that can be evolved and changed easily. 330 00:17:15,079 --> 00:17:18,359 So whilst in tech we might be more to the tech side, yeah, on 331 00:17:18,359 --> 00:17:22,040 the business they're more to the team side and they under invest 332 00:17:22,040 --> 00:17:24,280 in the tech side. So you know, different groups 333 00:17:24,280 --> 00:17:27,200 have different perspectives on that and I think that's why the 334 00:17:27,200 --> 00:17:30,800 joint optimization is important, trying to get everyone aligned 335 00:17:30,800 --> 00:17:34,680 on finding this balance between technical sweet spot and 336 00:17:34,680 --> 00:17:38,160 organizational sweet spot. Yeah, thanks for adding that on. 337 00:17:38,160 --> 00:17:39,240 Right. I think the term social 338 00:17:39,240 --> 00:17:42,920 technical itself implies they are both, you know, it's like a 339 00:17:42,920 --> 00:17:45,160 one thing, right? It's not like social only and 340 00:17:45,160 --> 00:17:47,200 technical only. So I think thanks for adding 341 00:17:47,200 --> 00:17:49,440 that. So interestingly in your book 342 00:17:49,440 --> 00:17:52,080 you also start from the business point of view, right? 343 00:17:52,080 --> 00:17:55,080 It's not the tech as the architecture and you know micro 344 00:17:55,080 --> 00:17:57,440 services and things like that. They actually started from the 345 00:17:57,440 --> 00:18:00,440 business point of view and you say that RE architecture or the 346 00:18:00,440 --> 00:18:03,240 architecture modernization should actually gives the 347 00:18:03,240 --> 00:18:06,160 business the competitive advantage so to speak, right. 348 00:18:06,520 --> 00:18:09,080 And you start by having this building block of modern 349 00:18:09,080 --> 00:18:11,920 architecture starting with independent value stream. 350 00:18:12,520 --> 00:18:15,760 So tell us more what do you mean by this and maybe we can dive 351 00:18:15,760 --> 00:18:18,280 deep a little bit more on this independent value stream. 352 00:18:19,000 --> 00:18:21,080 Cool. So the concept of independent 353 00:18:21,080 --> 00:18:26,080 value streams, so basically a value stream is a pipeline of 354 00:18:26,080 --> 00:18:28,120 work. It's a very simple concept 355 00:18:28,120 --> 00:18:30,200 actually. I think everybody works in a 356 00:18:30,200 --> 00:18:33,120 value stream. It's the sequence of activities 357 00:18:33,120 --> 00:18:36,960 you go through to identify new features you want to build, new 358 00:18:36,960 --> 00:18:40,680 improvements to your product all the way to building it, testing 359 00:18:40,680 --> 00:18:42,320 it and deploying it into production. 360 00:18:42,760 --> 00:18:45,800 So I don't think value streams are anything new. 361 00:18:45,880 --> 00:18:49,400 I think the reason I talk about value streams as the building 362 00:18:49,400 --> 00:18:52,440 blocks of architecture is that the concept of value stream 363 00:18:52,440 --> 00:18:55,680 touches on it's aligned to a part of your business. 364 00:18:56,200 --> 00:18:59,800 It has clear business objectives like contributes to product, 365 00:18:59,800 --> 00:19:03,840 North Stars or Key KPIs. It's a boundary for a team. 366 00:19:03,840 --> 00:19:07,200 So each value stream is owned by a team and the team should be 367 00:19:07,200 --> 00:19:10,720 able to deploy the software for their value stream independently 368 00:19:10,720 --> 00:19:13,880 and do continuous delivery. So I think the value stream as 369 00:19:13,880 --> 00:19:18,280 the basic concept is just a reminder to have that business, 370 00:19:18,640 --> 00:19:20,800 organizational and software perspective. 371 00:19:20,800 --> 00:19:23,800 It's like it's an abstraction that encompasses those things. 372 00:19:23,920 --> 00:19:27,840 So if we're talking about a value stream, that implies I'm 373 00:19:27,840 --> 00:19:31,280 thinking about the business side, the team side and the 374 00:19:31,280 --> 00:19:33,240 software side. Yeah. 375 00:19:33,400 --> 00:19:35,360 So I think there are 4 characteristics that you 376 00:19:35,360 --> 00:19:37,280 mentioned in this independent value stream, right? 377 00:19:37,360 --> 00:19:39,600 And I think let's start with the first one, which is domain 378 00:19:39,600 --> 00:19:42,360 aligned, since you're also the experts in Domain Driven Design, 379 00:19:42,360 --> 00:19:44,720 right? You said that we need to have a 380 00:19:44,720 --> 00:19:46,760 well defined domain boundaries, right? 381 00:19:46,840 --> 00:19:49,280 I think I assume when people think about value stream right, 382 00:19:49,280 --> 00:19:52,320 they all think about okay. There's a requirements, an idea? 383 00:19:52,800 --> 00:19:55,160 And you develop it, you test, you deploy and that's it, right? 384 00:19:55,160 --> 00:19:58,680 That may be just limited to just one team, but I think when you 385 00:19:58,680 --> 00:20:01,360 say domain aligned right, we also have to think from the 386 00:20:01,520 --> 00:20:03,680 maybe high level business overview kind of thing. 387 00:20:04,120 --> 00:20:06,720 Why do you think having this well defined domain boundaries 388 00:20:06,720 --> 00:20:09,920 is so critical? And tell us also this concept 389 00:20:09,920 --> 00:20:13,000 about change coupling, which I believe in many organizations 390 00:20:13,000 --> 00:20:15,880 this might accidentally happen. Cool. 391 00:20:15,880 --> 00:20:18,720 So yeah, those two points are very interrelated. 392 00:20:18,720 --> 00:20:21,040 I can tell you've been reading the book well, so 393 00:20:21,320 --> 00:20:24,200 congratulations, you've done a good job there in understanding 394 00:20:24,200 --> 00:20:25,600 that and explaining it back to me. 395 00:20:26,000 --> 00:20:30,000 So the first bit is the domain boundaries, and that can be 396 00:20:30,000 --> 00:20:32,840 quite important. If you don't have good domain 397 00:20:32,840 --> 00:20:35,280 boundaries, you'll end up with change coupling. 398 00:20:35,560 --> 00:20:37,760 So maybe I can start with an example. 399 00:20:38,240 --> 00:20:43,040 I worked in the UK government a few years ago and they had an 400 00:20:43,040 --> 00:20:45,320 awesome platform for building micro services. 401 00:20:45,680 --> 00:20:48,800 And you could spin up a new micro service in a couple of 402 00:20:48,800 --> 00:20:51,000 hours, right? You could have it all the way to 403 00:20:51,000 --> 00:20:52,920 production in a couple of hours almost. 404 00:20:53,320 --> 00:20:56,080 There was a manual step that had to be signed off. 405 00:20:56,080 --> 00:20:59,680 But basically in terms of technologies, it was a automated 406 00:20:59,680 --> 00:21:01,840 process. You could deploy this thing to 407 00:21:01,840 --> 00:21:05,560 production every day. And sometimes when it's so easy 408 00:21:05,560 --> 00:21:08,720 to create a micro service, you're like, oh, we're building 409 00:21:08,720 --> 00:21:11,760 a new feature, let's make a new micro service here. 410 00:21:12,240 --> 00:21:14,640 We can have this separate piece of code for this new feature 411 00:21:14,640 --> 00:21:18,520 we're working on and it'll be decoupled from all the other 412 00:21:18,520 --> 00:21:20,200 stuff. Let's do that. 413 00:21:20,640 --> 00:21:23,440 When you make architectural choices on that kind of gut 414 00:21:23,440 --> 00:21:26,240 instincts, it might work in the short term. 415 00:21:26,400 --> 00:21:29,640 But then as the system grows and you add more features, you get 416 00:21:29,640 --> 00:21:33,400 to the point where to implement this next feature, we now have 417 00:21:33,400 --> 00:21:35,640 to change four or five micro services. 418 00:21:35,960 --> 00:21:37,760 And I was talking to a company recently. 419 00:21:37,920 --> 00:21:41,600 You might not believe me, but they told me to implement one 420 00:21:41,600 --> 00:21:45,880 kind of feature we have to touch 20 or maybe even more micro 421 00:21:45,880 --> 00:21:48,680 services. And so the point of the main 422 00:21:48,680 --> 00:21:51,800 boundaries is it's really business analysis, it's 423 00:21:51,800 --> 00:21:55,960 analysing how your business works and thinking how do we 424 00:21:56,080 --> 00:21:59,960 organise a business into these different areas so that when 425 00:21:59,960 --> 00:22:04,120 we're implementing work, work happens in each area. 426 00:22:04,440 --> 00:22:07,240 And the benefit of doing that is you can align your software with 427 00:22:07,240 --> 00:22:11,000 those boundaries. And so the general idea is we 428 00:22:11,000 --> 00:22:14,400 want to create that loosely coupled software and the domain 429 00:22:14,400 --> 00:22:17,360 boundaries help us to think about how might we think about 430 00:22:17,360 --> 00:22:19,400 our business in a loosely coupled way. 431 00:22:19,720 --> 00:22:22,960 Should we have like a separate search and recommendations or 432 00:22:22,960 --> 00:22:25,360 should it be all part of the same thing like on a business 433 00:22:25,360 --> 00:22:28,640 level of those two things together or separate? 434 00:22:29,160 --> 00:22:32,600 And then the concept of change coupling is kind of what I was 435 00:22:32,600 --> 00:22:35,840 talking about before. If you have to change 20 micro 436 00:22:35,840 --> 00:22:38,640 services to implement a new feature, that's a very high 437 00:22:38,640 --> 00:22:42,040 level of change coupling. If those 20 micro services are 438 00:22:42,040 --> 00:22:45,280 all owned by the same team, it might not be so bad. 439 00:22:45,280 --> 00:22:49,600 But usually, change coupling is highly problematic when you're 440 00:22:49,600 --> 00:22:53,120 changing different parts of the system and there's multiple 441 00:22:53,120 --> 00:22:55,840 teams involved. So you know how it goes, right? 442 00:22:56,080 --> 00:22:58,640 You've got a feature, you have other teams, you have to 443 00:22:58,640 --> 00:23:01,360 implement some piece as well. So you need to have shared 444 00:23:01,360 --> 00:23:03,120 meetings. You need to design the 445 00:23:03,120 --> 00:23:05,280 architecture together. Which team will build which 446 00:23:05,280 --> 00:23:07,160 piece? Before you can finish your 447 00:23:07,160 --> 00:23:10,240 piece, another team has to finish their piece, but they 448 00:23:10,240 --> 00:23:11,960 haven't finished their piece on time. 449 00:23:11,960 --> 00:23:13,880 Why? Oh, they've got some other 450 00:23:13,880 --> 00:23:16,440 priorities that they're working on, so they can't do what you 451 00:23:16,440 --> 00:23:19,120 need them to do. So the Change Cup thing is all 452 00:23:19,120 --> 00:23:21,960 of that stuff trying to avoid having to coordinate teams. 453 00:23:22,560 --> 00:23:26,560 I think in a realistic setting we can't avoid that. 454 00:23:26,920 --> 00:23:29,320 Otherwise every team would be just building their own 455 00:23:29,320 --> 00:23:32,520 completely separate products. And it would be, you know, in a 456 00:23:32,520 --> 00:23:36,000 modern context we build products that bring together lots of 457 00:23:36,000 --> 00:23:39,320 different capabilities. So there always is some change 458 00:23:39,320 --> 00:23:41,600 coupling. We just want to make the best 459 00:23:41,600 --> 00:23:45,600 effort to minimize as much as possible and think explicitly 460 00:23:45,920 --> 00:23:48,920 where are we happy to have some coupling and change coupling, 461 00:23:48,920 --> 00:23:51,440 and where might we make an effort to avoid it? 462 00:23:52,440 --> 00:23:54,080 Thanks for that. Great example, right. 463 00:23:54,080 --> 00:23:57,160 So when you make one change 20 different micro services, you 464 00:23:57,160 --> 00:24:00,320 know all must change at the same time and also worst right? 465 00:24:00,320 --> 00:24:03,200 Where if it involves multiple team, you you have dependencies, 466 00:24:03,200 --> 00:24:06,000 you have bottleneck, you have coordination and don't forget 467 00:24:06,000 --> 00:24:08,880 also misunderstanding right? Like for example they all are 468 00:24:08,880 --> 00:24:11,360 not aligned on what kind of things they need to deliver. 469 00:24:11,800 --> 00:24:14,560 Also I like the point where you mentioned that we have to do a 470 00:24:14,560 --> 00:24:16,800 business analysis, right? It's not like change coupling, 471 00:24:16,800 --> 00:24:19,320 it's just like a technology analysis or software design 472 00:24:19,320 --> 00:24:21,160 analysis right? It's actually a business 473 00:24:21,160 --> 00:24:23,440 analysis. Which put us to the second 474 00:24:23,440 --> 00:24:26,080 attribute which you'd mentioned that independent value stream 475 00:24:26,080 --> 00:24:28,800 should have business outcome driven and you touch on about 476 00:24:28,800 --> 00:24:32,840 North Star or the KPI tell us more why this business outcome 477 00:24:32,840 --> 00:24:35,840 driven is so critical in this independent value stream. 478 00:24:36,760 --> 00:24:40,680 So I think the business outcomes is important for a quite a few 479 00:24:40,680 --> 00:24:43,960 reasons actually. I think on the first level, 480 00:24:44,280 --> 00:24:47,320 understanding which business outcomes a value stream 481 00:24:47,440 --> 00:24:50,920 supports, it's going to help you decide what level of 482 00:24:50,920 --> 00:24:52,920 modernisation will be necessary here. 483 00:24:53,200 --> 00:24:57,840 If a value stream is connected to your top business outcomes, 484 00:24:57,840 --> 00:25:01,120 like I don't know, maybe your company's trying to increase 485 00:25:01,120 --> 00:25:03,440 revenue by 10 million in the next year. 486 00:25:03,760 --> 00:25:07,680 And to do that you need to get 10,000 more sign ups for 487 00:25:07,680 --> 00:25:10,320 example. And this value stream is going 488 00:25:10,360 --> 00:25:13,240 to be a feature that increases the number of sign ups. 489 00:25:13,240 --> 00:25:17,840 Then you know, OK, this is a crucial value stream, putting a 490 00:25:17,840 --> 00:25:20,760 lot of effort in here, keeping it decoupled, making sure the 491 00:25:20,760 --> 00:25:23,600 team can innovate quickly, that's going to be super 492 00:25:23,600 --> 00:25:25,920 important there. And so the outcome helps you to 493 00:25:25,920 --> 00:25:29,040 decide what level of effort is going to be important. 494 00:25:29,440 --> 00:25:33,000 And I think the outcomes are also important in terms of 495 00:25:33,360 --> 00:25:35,480 allowing teams to make more decisions. 496 00:25:35,880 --> 00:25:39,760 Like the old approach is you give developers some 497 00:25:39,960 --> 00:25:44,080 requirements documents and they will turn that into the software 498 00:25:44,080 --> 00:25:45,880 that they think you're asking for. 499 00:25:46,440 --> 00:25:49,480 A more modern approach and this is one of the things I mean by 500 00:25:49,480 --> 00:25:53,720 modernization is actually the team themselves deciding. 501 00:25:53,960 --> 00:25:58,080 We know that 10,000 more signups is an important metric we're 502 00:25:58,080 --> 00:26:00,400 trying to achieve. And it's up to the team 503 00:26:00,400 --> 00:26:03,400 themselves to decide what will be some approaches that we can 504 00:26:03,400 --> 00:26:06,720 use to achieve that. And that might involve the team 505 00:26:06,720 --> 00:26:10,040 actually doing some user research, even the developers 506 00:26:10,040 --> 00:26:12,760 talking to users. I know that might sound scary to 507 00:26:12,760 --> 00:26:15,760 some people, but I've seen it working when I worked in the UK 508 00:26:15,760 --> 00:26:17,760 government. We had that going on, and we had 509 00:26:17,760 --> 00:26:20,280 junior developers in the team who would go to the user 510 00:26:20,280 --> 00:26:23,240 research lab with the user researchers and get some 511 00:26:23,240 --> 00:26:25,520 feedback directly from the citizens we're building the 512 00:26:25,520 --> 00:26:27,960 software for. So I think the outcome approach 513 00:26:27,960 --> 00:26:32,840 enables that enables the whole team to be more involved in 514 00:26:33,040 --> 00:26:36,000 choosing what they're going to work on, what solution to build 515 00:26:36,000 --> 00:26:37,920 rather than just how to implement it. 516 00:26:38,480 --> 00:26:41,800 And I think if we look at the way tech's going, the way AI is 517 00:26:41,800 --> 00:26:45,440 enabling more productivity, maybe that's going to be a trend 518 00:26:45,440 --> 00:26:49,560 that goes even further because more of the software creation 519 00:26:49,560 --> 00:26:53,560 is, I don't know, automated or the experience has improved. 520 00:26:53,560 --> 00:26:56,800 People are more productive, will have to spend more time thinking 521 00:26:56,800 --> 00:27:00,440 about better ideas to build rather than just how well we 522 00:27:00,440 --> 00:27:02,520 build the software. Right. 523 00:27:02,520 --> 00:27:06,040 So, yeah, it's very important I think to understand the business 524 00:27:06,040 --> 00:27:08,640 outcome, right. And the North Star, the KPI 525 00:27:08,800 --> 00:27:11,240 which you also just now discussed, it should be executed 526 00:27:11,240 --> 00:27:13,800 by the team who are not just given a requirements to build, 527 00:27:13,800 --> 00:27:15,440 right. They should be empowered, which 528 00:27:15,440 --> 00:27:18,040 is the third characteristics in this independent value stream, 529 00:27:18,040 --> 00:27:19,520 right. So they should have an 530 00:27:19,520 --> 00:27:23,160 empowerment and they should be able to achieve the outcomes, so 531 00:27:23,160 --> 00:27:26,720 they know the what, but the how. Maybe it's up to them to decide. 532 00:27:26,720 --> 00:27:29,480 So a little bit more maybe on this concept of empowerment 533 00:27:29,480 --> 00:27:31,600 because. I think this might be modern to 534 00:27:31,640 --> 00:27:34,120 some software companies or software teams out there, right? 535 00:27:35,000 --> 00:27:36,840 Yeah. So I think that continues where 536 00:27:36,840 --> 00:27:39,560 we talked about before. I would say there's two aspects 537 00:27:39,560 --> 00:27:43,040 to it empowered to decide what you want to build, and then 538 00:27:43,040 --> 00:27:45,160 empowered to actually make changes and deploy your 539 00:27:45,160 --> 00:27:47,240 software. So yeah, the example I was 540 00:27:47,240 --> 00:27:51,000 talking about in the UK government, that kind of falls 541 00:27:51,000 --> 00:27:54,440 under the umbrella of what people are calling continuous 542 00:27:54,440 --> 00:27:58,240 discovery these days. Where as a team you're doing 543 00:27:58,240 --> 00:28:01,800 your discovery together. User research, your developers, 544 00:28:01,800 --> 00:28:04,800 your UX researchers, your product people. 545 00:28:05,240 --> 00:28:09,800 Everyone's involved in learning about the customers problems and 546 00:28:09,800 --> 00:28:13,960 deciding what should we build. Obviously that might not be 547 00:28:13,960 --> 00:28:16,920 possible for every team. If you're building an internal 548 00:28:17,040 --> 00:28:21,200 platform that other teams use, then it's not quite as possible. 549 00:28:21,800 --> 00:28:25,960 But I I still do think it's good to understand if you're building 550 00:28:25,960 --> 00:28:28,920 for an internal team, what are they trying to achieve. 551 00:28:29,080 --> 00:28:32,120 And yeah, so I think having empowerment to define your own 552 00:28:32,120 --> 00:28:34,560 road map is important. Right. 553 00:28:34,840 --> 00:28:37,080 And the last attribute that you mentioned is about software 554 00:28:37,080 --> 00:28:39,000 alignment, right? So I assume this software 555 00:28:39,000 --> 00:28:42,160 aligning with your domains, right, which some people also 556 00:28:42,160 --> 00:28:43,880 touch on. You know the concept about 557 00:28:43,880 --> 00:28:47,040 Conway's Law. So tell us more why this is 558 00:28:47,040 --> 00:28:49,640 important, software alignment and the value stream concept, 559 00:28:49,640 --> 00:28:53,200 right, and why sometimes people do get this wrong. 560 00:28:54,120 --> 00:28:58,080 I think it's important because companies usually want to go 561 00:28:58,080 --> 00:29:01,680 faster, right? They're always looking for ways 562 00:29:01,680 --> 00:29:04,440 to how can we improve our product faster? 563 00:29:04,960 --> 00:29:08,400 We talk about legacy systems slowing us down or we'd like to 564 00:29:08,400 --> 00:29:11,560 deliver this new feature this month, but the legacy's hard to 565 00:29:11,560 --> 00:29:13,760 work with, so we're going to have to deliver it next month or 566 00:29:13,760 --> 00:29:16,720 the month after. So yeah, what people want most 567 00:29:16,720 --> 00:29:19,720 of the time is they want to build a better product, but they 568 00:29:19,720 --> 00:29:23,280 want to build it faster. And so for a team to be able to 569 00:29:23,280 --> 00:29:26,600 do continuous delivery, they need to be able to take a piece 570 00:29:26,600 --> 00:29:30,280 of work, take a requirement from their backlog, implement it in 571 00:29:30,280 --> 00:29:33,280 the software, and then deploy that software. 572 00:29:33,760 --> 00:29:36,920 If a team owns the software and has the means to deploy it 573 00:29:36,920 --> 00:29:40,000 themselves, then you've removed all the dependencies from the 574 00:29:40,000 --> 00:29:43,880 process and therefore the things that can slow A-Team down. 575 00:29:44,320 --> 00:29:47,200 So if you've read the book Accelerate, they talk about one 576 00:29:47,200 --> 00:29:49,920 of the metrics, which is I think it's the lead time. 577 00:29:49,960 --> 00:29:53,040 Yeah, lead time for changes. Basically, where how long does 578 00:29:53,040 --> 00:29:57,280 it take from committing some codes to your branch to it being 579 00:29:57,280 --> 00:30:00,320 in production? And if a team owns every step of 580 00:30:00,320 --> 00:30:03,480 that, then there's nothing to slow them down if they have to 581 00:30:03,480 --> 00:30:07,480 talk to another team, or if you want to deploy your software. 582 00:30:07,600 --> 00:30:10,120 But another team's working in the same code base and you have 583 00:30:10,120 --> 00:30:13,120 to get their permission. And they might say, oh, we we 584 00:30:13,120 --> 00:30:15,120 want to deploy as well, but we haven't quite finished the 585 00:30:15,120 --> 00:30:17,600 feature yet, so let's deploy next week instead. 586 00:30:18,080 --> 00:30:19,480 All those things can slow you down. 587 00:30:19,480 --> 00:30:23,720 So the 4th attribute is really can a team make changes and 588 00:30:23,720 --> 00:30:26,760 deploy those changes as quickly as possible without any 589 00:30:26,760 --> 00:30:29,160 dependencies or blockers? Right. 590 00:30:29,160 --> 00:30:31,320 And if we come back to the business outcome thing, right, 591 00:30:31,320 --> 00:30:34,280 the team, every time they release software, they increment 592 00:30:34,280 --> 00:30:37,800 the value to the value stream, right, which I think ultimately 593 00:30:37,800 --> 00:30:39,960 would improve the business outcomes as well. 594 00:30:40,360 --> 00:30:42,760 So I find this a concept independent value stream really 595 00:30:42,760 --> 00:30:44,680 powerful. So I think this will be the key 596 00:30:44,680 --> 00:30:46,560 chapter for me when I read your book, right. 597 00:30:46,600 --> 00:30:49,840 So I think architects, sometimes they focus a lot on technologies 598 00:30:49,840 --> 00:30:53,360 only or the new cool platform of cloud that we want to adopt. 599 00:30:53,760 --> 00:30:56,200 But I think this independent value stream concept and the 600 00:30:56,200 --> 00:30:59,120 four key attributes are really, really important to get this 601 00:30:59,120 --> 00:31:01,840 modernization right. So let's assume that we 602 00:31:01,840 --> 00:31:04,120 understand all this and we want to start the journey, right. 603 00:31:04,120 --> 00:31:06,280 I think that's always the challenge and the challenge you 604 00:31:06,280 --> 00:31:09,000 mentioned a couple of times, right, business company wants to 605 00:31:09,000 --> 00:31:12,560 move fast but they have legacy then the tech will say yeah we 606 00:31:12,560 --> 00:31:15,360 need time to refactor and re architect oh sorry, we don't 607 00:31:15,360 --> 00:31:16,880 have the time, we don't have the funding. 608 00:31:17,160 --> 00:31:20,000 So maybe the first question is how to get the buy in right? 609 00:31:20,640 --> 00:31:23,440 How to get the buy in? Yeah, always a difficult one. 610 00:31:23,720 --> 00:31:27,040 Well, not always. I guess the easiest approach is. 611 00:31:27,520 --> 00:31:30,040 You just keep waiting and waiting, let the software get 612 00:31:30,040 --> 00:31:33,240 worse and worse until the whole business is complaining that 613 00:31:33,240 --> 00:31:36,360 everything's taking so long and you're like, there's nothing we 614 00:31:36,360 --> 00:31:38,720 can do about this apart from rewriting the system. 615 00:31:39,320 --> 00:31:41,680 So that's how a lot of these situations happen. 616 00:31:41,720 --> 00:31:45,440 Until the pain is so bad, nobody's really willing to 617 00:31:45,640 --> 00:31:49,080 invest in it, unfortunately. But that doesn't mean we should 618 00:31:49,080 --> 00:31:51,880 just accept that. If we believe that modernizing 619 00:31:51,880 --> 00:31:54,400 the system can bring some business value, then I think 620 00:31:54,400 --> 00:31:57,360 it's important that we try and articulate those benefits. 621 00:31:57,760 --> 00:31:59,880 And there's there's a few strategies there, right? 622 00:32:00,240 --> 00:32:03,480 I think understanding what the business is trying to achieve is 623 00:32:03,480 --> 00:32:07,400 the first step because then you can try and turn it into a 624 00:32:07,400 --> 00:32:09,840 proposal. If you invest in this, then 625 00:32:09,840 --> 00:32:11,920 you'll get these business benefits out of it. 626 00:32:12,200 --> 00:32:14,880 At the moment we're delivering one new feature a month. 627 00:32:15,280 --> 00:32:17,760 If you invest in this modernisation, we can deliver 5 628 00:32:17,760 --> 00:32:19,600 new features a month for example. 629 00:32:19,800 --> 00:32:23,160 Something along those lines, obviously more tailored to your 630 00:32:23,320 --> 00:32:27,000 organization specifics. And I think really what makes 631 00:32:27,000 --> 00:32:30,280 the most difference is actually proving it. 632 00:32:30,800 --> 00:32:34,160 So I'm always encouraging people just to try and start small 633 00:32:34,160 --> 00:32:36,680 somewhere. If you can actually demonstrate 634 00:32:36,680 --> 00:32:39,800 an example of modernising a small part of your system and 635 00:32:39,800 --> 00:32:43,480 getting some value from that. And it's much easier to say 636 00:32:43,720 --> 00:32:46,320 we've done it once. If you give us more funding, we 637 00:32:46,320 --> 00:32:49,160 can do more of this in other parts of the system that you're 638 00:32:49,160 --> 00:32:52,040 looking to improve. So if you can do it that way, I 639 00:32:52,040 --> 00:32:54,480 think that's always nice. You can demonstrate with 640 00:32:54,480 --> 00:32:57,520 progress. But obviously in in larger 641 00:32:57,520 --> 00:33:01,560 companies when the legacy's been built up over decades, it's not 642 00:33:01,560 --> 00:33:05,720 always possible to do that. And yeah, in those experiences. 643 00:33:06,040 --> 00:33:08,800 My experience has been mostly, yeah, things get really bad. 644 00:33:08,800 --> 00:33:13,040 The CTO gets fired, a new CTO comes in, and that CTO has got 645 00:33:13,040 --> 00:33:15,120 like a year to start delivering some changes. 646 00:33:15,120 --> 00:33:17,320 Improve modernisation is going to work. 647 00:33:17,720 --> 00:33:20,040 I think it can, It can work in other ways. 648 00:33:20,040 --> 00:33:23,240 When I worked at Salesforce, for example, I think one of the 649 00:33:23,240 --> 00:33:26,440 things that really triggered Salesforce like the the global 650 00:33:26,440 --> 00:33:30,120 CTO of the whole Salesforce. So you know, he's overseeing 651 00:33:30,120 --> 00:33:32,200 like thousands of engineers across the world. 652 00:33:32,600 --> 00:33:34,960 I think he read Sam Newman's micro services book. 653 00:33:35,360 --> 00:33:37,520 And he was like, yeah, we should be doing this stuff. 654 00:33:38,200 --> 00:33:43,000 So things like that, I'm a bit, sometimes these buzzwords can 655 00:33:43,000 --> 00:33:45,440 lead us in the wrong direction. We can do micro services for the 656 00:33:45,440 --> 00:33:48,040 wrong reason. But sometimes it's actually a 657 00:33:48,040 --> 00:33:50,880 buzzword that can get people excited. 658 00:33:50,960 --> 00:33:55,200 And you can use that to start explaining, Oh yeah, these micro 659 00:33:55,200 --> 00:33:56,800 services things are actually pretty good. 660 00:33:57,200 --> 00:34:00,240 If we invested in those, we could get some of those benefits 661 00:34:00,240 --> 00:34:03,240 Sam's talking about in the book. In the last couple of years 662 00:34:03,240 --> 00:34:06,360 we've also seen teams apologies. And teams, apologies has a lot 663 00:34:06,360 --> 00:34:09,400 of great ideas in there on the organizational side, touch and 664 00:34:09,400 --> 00:34:12,040 architecture too. And I think a lot of companies 665 00:34:12,040 --> 00:34:15,560 have decided, yeah, we'd like to apply that in our company. 666 00:34:15,560 --> 00:34:18,600 I think it's reached like the CEO level, the senior leadership 667 00:34:18,600 --> 00:34:20,840 level. So sometimes those buzzwords can 668 00:34:20,840 --> 00:34:24,199 help you to get ideas across. Obviously, there's some definite 669 00:34:24,199 --> 00:34:26,920 risks in that approach. People might be expecting a 670 00:34:26,920 --> 00:34:29,920 quick silver bullet. Oh, if we just build a couple of 671 00:34:29,920 --> 00:34:34,920 micro services in a few weeks or if we just rename all our teams 672 00:34:34,920 --> 00:34:37,199 to streamline teams, we're going to get some benefits. 673 00:34:37,199 --> 00:34:42,000 So the buzzword solution, the buzzword approach definitely has 674 00:34:42,000 --> 00:34:44,280 its risks. But in terms of getting that 675 00:34:44,280 --> 00:34:47,400 initial spark and excitement, helping people to see that? 676 00:34:47,840 --> 00:34:49,960 The industry has moved on. There are different ways of 677 00:34:49,960 --> 00:34:51,920 doing this. I think that can help you to get 678 00:34:51,920 --> 00:34:55,760 started and then as a leader you've got to try and keep 679 00:34:55,760 --> 00:34:59,600 people excited but also be realistic about what's possible. 680 00:35:00,440 --> 00:35:02,320 Yeah, I find this buzzword driven. 681 00:35:02,320 --> 00:35:04,760 Whatever, right? It's also very dangerous, right? 682 00:35:04,760 --> 00:35:07,720 People tend to just see on the paper, oh, this looks good. 683 00:35:08,040 --> 00:35:10,640 This is how the things get implemented, right? 684 00:35:10,640 --> 00:35:12,840 But they don't understand the rationale, the principles, 685 00:35:12,840 --> 00:35:14,960 right? Which I think what I find to get 686 00:35:14,960 --> 00:35:18,320 by also I think we may need to educate those leaders who really 687 00:35:18,320 --> 00:35:20,520 understand the concept, just like for example, independent 688 00:35:20,520 --> 00:35:22,160 value stream just now. I think it's really, really 689 00:35:22,160 --> 00:35:25,880 crucial, right, So that they don't just see it as fixing the 690 00:35:25,880 --> 00:35:28,360 legacy and moving it to a new architecture. 691 00:35:29,000 --> 00:35:31,120 And the other thing that you mentioned in your book is that 692 00:35:31,120 --> 00:35:34,280 you really advocate a lot about you know, collaborative 693 00:35:34,280 --> 00:35:38,040 architecture practices and not making it as an IT silos. 694 00:35:38,200 --> 00:35:39,480 Why do you think this is important? 695 00:35:39,480 --> 00:35:42,920 How we can do it, you know, more collaboratively before starting 696 00:35:42,920 --> 00:35:46,640 this modernization journey. Yeah, it's very easy to wave 697 00:35:46,640 --> 00:35:48,520 your arms and say collaborate more, right? 698 00:35:48,520 --> 00:35:51,000 Oh yeah, If we just collaborate, everything will be great. 699 00:35:51,200 --> 00:35:53,400 So I'm very careful not to say that. 700 00:35:53,760 --> 00:35:56,760 I think if you just get a bunch of people together, throw them 701 00:35:56,760 --> 00:35:58,680 in A room without a clear purpose. 702 00:35:59,080 --> 00:36:01,160 It's probably not going to work out too well. 703 00:36:01,560 --> 00:36:06,080 So I think collaboration with specific purpose using specific 704 00:36:06,080 --> 00:36:08,280 techniques can be very effective. 705 00:36:08,880 --> 00:36:11,280 And one of the techniques I use a lot is event storming. 706 00:36:11,800 --> 00:36:14,800 Event storming is a way to either map out the current state 707 00:36:14,800 --> 00:36:17,480 of your business or the future state of your business. 708 00:36:17,840 --> 00:36:20,880 And actually this goes back to the previous point about getting 709 00:36:20,880 --> 00:36:23,040 buy in. So I was working with a company. 710 00:36:23,040 --> 00:36:25,440 A new CTO came in. He'd heard about domain during 711 00:36:25,440 --> 00:36:28,640 design. And he was facing a situation 712 00:36:28,640 --> 00:36:32,120 where the the company had like some silos like quite a top down 713 00:36:32,120 --> 00:36:34,360 approach. Product was over here, 714 00:36:34,360 --> 00:36:38,080 developers were over here, things in the company 1 715 00:36:38,400 --> 00:36:40,320 operating as well as people would like to. 716 00:36:40,320 --> 00:36:42,200 So people recognize there was a problem. 717 00:36:42,200 --> 00:36:45,000 So with event storming we got people together and this is 718 00:36:45,000 --> 00:36:46,800 quite a common pattern I do in my work. 719 00:36:46,800 --> 00:36:49,720 We got people together and we mapped out their process, how 720 00:36:49,720 --> 00:36:52,680 their business works. With Event Storming, you can 721 00:36:52,680 --> 00:36:56,960 invite anyone to the workshop. So we had products, developers, 722 00:36:56,960 --> 00:37:00,040 sales, marketing, customer support, mapping out their 723 00:37:00,040 --> 00:37:02,640 processes together along the wall. 724 00:37:03,160 --> 00:37:06,520 And then as a result of that you just learn a lot of things like, 725 00:37:06,520 --> 00:37:10,800 oh, the sales team have a process with 180 steps involving 726 00:37:10,800 --> 00:37:14,280 multiple spreadsheets and people just had no idea that was going 727 00:37:14,280 --> 00:37:17,040 on in the company. The sales teams were like, we 728 00:37:17,040 --> 00:37:19,360 just got to get our job done as best as we can. 729 00:37:19,360 --> 00:37:21,920 We didn't realise IT could help us with this problem. 730 00:37:22,240 --> 00:37:24,080 So the collaborative approach is like that. 731 00:37:24,560 --> 00:37:26,640 They serve a few different purposes. 732 00:37:26,640 --> 00:37:28,360 The the first one is the knowledge. 733 00:37:28,400 --> 00:37:31,240 You just understand more about your company and more about what 734 00:37:31,240 --> 00:37:34,040 different teams are working on, more about different departments 735 00:37:34,440 --> 00:37:37,800 and you might realise, oh, we could modernise that old legacy 736 00:37:37,800 --> 00:37:41,320 system. But actually if we can get that 737 00:37:41,320 --> 00:37:45,560 process down from 180 steps and three spreadsheets to like 20 738 00:37:45,560 --> 00:37:48,960 steps and no spreadsheets, the software solution will be much 739 00:37:48,960 --> 00:37:50,640 simpler. We don't need to modernise all 740 00:37:50,640 --> 00:37:53,040 that, we can just simplify the whole thing, remove loads of 741 00:37:53,040 --> 00:37:55,320 complexity. So it encourages those kind of 742 00:37:55,320 --> 00:37:58,320 learnings and the example I wanted to talk about was a 743 00:37:58,320 --> 00:38:01,920 recent one, a recent example of this where we talked about 744 00:38:01,920 --> 00:38:05,680 getting BIND for modernisation. We did one of these workshops 745 00:38:06,000 --> 00:38:08,880 and one of the groups mapped out their whole one of their whole 746 00:38:08,880 --> 00:38:13,040 processes along probably 10 metres of wall space. 747 00:38:13,360 --> 00:38:16,120 And with the event storm they had split it up into these 748 00:38:16,120 --> 00:38:19,520 different possible domains and subdomains, and these had been 749 00:38:19,520 --> 00:38:22,320 defined together by the whole group collaboratively. 750 00:38:22,840 --> 00:38:24,520 And that was a spot for the company. 751 00:38:24,520 --> 00:38:28,040 I think the CEO was Pop coming into the workshops and having a 752 00:38:28,040 --> 00:38:30,880 look. The COO was there, the CTO was 753 00:38:30,880 --> 00:38:34,200 there and they were all like, yeah, we've we've not really 754 00:38:34,200 --> 00:38:36,440 done this before. This is quite impressive to see, 755 00:38:36,440 --> 00:38:39,560 this amount of knowledge, these amount of insights, things that 756 00:38:39,560 --> 00:38:42,760 people had no idea what's happening, solutions that can 757 00:38:42,760 --> 00:38:45,640 solve problems we've had for months or years that no one 758 00:38:45,640 --> 00:38:47,920 realized were possible because they weren't talking. 759 00:38:48,400 --> 00:38:51,560 And that can be one of those catalysts, one of those sparking 760 00:38:51,560 --> 00:38:54,160 moments where people realise, yeah, there's a lot of value 761 00:38:54,160 --> 00:38:57,880 here, if we do more of this, we can solve some of our problems 762 00:38:57,880 --> 00:38:59,760 more effectively. Yeah. 763 00:38:59,760 --> 00:39:03,360 So I find some collaborative session that I attended also 764 00:39:03,360 --> 00:39:04,600 brought the same experience, right? 765 00:39:04,600 --> 00:39:07,880 Oh, we didn't know such things exist or we didn't know that 766 00:39:07,880 --> 00:39:10,840 actually there are so many, you know, inefficiencies or waiting 767 00:39:10,840 --> 00:39:13,360 time in bottlenecks, right. So sometimes this all could 768 00:39:13,360 --> 00:39:15,760 appear as well. So I think maybe using some of 769 00:39:15,760 --> 00:39:18,200 the well known techniques like event storming or even like 770 00:39:18,200 --> 00:39:20,960 value stream mapping itself is also quite common in some of the 771 00:39:21,440 --> 00:39:24,960 you know teams that I work with and the other one quite recently 772 00:39:24,960 --> 00:39:27,040 popular is called the wordly mapping. 773 00:39:27,360 --> 00:39:29,280 So maybe if you can give a little bit of a gist. 774 00:39:29,280 --> 00:39:32,880 I know the concept itself maybe will take some time to explain, 775 00:39:33,120 --> 00:39:36,120 but maybe if you can give us a gist what is wordly mapping and 776 00:39:36,120 --> 00:39:38,600 how it is beneficial for us to learn about. 777 00:39:39,360 --> 00:39:42,240 Yeah, I think wardly mapping. I did a talk recently about 778 00:39:42,240 --> 00:39:47,080 modernisation at the conference in Copenhagen and I said I think 779 00:39:47,360 --> 00:39:50,200 wardly mapping is one of the most important techniques 780 00:39:50,600 --> 00:39:54,280 touches on what we spoke about earlier around prioritisation, 781 00:39:54,280 --> 00:39:57,360 what level of effort? So the idea with the wardly map 782 00:39:57,360 --> 00:40:02,000 is you start with your customers and you figure out what user 783 00:40:02,000 --> 00:40:05,200 needs do they have, what problems is our product solving? 784 00:40:05,440 --> 00:40:08,800 So it might be. We build an app where people can 785 00:40:08,800 --> 00:40:12,560 sell their old items, maybe like an eBay kind of thing, and then 786 00:40:12,560 --> 00:40:15,640 you map out the capabilities your company needs to enable 787 00:40:15,640 --> 00:40:17,560 that. So you need a marketplace where 788 00:40:17,560 --> 00:40:21,400 people can sell the products. You need the capability to ship 789 00:40:21,600 --> 00:40:22,840 a product. You need to be able to do 790 00:40:22,840 --> 00:40:26,800 payments like all the services in your system and how they fit 791 00:40:26,800 --> 00:40:28,720 together. So that's the first part. 792 00:40:28,720 --> 00:40:32,200 And once you've done that, what you then have to do is decide 793 00:40:32,480 --> 00:40:36,440 which stage of evolution does each of these components fit in. 794 00:40:37,040 --> 00:40:40,000 So evolution begins with Genesis. 795 00:40:40,040 --> 00:40:45,120 So evolution represents how advanced is a concept in terms 796 00:40:45,120 --> 00:40:48,560 of its life cycle. So if something's in Genesis 797 00:40:48,560 --> 00:40:52,320 that represents a completely new concept or idea is just coming 798 00:40:52,320 --> 00:40:56,160 out in the world, for example, like imagine when the iPhones 799 00:40:56,160 --> 00:40:59,000 came out for the first time and it was a whole brand new thing. 800 00:40:59,000 --> 00:41:01,680 People hadn't seen it before. Like, wow, that's amazing. 801 00:41:02,040 --> 00:41:03,880 This is on the left of a worldly map. 802 00:41:04,400 --> 00:41:07,600 As things become mature and standardized, they end up as a 803 00:41:07,600 --> 00:41:10,320 commodity. A commodity is something that 804 00:41:10,520 --> 00:41:14,000 people just take for granted. It's the same for every company. 805 00:41:14,440 --> 00:41:18,360 If you want to stream something on Netflix or Amazon Prime, a 806 00:41:18,360 --> 00:41:19,920 lot of the UI looks the same, right? 807 00:41:19,920 --> 00:41:22,680 You search what you're looking for, it's become very 808 00:41:22,680 --> 00:41:24,720 standardized. We just expect it to work in a 809 00:41:24,720 --> 00:41:27,360 certain way. And so with a wordly map, you 810 00:41:27,360 --> 00:41:29,840 map each of the parts of your system into these different 811 00:41:29,840 --> 00:41:35,240 stages of evolution. And that helps you to identify 812 00:41:35,240 --> 00:41:38,040 how important is it. So if something's a commodity, 813 00:41:38,240 --> 00:41:41,440 you know that we can't really improve that as a company 814 00:41:41,440 --> 00:41:43,880 because there's nothing else to improve here. 815 00:41:43,880 --> 00:41:45,800 We can't add any new improvements there. 816 00:41:46,400 --> 00:41:49,880 So the main objective there is how can we continue to provide 817 00:41:49,880 --> 00:41:52,640 that for the lowest possible costs? 818 00:41:53,080 --> 00:41:55,760 Maybe if we can put like 2 developers on that just to keep 819 00:41:55,760 --> 00:41:59,160 it running, that will be enough. We don't need a team of 10 820 00:41:59,160 --> 00:42:02,280 people on it continuously adding new features because the 821 00:42:02,280 --> 00:42:04,280 customers just won't value that in any way. 822 00:42:04,920 --> 00:42:08,400 And on the other side, when you get more towards just coming out 823 00:42:08,400 --> 00:42:11,880 of Genesis into the second stage, custom built, that's a 824 00:42:11,880 --> 00:42:16,520 phase where your idea is starting to become accepted. 825 00:42:16,520 --> 00:42:18,400 You start to see that this concept. 826 00:42:18,400 --> 00:42:21,320 Does have value and there's a lot of potential to 827 00:42:21,320 --> 00:42:24,000 differentiate. So that's where you want to put 828 00:42:24,000 --> 00:42:26,760 a lot of your time and effort, being able to innovate quickly, 829 00:42:26,760 --> 00:42:29,040 adding new features in that part of your system. 830 00:42:29,400 --> 00:42:33,320 So the Wardley mapping can help you to have those conversations 831 00:42:33,480 --> 00:42:37,080 on a business and technical level, what's the business 832 00:42:37,080 --> 00:42:40,560 importance of each component? And then you can start making 833 00:42:40,560 --> 00:42:43,320 architecture and modernisation decisions based on that. 834 00:42:43,640 --> 00:42:46,800 But there's one key detail I haven't talked about yet, which 835 00:42:46,800 --> 00:42:50,320 is everything's evolving. So when you build a Wardy map, 836 00:42:50,640 --> 00:42:54,200 you need to ask questions like how quickly do we think that 837 00:42:54,200 --> 00:42:57,200 this component will move from left to right across the Wardy 838 00:42:57,200 --> 00:43:00,160 map. You might say, for example, oh, 839 00:43:00,160 --> 00:43:04,400 this component here, it's only halfway across the Wardley map. 840 00:43:04,400 --> 00:43:06,960 Therefore, it's still quite a new idea. 841 00:43:06,960 --> 00:43:09,920 There's still chance to add new features and improve this and 842 00:43:09,920 --> 00:43:12,000 differentiate ourselves as a company. 843 00:43:12,440 --> 00:43:15,320 So you might think, well, that must be a really important thing 844 00:43:15,320 --> 00:43:17,680 to focus on. But someone else in the group 845 00:43:17,680 --> 00:43:21,240 might say, actually we think that in just one year from now 846 00:43:21,480 --> 00:43:24,360 this will be all the way across the commodity because all of our 847 00:43:24,360 --> 00:43:26,600 competitors are building the exact same thing. 848 00:43:27,120 --> 00:43:29,880 So you know, actually in one year from now it will be a 849 00:43:29,880 --> 00:43:32,880 commodity. So this isn't a long term thing 850 00:43:32,880 --> 00:43:35,800 we focus on. We just need to invest in this 851 00:43:35,800 --> 00:43:38,360 for one year and then it will move into kind of like a 852 00:43:38,360 --> 00:43:41,760 maintenance mode where we just keep maybe adding small tweaks 853 00:43:41,760 --> 00:43:45,480 and bug fixes and improvements. So yeah, to summarize, the wall 854 00:43:45,480 --> 00:43:50,000 lead map helps you to understand how evolved your components are 855 00:43:50,080 --> 00:43:53,920 in terms of your industry, how much opportunity there is to get 856 00:43:53,920 --> 00:43:56,280 a business value from each of those components. 857 00:43:56,320 --> 00:43:59,240 And then with that knowledge you can actually make your 858 00:43:59,240 --> 00:44:02,200 architecture decisions based on the business value. 859 00:44:02,520 --> 00:44:05,640 You can do that collaboratively and it's a great way again to 860 00:44:05,640 --> 00:44:09,280 get that buy in because if your business leaders are saying this 861 00:44:09,280 --> 00:44:13,000 is where we focus, this is going to be our custom built product 862 00:44:13,040 --> 00:44:16,160 phase for the next five years, then you can say well. 863 00:44:16,560 --> 00:44:18,760 Seems like we need some modernization in that area then 864 00:44:18,760 --> 00:44:21,080 to be able to go at the speed that you're looking for there. 865 00:44:21,960 --> 00:44:25,640 Right, I hope people here could follow your explanation right. 866 00:44:25,640 --> 00:44:29,360 I think wordly mapping is always like for me whenever I read it. 867 00:44:29,520 --> 00:44:32,320 It takes a couple of iterations to actually fully get it and 868 00:44:32,320 --> 00:44:34,320 especially if you haven't done it before right? 869 00:44:34,520 --> 00:44:36,880 Maybe doing it with someone who has experience with it. 870 00:44:37,240 --> 00:44:39,280 Be much better. And I have also two other 871 00:44:39,280 --> 00:44:41,960 episodes which touch on worldly mapping a little bit, Suzanne 872 00:44:41,960 --> 00:44:45,040 Kaiser, she talks about worldly mapping, domain driven design 873 00:44:45,040 --> 00:44:48,000 and team topologies all in one goal which is a little bit 874 00:44:48,200 --> 00:44:50,920 overwhelming at times and also Dave Anderson as well. 875 00:44:50,920 --> 00:44:53,720 So I think this worldly mapping seems to be appearing more and 876 00:44:53,720 --> 00:44:56,120 more frequently. I would suggest listeners to 877 00:44:56,120 --> 00:44:59,400 have a look and understand how it is going to be beneficial, 878 00:44:59,400 --> 00:45:01,640 maybe not just for your modernization, but also to 879 00:45:01,640 --> 00:45:04,440 actually understand your business landscape and 880 00:45:04,440 --> 00:45:06,360 competitive advantage that you have, right. 881 00:45:07,160 --> 00:45:10,600 So the other thing is about product taxonomy. 882 00:45:10,600 --> 00:45:13,360 So you mentioned in the modernization preparation, 883 00:45:13,360 --> 00:45:15,200 right? You need to come up with product 884 00:45:15,200 --> 00:45:18,360 taxonomy. So this is a very interesting 885 00:45:18,360 --> 00:45:20,600 term for me. Maybe if you can explain a 886 00:45:20,600 --> 00:45:23,440 little bit what do you mean by coming up with product taxonomy. 887 00:45:24,160 --> 00:45:28,520 Yeah, so basically the idea of a product taxonomy is a way to 888 00:45:28,520 --> 00:45:32,600 view your overall architecture. Like how do you describe your 889 00:45:32,600 --> 00:45:35,800 overall system? If people are familiar with 890 00:45:36,120 --> 00:45:39,400 business capability maps, it's that kind of idea. 891 00:45:39,800 --> 00:45:44,200 It's the overall view of your system and all the capabilities 892 00:45:44,200 --> 00:45:47,280 and how they fit together. And the example I use in the 893 00:45:47,280 --> 00:45:50,160 book here is a product taxonomy. I'm not saying you should 894 00:45:50,160 --> 00:45:53,000 definitely use that, but in my experience that's a useful 895 00:45:53,000 --> 00:45:56,280 format because it's focused on business outcomes. 896 00:45:56,720 --> 00:46:00,280 So you can look at this as a company and say what are our 897 00:46:00,280 --> 00:46:05,280 different products and which value streams are part of each 898 00:46:05,280 --> 00:46:09,960 product and which value streams are part of platforms that are 899 00:46:09,960 --> 00:46:13,920 supporting multiple products. So I think the important thing 900 00:46:13,920 --> 00:46:18,160 here is it's not that different to other types of diagrams. 901 00:46:18,160 --> 00:46:21,400 I think I just like to have a product focus because the 902 00:46:21,400 --> 00:46:24,360 product represents the interaction with the customer. 903 00:46:24,360 --> 00:46:27,600 The product represents, here's what customers are paying for. 904 00:46:27,920 --> 00:46:31,640 So I find it really useful to be able to look at an architecture 905 00:46:31,680 --> 00:46:33,080 and see it from that perspective. 906 00:46:33,400 --> 00:46:36,040 When I look at a certain part of the system, I'd like to know, 907 00:46:36,200 --> 00:46:39,520 yeah, what product is that supporting exactly and what 908 00:46:39,520 --> 00:46:41,960 customers are getting value from that. 909 00:46:42,160 --> 00:46:43,680 So that's. Kind of framing I find really 910 00:46:43,680 --> 00:46:45,600 useful. Yeah. 911 00:46:45,680 --> 00:46:48,560 And if I understand correctly you, you don't just refer to 912 00:46:48,560 --> 00:46:51,400 like tangible products, right? But this could also mean like 913 00:46:51,400 --> 00:46:54,920 internal, you know, services or platforms at least you identify 914 00:46:54,920 --> 00:46:57,040 who are the customers of that product, right? 915 00:46:57,040 --> 00:47:00,280 It could be internal, external. And I think when I read that 916 00:47:00,280 --> 00:47:02,520 chapter right, I think in the sense right, Because if you 917 00:47:02,520 --> 00:47:05,400 don't have this well defined, again coming back to the well 918 00:47:05,400 --> 00:47:07,920 defined boundaries, right? Which also means the well 919 00:47:07,920 --> 00:47:10,560 defined services and all that. I think it's gonna be difficult 920 00:47:10,560 --> 00:47:12,720 to really identify and focus your effort. 921 00:47:13,000 --> 00:47:15,120 So let's imagine that we have done all this, all the 922 00:47:15,120 --> 00:47:16,760 preparation and we need to execute. 923 00:47:16,760 --> 00:47:19,760 Now it's time to execute. You mentioned this thing called 924 00:47:19,760 --> 00:47:22,000 architecture modernization enabling team. 925 00:47:22,440 --> 00:47:24,080 So tell us more about this right. 926 00:47:24,080 --> 00:47:26,920 What is this team? Is it like a special SWAT team, 927 00:47:26,920 --> 00:47:30,560 you know, coming up and doing all this RE architecture stuff 928 00:47:30,600 --> 00:47:34,560 or or like what does it mean actually this MF thing, yeah, 929 00:47:34,560 --> 00:47:36,920 it's a special SWOT team. They go around the company and 930 00:47:37,280 --> 00:47:39,840 if anyone's not trying hard enough then those people 931 00:47:39,840 --> 00:47:43,320 disappear. So basically the idea of an 932 00:47:43,320 --> 00:47:47,440 architect modernisation enabling team, it builds on the idea of 933 00:47:47,440 --> 00:47:50,680 enabling teams from teams. Apologies, but the purpose of 934 00:47:50,680 --> 00:47:54,440 these teams is, I would say if I start from the problem and then 935 00:47:54,440 --> 00:47:58,280 talk about the team, the problem that I see is it's not easy to 936 00:47:58,280 --> 00:48:00,680 go from. We're building features in a 937 00:48:00,680 --> 00:48:03,840 monolithic system to hey, we're modernising everything, let's go 938 00:48:03,840 --> 00:48:06,480 like that. Mindset shift is huge, right? 939 00:48:06,800 --> 00:48:10,760 I've been in companies where the leaders are wanting to 940 00:48:10,760 --> 00:48:14,480 modernise, but the developers have been working legacy systems 941 00:48:14,480 --> 00:48:17,120 for so long that you know, it's just a complete, complete 942 00:48:17,120 --> 00:48:20,360 mindset shift. So for reasons like that, 943 00:48:20,360 --> 00:48:22,800 getting started with modernisation can be difficult. 944 00:48:22,800 --> 00:48:28,080 Transitioning from just working normally to OK Now my job is to 945 00:48:28,080 --> 00:48:31,680 think about how can we improve every part of the system and how 946 00:48:31,680 --> 00:48:34,120 we work. So the purpose of an enabling 947 00:48:34,120 --> 00:48:38,840 team is to support that process. In a modern architecture, as I 948 00:48:38,840 --> 00:48:41,480 talked about, we want to have teams that are more empowered, 949 00:48:42,000 --> 00:48:44,640 want to have teams that are practising continuous delivery. 950 00:48:45,120 --> 00:48:49,000 So the goal of an AMAT is to help the teams to get to that 951 00:48:49,000 --> 00:48:52,000 level. It's to identify what problems 952 00:48:52,000 --> 00:48:54,520 are the teams facing. Maybe they're not sure where to 953 00:48:54,520 --> 00:48:57,480 get started, or maybe they've heard about Domain Driven Design 954 00:48:57,480 --> 00:49:00,440 and they're getting confused by all these jargon words like 955 00:49:00,800 --> 00:49:03,080 ubiquitous language and bounded context. 956 00:49:03,520 --> 00:49:07,720 Or maybe it can be things like, yeah, the leadership team has 957 00:49:08,000 --> 00:49:11,080 given teams some space to modernise, but now they're 958 00:49:11,080 --> 00:49:14,200 starting to ask them to deliver features again and teams don't 959 00:49:14,200 --> 00:49:16,680 have time to modernise. So the I think the AIM At's job 960 00:49:16,680 --> 00:49:20,280 is to try and keep things on the right track, to identify what 961 00:49:20,280 --> 00:49:23,960 support do people need, what problems are popping up, and to 962 00:49:23,960 --> 00:49:27,000 keep things moving. It's not intended to be like a 963 00:49:27,120 --> 00:49:30,400 team that makes decisions. It's not like the old approaches 964 00:49:30,400 --> 00:49:33,120 where the architects would design the system and the teams 965 00:49:33,120 --> 00:49:35,440 go build it. But there is some of that I 966 00:49:35,440 --> 00:49:39,040 would say when an organization is immature at the start of a 967 00:49:39,040 --> 00:49:42,920 journey, maybe the Aimet will make some decisions and maybe 968 00:49:42,920 --> 00:49:45,720 the Aimet will steer things in the right direction. 969 00:49:46,280 --> 00:49:49,880 But a good aim at people working in, an aim at, I think they need 970 00:49:49,880 --> 00:49:53,360 to realise, you know, when do I step forward, when do I step 971 00:49:53,360 --> 00:49:56,920 back, when do I try and help A-Team and when do I step in and 972 00:49:56,920 --> 00:49:59,520 say this team's not working, we need to change something, you 973 00:49:59,520 --> 00:50:02,760 know, It's finding that balance very difficult, very skillfully 974 00:50:02,760 --> 00:50:04,960 I would say. But yeah, the goal is mostly to 975 00:50:04,960 --> 00:50:08,160 support teams and to keep the modernisation journey moving in 976 00:50:08,160 --> 00:50:11,480 the right direction. So if I may ask further, who 977 00:50:11,480 --> 00:50:12,880 should comprise this team, right? 978 00:50:12,880 --> 00:50:15,760 Because let's say, imagine I'm sure many, many companies have 979 00:50:15,760 --> 00:50:19,160 this legacy right monolith database, monolith service or 980 00:50:19,160 --> 00:50:22,000 whatever that is. Like, how would this Amap come 981 00:50:22,000 --> 00:50:25,360 in and try to decide, OK, maybe we should split this boundaries. 982 00:50:25,360 --> 00:50:28,320 You know, this thing, does it also involve business in the 983 00:50:28,320 --> 00:50:30,560 Amap team? Like maybe a little bit more 984 00:50:30,560 --> 00:50:33,320 about this Amap? Yeah, definitely. 985 00:50:34,440 --> 00:50:36,960 But the composition of the team can vary according to your 986 00:50:36,960 --> 00:50:41,240 organization's unique challenges, and also different 987 00:50:41,240 --> 00:50:44,480 people can be more involved and less involved in the team. 988 00:50:44,880 --> 00:50:47,800 You might have a core aim at, an extended aim at some people who 989 00:50:47,800 --> 00:50:50,240 are doing this full time every day, and some people who come in 990 00:50:50,240 --> 00:50:52,880 and out as needed. So the pattern isn't intended to 991 00:50:52,880 --> 00:50:55,040 be something extremely prescriptive. 992 00:50:55,040 --> 00:50:58,440 There is some flexibility there. I would say with a modernisation 993 00:50:58,440 --> 00:51:00,920 journey, as we talked about before, there's a lot of 994 00:51:01,280 --> 00:51:04,240 decisions that will have a business impact for example. 995 00:51:04,600 --> 00:51:07,760 And so having some product people in there where you can 996 00:51:07,760 --> 00:51:11,360 make some joint decisions, for example, the company wants to 997 00:51:11,360 --> 00:51:14,320 build a new feature, it's a significant piece of work. 998 00:51:14,560 --> 00:51:18,160 Should we build it in the old monolith to get it to market as 999 00:51:18,160 --> 00:51:22,040 quickly as possible or should we build it in the new system that 1000 00:51:22,040 --> 00:51:24,720 we're still figuring out and it might take longer. 1001 00:51:24,720 --> 00:51:27,280 So having those different perspectives in there can be 1002 00:51:27,280 --> 00:51:30,400 important. I think going back to your point 1003 00:51:30,400 --> 00:51:33,840 about, yeah, how do we take this old system and split it up into 1004 00:51:33,840 --> 00:51:36,320 boundaries. I think one thing the AMEC can 1005 00:51:36,320 --> 00:51:39,320 definitely do there is to organise sessions like event 1006 00:51:39,320 --> 00:51:41,920 storming for example. Let's map out the business, 1007 00:51:41,920 --> 00:51:44,520 think about how we'd split the business up and then we can 1008 00:51:44,520 --> 00:51:48,320 start thinking about how we might align the boundaries in 1009 00:51:48,320 --> 00:51:51,280 the software to that. But what you touch on there is 1010 00:51:51,280 --> 00:51:54,680 actually something much more significant in terms of, yeah, 1011 00:51:54,680 --> 00:51:58,000 who makes the decision. So I think an Amet should be 1012 00:51:58,000 --> 00:52:01,520 skilled in architecture. An amet does need to have strong 1013 00:52:01,520 --> 00:52:04,360 architecture skills. The Amet wants to help the 1014 00:52:04,360 --> 00:52:08,760 group, but an amet person needs to know, is this group going in 1015 00:52:08,760 --> 00:52:10,880 the wrong direction here? Do I need to step in here and 1016 00:52:10,880 --> 00:52:14,920 say actually you're proposing we make that a micro service, but 1017 00:52:15,360 --> 00:52:18,120 we're quite for various reasons that won't work. 1018 00:52:18,120 --> 00:52:21,480 It's not a good approach. So stepping in and actually 1019 00:52:21,480 --> 00:52:23,560 either guiding the group in the right direction or making a 1020 00:52:23,560 --> 00:52:26,440 decision is sometimes necessary. That's what I was talking about 1021 00:52:26,440 --> 00:52:30,600 before. So I would say that someone like 1022 00:52:30,600 --> 00:52:32,400 an architect who works in the Amet. 1023 00:52:32,400 --> 00:52:36,520 I would say the dream skill set is someone who's super awesome 1024 00:52:36,520 --> 00:52:39,640 at architecture, but he's actually really skilled at 1025 00:52:39,640 --> 00:52:41,440 coaching and working with people as well. 1026 00:52:41,880 --> 00:52:45,120 He's doing both of those things. Not easy to find. 1027 00:52:45,160 --> 00:52:47,440 Not everyone's going to be perfect at both of those things. 1028 00:52:47,440 --> 00:52:50,160 So if you can find the right balance in the team, maybe some 1029 00:52:50,160 --> 00:52:52,560 people who are more technically good, some people who are more 1030 00:52:52,560 --> 00:52:55,080 good at coaching, you can balance it out by having 1031 00:52:55,080 --> 00:52:59,320 different voices in the group. And I think the other point is 1032 00:52:59,320 --> 00:53:03,000 connected to that is if you're going to work in an Amex, I 1033 00:53:03,000 --> 00:53:06,200 think you need to be committed to trying to improve yourself in 1034 00:53:06,200 --> 00:53:09,080 both of those areas. Like, yeah, you might have been 1035 00:53:09,080 --> 00:53:11,800 the the genius architect who makes all the decisions. 1036 00:53:11,800 --> 00:53:14,480 You can still work in an A map if you really try hard to 1037 00:53:14,480 --> 00:53:16,880 improve your facilitation and coaching skills. 1038 00:53:17,440 --> 00:53:19,760 Like just because you aren't good at those things now doesn't 1039 00:53:19,760 --> 00:53:21,080 mean you can't achieve those things. 1040 00:53:21,080 --> 00:53:24,160 So yeah. Thanks for the pluck of adding 1041 00:53:24,160 --> 00:53:26,320 this coaching communication skill, you know, so like 1042 00:53:26,320 --> 00:53:28,160 stakeholder management influencing, right? 1043 00:53:28,160 --> 00:53:30,800 I find it's very. Difficult probably to find this 1044 00:53:30,800 --> 00:53:32,400 person, but yeah, like you mentioned, right. 1045 00:53:32,400 --> 00:53:35,400 Don't just give up. Maybe you can put a few people 1046 00:53:35,400 --> 00:53:38,640 together, some maybe strong at architecture, some might be more 1047 00:53:38,640 --> 00:53:40,400 on this communication collaboration. 1048 00:53:40,800 --> 00:53:44,200 But the concept is also is an enabling team, right from team 1049 00:53:44,200 --> 00:53:45,600 topologists. It's not like a central 1050 00:53:45,600 --> 00:53:48,600 architecture team who makes decision and you know just 1051 00:53:48,600 --> 00:53:50,720 execute, right. So I think that's also really 1052 00:53:50,720 --> 00:53:52,720 powerful concept. The other thing I would like to 1053 00:53:52,720 --> 00:53:55,880 ask modernization, I mean if you're lucky, right, it takes 1054 00:53:55,880 --> 00:53:59,240 maybe a year, but most of the time it may take more than. 1055 00:53:59,640 --> 00:54:02,240 A year, right? And also depending on complexity 1056 00:54:02,240 --> 00:54:05,680 and how old the legacy is or for example, your business has grown 1057 00:54:05,680 --> 00:54:08,920 so much and you have to modernize certain aspects of the 1058 00:54:09,080 --> 00:54:11,360 technology so that it scales with the new demand and things 1059 00:54:11,360 --> 00:54:13,600 like that. So we need probably to build a 1060 00:54:13,600 --> 00:54:16,560 road map and plan. Any tips, maybe from your 1061 00:54:16,640 --> 00:54:19,040 consulting experience as well, How can people start building 1062 00:54:19,040 --> 00:54:21,000 Rd. maps? Any gotchas that we need to 1063 00:54:21,000 --> 00:54:23,320 think about? Yeah, I mean, Rd. 1064 00:54:23,320 --> 00:54:26,240 Maps is always hard, right? A road map is a prediction about 1065 00:54:26,240 --> 00:54:27,920 how you think the future is going to work out. 1066 00:54:27,920 --> 00:54:30,680 And we know that the future never works out as we planned 1067 00:54:30,680 --> 00:54:32,720 to. But on the other hand, we can't 1068 00:54:32,720 --> 00:54:35,600 just say, well, we can't predict the future, so let's not have a 1069 00:54:35,600 --> 00:54:37,480 road map. That's not possible either, 1070 00:54:37,480 --> 00:54:40,120 because how do people know that they're moving in the right 1071 00:54:40,120 --> 00:54:42,400 direction? How does someone know that in a 1072 00:54:42,400 --> 00:54:44,840 few months from now, some other teams are going to be depending 1073 00:54:44,840 --> 00:54:47,840 on the work we're doing? So some level of planning is 1074 00:54:47,840 --> 00:54:50,000 important. It will vary according to the 1075 00:54:50,000 --> 00:54:54,640 context, so I think identifying dependencies is important and 1076 00:54:54,640 --> 00:54:57,280 making sure those things are defined well on the road map. 1077 00:54:57,760 --> 00:55:01,520 I think going out and talking to teams and understanding what 1078 00:55:01,520 --> 00:55:04,280 challenges they have and when they might be ready to modernise 1079 00:55:04,280 --> 00:55:08,280 is important. I think delivery soon is 1080 00:55:08,280 --> 00:55:10,920 important, like you don't need to have a full road map before 1081 00:55:10,920 --> 00:55:13,280 you start delivering stuff. I think you know you want to be 1082 00:55:13,280 --> 00:55:16,200 delivering as soon as possible, really getting the feedback, 1083 00:55:16,280 --> 00:55:18,040 feeding that back into your plans. 1084 00:55:18,520 --> 00:55:21,360 And I think a modern modernization isn't something 1085 00:55:21,360 --> 00:55:22,960 that's normally defined centrally. 1086 00:55:23,120 --> 00:55:26,160 So when I worked at Salesforce for example, there was the 1087 00:55:26,160 --> 00:55:30,240 concept of like playbooks, basically different teams could 1088 00:55:30,240 --> 00:55:33,720 modernize when they wanted to. It was up to the teams to decide 1089 00:55:33,720 --> 00:55:37,080 when do we modernize, how much modernization work do we do this 1090 00:55:37,080 --> 00:55:40,640 month or next month. And the, the playbooks can say 1091 00:55:41,040 --> 00:55:44,680 if you're modernizing something from the old COBOL system to a a 1092 00:55:44,680 --> 00:55:48,680 Java API on AWS, here's the playbook you can follow. 1093 00:55:48,800 --> 00:55:51,200 So then you can do it yourself. You know, you might want to do 1094 00:55:51,200 --> 00:55:54,120 it this quarter, next quarter. It's up to your team when you do 1095 00:55:54,120 --> 00:55:57,360 that. But you you might also have some 1096 00:55:57,360 --> 00:56:00,840 specific objectives. You might say we want all teams 1097 00:56:00,840 --> 00:56:04,520 to have achieved this first step or modernise certain things by a 1098 00:56:04,520 --> 00:56:07,200 certain, by one year for example. 1099 00:56:07,520 --> 00:56:10,120 And so you might have, yeah, you might need to check that and 1100 00:56:10,120 --> 00:56:11,880 check in with the teams. And that's something that an 1101 00:56:11,920 --> 00:56:15,080 Amit can help with. Like, hey, I see that this team 1102 00:56:15,080 --> 00:56:17,400 hasn't started modernising yet. What's stopping you? 1103 00:56:17,400 --> 00:56:20,400 What help do you need? Maybe they're just a bit scared 1104 00:56:20,400 --> 00:56:22,360 because they've got some complex legacy. 1105 00:56:22,760 --> 00:56:26,800 So yeah, to summarise, I think there probably isn't going to be 1106 00:56:26,800 --> 00:56:29,520 one huge road map that describes everything. 1107 00:56:29,720 --> 00:56:32,560 I mean, you know, if you want the easy answer, the easy answer 1108 00:56:32,560 --> 00:56:36,320 is you design your target architecture, your entire target 1109 00:56:36,320 --> 00:56:39,440 architecture, You decide how we're going to migrate each 1110 00:56:39,440 --> 00:56:42,480 piece from the current to the future and you put all of those 1111 00:56:42,480 --> 00:56:45,160 in order of importance on a road map like that's the old 1112 00:56:45,160 --> 00:56:48,240 waterfall approach. It's a simple solution, but it 1113 00:56:48,240 --> 00:56:51,800 doesn't really work in practice. So I think firstly having an 1114 00:56:51,800 --> 00:56:55,120 understanding of what does each team need, there might be as 1115 00:56:55,120 --> 00:56:58,640 well parts of the current system that will require an 1116 00:56:58,640 --> 00:57:01,800 organization restructure. So I think there's different 1117 00:57:01,800 --> 00:57:04,200 levels here. So it's Salesforce for example, 1118 00:57:04,200 --> 00:57:07,960 you had like a team, a group of teams, a group of group of teams 1119 00:57:08,480 --> 00:57:11,520 and then you can have different decision making at different 1120 00:57:11,520 --> 00:57:13,640 levels. The key thing I wanted to get 1121 00:57:13,640 --> 00:57:17,800 across is depending on the size of your organization, you might 1122 00:57:17,800 --> 00:57:19,360 have Rd. maps at different. Levels. 1123 00:57:19,360 --> 00:57:23,720 So if you're if you're CTO who's got 10,000 engineers working for 1124 00:57:23,720 --> 00:57:25,440 you. You might have a very high level 1125 00:57:25,440 --> 00:57:28,640 road map where you just say I'd like to see this amount of 1126 00:57:28,640 --> 00:57:32,520 progress by these points or I'd like to see us off this old 1127 00:57:32,520 --> 00:57:36,280 infrastructure by this certain dates and then that cascades 1128 00:57:36,280 --> 00:57:38,200 down to the next level perhaps you're. 1129 00:57:38,520 --> 00:57:42,480 CT OS in each business area or your VPS of engineering, and 1130 00:57:42,480 --> 00:57:44,960 they might have their own more detailed road map for how their 1131 00:57:44,960 --> 00:57:47,600 teams in that area will achieve those objectives. 1132 00:57:48,160 --> 00:57:50,600 So I think the concept of pushing decisions down is 1133 00:57:50,600 --> 00:57:53,720 something I've seen in larger companies and would recommend. 1134 00:57:54,600 --> 00:57:55,640 Right. And especially if the 1135 00:57:55,640 --> 00:57:57,240 organization is really large, right? 1136 00:57:57,240 --> 00:57:59,000 Sometimes there's this inner share, right? 1137 00:57:59,280 --> 00:58:02,400 People just falls into the habit or maybe they have features to 1138 00:58:02,400 --> 00:58:04,680 deliver, right? They are just overwhelmed. 1139 00:58:05,120 --> 00:58:06,480 And also don't forget the risk right? 1140 00:58:06,480 --> 00:58:08,640 If you wanna refactor, especially to align with the 1141 00:58:08,640 --> 00:58:11,480 domain boundaries, sometimes you really need to refactor the 1142 00:58:11,480 --> 00:58:13,400 workflow itself. Sometimes you know, like one 1143 00:58:13,400 --> 00:58:16,560 atomic transaction could be multiple and that creates a lot 1144 00:58:16,560 --> 00:58:19,400 of risk and complexity and data migration, things like that. 1145 00:58:19,680 --> 00:58:21,720 So I don't think many people fancy that. 1146 00:58:21,720 --> 00:58:24,640 And yeah, having it driven from the top probably is also one 1147 00:58:24,640 --> 00:58:26,280 alternative that people should think about. 1148 00:58:26,960 --> 00:58:30,040 And yeah, like you said, deliver value early, don't wait until 1149 00:58:30,040 --> 00:58:32,000 one year and wait for the result, right. 1150 00:58:32,000 --> 00:58:35,040 Sometimes there could be surprises that it didn't work as 1151 00:58:35,040 --> 00:58:37,640 what you planned. So, Nick, thank you so much for 1152 00:58:37,640 --> 00:58:39,520 this conversation. I really encourage people to 1153 00:58:39,520 --> 00:58:41,680 read the book, especially if they want to go and buck the 1154 00:58:41,680 --> 00:58:43,480 journey of architecture modernization. 1155 00:58:43,800 --> 00:58:45,920 I have one last question for you, which I call the three 1156 00:58:45,920 --> 00:58:48,600 technical leadership wisdom. You can think of it like advice 1157 00:58:48,600 --> 00:58:50,120 that you want to give to the listeners here. 1158 00:58:50,400 --> 00:58:52,160 So maybe if you can share some for us. 1159 00:58:53,000 --> 00:58:55,400 Yeah, sure. I think the first thing I would 1160 00:58:55,400 --> 00:58:59,720 like to suggest is using techniques like event storming. 1161 00:59:00,120 --> 00:59:04,840 If you're making software decisions of any kind, really, 1162 00:59:04,840 --> 00:59:08,120 just having the domain experts knowledge, having more domain 1163 00:59:08,120 --> 00:59:10,360 knowledge about the domain you're working in, having 1164 00:59:10,360 --> 00:59:12,480 different perspectives from the people you work with in the 1165 00:59:12,480 --> 00:59:15,440 company, it's so useful get so much value from these. 1166 00:59:15,720 --> 00:59:18,320 I see people getting so much value from these sessions. 1167 00:59:18,320 --> 00:59:20,760 So I think trying out things like event storming if you 1168 00:59:20,760 --> 00:59:24,000 haven't done it. I would really recommend it. 1169 00:59:24,480 --> 00:59:27,160 I think the second one will probably be around the concept 1170 00:59:27,160 --> 00:59:29,600 of enabling teams and facilitation. 1171 00:59:29,640 --> 00:59:32,080 I think those aren't maybe used enough. 1172 00:59:32,480 --> 00:59:35,880 So yeah, think about the challenges you're facing, if not 1173 00:59:35,880 --> 00:59:38,880 related to architecture modernisation, then what else 1174 00:59:38,880 --> 00:59:42,480 might it be and how could you form an enabling team to try and 1175 00:59:42,560 --> 00:59:44,280 help the idea to get some traction? 1176 00:59:44,280 --> 00:59:47,120 Keep moving it forward, Yeah, so enabling teams are quite useful 1177 00:59:47,120 --> 00:59:49,920 concepts. And the third one. 1178 00:59:50,520 --> 00:59:54,480 The third one I would probably say is another one of those arm 1179 00:59:54,480 --> 00:59:55,960 waving things like collaboration. 1180 00:59:55,960 --> 01:00:00,960 But I would say trust is one of the biggest differentiators of 1181 01:00:01,280 --> 01:00:03,320 people who get success and people who don't. 1182 01:00:03,680 --> 01:00:08,000 So some companies I work with as a very disconnect, very big 1183 01:00:08,000 --> 01:00:11,000 disconnect between on the tech side and the business side. 1184 01:00:11,400 --> 01:00:13,200 Tech people have a lot of legacy. 1185 01:00:13,200 --> 01:00:16,200 They've got a lot of problems in the code level and they're 1186 01:00:16,200 --> 01:00:18,240 struggling. They have to improve it because 1187 01:00:18,240 --> 01:00:19,920 it's just so difficult to work with. 1188 01:00:20,480 --> 01:00:22,880 But then when you talk to the business leaders, they just 1189 01:00:22,880 --> 01:00:26,040 think all the tech people are geeks who want to use the latest 1190 01:00:26,040 --> 01:00:28,600 technologies. So I think as a technical 1191 01:00:28,600 --> 01:00:32,280 leader, if you can build trust with business leaders, if you 1192 01:00:32,280 --> 01:00:35,720 can go to a business leader and say we should stop building 1193 01:00:35,720 --> 01:00:39,160 features for three months and that will make us put in a much 1194 01:00:39,160 --> 01:00:40,720 healthier position for the long term. 1195 01:00:41,240 --> 01:00:45,080 If you can say that to like ACEO or senior business leader and 1196 01:00:45,080 --> 01:00:48,000 they think to themselves. I trust this person. 1197 01:00:48,000 --> 01:00:50,840 I don't understand anything about micro services, but I know 1198 01:00:50,840 --> 01:00:54,200 that this person is trustworthy, so I'm going to support this 1199 01:00:54,200 --> 01:00:55,880 decision. I think that's the key. 1200 01:00:55,960 --> 01:00:59,720 I think being able to convey ideas in business language and 1201 01:00:59,720 --> 01:01:02,920 have conversations with business stakeholders very often. 1202 01:01:02,920 --> 01:01:06,240 That's the differentiator. You could have two architects 1203 01:01:06,240 --> 01:01:09,200 proposing the same ideas saying the exact same words. 1204 01:01:09,600 --> 01:01:12,760 One might get accepted and one might get rejected simply 1205 01:01:12,760 --> 01:01:15,720 because you was a person. Aren't trusted. 1206 01:01:15,720 --> 01:01:18,200 You don't have as much credibility in the company. 1207 01:01:18,320 --> 01:01:21,320 So I think, yeah, I think building that trust up and down 1208 01:01:21,320 --> 01:01:24,760 is, is a big differentiator. Wow. 1209 01:01:24,760 --> 01:01:26,120 So I think it's really important. 1210 01:01:26,120 --> 01:01:27,640 Yeah, trust is really, really important. 1211 01:01:27,640 --> 01:01:29,760 And coming back to our initial discussion about social, 1212 01:01:29,760 --> 01:01:31,720 technical right. So don't forget, trust is part 1213 01:01:31,720 --> 01:01:34,480 of the social. So when you embark organization, 1214 01:01:34,480 --> 01:01:35,840 you know the architecture, right? 1215 01:01:36,280 --> 01:01:38,160 Don't forget the social aspect as well. 1216 01:01:38,440 --> 01:01:41,400 So Nick, if people love this concept, they won't want to 1217 01:01:41,400 --> 01:01:42,800 learn more, maybe reach out to you. 1218 01:01:42,800 --> 01:01:44,720 Is there a place where they can find you online? 1219 01:01:45,240 --> 01:01:49,000 Yeah, I'm normally hanging out on LinkedIn these days, find 1220 01:01:49,000 --> 01:01:50,360 most of my conversations on that. 1221 01:01:50,360 --> 01:01:54,000 I'm also on Mastodon as well, limiting myself to two social 1222 01:01:54,000 --> 01:01:56,320 networks at the moment. So yeah, I'm always happy to 1223 01:01:56,520 --> 01:01:58,240 talk. About pineapple pizza and that 1224 01:01:58,240 --> 01:02:02,120 kind of stuff and maybe some modernisation sometimes. 1225 01:02:02,920 --> 01:02:04,880 Right. So I'll make sure to put that in 1226 01:02:04,880 --> 01:02:06,400 the show notes. Thank you so much for your time. 1227 01:02:06,400 --> 01:02:09,000 So for people who want to embark on architecture modernization, 1228 01:02:09,000 --> 01:02:11,080 again highly recommended to read this book. 1229 01:02:11,160 --> 01:02:13,080 So thanks again, Nick. Thank you as well. 1230 01:02:13,080 --> 01:02:18,600 It's been a great pleasure. Thank you for listening to this 1231 01:02:18,600 --> 01:02:21,000 episode and for staying right until the end. 1232 01:02:21,360 --> 01:02:24,480 If you highly enjoyed it, I would appreciate if you share it 1233 01:02:24,480 --> 01:02:27,480 with your friends and colleagues who you think would also benefit 1234 01:02:27,480 --> 01:02:30,280 from listening to this episode and if you're new to the 1235 01:02:30,280 --> 01:02:32,520 podcast. Make sure to subscribe and leave 1236 01:02:32,520 --> 01:02:34,520 me your valuable review and feedback. 1237 01:02:34,880 --> 01:02:37,760 It helps me a lot in order to grow this podcast better. 1238 01:02:38,280 --> 01:02:41,160 You can also find the full show notes of this conversation on 1239 01:02:41,160 --> 01:02:44,120 the episode page at techlitjournal dot dev website, 1240 01:02:44,440 --> 01:02:48,040 including the full transcript, interesting quotes, and links to 1241 01:02:48,040 --> 01:02:50,440 the resources mentioned from the conversation. 1242 01:02:50,880 --> 01:02:53,920 And lastly, make sure to subscribe to the show's mailing 1243 01:02:53,920 --> 01:02:57,720 list on techlitjournal dot dev to get notified for any future 1244 01:02:57,720 --> 01:03:00,320 episodes. Stay tuned for the next Techly 1245 01:03:00,320 --> 01:03:03,240 Journal episode, and until then, goodbye.