1 00:00:00,000 --> 00:00:05,120 Well, hi there. This is part two in a little series that Rohit and I did about how we 2 00:00:05,120 --> 00:00:10,440 help people figure out their application modernization strategy. Hopefully you'll enjoy 3 00:00:10,440 --> 00:00:17,760 it. Also coming up very soon, we have a totally free all online conference, SpringOne, on September 4 00:00:17,760 --> 00:00:23,920 2nd and 3rd. You can register for it at spring1.io. Now we'll be talking about not only things like 5 00:00:23,920 --> 00:00:29,420 application modernization, but also all sorts of development ideas and frameworks and techniques 6 00:00:29,420 --> 00:00:34,220 and stories and the Java and Spring and other worlds. But also we have lots of case studies 7 00:00:34,220 --> 00:00:39,020 of large organizations that have really been transforming and changing and just overall 8 00:00:39,020 --> 00:00:42,960 improving the way that they do software so they can improve the way that they're doing 9 00:00:42,960 --> 00:00:47,920 their business. So if you're interested in that, just go to spring1.io and you can sign 10 00:00:47,920 --> 00:00:53,680 up and attend totally for free. And it's September 2nd and 3rd. So with that, let's jump right 11 00:00:53,680 --> 00:01:00,100 in as Rohit continues to show us how we help organizations sort out and kind of move along 12 00:01:00,100 --> 00:01:05,620 how to modernize their large portfolio so they can start using software as the core way to 13 00:01:05,620 --> 00:01:09,840 run and innovate and overall make their business and their organization better. 14 00:01:10,480 --> 00:01:17,640 I think we left off. You'll have to help me explain it correctly. But we left off sort of like we had 15 00:01:17,640 --> 00:01:24,500 been discussing how you figure out the sort of business and technical feasibility of the applications 16 00:01:24,500 --> 00:01:32,540 that you're going to go through and modernize. And I think I sort of cut you off at the point where I 17 00:01:32,540 --> 00:01:38,340 was saying, well, what are some problems that you have with modernizing and how do you kind of get over 18 00:01:38,340 --> 00:01:45,520 them? And, and how do you sort of drive towards actually doing things? But you had gone through a, 19 00:01:45,520 --> 00:01:51,700 a great way of showing how you figure out which applications to work on and kind of think about 20 00:01:51,700 --> 00:01:55,360 which ones to do. And then I left you off right there. 21 00:01:56,120 --> 00:02:04,840 Right. So like just, just a small recap, right? Like this is your universe of applications, right? So 22 00:02:04,840 --> 00:02:12,020 certain applications like will stay as VMs and you will move them to the cloud, like run them. 23 00:02:12,020 --> 00:02:19,200 You just put the VM to run in AWS or, or on VCF or any of the, so like you just keep the VM. Some 24 00:02:19,200 --> 00:02:26,380 VMs, some you will like move to some, you will move to containers and then run them in the cloud. 25 00:02:26,380 --> 00:02:36,380 Right. You will not make any changes to the application. So you're just like taking, putting lipstick on a pig, but getting all the operational and flexible power of the, of the cloud. 26 00:02:36,380 --> 00:02:43,560 So just take the stuff up. So just take the VM up, package it up and put, learn it in the cloud. No, no zero code changes. 27 00:02:43,560 --> 00:02:59,560 So like this is the zone of zero code changes. Then you want to kind of, now you want to leverage the productivity benefits, the developer, the developer productivity that you get by using more, more, more modern microservices, cloud native frameworks. 28 00:02:59,560 --> 00:03:11,560 So at that point, like you're taking a Webster or Weblogic app and converting it to using Spring Boot or you're using a more modern framework, whatever it is, Quarkers, whatever you want, I do want you to use Boot. 29 00:03:11,560 --> 00:03:28,560 But here you are starting to make some code changes to your application. Again, remember these applications are like small, medium and large size applications. So like if your portfolio is thousand apps, probably 500 end up here, like 200 end up here. 30 00:03:28,560 --> 00:03:46,560 Like you take another 200 to boot, then you have this megalith or monolith apps, probably five or 10 in your portfolio. These you need to break into microservices, right? Because they are extremely strategic and you can't just shovel them and run them in VMs or you are actually doing development on them. 31 00:03:46,560 --> 00:04:10,560 Like if you don't, these are value enhancing to your business. Like if you don't break them down, like you will get disrupted and eaten by your competitors. So like this is where we are right now in this, in this top track, we are on the top of the pyramid here because this process that I'm going to explain of how to break down a monolith is the, is the part we are here. Um, just, just to frame in the map where we are in the, in the tragic. 32 00:04:10,560 --> 00:04:40,280 And now, you know, I think, I think there's a point probably worth drawing out here, which, which we talked about last time that, uh, you can't really do everything all at once very quickly, which, which is also, I think, aside of the, uh, there's no silver bullets, which is to say, like, if there's some magical way of doing everything, then you could do everything. It's a nonsensical way of putting it. But, you know, I think, I think the quantity of like, let's start with like one to five applications, right? 33 00:04:40,280 --> 00:04:53,980 It's a good realistic way to kind of bootstrap your way into this, into this process rather than having, uh, you know, we're going to do 500 things all at once. We're just going to do select all and then drag them over here and everything will work fine. 34 00:04:53,980 --> 00:05:10,000 I mean, I call that the great MNM debate. Did I ever tell you, uh, no, no, what's that? Great MNM debate is migrate and modernize or modernize and migrate, which, which path should you take? Um, if you ask the IT guys, IT guys, 35 00:05:10,000 --> 00:05:38,680 you guys are like select all, just move it to the cloud. I don't care. Right. Migrate and then modernize. You ask the dev developers, they are like, no, what's the point? Just moving it to the cloud. We want modernize it. We want to make it cloud native. Then we'll move it to the cloud. So like different people come at it from different points of view. I call it MNM, uh, migrate and modernize and migrate. Okay. So we have, we have, we have a monolithic application. We have established that this is a business critical application. 36 00:05:40,000 --> 00:05:52,160 It is a monolith. Right. Um, and so the context is that we have a, uh, basically a massive monolith. It is strategic and it's basically gets deployed as one massive chunk. 37 00:05:52,160 --> 00:05:56,720 So like the first step in the process is what I call as like goal alignment. 38 00:05:58,540 --> 00:06:05,760 This is, this is very important. You need to establish why you're modernizing this app, right? 39 00:06:05,760 --> 00:06:35,000 What is the core like business trigger, um, as a result of which you, you are modernizing this monolith? Is it, is it because you want like them, you want developer productivity? You are not releasing this. You are not making functional changes to the application fast enough for a, from a business perspective. Um, is it like digital experience? Um, is it that your volume is growing, going up and you just app cannot scale? 40 00:06:35,000 --> 00:06:44,820 Right. Like what is the trigger for you to take this business critical system application and break it down into smaller services, right? Uh, to modernize this application. 41 00:06:44,820 --> 00:06:54,760 And so in order for you to do that, um, there is this thing that this pyramid that we draw where we establish like the broad goals of the engagement. 42 00:06:54,760 --> 00:07:02,580 So like the goals and then objectives and key results. 43 00:07:02,580 --> 00:07:18,580 I think this is important from an executive alignment perspective. And then if you want, you can also write down all the risks to the process. So any, any exercise begins with alignment around why the hell are we doing this? What do we want to achieve? How do we measure success? Right. 44 00:07:18,580 --> 00:07:25,660 How do we measure success? Right. And if you don't have that, then these programs keep going on and on and on and on. And you don't know whether you have hit any measurable mark or other. 45 00:07:25,660 --> 00:07:44,540 Do you find that, that people know these things? Like, is this, is this like a common thing that comes up or do you have to spend some extra time to like figure out what the objectives are? I guess, you know, to peel back the, uh, the question I'm asking, like, I'm always curious, especially when it comes to modernization. 46 00:07:44,540 --> 00:07:47,640 If anyone remembers why this software is valuable. 47 00:07:49,340 --> 00:08:13,760 Exactly. One, why is this software valuable? And two, everyone has their kind of own, own bias and like thought process around why we are modernizing it. It is critical at the executive VP, like we, like the line of business level, the person who's sponsoring this million dollar project, they need to understand why are we doing this so that everyone on rank and file also understand what are they going for? 48 00:08:13,760 --> 00:08:42,460 Because everybody's smart. Everybody has their own thinking into why we are modernizing it. Like you, if the goal is we are modernizing this application to us to provide a comprehensive 360 degree customer experience to our customers. We are modernizing this application so that credit, uh, so that, uh, commercial credit can now be determined, uh, in a, in less than five minutes with multiple providers. Like you need to have some, some anchor, 49 00:08:42,980 --> 00:08:47,760 some foundational principle around why the modernization is taking place so that everyone kind of aligns around. 50 00:08:47,880 --> 00:08:47,880 Right. 51 00:08:48,400 --> 00:09:12,360 So step number one is goal alignment. Step number two is understanding your domain. This is, this is tough in certain situations, but we have a exercise called, uh, uh, event storming where everyone from business, whoever understands the business process, plus the technical team, plus the executives, plus designers, whoever, 52 00:09:12,360 --> 00:09:23,360 uh, essentially charts out, uh, essentially charts out the business process of your, the current business process and the story of the system in terms of events. 53 00:09:23,360 --> 00:09:41,180 As you look back in life, as you look back in life, your life has been molded by a series of events. Similarly in an application, an application is an application encodes a business, a business process, right? And, uh, a flow of data, right? And messages. 54 00:09:41,180 --> 00:09:56,180 So the, uh, what we do is we, we write out these events, what is known as a domain event, like for instance, insurance policy process, or, um, another one is user authenticated. 55 00:09:56,180 --> 00:10:10,860 These events that are really not technical, uh, but speak the language of the domain, like, uh, item ship, for instance, or inventory decremented. 56 00:10:11,180 --> 00:10:25,940 These are, these are, these are words that both the technical people and the business people understand, but that tells you the story of your, of, of the system and the domain and the flow of data and messages and API across this domain. 57 00:10:25,940 --> 00:10:38,620 This process is called, uh, and this, um, and this, this is conducted to understand and take inventory of what is actually going on in the system in the form of events. 58 00:10:38,820 --> 00:10:49,180 And, and again, in this case, is this, um, is this something like easily obtained or like what's been your experience as far as like finding this information? 59 00:10:49,180 --> 00:10:59,440 Like the, every time do you have to actually just get the people and start from fresh or can you go get like, uh, I don't know, tell rational Rose to give you some event storming thing. 60 00:10:59,440 --> 00:11:12,560 Um, my, in, in the 40 or so of these events that I have done, you almost never have this information and if it does exist, it is all outdated. 61 00:11:12,560 --> 00:11:21,720 The value in the exercise is everyone coming together and discovering their own domain, bringing up conflicts. 62 00:11:21,860 --> 00:11:23,520 Hey, this doesn't work like this. 63 00:11:23,600 --> 00:11:24,880 This is supposed to work like this. 64 00:11:25,140 --> 00:11:30,480 So this is like a red spot where we need to fix the system or are you sure this works like this? 65 00:11:30,520 --> 00:11:37,700 So it surfaces all the conflict in the system and it gives us, because the system is so vast, it's like an elephant. 66 00:11:38,080 --> 00:11:39,840 Everyone understands one portion of it. 67 00:11:39,880 --> 00:11:44,160 Someone understands the hind leg, someone understands the trunk, someone understands the back. 68 00:11:44,540 --> 00:11:51,160 You're putting together a vision, a view of the system by talking to all the stakeholders because they're almost in an organization. 69 00:11:51,640 --> 00:11:59,620 They never talk to one or another in a group like this event storm, like this system map, this business process map doesn't really exist. 70 00:11:59,620 --> 00:12:06,920 Or if it has existed, some enterprise architect has written it down in the ivory tower and has no relation to what it looks like in real life. 71 00:12:07,460 --> 00:12:22,720 So, like in any process of fixing or rebuilding or reimagination, you have to start with understanding how FW are, like how deep in the hole are you. 72 00:12:23,200 --> 00:12:29,580 So that begins with first understanding and acknowledging the current situation, which you do with this process of event storming. 73 00:12:29,580 --> 00:12:30,960 There are multiple ways of doing this. 74 00:12:31,040 --> 00:12:32,240 Don't get hung up on me. 75 00:12:32,580 --> 00:12:35,460 Some people do it in the form of like user journey maps. 76 00:12:37,480 --> 00:12:41,300 There are kind of other variants of event storming as well. 77 00:12:42,020 --> 00:12:42,960 It's called work. 78 00:12:42,960 --> 00:12:51,440 But event storming has basically become kind of the industry standard now for decomposing massive systems to understand the process. 79 00:12:52,720 --> 00:13:03,760 Oftentimes, the mistake that people make in this phase is that they start getting ready to the individual workarounds and the technical nitty-gritties of the system. 80 00:13:04,320 --> 00:13:05,820 That's not really the purpose of this. 81 00:13:05,880 --> 00:13:14,680 The purpose of event storming coming out is a set of domains, also called business capabilities. 82 00:13:16,680 --> 00:13:28,180 And so domains and business capabilities, so all the candidate services in your future target architecture get identified in this process, right? 83 00:13:29,240 --> 00:13:31,060 So let me give you a case in point. 84 00:13:31,200 --> 00:13:40,080 Like what are, what would be the domains like pricing, ship in a retail, pricing, shipping, order management, right? 85 00:13:41,220 --> 00:13:41,700 Customer. 86 00:13:43,080 --> 00:13:46,880 So these are kind of like some of the domains that come out. 87 00:13:49,760 --> 00:13:51,120 Store, right? 88 00:13:51,120 --> 00:13:58,960 So these higher-level services in domain-driven design, they're also called as bounded contexts. 89 00:13:59,420 --> 00:14:01,960 These come out of event storming. 90 00:14:02,180 --> 00:14:09,880 Also, as an interesting side effect, you get a prioritized list of the most painful things in your system, one, two, and three. 91 00:14:10,680 --> 00:14:15,980 So you can attack and start decomposing the most high-priority problem, which is number one. 92 00:14:16,540 --> 00:14:20,340 So it's a lot of things that this exercise gives you. 93 00:14:20,340 --> 00:14:30,420 You know, over the years, that's the interesting thing about doing the domain modeling and making sure you're doing the event storming and getting everyone in there, 94 00:14:30,840 --> 00:14:38,140 is you use it as sort of like a tool to spelunk through the software and find out what it actually does. 95 00:14:38,780 --> 00:14:50,280 And I think, as I suspect you'll get to, what's interesting about that then is it also defines what the software doesn't do that people might think it does do. 96 00:14:50,940 --> 00:14:53,500 And things that you don't have to modernize, right? 97 00:14:53,520 --> 00:14:56,200 Like, we don't really need this part anymore, and it doesn't need to do this. 98 00:14:56,300 --> 00:15:00,740 Like, it's an interesting way of cleaning up shop of the features that you have. 99 00:15:00,860 --> 00:15:09,840 Like, for instance, like you said, we no longer need to do step number three because we are going to get rid of this or use a SaaS system, for instance. 100 00:15:10,160 --> 00:15:14,880 So it gives you a chance to, the word I like to do is reimagine the business. 101 00:15:15,580 --> 00:15:20,820 So now you have taken inventory, you understand, you have a common language. 102 00:15:21,000 --> 00:15:27,340 I think that is also a very nice side effect of this is everyone now talks in this unique common language. 103 00:15:27,540 --> 00:15:35,240 It's also called ubiquitous language where everyone now, when you say a term, everyone kind of understands what it is. 104 00:15:35,860 --> 00:15:39,300 So ubiquitous language is an output from here. 105 00:15:40,720 --> 00:15:43,880 So, okay, think of this as like landing a plane, right? 106 00:15:43,960 --> 00:15:46,180 We were at like the 30,000 feet. 107 00:15:46,400 --> 00:15:47,620 We have descended a little bit. 108 00:15:47,980 --> 00:15:49,320 We are now at 20,000 feet. 109 00:15:49,900 --> 00:15:55,580 Now what happens is you have to actually, in order to build a new system, you have to create a backlog of storage. 110 00:15:55,680 --> 00:15:57,180 So we are kind of driving towards that. 111 00:15:57,860 --> 00:16:12,200 So in any complex system, there will be multiple end-to-end user flows into like a shopping cart flow, a procurement flow, a checkout flow. 112 00:16:12,560 --> 00:16:16,260 So there are multiple end-to-end use cases. 113 00:16:17,860 --> 00:16:20,920 We call these as thin slices, right? 114 00:16:21,360 --> 00:16:25,720 So you now have to identify like your top three thin slices. 115 00:16:25,940 --> 00:16:32,280 A user checks in, user puts items in the cart, and then user checks out, and the item gets shipped. 116 00:16:32,380 --> 00:16:32,920 Something like that. 117 00:16:33,000 --> 00:16:33,440 Happy path. 118 00:16:34,500 --> 00:16:38,480 Or I have created a purchase order for this item. 119 00:16:38,720 --> 00:16:42,840 The item is sent to the item is then procured from a vendor. 120 00:16:43,340 --> 00:16:44,360 The inventory is updated. 121 00:16:44,360 --> 00:16:46,840 So there are multiple thin slices. 122 00:16:47,560 --> 00:16:49,160 People call these steel threads. 123 00:16:49,920 --> 00:16:57,800 You end-to-end use cases that define all the use cases or the scenarios of the system. 124 00:16:58,140 --> 00:17:00,540 You have to pick like one thin slice. 125 00:17:00,760 --> 00:17:07,800 So in this phase, in phase number three, you are identifying thin slices. 126 00:17:09,240 --> 00:17:23,260 You now have, so you now have the services, and you have now identified the thin end-to-end slice, which is the steel thread along which you are going to modernize. 127 00:17:23,920 --> 00:17:34,020 So like, think of this as like, there are like all these thin slices together, right, aggregate and give you all the functionality in your system. 128 00:17:34,760 --> 00:17:36,580 But we can't do everything in one go. 129 00:17:37,120 --> 00:17:46,620 So you identify one thin slice, and then for that thin slice, you map out the interaction between all the domains. 130 00:17:47,000 --> 00:17:54,400 So what this, what this means is our color, we use different colors for these domains. 131 00:17:55,140 --> 00:17:56,320 Let's then find the color. 132 00:17:59,880 --> 00:18:04,360 Save blue, and then this is all, and then let's do that. 133 00:18:05,360 --> 00:18:11,400 So let's assume this is pricing, right? 134 00:18:12,040 --> 00:18:13,340 This could be inventory. 135 00:18:15,380 --> 00:18:15,880 Service. 136 00:18:16,340 --> 00:18:40,680 So now you kind of map the interaction of data and APIs, like data and APIs across these domains, and figure out what those external interfaces are in terms of events and APIs. 137 00:18:40,680 --> 00:18:51,100 And this process of mapping out the interaction of events, like data and APIs, for a thin slice, this process is called Boris. 138 00:18:51,660 --> 00:18:57,700 So then you know what is the exact API that the inventory service exposes to product. 139 00:18:58,080 --> 00:19:00,940 What does the, what is the exact API account exposes? 140 00:19:01,340 --> 00:19:03,520 What are the events that flow back and forth? 141 00:19:03,520 --> 00:19:13,580 So for instance, when a product, like, and over here is order, order to, like, when an order is placed, then shipping needs to know, right? 142 00:19:14,520 --> 00:19:17,020 And it needs to do a certain set of actions. 143 00:19:17,780 --> 00:19:33,220 So this, like, think of this as like a, like a wireframe or a context diagram tells you the, it gives you an understanding of all the interactions. 144 00:19:33,520 --> 00:19:38,460 Between the services to achieve the outcome of that thin slice. 145 00:19:38,780 --> 00:19:42,020 So this diagram looks like a spider diagram, it's called Boris. 146 00:19:42,260 --> 00:19:44,460 So in that example, what was the thin slice again? 147 00:19:44,500 --> 00:19:52,280 So the thin, the thin slice here is that user has shopped and checked out, like a concrete item, a shoe. 148 00:19:52,580 --> 00:19:53,100 Okay. 149 00:19:54,240 --> 00:19:58,640 At the, at the, at the, at the digital store. 150 00:19:59,720 --> 00:20:02,300 So you, user is buying, buys a shoe. 151 00:20:02,320 --> 00:20:03,620 User buys a shoe, basically. 152 00:20:04,600 --> 00:20:06,040 Maybe just a replacement shoe. 153 00:20:06,140 --> 00:20:08,640 They've, they've lost the right shoe and they need a. 154 00:20:08,880 --> 00:20:10,120 So that's a complicated case. 155 00:20:10,200 --> 00:20:14,180 So that I would, we would do that in like step number two, because returns are handled in a different. 156 00:20:14,560 --> 00:20:17,700 So these are the, like, you're not talking to all the use cases. 157 00:20:17,880 --> 00:20:23,680 So step first thin slices, I go to the store, I bought a shoe, I checked out, I paid for it. 158 00:20:23,760 --> 00:20:26,240 I got a receipt and a shipping notification. 159 00:20:26,700 --> 00:20:31,700 But when that happens in the thin slice, all these domains interact with one another, right? 160 00:20:32,060 --> 00:20:33,740 Then an order is shipped. 161 00:20:34,260 --> 00:20:40,600 An event is put on the, an event is generated called order ship, order placed. 162 00:20:41,040 --> 00:20:52,180 Now, who cares about order placed shipping obviously does because he has to ship the item inventory does because inventory has to reduce the inventory product. 163 00:20:52,520 --> 00:20:54,040 There might be a recommendations engine. 164 00:20:54,300 --> 00:20:58,200 So like you have to model the flow of APIs and interaction. 165 00:20:58,200 --> 00:21:02,640 You have to model the interactions between these domains as events and APIs. 166 00:21:03,420 --> 00:21:13,300 And then there are other aspects too, which are like, you, we do other things as well, like UIs and then read and write models. 167 00:21:13,460 --> 00:21:17,480 So now, as you can see, it starts becoming more, more and more technical. 168 00:21:17,480 --> 00:21:20,140 We are getting to the level where we need a backlog, right? 169 00:21:20,500 --> 00:21:25,100 So when we were at the event storming level, we were at the business language level, right? 170 00:21:25,200 --> 00:21:27,280 Because we tried not to go too deep technically. 171 00:21:27,640 --> 00:21:33,640 At this point, you are actually creating a blueprint or the target architecture. 172 00:21:33,920 --> 00:21:42,040 When you're drawing the, the, the ovals there, the different sort of parts of the system that events are bouncing around to, to satisfy buying some shoes. 173 00:21:43,160 --> 00:21:47,400 When do you determine not to have an oval? 174 00:21:47,400 --> 00:22:02,680 And, and the absurd example is like, you know, uh, if you're a company, you need to figure out revenue recognition, which is to say, when do I put this revenue on the books officially, no matter when I, you know, when did I actually receive the cash versus when do I sell the thing? 175 00:22:02,680 --> 00:22:05,260 And so therefore I can report it on this quarter or not. 176 00:22:05,600 --> 00:22:17,340 And I would imagine, you know, somewhere in the system is like the money for buying that piece of shoe, those shoes rolls up into finance somewhere so they can report that as part of their quarterly revenue. 177 00:22:17,460 --> 00:22:24,820 But that seems like maybe we shouldn't worry about that at the moment, or, or, you know, maybe that's, that's somewhere else, right? 178 00:22:24,840 --> 00:22:31,240 Like, or, or I don't know, like, how do you, when do you determine when to stop mapping the entire universe? 179 00:22:31,560 --> 00:22:45,020 Proper scoping of the thin slices is important, like in this case, like you could make a explicit decision that, um, that we won't, that we won't model the downstream aspects of order processing. 180 00:22:45,240 --> 00:22:53,760 Well, how we try to make sure that we don't model everything in one go is that we try to make sure that our thin slices are scoped correctly. 181 00:22:53,760 --> 00:23:04,100 Or for instance, we will only start modeling like the middle, the initial half of the system and then split it into three parts and then stitch together a view across the three parts. 182 00:23:04,220 --> 00:23:10,040 Like for instance, pharmacy management in, in pharmacy management, they have, they're like multiple stages. 183 00:23:10,200 --> 00:23:12,300 First, you have to submit a claim, right? 184 00:23:12,300 --> 00:23:17,300 The claim gets, so you have to, the process of submitting and accepting a claim is called pre-adjudication. 185 00:23:17,780 --> 00:23:20,300 Then the claim is adjudicated. 186 00:23:20,520 --> 00:23:23,400 And then there's a whole bunch of post-adjudication stuff that happens. 187 00:23:23,760 --> 00:23:35,320 So when we modernized the pharmacy management system, we split it into three, like we split the whole domain into three sub domains, pre-adjudication, adjudication and post-adjudication. 188 00:23:35,520 --> 00:23:49,060 And then we kind of, we modeled each one of those areas separately, but, and, but we made sure that these oval circles stayed the same across all the three or were consistent. 189 00:23:49,240 --> 00:23:50,880 And then we stitched the picture together. 190 00:23:51,080 --> 00:23:56,900 So the only way to scale, if it is a massive thing is that you have to break it down and bring it back together. 191 00:23:56,900 --> 00:23:59,920 Just like think of like how we do recursive code program, right? 192 00:23:59,940 --> 00:24:01,860 Like you just break it down, break it down, break it down. 193 00:24:01,940 --> 00:24:03,480 And it all starts at the end. 194 00:24:03,520 --> 00:24:05,380 It all starts coming, starts coming together. 195 00:24:06,080 --> 00:24:10,500 So yeah, the two answers, scope the thin slices correctly. 196 00:24:10,500 --> 00:24:14,420 And if the domain is too big, focus on big parts of the process. 197 00:24:14,420 --> 00:24:17,840 Like there's a natural ordering in the domain that already exists. 198 00:24:18,240 --> 00:24:18,800 Leverage that. 199 00:24:18,880 --> 00:24:30,860 So now I have my target architecture, like, so one, two, three, four, the fifth, the fifth step is what we know, what we call as tactical patterns, right? 200 00:24:32,240 --> 00:24:39,800 So what this means is there is already probably a, let's take the, let's take the pricing code. 201 00:24:39,800 --> 00:24:43,140 So I want to create a new pricing microservice, right? 202 00:24:43,500 --> 00:24:44,580 That's what I want to do. 203 00:24:45,140 --> 00:24:51,860 But in all likelihood, there is already an existing system that provides pricing. 204 00:24:52,560 --> 00:24:59,080 It's probably some vendor product that exposes pricing, right? 205 00:24:59,080 --> 00:25:02,980 There is already an existing interface that exists for pricing. 206 00:25:03,680 --> 00:25:10,340 So what we have to do is we then expose this API, but wrap all of this up. 207 00:25:10,740 --> 00:25:19,960 So we have our external API and then initially we may just get the prices from the vendor, from, from the vendor. 208 00:25:19,960 --> 00:25:47,860 So a bunch of tactical patterns have to be run, including strangler, facade, and anti-corruption that graft in our newer services on top of the older services and get rid of the strangle of the older services. 209 00:25:47,860 --> 00:25:56,520 So strangler, facade, and anti-corruption layer are like the three major patterns that we use to gradually coexist. 210 00:25:57,200 --> 00:26:07,120 Like think of it as like coexist and then our stuff gets bigger and bigger and bigger and bigger, our services gets bigger and the existing service to vendor or in the monolith shrinks. 211 00:26:07,540 --> 00:26:16,420 And that's how eventually these old circles representing the new services are the only ones in all this, the old vendor stuff goes away. 212 00:26:16,540 --> 00:26:21,420 What is the, uh, what's the, uh, what's the anti-corruption layer? 213 00:26:21,620 --> 00:26:23,000 I know the other two, but what's that? 214 00:26:23,080 --> 00:26:25,360 Anti-corruption layer is, is very simple. 215 00:26:25,360 --> 00:26:30,580 Anti-corruption layer is like, like what you are doing is you have your new service, right? 216 00:26:30,680 --> 00:26:32,320 This is my new sign, new service. 217 00:26:32,580 --> 00:26:37,200 I have my own set of classes and objects and model within it. 218 00:26:37,440 --> 00:26:38,920 This is my code. 219 00:26:38,920 --> 00:26:54,260 I have implemented pricing and inventory in the way I see fit, but the external system or there are consumers that expect a certain interface, like a certain API, like the old API. 220 00:26:54,920 --> 00:26:59,540 But I don't want to expose the old API because the old API perpetuates the mistakes. 221 00:27:00,000 --> 00:27:09,960 So I keep this translation layer whose job is, so this is the ACL to translate from the old to the new and from the new back to the old. 222 00:27:10,360 --> 00:27:18,640 So he is basically a glorified translator that understands the old and translates it to the new and takes the new and translates it to the old. 223 00:27:18,640 --> 00:27:28,200 So that's the anti-corruption layer because it prevents the corruption of your domain from the older API and the mistakes of the old. 224 00:27:28,500 --> 00:27:30,240 That's why it's called anti-corruption layer. 225 00:27:30,380 --> 00:27:41,720 So you can basically evolve, to use your word, the domain into, you know, a new way without actually changing all the backend services. 226 00:27:41,720 --> 00:27:48,820 So you don't have to go back to like the pricing thing that might have its own weird names for things and concepts, but you can modernize it nonetheless. 227 00:27:49,120 --> 00:27:49,280 Right. 228 00:27:49,380 --> 00:27:58,180 So like in terms of pricing, right, initially you have multiple, let's say this is the web, this is the web channel. 229 00:27:58,620 --> 00:27:59,960 This is the mobile channel. 230 00:28:01,740 --> 00:28:04,740 Let's say like there's some other API channel, right? 231 00:28:06,060 --> 00:28:07,500 So this is the old API. 232 00:28:08,160 --> 00:28:12,120 Like all these are called the old pricing, right? 233 00:28:13,020 --> 00:28:17,660 But then we are creating a new pricing system here, right? 234 00:28:19,280 --> 00:28:25,940 So typically what happens is in these systems, usually they talk directly to the pricing system. 235 00:28:27,400 --> 00:28:35,120 So when we start, when we modernize it, what the first thing that we do is like we make one common API here, right? 236 00:28:35,120 --> 00:28:40,340 So that we can switch from this pricing system to this new pricing system. 237 00:28:40,340 --> 00:28:48,380 But if we cannot do that, then what happens is we introduce like the, what is known as the anti-corruption layer. 238 00:28:51,500 --> 00:28:57,820 That still exposes the old APIs, but then translates it to the new ones. 239 00:28:57,960 --> 00:29:05,000 So he handles all the mapping from the old, from the new to the old. 240 00:29:05,780 --> 00:29:08,380 So the ACL can go both ways, basically. 241 00:29:08,840 --> 00:29:17,460 It's not only for like a new way of thinking about the old stuff, but you can, the new thing can behave like the old thing. 242 00:29:17,680 --> 00:29:18,600 Yeah, exactly. 243 00:29:18,600 --> 00:29:21,760 And that is the 140 character definition of an ACL. 244 00:29:22,040 --> 00:29:28,920 The new thing can behave like the old thing with the help of this sidecar ACL that is bolted on the side, right? 245 00:29:29,660 --> 00:29:30,480 Right, right, okay. 246 00:29:30,620 --> 00:29:32,120 So that's anti-corruption layer. 247 00:29:32,280 --> 00:29:43,920 And the last step in this process today, which is step number six, is that all these interactions result in a set of user stories for each slice. 248 00:29:44,220 --> 00:29:47,660 So then we create these user stories. 249 00:29:47,660 --> 00:29:56,620 And then for each slice, so let's say this is end-to-end flow one, this is end-to-end flow two, and then we create end-to-end flow three. 250 00:29:57,220 --> 00:29:59,500 At some point, we define the MVP. 251 00:30:00,080 --> 00:30:01,460 This is MVP one. 252 00:30:02,260 --> 00:30:04,420 This is MVP two. 253 00:30:04,680 --> 00:30:13,540 So we do what is known as like a journey map or a user story map to identify, okay, at this point, what value have we delivered to the business? 254 00:30:13,900 --> 00:30:16,520 When we have done stories one, two, and three. 255 00:30:17,180 --> 00:30:20,320 When we have done stories one, two, and three, we can replace pricing. 256 00:30:20,840 --> 00:30:27,700 When we have done stories four, five, and six, we have changed inventory. 257 00:30:28,340 --> 00:30:36,740 So it is critical to lay out all the stories and then map out what the MVPs are to demonstrate return value. 258 00:30:36,740 --> 00:30:45,840 Because the biggest mistake organizations make is that they create the blueprint, they create this target architecture, but they don't know how to get there. 259 00:30:46,380 --> 00:30:59,200 It is important to sequence out all the work, stories and MVPs, and assign a business value to each MVP so that you can track and measure the progress towards modernizing the system. 260 00:30:59,300 --> 00:31:18,800 When you're writing a new application or modifying an existing one, a lot of what we in Tanzu Pivotal Agile land espouse is like, you know, sort of learning as you do it, what the functionality needs to be and kind of experimenting with is, is this the best way to implement this feature or is there another way to do it? 261 00:31:19,420 --> 00:31:27,840 But, I mean, tell me if I'm wrong, but it seems like when you're modernizing something, you sort of know what the end result needs to look like. 262 00:31:28,660 --> 00:31:37,280 So, so you can spend more time on upfront planning because you're sort of saying like, I want that, but modernized, right? 263 00:31:37,280 --> 00:31:44,020 Like don't, don't necessarily like change the functionality and how it behaves, just like modernize the code a long way. 264 00:31:44,080 --> 00:31:48,280 So you can do a lot more upfront planning than you would normally do in a more agile way. 265 00:31:48,280 --> 00:31:50,760 Yeah, you have to do more upfront planning. 266 00:31:51,240 --> 00:32:04,280 There's no, and, and that is why you do these like sticky based processes, like event storming and Boris and like all this up to step number six is all now in, like you are still in user sticky land. 267 00:32:04,400 --> 00:32:07,180 You have not written a single line of code so far. 268 00:32:07,340 --> 00:32:10,440 So reorienting all this in stickies is quick, right? 269 00:32:10,440 --> 00:32:19,900 Like if you don't, spending the two weeks designing this will, might save you six to eight months of reworking code later. 270 00:32:20,220 --> 00:32:30,340 And which is why we have such a rigorous process around called Swift, this whole six step process is Swift, which, which models the system. 271 00:32:30,580 --> 00:32:33,260 It allows you to play, okay, maybe this is not the service. 272 00:32:33,340 --> 00:32:34,220 We should call it this. 273 00:32:34,560 --> 00:32:49,860 Maybe this domain is incorrect by keeping this all at the whiteboarding level or at the sticky level, we can change things up and get to a right solution and go through that initial five iterations very quickly in our mind before we start developing. 274 00:32:49,860 --> 00:33:02,400 But after we start again, we are always open to changing things, but there is a higher, you have to think through your starting point very rigorously when you are modernizing a system that is generating a billion dollars of revenue. 275 00:33:02,700 --> 00:33:06,700 It's not going to be enough to just show up and say, hey, okay, why don't we just rewrite this? 276 00:33:07,480 --> 00:33:12,480 What is, you need to have a rationale and like this rationale starts from goals and objectives, right? 277 00:33:12,820 --> 00:33:15,180 These influence all these decisions downstream. 278 00:33:15,180 --> 00:33:20,500 And then also, I mean, you know, two weeks in the grand scheme of things isn't a very long time. 279 00:33:21,280 --> 00:33:31,400 And, and, and if you, as you're going over, if you put enough agility into the tools that you can just move things around, as you're saying, you know, with sticky notes, like there, there is. 280 00:33:32,160 --> 00:33:41,520 There is that ability to learn and change things, but it, but it, at worst, you haven't spent like three months doing a huge amount of analysis. 281 00:33:41,520 --> 00:33:44,340 You've just done a couple of weeks and you're moving more incrementally. 282 00:33:44,340 --> 00:33:46,720 So you still do a large amount. 283 00:33:47,180 --> 00:33:56,780 Well, you still do upfront analysis, but you do it in smaller chunks than doing everything all at once, which gives you more of that ability to change as you learn things. 284 00:33:56,780 --> 00:34:01,300 Not necessarily change, but determine the better way to do things as you're working. 285 00:34:01,740 --> 00:34:01,920 Yeah. 286 00:34:02,020 --> 00:34:03,520 And this stuff all lives in Miro. 287 00:34:03,840 --> 00:34:10,840 So it's all kind of this, this architecture diagram, the events, Tom, the goals, everything is in Miro. 288 00:34:10,940 --> 00:34:13,060 So the architecture is extremely well-documented. 289 00:34:13,280 --> 00:34:20,420 I mean, unlike in the past, like the stuff in Miro is a living document and you can drag and drop things and move things around. 290 00:34:20,640 --> 00:34:23,200 And then the code gets, the code is written eventually. 291 00:34:23,360 --> 00:34:32,840 So I feel like this process, in fact, like the reinforcing the remoteness on this has helped the long, in the short term, it has made collaboration difficult. 292 00:34:32,840 --> 00:34:44,960 But in the long term, because you persist all the artifacts in Miro, it creates a trail of provenance for the design and helps you understand why certain decisions were taken. 293 00:34:45,180 --> 00:34:48,940 It keeps a living copy of the architecture for you as you design the system. 294 00:34:49,280 --> 00:34:55,140 So you don't have the same problem as before where no one knows where they have, like what the system does. 295 00:34:55,140 --> 00:35:07,340 And like the issue where this process breaks down, Coté, is when you want to understand the domain and you only involve the technical people, then you get a very technical bias solution. 296 00:35:07,480 --> 00:35:09,520 You might just build the same thing over again. 297 00:35:09,520 --> 00:35:24,580 So I think coming back to one of your key points, when you go through this redesign or reimagination, you should use this as a license to throw away stuff, to really ask what is the business problem we are solving? 298 00:35:24,680 --> 00:35:26,520 Because we might not need a shipping service. 299 00:35:26,900 --> 00:35:31,240 We might use USPS for that, or maybe it's time to rethink order process. 300 00:35:31,240 --> 00:35:37,700 So use this as a license to reimagine your business process, because ultimately, that's the goal. 301 00:35:37,860 --> 00:35:40,300 We are solving for 360 degree digital experience. 302 00:35:40,680 --> 00:35:43,840 We are not solving to create a new order microservice. 303 00:35:44,040 --> 00:35:45,600 No one cares, right? 304 00:35:46,760 --> 00:35:48,680 The outcome is what you need to keep in mind. 305 00:35:48,960 --> 00:35:49,200 All right. 306 00:35:49,260 --> 00:35:58,560 So we got to the point, I think, where we broke things up and we were figuring out the tactical patterns to start interacting between the new and the old parts of the system. 307 00:35:58,560 --> 00:36:08,240 And we've almost found the, I know in this world, the word, you know, seam means something else, but we found the kind of edges of the things that we're working on. 308 00:36:08,420 --> 00:36:14,880 And we systematically went through and worked on the user stories and various streams, and we've been moving along. 309 00:36:15,680 --> 00:36:21,540 And I don't know, that's sort of like midway through the happy, joyful journey of modernization. 310 00:36:22,320 --> 00:36:23,380 Where do things progress from? 311 00:36:23,380 --> 00:36:23,660 Oh, yeah. 312 00:36:23,660 --> 00:36:27,600 So now you have done the six-step process. 313 00:36:27,960 --> 00:36:29,960 So this, I draw this journey like this. 314 00:36:30,020 --> 00:36:31,620 So we started here. 315 00:36:32,300 --> 00:36:35,320 We ran the Swift process, right? 316 00:36:37,440 --> 00:36:52,880 And then, like, we did all the six steps, which is goal alignment and goal, event storming, thin slices, Boris, tactical patterns, and backlog. 317 00:36:53,740 --> 00:37:06,080 So now you do what is known as an inception, where you organize the backlog and, like, organize things in, like, four to six-week increments. 318 00:37:07,680 --> 00:37:11,880 So, like, inception creates stories enough for four to six weeks. 319 00:37:11,880 --> 00:37:16,720 And then for every week, every, like, we run iterations every week. 320 00:37:17,080 --> 00:37:26,620 So at the end of the stories for that week, you then do demos, a retrospective, right? 321 00:37:27,020 --> 00:37:32,480 And then, like, this cycle basically repeats for four to six weeks. 322 00:37:33,560 --> 00:37:35,780 And every week, you show value. 323 00:37:36,420 --> 00:37:43,740 And then you track the MVPs that you have achieved, MVP 1, MVP 2, MVP 3. 324 00:37:44,080 --> 00:37:48,020 Your flywheel, as they like to call it, has begun for modernization. 325 00:37:48,760 --> 00:37:52,140 Now, you may choose to do this after four to six weeks. 326 00:37:52,400 --> 00:37:57,200 You may go back to this and run this process again. 327 00:37:58,100 --> 00:38:00,560 So it's not like this is a one-time process. 328 00:38:00,820 --> 00:38:02,400 You do this for four to six weeks. 329 00:38:02,460 --> 00:38:03,360 You see where you are. 330 00:38:03,400 --> 00:38:06,780 Then you can redo the process for a different domain or the same domain. 331 00:38:07,020 --> 00:38:13,940 So it is the longer, like, so this whole process kind of continues in these loops. 332 00:38:14,320 --> 00:38:18,000 How have you all arrived at, like, the four to six weeks rule of thumb? 333 00:38:18,220 --> 00:38:23,440 Like, I'm interested in how, what the common time chunking is. 334 00:38:23,760 --> 00:38:25,140 I really like six weeks. 335 00:38:25,760 --> 00:38:25,860 Okay. 336 00:38:26,620 --> 00:38:29,160 And I like a team size of 3.25. 337 00:38:30,080 --> 00:38:35,620 It's kind of my, like, if I were to, like, tomorrow, if I were to get fired and create a startup, 338 00:38:36,120 --> 00:38:38,140 I would do six weeks at 3.25. 339 00:38:38,180 --> 00:38:41,240 I actually have a blog post on this, like, I don't know if you care, 340 00:38:41,240 --> 00:38:44,740 but that explains my rationale of six weeks and 3.25. 341 00:38:46,180 --> 00:38:50,160 Even the base camp guys, in their shape-up book, 342 00:38:50,700 --> 00:38:53,600 I think they have a much more sophisticated reason for using six weeks. 343 00:38:53,940 --> 00:38:59,240 I think six weeks is just the right amount of time where you get momentum and can demonstrate value, 344 00:38:59,900 --> 00:39:06,020 but are not completely wedded to the outcome so that you don't have sunk cost fallacy. 345 00:39:06,620 --> 00:39:12,320 Six weeks is that, like, happy path where even if stuff doesn't, hasn't worked, 346 00:39:12,620 --> 00:39:14,800 you can take the feedback to turn the ship around. 347 00:39:15,220 --> 00:39:20,360 If you do it as 12 to 14 weeks, you might end up with the sunk cost fallacy, 348 00:39:20,480 --> 00:39:22,580 like, we already spent so much effort in this. 349 00:39:22,940 --> 00:39:24,840 Like, we can't really rework this, right? 350 00:39:24,840 --> 00:39:31,920 So, I think, and a team of bigger than 3.25 is just, like, initially, it just creates a lot of drag 351 00:39:31,920 --> 00:39:34,860 because there is a lot of collaboration initially. 352 00:39:35,100 --> 00:39:40,340 Having more than three people means that you now, if you have a team of four, 353 00:39:40,700 --> 00:39:42,220 then one person is just doing coordination. 354 00:39:42,660 --> 00:39:48,540 So, like, if you look, if you look at the, there's, like, the theory of how many nodes have to be there, 355 00:39:48,940 --> 00:39:51,680 it's, like, the, and the two pizza teams and stuff like that, 356 00:39:51,740 --> 00:39:55,460 I feel like 3.25, six weeks gives you, like, the idea. 357 00:39:55,660 --> 00:40:00,120 And the 0.25 is, like, the PM or the product manager who has to craft the stories. 358 00:40:00,120 --> 00:40:01,800 It can be 3.5 or whatever. 359 00:40:02,400 --> 00:40:10,220 But 3.25 at six weeks, it breaks in between, reorient and, like, redo some part of the initial process, 360 00:40:10,720 --> 00:40:14,000 gets you to, and then at six weeks, you can show value. 361 00:40:14,320 --> 00:40:18,780 Your stakeholders can get an understanding, and you're demoing every week, too. 362 00:40:19,420 --> 00:40:21,580 So, it's going to be a crazy six weeks. 363 00:40:21,640 --> 00:40:26,520 Then you take maybe a breather and then start the whole thing, start the machine. 364 00:40:26,820 --> 00:40:30,720 There's at least three things, I think, that drive that chunking. 365 00:40:31,420 --> 00:40:37,000 And it is, you know, it's feasible to do something in six weeks, right? 366 00:40:37,120 --> 00:40:40,760 Like, one day would be too small, and a week would probably be too small, 367 00:40:40,860 --> 00:40:43,240 and, you know, to build it up from absurdness. 368 00:40:43,260 --> 00:40:46,760 So, you can do something significant in six weeks. 369 00:40:47,400 --> 00:40:50,180 And then I hadn't really thought of the second point you made, 370 00:40:50,240 --> 00:40:57,120 that it also means you're not afraid to, at worst case, throw away six weeks worth of work. 371 00:40:57,120 --> 00:41:02,560 And then also, you know, the third thing is, like, that's probably as long as your bosses are going to let you go 372 00:41:02,560 --> 00:41:04,300 without seeing if you're doing anything. 373 00:41:04,460 --> 00:41:11,260 So, you have to, like, demonstrate and kind of show progress to kind of refuel sort of the corporate permission 374 00:41:11,260 --> 00:41:12,780 and the resources to keep going. 375 00:41:13,120 --> 00:41:19,240 And, you know, like, you know, four to six weeks seems like about the right amount of chunking for that. 376 00:41:19,240 --> 00:41:26,900 You know, I wanted to ask this because it's one more avenue to kind of reverse engineer how to scope things, right? 377 00:41:26,980 --> 00:41:30,700 So, when you're thinking about how do we scope a backlog, how do we scope the items in the backlog, 378 00:41:31,300 --> 00:41:36,780 in the back of your head, you're always like, and we have four to six weeks to be done with this. 379 00:41:37,240 --> 00:41:41,780 So, a backlog item isn't going to be, like, rewrite pricing, right? 380 00:41:41,820 --> 00:41:45,920 It needs to be scoped down to something that fits into that time period that we have. 381 00:41:45,960 --> 00:41:46,340 Exactly. 382 00:41:47,240 --> 00:41:55,500 And, like, at the weekly demo, you call your first line manager or whoever is, like, your most immediate stakeholder. 383 00:41:55,500 --> 00:42:00,740 At the six-week mark, you're calling the VP of line of business or the CTO. 384 00:42:02,120 --> 00:42:10,740 And it's like you, and then you have to, like, because things will actually get, in reality, things get worse before they get better. 385 00:42:11,440 --> 00:42:12,620 Modernization is hard. 386 00:42:14,120 --> 00:42:18,260 You're going to have the original team maintaining the critical system. 387 00:42:18,400 --> 00:42:21,160 Now, you have this new team branching out code. 388 00:42:22,840 --> 00:42:31,820 So, we've lived through enough of these where, like, you understand that this is, like, that's why you don't do this for all the applications, right? 389 00:42:32,860 --> 00:42:37,200 You do these for applications that are critical systems that make sense. 390 00:42:37,800 --> 00:42:40,340 And then we discuss the easy modernization, too. 391 00:42:40,400 --> 00:42:43,960 Like, this is, what I just showed you is, like, the Ferrari of modernization. 392 00:42:44,240 --> 00:42:51,120 But remember, we also discussed the Cambry and the Accord, which is, hey, let's just break this into UI and backend processing. 393 00:42:51,480 --> 00:42:55,760 Let's just break this into, like, some, this one-year file has eight more files. 394 00:42:55,960 --> 00:42:57,340 Let's just make this more file. 395 00:42:57,940 --> 00:42:59,720 There are cheaper ways of doing this, too. 396 00:43:00,620 --> 00:43:05,680 But you do this when you know that, hey, this system is critical for me to be competitive. 397 00:43:05,880 --> 00:43:07,800 It's going to make me revenue for the next five years. 398 00:43:08,160 --> 00:43:15,100 If I don't invest, Amazon is going to come and basically make mincemeat out of me. 399 00:43:15,420 --> 00:43:16,940 So, like, that's why you do it. 400 00:43:17,240 --> 00:43:19,720 To start to close out, does this process ever end? 401 00:43:21,080 --> 00:43:22,600 Yeah, that's a good point. 402 00:43:22,600 --> 00:43:29,360 The process has a point where active development kind of subsides and it goes into maintenance mode. 403 00:43:29,500 --> 00:43:33,660 So, you may not need as big a team for the entire life of the project. 404 00:43:35,120 --> 00:43:42,740 But the thing is, if you do this right, like, all your legacy team now starts developing on these newer services. 405 00:43:43,380 --> 00:43:55,220 So, it's not so much as the process ends, but, like, now you have gone from working on the old system to the entire team working on the new system and keeps developing all the services and so on. 406 00:43:55,320 --> 00:44:01,440 So, there is a gradual shift of people working from the old to the new, right? 407 00:44:02,780 --> 00:44:08,900 Eventually, we should expect maybe a single person maintaining the old system and then everyone working on the new system. 408 00:44:09,040 --> 00:44:10,480 And then the cycle of life goes on. 409 00:44:10,560 --> 00:44:11,940 These services are ever evolving. 410 00:44:12,420 --> 00:44:16,360 As long as these services are being under development, like, this system keeps running. 411 00:44:16,480 --> 00:44:28,580 And kind of as you're describing, it seems like, well, in most of the large organizations we talked with, like, you know, even a new system in three years is going to be an old system. 412 00:44:28,980 --> 00:44:39,160 So, right, like, as every piece of software that you write now under some new cool way of doing stuff is eventually going to go through this process, right? 413 00:44:39,200 --> 00:44:48,040 Like, it's new things will come about and people will move around and, you know, legacy software is just yesterday's brand new software that everyone really liked. 414 00:44:48,240 --> 00:45:04,280 And so, you know, I would hope long term that, like, you know, as an organization maybe spends a year or so going through this cycle, part of the modernization is they're better at remembering all the old systems. 415 00:45:04,400 --> 00:45:12,040 So, a lot of that analysis that we were going, you were going through at the beginning and things like that, that they're more attuned to that. 416 00:45:12,040 --> 00:45:21,200 And they more treat their IT estate as more of this living system that needs to be continually nurtured instead of just sort of, like, locked in a closet until it becomes burdensome. 417 00:45:22,180 --> 00:45:30,720 But, you know, getting those longer term enterprise architectural habits in place is hopefully something that people learn and put into effect. 418 00:45:30,740 --> 00:45:37,360 Because you'll always have legacy stuff, but at least you can make modernizing it easier than it was last year. 419 00:45:37,360 --> 00:45:41,200 Yeah. The importance of these systems is going up, like, disruption is real. 420 00:45:41,400 --> 00:45:51,840 Like, most non-IT, like, as we say, old school businesses understand that, like, unless they're modernizing and keep modernizing, like, they will go out of business. 421 00:45:52,000 --> 00:45:52,540 Like, it's real. 422 00:45:52,940 --> 00:46:01,720 So, like, there is increased focus on modernization and keeping it going for their own strategic advantage, not just from an IT perspective. 423 00:46:02,120 --> 00:46:03,840 All right. Well, I think that's a pretty good place to end. 424 00:46:04,200 --> 00:46:10,100 Now, you, I'll put a link in the show notes we have to your blog and the one you mentioned. 425 00:46:10,760 --> 00:46:13,940 But do you have a Twitter handle or anything you would direct people to? 426 00:46:13,940 --> 00:46:18,520 Yeah, it's just my, it's just four letters, R, no, five, R-K-E-L-A. 427 00:46:20,040 --> 00:46:20,800 There you go. 428 00:46:21,200 --> 00:46:23,500 And, yeah, there's always fun stuff on your blog. 429 00:46:23,740 --> 00:46:26,220 Well, thanks for doing a little series here. 430 00:46:26,660 --> 00:46:32,700 We'll have to visit you again in the land of happy modernization and see how things are going. 431 00:46:33,340 --> 00:46:34,300 Thank you so much. 432 00:46:34,300 --> 00:46:34,920 All right. 433 00:46:35,020 --> 00:46:42,760 Well, as always, this has been a simulcast episode of Tanzu Talk, also streamed on our Twitch thing. 434 00:46:42,980 --> 00:46:48,520 Now, if you want to get other live streaming things, I think every Tuesday we stream at least one thing. 435 00:46:48,820 --> 00:46:54,980 If you go to twitch.tv slash VMware Tanzu, you can find that. 436 00:46:55,480 --> 00:46:59,300 And we're also always tanzu.vmware.com slash podcast. 437 00:46:59,880 --> 00:47:02,100 Find the show notes, everything else. 438 00:47:02,660 --> 00:47:04,760 So with that, we'll see everyone next time. 439 00:47:05,000 --> 00:47:05,380 Bye-bye.