Aligning Tech Modernization with Economic Value

Most modernization efforts fail because they focus on technology first instead of the underlying economics. In this clip, we unpack why aligning IT projects to measurable value is the key to sustainable change.

Video Transcript

Mike Cottmeyer

If I’ve got to spend tens of millions of dollars and wait years to be able to do it well then it’s not particularly economically viable and it’s a huge risk. So, it’s not just find the business problem that’s worth the dollars, do the extraction, build the organization. It’s find the problem that you can solve in an incremental and iterative way, incrementally and iteratively extract and modernize and incrementally and iteratively build the organization around it and tie it up through governance.

And for us, because we started off as an agile transformation company, our kind of mental model was stabilize the system in place in the presence of dependencies start to reduce batch size and increase flow and then start to break down the technical dependencies creating encapsulated objects like you might in a composable enterprise and then we can fund independently those composable objects. What we’re really fundamentally doing with this; it’s really almost a reverse.

It’s like figure out the economics first and what you want to fund persistently, which things are going to be the largest force multipliers in our ability to solve economic problems. Those are the things we want to invest in. And which technical dependencies, which areas of technical debt, which areas of the applications need to be modernized and then start to run small batches through it and then stabilize the system and make sure that it operates in a reliable and repeatable way moving forward.

Stacy Gordon

Well, so the question I have about that is I think the biggest challenge is that people have is really defining that MVP, what is that minimal viable product? How do I make sure that it is small enough that the things that we are putting in that goal can be done? I think that’s got to be something. I wonder if we talk about a enough, because from what I’ve seen over the years, and it’s not always in modernization, but it’s in application goals or new feature sets and it’s like, okay, if we’re trying to build this thing and this is the minimum viable product, making a customer understand really do you don’t need all these other things, it’s going to make it more complicated and harder to reach that goal in 90 days. So how do you make sure that they understand that you can’t throw too much into that minimal viable product if we want, because we are looking to get something out the door in 90 days that’s going to start returning value.

And the more things you throw in, the bigger that thing that you’re trying to solve is, which is going to continue to, it’s not going to happen 90 days now. It’s going to happen in 120 days now. It’s going to happen longer. To me, there’s this dynamic that I don’t know if we talk enough about on how you walk them through the process to make sure that the chunks that you’re choosing to work on so that you can show time to value faster. There’s definitely a nuance to that and how you manage the customer.

Mike Cottmeyer

Yeah, for sure. What was going on in my head as you asked that question or made that statement was kind of interesting. It was almost like my brain wanted to take a step back and what I was kind of teasing out was this idea of a minimally viable product on one side that almost implies that maybe we’re building something from the ground up. What my brain was floating over to was almost like the idea of a minimally viable extraction, a minimally viable modernization. So one of my initial hypotheses is when we started going down this path a couple of years ago, especially around with AWS, was that we had had these monoliths that were moved to the cloud that were driving out control spend and preventing often those lift and shifted applications from being able to consume what we might call the high value strategic services that AWS can do. And my initial hypothesis was that yes, Amazon’s going to take a hit on the front side because their cloud costs are going to be lowered, but then there’s opportunity on the backside for them to consume more strategic services, which also has the net effect of making those customers more sticky to the AWS platform. So, they can’t as easily be enticed away with lower prices on the next contract negotiation or something like that.

And it’s fascinating because if I take it from a cloud optimization perspective, the minimally viable extraction might be something like, okay, let’s go find the areas of the application that are driving most of the costs and let’s extract and modernize those and see how we can then make that extracted object work with the rest of the legacy monolith. On one of the use cases we’ve referred to here recently, one of the challenges that they had is that it was yes, they were using a legacy monolith, but they actually had legacy business processes associated with that legacy monolith. And so as once we identified the business problem that they wanted to solve and we had our revenue increase hypotheses, we didn’t actually really extract the code out of that monolith. What we ended is rewrite it, rewrote it, and deprecated it. And when we had the opportunity to rewrite it, because the business and the technology organization were so closely aligned and both had a seat at the table, we could reevaluate the business processes, take a fresh look at the application and data architecture that were needed to support that, and then that flips into the other side of what you’re talking about that was more like, okay, now what is minimally viable in the presence of these new business processes and this new data architecture?

So, it’s kind of interesting and I’ll tell you, I think that’s what’s so hard about having these conversations sometimes because very self-aware as I’m even using these words, because what I try to do is I try to use words that are a high enough level of abstraction. So, they’re generally applicable in most settings, but then when people hear the messages, they’re like, well, what do you mean by technology object? I had somebody ask me that on LinkedIn the other day, what do you mean by technology object? And what I want to say is anything that can be encapsulated that provides a service, right? On one side it could be a microservice on the other side, it could be maybe an application that could be supported by a team, something like that. To me, it all comes back down to this encapsulation orchestration thing that I talk about all the time. So, it’s like I have this kind of riffing here at this point. I have this problem in lots of areas in my life right now. I’m trying to sort through just and create a mental model around. It’s like how do you have conversations about really abstract, important things when people are living in the details of it every day?

And so, you got to align people on concepts, you got to align them on the words you’re using. You have to understand the constraints that they’re operating within their particular world. You’ve got to, it’s almost like creating an instance of a language to have a very specific conversation that’s tough. And just even Stacy and some of the stuff that we’re talking about here, just the idea that you could have the business show up at the table, reimagine the business process while we’re extracting that technology object out of the monolith and do that in parallel in such a way that we can do the transformation, the teaming strategies and the governance and stuff on the other side. Even that I think is a psychological barrier for a lot of people that might hear this. And then that gets to your earlier comment that we made is like, are we selling to the CIO, the CTO or the CFO?

And I think that’s where a lot of this problem is going to have to eventually be solved and why it has to start with the dollars. Because at the end of the day, who else can solve the business and IT have to interact appropriately. They have to partner together. We have to look at the business process while we look at the technology so that we can actually solve the economic things that the company needs us to solve. And when you can get all that stuff aligned, magic can happen.

And when that stuff’s misaligned, I think that’s why we end up with agile transformation on one side doing its thing. You got the technology modernization, extraction, refactoring stuff on the other side. And I think if we can align it around the economic value prop that gets delivered incrementally and iteratively, bring the business and IT together to figure out what to extract and modernize, whether it be on business process side or whether it be on the technology side, and then organize around it and make it accountable and make it measurable on the backside. That’s the secret sauce in it.