You can’t do everything at once, large scale app modernizing, part two, with Rohit Kelapure

Episode 175 · 47:06 · SRT · archive.org · all Tanzu Talk

Well, hi there. This is part two in a little series that Rohit and I did about how we help people figure out their application modernization strategy. Hopefully you'll enjoy it. Also coming up very soon, we have a totally free all online conference, SpringOne, on September 2nd and 3rd. You can register for it at spring1.io. Now we'll be talking about not only things like application modernization, but also all sorts of development ideas and frameworks and techniques and stories and the Java and Spring and other worlds. But also we have lots of case studies of large organizations that have really been transforming and changing and just overall improving the way that they do software so they can improve the way that they're doing their business. So if you're interested in that, just go to spring1.io and you can sign up and attend totally for free. And it's September 2nd and 3rd. So with that, let's jump right in as Rohit continues to show us how we help organizations sort out and kind of move along how to modernize their large portfolio so they can start using software as the core way to run and innovate and overall make their business and their organization better. I think we left off. You'll have to help me explain it correctly. But we left off sort of like we had been discussing how you figure out the sort of business and technical feasibility of the applications that you're going to go through and modernize. And I think I sort of cut you off at the point where I was saying, well, what are some problems that you have with modernizing and how do you kind of get over them? And, and how do you sort of drive towards actually doing things? But you had gone through a, a great way of showing how you figure out which applications to work on and kind of think about which ones to do. And then I left you off right there. Right. So like just, just a small recap, right? Like this is your universe of applications, right? So

certain applications like will stay as VMs and you will move them to the cloud, like run them. 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 VMs, some you will like move to some, you will move to containers and then run them in the cloud. 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. 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. 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. 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. 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. 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. 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.

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? 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. 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, 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. 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. So like the first step in the process is what I call as like goal alignment. This is, this is very important. You need to establish why you're modernizing this app, right? 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?

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. 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. So like the goals and then objectives and key results. 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. 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. 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. If anyone remembers why this software is valuable. 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? 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,

some foundational principle around why the modernization is taking place so that everyone kind of aligns around. Right. 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, 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. 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. 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. These events that are really not technical, uh, but speak the language of the domain, like, uh, item ship, for instance, or inventory decremented. 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. 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. 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?

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. 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. The value in the exercise is everyone coming together and discovering their own domain, bringing up conflicts. Hey, this doesn't work like this. This is supposed to work like this. So this is like a red spot where we need to fix the system or are you sure this works like this? So it surfaces all the conflict in the system and it gives us, because the system is so vast, it's like an elephant. Everyone understands one portion of it. Someone understands the hind leg, someone understands the trunk, someone understands the back. You're putting together a vision, a view of the system by talking to all the stakeholders because they're almost in an organization. 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. 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. 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. So that begins with first understanding and acknowledging the current situation, which you do with this process of event storming. There are multiple ways of doing this. Don't get hung up on me. Some people do it in the form of like user journey maps. There are kind of other variants of event storming as well. It's called work. But event storming has basically become kind of the industry standard now for decomposing massive systems to understand the process.

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. That's not really the purpose of this. The purpose of event storming coming out is a set of domains, also called business capabilities. And so domains and business capabilities, so all the candidate services in your future target architecture get identified in this process, right? So let me give you a case in point. Like what are, what would be the domains like pricing, ship in a retail, pricing, shipping, order management, right? Customer. So these are kind of like some of the domains that come out. Store, right? So these higher-level services in domain-driven design, they're also called as bounded contexts. These come out of event storming. Also, as an interesting side effect, you get a prioritized list of the most painful things in your system, one, two, and three. So you can attack and start decomposing the most high-priority problem, which is number one. So it's a lot of things that this exercise gives you. 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, is you use it as sort of like a tool to spelunk through the software and find out what it actually does. 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. And things that you don't have to modernize, right?

Like, we don't really need this part anymore, and it doesn't need to do this. Like, it's an interesting way of cleaning up shop of the features that you have. 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. So it gives you a chance to, the word I like to do is reimagine the business. So now you have taken inventory, you understand, you have a common language. I think that is also a very nice side effect of this is everyone now talks in this unique common language. It's also called ubiquitous language where everyone now, when you say a term, everyone kind of understands what it is. So ubiquitous language is an output from here. So, okay, think of this as like landing a plane, right? We were at like the 30,000 feet. We have descended a little bit. We are now at 20,000 feet. Now what happens is you have to actually, in order to build a new system, you have to create a backlog of storage. So we are kind of driving towards that. 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. So there are multiple end-to-end use cases. We call these as thin slices, right? So you now have to identify like your top three thin slices. A user checks in, user puts items in the cart, and then user checks out, and the item gets shipped. Something like that. Happy path. Or I have created a purchase order for this item. The item is sent to the item is then procured from a vendor. The inventory is updated. So there are multiple thin slices. People call these steel threads. You end-to-end use cases that define all the use cases or the scenarios of the system.

You have to pick like one thin slice. So in this phase, in phase number three, you are identifying thin slices. 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. 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. But we can't do everything in one go. So you identify one thin slice, and then for that thin slice, you map out the interaction between all the domains. So what this, what this means is our color, we use different colors for these domains. Let's then find the color. Save blue, and then this is all, and then let's do that. So let's assume this is pricing, right? This could be inventory. Service. 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. And this process of mapping out the interaction of events, like data and APIs, for a thin slice, this process is called Boris. So then you know what is the exact API that the inventory service exposes to product.

What does the, what is the exact API account exposes? What are the events that flow back and forth? 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? And it needs to do a certain set of actions. 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. Between the services to achieve the outcome of that thin slice. So this diagram looks like a spider diagram, it's called Boris. So in that example, what was the thin slice again? So the thin, the thin slice here is that user has shopped and checked out, like a concrete item, a shoe. Okay. At the, at the, at the, at the digital store. So you, user is buying, buys a shoe. User buys a shoe, basically. Maybe just a replacement shoe. They've, they've lost the right shoe and they need a. So that's a complicated case. So that I would, we would do that in like step number two, because returns are handled in a different. So these are the, like, you're not talking to all the use cases. So step first thin slices, I go to the store, I bought a shoe, I checked out, I paid for it. I got a receipt and a shipping notification. But when that happens in the thin slice, all these domains interact with one another, right? Then an order is shipped. An event is put on the, an event is generated called order ship, order placed. 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. There might be a recommendations engine. So like you have to model the flow of APIs and interaction.

You have to model the interactions between these domains as events and APIs. 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. So now, as you can see, it starts becoming more, more and more technical. We are getting to the level where we need a backlog, right? So when we were at the event storming level, we were at the business language level, right? Because we tried not to go too deep technically. At this point, you are actually creating a blueprint or the target architecture. 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. When do you determine not to have an oval? 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? And so therefore I can report it on this quarter or not. 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. 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? Like, or, or I don't know, like, how do you, when do you determine when to stop mapping the entire universe? 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. 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. 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.

Like for instance, pharmacy management in, in pharmacy management, they have, they're like multiple stages. First, you have to submit a claim, right? The claim gets, so you have to, the process of submitting and accepting a claim is called pre-adjudication. Then the claim is adjudicated. And then there's a whole bunch of post-adjudication stuff that happens. 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. 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. And then we stitched the picture together. 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. Just like think of like how we do recursive code program, right? Like you just break it down, break it down, break it down. And it all starts at the end. It all starts coming, starts coming together. So yeah, the two answers, scope the thin slices correctly. And if the domain is too big, focus on big parts of the process. Like there's a natural ordering in the domain that already exists. Leverage that. 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? So what this means is there is already probably a, let's take the, let's take the pricing code. So I want to create a new pricing microservice, right? That's what I want to do. But in all likelihood, there is already an existing system that provides pricing. It's probably some vendor product that exposes pricing, right? There is already an existing interface that exists for pricing. So what we have to do is we then expose this API, but wrap all of this up.

So we have our external API and then initially we may just get the prices from the vendor, from, from the vendor. 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. So strangler, facade, and anti-corruption layer are like the three major patterns that we use to gradually coexist. 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. 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. What is the, uh, what's the, uh, what's the anti-corruption layer? I know the other two, but what's that? Anti-corruption layer is, is very simple. Anti-corruption layer is like, like what you are doing is you have your new service, right? This is my new sign, new service. I have my own set of classes and objects and model within it. This is my code. 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. But I don't want to expose the old API because the old API perpetuates the mistakes. 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.

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. 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. That's why it's called anti-corruption layer. So you can basically evolve, to use your word, the domain into, you know, a new way without actually changing all the backend services. 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. Right. So like in terms of pricing, right, initially you have multiple, let's say this is the web, this is the web channel. This is the mobile channel. Let's say like there's some other API channel, right? So this is the old API. Like all these are called the old pricing, right? But then we are creating a new pricing system here, right? So typically what happens is in these systems, usually they talk directly to the pricing system. So when we start, when we modernize it, what the first thing that we do is like we make one common API here, right? So that we can switch from this pricing system to this new pricing system. But if we cannot do that, then what happens is we introduce like the, what is known as the anti-corruption layer. That still exposes the old APIs, but then translates it to the new ones. So he handles all the mapping from the old, from the new to the old. So the ACL can go both ways, basically. 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.

Yeah, exactly. And that is the 140 character definition of an ACL. The new thing can behave like the old thing with the help of this sidecar ACL that is bolted on the side, right? Right, right, okay. So that's anti-corruption layer. 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. So then we create these user stories. 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. At some point, we define the MVP. This is MVP one. This is MVP two. 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? When we have done stories one, two, and three. When we have done stories one, two, and three, we can replace pricing. When we have done stories four, five, and six, we have changed inventory. So it is critical to lay out all the stories and then map out what the MVPs are to demonstrate return value. 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. 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. 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?

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. So, so you can spend more time on upfront planning because you're sort of saying like, I want that, but modernized, right? Like don't, don't necessarily like change the functionality and how it behaves, just like modernize the code a long way. So you can do a lot more upfront planning than you would normally do in a more agile way. Yeah, you have to do more upfront planning. 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. You have not written a single line of code so far. So reorienting all this in stickies is quick, right? Like if you don't, spending the two weeks designing this will, might save you six to eight months of reworking code later. 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. It allows you to play, okay, maybe this is not the service. We should call it this. 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. 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. It's not going to be enough to just show up and say, hey, okay, why don't we just rewrite this? What is, you need to have a rationale and like this rationale starts from goals and objectives, right? These influence all these decisions downstream. And then also, I mean, you know, two weeks in the grand scheme of things isn't a very long time.

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. 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. You've just done a couple of weeks and you're moving more incrementally. So you still do a large amount. 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. Not necessarily change, but determine the better way to do things as you're working. Yeah. And this stuff all lives in Miro. So it's all kind of this, this architecture diagram, the events, Tom, the goals, everything is in Miro. So the architecture is extremely well-documented. 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. And then the code gets, the code is written eventually. 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. 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. It keeps a living copy of the architecture for you as you design the system. So you don't have the same problem as before where no one knows where they have, like what the system does. 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. You might just build the same thing over again. 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?

Because we might not need a shipping service. We might use USPS for that, or maybe it's time to rethink order process. So use this as a license to reimagine your business process, because ultimately, that's the goal. We are solving for 360 degree digital experience. We are not solving to create a new order microservice. No one cares, right? The outcome is what you need to keep in mind. All right. 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. 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. And we systematically went through and worked on the user stories and various streams, and we've been moving along. And I don't know, that's sort of like midway through the happy, joyful journey of modernization. Where do things progress from? Oh, yeah. So now you have done the six-step process. So this, I draw this journey like this. So we started here. We ran the Swift process, right? And then, like, we did all the six steps, which is goal alignment and goal, event storming, thin slices, Boris, tactical patterns, and backlog. 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. So, like, inception creates stories enough for four to six weeks. And then for every week, every, like, we run iterations every week. So at the end of the stories for that week, you then do demos, a retrospective, right?

And then, like, this cycle basically repeats for four to six weeks. And every week, you show value. And then you track the MVPs that you have achieved, MVP 1, MVP 2, MVP 3. Your flywheel, as they like to call it, has begun for modernization. Now, you may choose to do this after four to six weeks. You may go back to this and run this process again. So it's not like this is a one-time process. You do this for four to six weeks. You see where you are. Then you can redo the process for a different domain or the same domain. So it is the longer, like, so this whole process kind of continues in these loops. How have you all arrived at, like, the four to six weeks rule of thumb? Like, I'm interested in how, what the common time chunking is. I really like six weeks. Okay. And I like a team size of 3.25. It's kind of my, like, if I were to, like, tomorrow, if I were to get fired and create a startup, I would do six weeks at 3.25. I actually have a blog post on this, like, I don't know if you care, but that explains my rationale of six weeks and 3.25. Even the base camp guys, in their shape-up book, I think they have a much more sophisticated reason for using six weeks. I think six weeks is just the right amount of time where you get momentum and can demonstrate value, but are not completely wedded to the outcome so that you don't have sunk cost fallacy. Six weeks is that, like, happy path where even if stuff doesn't, hasn't worked, you can take the feedback to turn the ship around. If you do it as 12 to 14 weeks, you might end up with the sunk cost fallacy, like, we already spent so much effort in this. Like, we can't really rework this, right? So, I think, and a team of bigger than 3.25 is just, like, initially, it just creates a lot of drag

because there is a lot of collaboration initially. Having more than three people means that you now, if you have a team of four, then one person is just doing coordination. So, like, if you look, if you look at the, there's, like, the theory of how many nodes have to be there, it's, like, the, and the two pizza teams and stuff like that, I feel like 3.25, six weeks gives you, like, the idea. And the 0.25 is, like, the PM or the product manager who has to craft the stories. It can be 3.5 or whatever. But 3.25 at six weeks, it breaks in between, reorient and, like, redo some part of the initial process, gets you to, and then at six weeks, you can show value. Your stakeholders can get an understanding, and you're demoing every week, too. So, it's going to be a crazy six weeks. Then you take maybe a breather and then start the whole thing, start the machine. There's at least three things, I think, that drive that chunking. And it is, you know, it's feasible to do something in six weeks, right? Like, one day would be too small, and a week would probably be too small, and, you know, to build it up from absurdness. So, you can do something significant in six weeks. And then I hadn't really thought of the second point you made, that it also means you're not afraid to, at worst case, throw away six weeks worth of work. And then also, you know, the third thing is, like, that's probably as long as your bosses are going to let you go without seeing if you're doing anything. So, you have to, like, demonstrate and kind of show progress to kind of refuel sort of the corporate permission and the resources to keep going. And, you know, like, you know, four to six weeks seems like about the right amount of chunking for that. You know, I wanted to ask this because it's one more avenue to kind of reverse engineer how to scope things, right? So, when you're thinking about how do we scope a backlog, how do we scope the items in the backlog,

in the back of your head, you're always like, and we have four to six weeks to be done with this. So, a backlog item isn't going to be, like, rewrite pricing, right? It needs to be scoped down to something that fits into that time period that we have. Exactly. And, like, at the weekly demo, you call your first line manager or whoever is, like, your most immediate stakeholder. At the six-week mark, you're calling the VP of line of business or the CTO. 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. Modernization is hard. You're going to have the original team maintaining the critical system. Now, you have this new team branching out code. 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? You do these for applications that are critical systems that make sense. And then we discuss the easy modernization, too. Like, this is, what I just showed you is, like, the Ferrari of modernization. But remember, we also discussed the Cambry and the Accord, which is, hey, let's just break this into UI and backend processing. Let's just break this into, like, some, this one-year file has eight more files. Let's just make this more file. There are cheaper ways of doing this, too. But you do this when you know that, hey, this system is critical for me to be competitive. It's going to make me revenue for the next five years. If I don't invest, Amazon is going to come and basically make mincemeat out of me. So, like, that's why you do it. To start to close out, does this process ever end? Yeah, that's a good point. The process has a point where active development kind of subsides and it goes into maintenance mode. So, you may not need as big a team for the entire life of the project.

But the thing is, if you do this right, like, all your legacy team now starts developing on these newer services. 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. So, there is a gradual shift of people working from the old to the new, right? Eventually, we should expect maybe a single person maintaining the old system and then everyone working on the new system. And then the cycle of life goes on. These services are ever evolving. As long as these services are being under development, like, this system keeps running. 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. 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? 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. 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. 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. 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. But, you know, getting those longer term enterprise architectural habits in place is hopefully something that people learn and put into effect. Because you'll always have legacy stuff, but at least you can make modernizing it easier than it was last year.

Yeah. The importance of these systems is going up, like, disruption is real. 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. Like, it's real. So, like, there is increased focus on modernization and keeping it going for their own strategic advantage, not just from an IT perspective. All right. Well, I think that's a pretty good place to end. Now, you, I'll put a link in the show notes we have to your blog and the one you mentioned. But do you have a Twitter handle or anything you would direct people to? Yeah, it's just my, it's just four letters, R, no, five, R-K-E-L-A. There you go. And, yeah, there's always fun stuff on your blog. Well, thanks for doing a little series here. We'll have to visit you again in the land of happy modernization and see how things are going. Thank you so much. All right. Well, as always, this has been a simulcast episode of Tanzu Talk, also streamed on our Twitch thing. Now, if you want to get other live streaming things, I think every Tuesday we stream at least one thing. If you go to twitch.tv slash VMware Tanzu, you can find that. And we're also always tanzu.vmware.com slash podcast. Find the show notes, everything else. So with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.