Deliberate and Data-Driven App Modernization

Discover how organizations use business capability heatmaps and domain alignment to make deliberate, data-driven, and defensible modernization decisions that deliver business value at every step of the journey.

Video Transcript

Stacy Gordon:

We got to build the model, the heat map, we got to do the domain alignment, especially if you’re starting from scratch. That’s a lot of work and effort and expense before you actually even modernize one little thing. So how do you avoid this analysis by paralysis a year of just mapping and you deliver nothing?

Melissa Roberts:

Well, first of all, you scope it like anything else ruthlessly. So you don’t need an entire enterprise-wide capability model before you do anything. You start with the highest pressure business unit or domain and build that model on that heat map in that area and make the decision, deliver something, and then move on. The model expands as you go and is informed by real decisions rather than built in a vacuum. So the mapping exercise itself has taken a year, that’s assigned the scope was wrong to begin with. And you are not using the right approach that I am stating here, which is small chunks. What is that highest business value business domain that you’re going after? So if you use this approach, you can complete the scoped heat map in weeks, not years or months.

Stacy Gordon:

Hi everyone. Thanks for joining the conversation. My name is Stacy Gordon and I’m the director of strategic growth here at LiminalArc. I’m excited to be reconnecting with my friend Melissa Roberts to continue our conversation around why application modernizations fail. Melissa is a business architect and value engineer here at LiminalArc and has published a series of articles around application modernization and how organizations are bleeding money more often than not during their modernization attempts. So Melissa, let’s get right into it.

Melissa Roberts:

Sure.

Stacy Gordon:

Your last article argued most modernization efforts fail because organizations lack a decision framework. For someone who didn’t read part one, what does that failure actually look like inside a company and what’s the cost of getting it wrong?

Melissa Roberts:

Great question. So it looks like a multi-year program that is over budget, that when it finally delivers, doesn’t really deliver what the business needs. So what does that mean? Teams are rebuilding the applications. They’re building them in the cloud. They’re swapping out a database. They’re migrating his stack. Six months later, the business has the same issues. So the business is continuing to put in requests to make things work better. You’re not moving your market share like the strategy suggested that you would be doing. So what’s happened is nobody, it’s not a business decision at that point. It became the technology decision. And that’s the heart of it. Organizations are going to confuse. We need to modernize technology with, we need to improve the business. Those are not the same thing.

Stacy Gordon:

It’s interesting so often that it seems like people don’t really know that. One of the things I loved your comment was like you open your piece with the bowl of spaghetti image. First of all, I have to tell you, it made me think of like an old game called Kerplunk. I don’t know if anybody, you put the needles with the marbles, but I know that’s not exactly the same thing of what you’re doing here, but you talk about pull one noodle and four others break. Why is that interconnectivity the thing that makes modernization so hard to scope?

Melissa Roberts:

Well, a lot of it is because it’s the legacy system was never built with boundaries in mind. So they grew organically, either through a business request or technology needs. And over time, they started quietly depending on each other. And no one really knew that. So the moment you go to scope your technology modernization effort and you try to move one piece, three other things have broken and you don’t know why. There’s no documentation. No person is there anymore that started your legacy systems. So that’s why you pull one noodle and four others fall apart. So capabilities allow you to reason about that business problem. First, you can figure out what systems are entangled to help solve it. So then it helps your kerplunk, not kerplunk.

Stacy Gordon:

Okay. I love, thank you for tying it back to that Mattel game that just brings me back to my childhood. I think it’s got to be so frustrating. It’s like how documentation was a part of things as they went along and that’s part of like some of the core foundational issues for this. So when you’re going through your article, you talk about heat maps. And so help walk me through the heat map. You assess capabilities on value, performance and risk. How do these three dimensions combine to tell an executive where to spend the money and where to leave well enough alone? Well,

Melissa Roberts:

It’s a super cool concept. So each dimension is asking or answering rather a different question. So when you’re talking about the value, it tells you how strategic the capability is. So does it differentiate you in the market? So don’t take strategic as meaning like your HR system’s not strategic. It’s strategic because you cannot operate without it, but it doesn’t differentiate you in the market. You’re also looking at your performance. How well is it being delivered today? Is it fully automated? Does it need to be fully automated? Do you have the right people in place? Are your processes okay? And then you have that third dimension of risk. And that’s simply how flexible or inflexible it is to move. So think of your bowl of spaghetti. If that bowl of spaghetti, if that legacy application is inflexible and it breaks every time you try to change something, it’s a high risk.

When you combine all three of these together, let’s say you have a very strategic capability like customer service and your legacy system is a bowl of spaghetti. When you try to change something, that’s high risk, but you have to change it because it differentiates yourself. That’s a capability in the heat map that your executive is going to hone in on and is going to want to change. But if you have something like HR, it doesn’t differentiate you in your market. And it may not be flexible, but you’re not going to invest that much in it because it doesn’t move your market. It doesn’t move your strategy. It doesn’t move whatever business goals you have.

Stacy Gordon:

So ultimately you’re saying it gives you, instead of a list, you get a picture. So it’s a better way to kind of look at how all the things interact together. It’s almost like on a matrix, right? Of when you start pinpointing those items.

Melissa Roberts:

Absolutely. Yeah.

Stacy Gordon:

Okay. Well, I start to see why that would be a much better way to approach this at the beginning. And Melissa, you talk a little bit about strategic versus utility items. And so when you tell a leader that a capability is just utility, how do they take that? We talked a lot before about how ego plays a big part in this as executives continue to walk down the same path as people before them and these application modernizations fail. So knowing that there’s some ego here, is this a hard conversation to have?

Melissa Roberts:

It can be a very hard conversation, especially if that leader has spent years building and championing that system. But I try to reframe it before I go in and before it becomes personal. So utility doesn’t mean it’s that important. It just means that’s not where you differentiate. Every business needs utility capabilities like HR or like payroll. They all have to work. So the question isn’t, is the capability good or bad? It’s, is this where we win in the market? And if it’s not, then we just need to keep it humming and moving along as cheaply as we can.

Stacy Gordon:

I like how you say to frame it before you go in so it isn’t personal. I can see that that would be a huge differentiator when you go in to talk to someone about these issues because again, there’s a lot of pride in their business. It’s their baby. And I can see any chance you get to kind of soften that conversation would make it go over way easier. So if we were to look at some counterintuitive points in this piece, the heat map tells you where not to invest. But in my experience, most firms are actually pitching you to do more, not deliberately less. So what are your thoughts on that?

Melissa Roberts:

So I think it’s the most valuable and the most underused part of the exercise. Like you said, most modernization pitches are doing around more, not less. But the real value of your heat map is giving you permission to stop. If the capability is already performing well and it isn’t strategically differentiating it, then why continue pouring your money in a modernization budget? That’s just a waste. It’s not moving you where you need to be. Organizations tend to hemorrhage money on exactly that pattern, improving things that don’t need to be improved because nobody had the data that they needed to say to leave it alone. Saying

Stacy Gordon:

No

Melissa Roberts:

To a modernization request with a heat map behind you is a very different conversation than saying no to a gut fill.

Stacy Gordon:

Yeah. It’s so interesting on the permission to stop. I talk a lot of times to my customers and it is prioritizing the work that needs doing. And it’s so oftentimes that that’s a different concept that people don’t hear very often. And it definitely stands out when they’re like, “You mean I don’t really need to spend money and budget on this and I can now allocate that somewhere else where it’s a better bang for my buck where it’s going to help me stand out in the market.” I really like that. But I’m going to challenge you a little bit on the heat map concept. So the heat map scores value performance and risk, but ultimately it’s based on people’s judgment. So you have two architects in a room. They could rate that same capability very differently. So how is this genuinely supposed to be more objective than those gut feel decisions that we were just talking about?

Melissa Roberts:

Well, Stacy, that’s a fair challenge. And I won’t pretend that the heat map is going to remove judgment entirely. It doesn’t. But it’s important to keep in mind that it’s not just two architects in an ivory tower doing this. It’s the business coming together and scoring it. The heat map does make the judgment visible, structured and comparable. And what’s really, really cool is when you start scoring these and folks say, “Oh, I think this is strategic,” or, “Oh, I think this is high risk.” You have a conversation of things that were inside the person’s head that were never brought up before. So yes, it’s subjective, but that objectivity isn’t eliminating the subjectivity. It’s forcing the subjectivity into a consistent framework.

Stacy Gordon:

Okay. So the key element here, of course, then ultimately is making sure you have all the relevant parties in the room to be scoring together. And that is how it really creates, it bubbles up differentiated thoughts that people have on this kind of stuff. So I’m assuming these exercises are live, right? They’re happening with everybody in the room. So I mean, tell me, do they get heated? Have you got some fun stories to share? I mean, who leaves the room first because they’re mad? I mean, it’s got to be.

Melissa Roberts:

Honestly, it’s probably the architects that leave

Stacy Gordon:

Okay. Well, maybe we can live Zoom that and do a play by play the next time that we get together because I think that’d be pretty interesting. Yeah.

Melissa Roberts:

You get a technical architect in there. They have very, very, very, very solid, usually correct opinions.

Stacy Gordon:

Well, I wonder if it’s interesting for them too, because I think sometimes everybody can put blinders on and only think through their lens. I know on teams that I worked in before, how important it is to make sure that you’re constantly talking to your technical teams about the business goals because they can get disconnected from those. And when you understand them, it helps you make decisions in a different way. So, okay, everybody in the room, and then we’ll bring them out for beers afterwards to say thanks for all the pressure filled hard work. Absolutely. Yeah. So moving on, your framework presupposes you already have a capability model and a heat map, but most organizations don’t, right? Or maybe they have a half built one that nobody trusts. Is this only useful to the minority who’ve already done the hard part? What does someone do if they’re starting from ground zero?

Melissa Roberts:

Right. So you’re right. Most organizations don’t have a fully baked business capability map, and that’s okay. So the article does assume the model exists and that’s deliberate because building the model is its own body of work and deserves its own treatment. If you’re starting from zero, the answer isn’t to skip straight to modernization decisions. You need to step back. You need to invest in building what I would consider a minimal viable capability model first. So what that means is you start with the domain or the area or the concern that you’re working on first. I’m going to pick on customers again. If it’s customers and customer service, you start on that first. You don’t care about your payroll or your HR capabilities. You care about those customer service capabilities.

Stacy Gordon:

Okay. Well, so we talked, I know, about boiling the ocean. So this is saying it’s okay if you don’t have this, but don’t try to take it all off in one bite. Let’s prioritize and focus on one effort. So I think hopefully that’ll make some people feel a little bit more comfortable out there that there is a place to start that is actually reasonable to think that you can actually get it done.

Melissa Roberts:

Yeah. Yeah.

Stacy Gordon:

You talk about Conway’s law as a design advantage rather than a warning. Most people invoke it to explain why systems turn out badly. How do you flip it into something that’s more deliberate?

Melissa Roberts:

Yeah. I mean, you’re right. People do tend to invoke it after the fact. They do that to explain why their architecture turned out tangled. Well, of course it’s a mess. Look how your teams are organized. So yeah, I’m going to blame Conway’s law. I’d rather use it before the fact. So systems produce what they’re designed to produce. Then the lever isn’t fighting that tendency. Okay? It’s designing your teaming structure deliberately. So the system produces is the one what it produces is what you want.

Stacy Gordon:

Aligning

Melissa Roberts:

Your teams to domain boundaries on purpose. And Conway’s law starts working for you instead of against you.

Stacy Gordon:

Well, I like flipping that for sure. So talking a little bit about capabilities. So you say that capabilities are non-redundant, but domains can be redundant. So why does that distinction matter for someone making, let’s say, a refactoring decision?

Melissa Roberts:

Yeah. I mean, it tells you what kind of duplication is a problem and what isn’t. So you see customer showing up in five different domains. Your instinct might be to automatically consolidate, “Hey, there’s only one capability call customer.” But the capabilities are non-redundant. It’s where the duplication is that shows that red flag. So domains, when I talk about domains, you’ve heard me a couple of times. They’re different. It’s the same concept, legitimately means different things in different bounded context. Then you have to understand which layer you’re looking at. So for example, because this is very complicated for non-technical folks. Thank

Stacy Gordon:

You, thank you, thank you. Okay. Okay. You’re picking up what I’m laying down. Okay. Pull out your crayons here. Give me some examples. I hope I’m not the only one, but at least let’s bring it into real life. So walk me through it.

Melissa Roberts:

Okay. So let’s take. I’m going to take billing, for example. So you have a customer, they’re going to buy something from your website and they have to pay for it. They get invoiced. Now they get invoiced and payroll or finance also has an invoice. Do they mean the same things? No, because an invoice in finance could be an invoice for your vendor. It could be an invoice for your customer. It could be an invoice for something else. But in the customer’s world, their invoice is always what they’re being charged, always what they have to pay for. So in that instance, it’s not the capability of invoicing or a customer that’s the same. Those are two different, distinct things in a domain.

Stacy Gordon:

Okay. So how about the flip side? If you have the logic, if the same logic. Okay, let me make sure I’m getting it right. The same logic is in two places, that’s the problem. So how does someone tell the difference between healthy duplication and the kind that’s quietly costing them money? Yeah.

Melissa Roberts:

So again, the difference is the business justification, like you said. So billing cares about payment history and credit status. Shipping cares about delivery address and preferences. Those aren’t the same concept, wearing different clothes. They’re genuinely different responsibilities. So you can’t force them to be the same thing. Billing cares about the payment history of that customer. Billing cares about were they invoiced? Were they not invoiced? Net 30, net 60, whatever it is. The customer, from a customer service perspective, just cares that they got the bill.

Stacy Gordon:

Right. Right, right, right.

Melissa Roberts:

So those business rules, those business justifications are different. So it’s okay to have the customer billing and billing and finance be in two separate places.

Stacy Gordon:

So what I think is so interesting about this conversation truly is that this is not easy to untangle. And so it probably explains why you have so much duplicative data and why people are dealing with the issues that they have today. Because it really takes almost an outside, it takes an outside consulting firm or a very dedicated effort to sit down and start understanding, again, what is okay to be duplicative and what is not. So I don’t think that that’s easily solved, but can be solved, which is I think what you’re helping me understand.

Melissa Roberts:

Yeah. So if we take, for example, pricing. And that pricing is you find pricing in multiple places. Let’s just take two for simplicity. You find pricing in two places. Pricing is pricing, is pricing. I mean, you don’t change the business logic for pricing. But if you see that logic in one area and it’s different than the logic in another area, that’s a red flag. A place where you want to dig in and say, “Is this duplication business justification or not?” And it probably is not.

Stacy Gordon:

Okay. All right. Well, at least now I know what I’m supposed to be telling people to look for. I just find that just so interesting because it’s easy to gloss over, but it makes such a big difference. I can tell once you get into it. Switching tracks. When we talk about wanting to refactor or refactor as warranted, you say the target isn’t necessarily a shared service. You designate an authoritative context and have others consume it via API. Why is collapse it all into one service so often the wrong move for someone to do?

Melissa Roberts:

Well, the goal isn’t unification for its own sake. It’s removing that accidental complexity while preserving the autonomy that lets the team move fast. So what do I mean by that? If you collapse everything into one service, then you’ve just had everyone having to wait on that one team to get everything done. And that’s the exact opposite of what we’re trying to do. So think of it as encapsulating it too much.

Stacy Gordon:

You

Melissa Roberts:

Encapsulate what you need to and you orchestrate everything else. So that’s the exact problem that bounded contexts are designed to avoid.

Stacy Gordon:

It seems just like for a $2 word, which I’m known for here at Luminal Arc, it sounds like it’s just creating another bottleneck for you. You’re not able to move fast or accelerate on kind of any business decision because now it’s all in one small area to get it done.

Melissa Roberts:

Yes. As long as you remember that there’s only one authoritative source of the truth, which is that one API, and everybody who goes after that API is going after that source of truth. They don’t have their own sources of truth about the same

Stacy Gordon:

Thing. Okay. That makes sense to me. So when a lot of what I know Luminal Arc talks about is aligning teams to domains and that’s reorganizing people. And that is hard. That is not easy to do, especially in a large enterprise organization. So I’m going to ask you kind of a tough question. Is this your approach on, are you smuggling in like this massive organizational change program, but we’re going to call it an architecture decision? Is it really realistic that a modernization budget can also move the organizational chart?

Melissa Roberts:

So a couple of things. One is when we’re talking about aligning teams to domains or business capabilities, that’s not an organizational change. That’s not an HR change. That’s just a teaming structure change. So I can give an example if you have in your organization, all your business architects in one area and they’re reporting to one person, that’s not working. You need to spread them out along the different business capabilities. They still report to the one person, but they’re also dotted line to their team. And that’s their first priority is their team. So the realistic. It’s not a small ask, but the realistic answer is you also don’t need to do this for the entire organization. Pick that one domain, that one strategic area, that one business capability that you need to work on first and do that. And then slowly start rolling out the other changes.

Stacy Gordon:

Well, and the good thing about that is, and I know it’s something that we talk a lot about at Lemonal Arc, is doing things in prioritize small scoped work slices because it also allows you to, within your organization, something that may be foreign to them that they are really questioning. You can showcase how it’s going to work and then you can build credibility. You can build safety in order to continue to roll this out into other areas. So it definitely, it’s nice to hear that you can do it in a way that is smaller. And it doesn’t, again, going back to that boil the ocean. You don’t have to do it across the entire enterprise all at one time because again, then ultimately things will fail.

Melissa Roberts:

Right. Right.

Stacy Gordon:

I do have to laugh because I tease all of my friends that have been in consulting forever. And I love the phrase, “It depends.”

Melissa Roberts:

Oh, yes.

Stacy Gordon:

And I get it. I get it. I get it. I get it. But if I’m an executive who has to make a decision on Monday morning, if I use the word it depends, that sounds a little fuzzy. I mean, how do I turn it depends into something someone can actually act on?

Melissa Roberts:

Okay. Well, that’s a fair hit. We do love that it depends.

Stacy Gordon:

It depends.

Melissa Roberts:

But it depends isn’t fuzziness. It’s precision about what the answer depends on, which okay, is also kind of fuzzy. But the heat map and the domain alignment exercises exist specifically to convert the it depends into it depends on these three things, three measurable things. And here’s where we land on each one of these for a specific capability. By Monday, an executive doesn’t need to know the universal rule. They don’t need to know the whole organization. They need a ranked list of which capabilities to focus on first. And that’s exactly what that heat map gives you. A prioritized list with the reasoning attached.

Stacy Gordon:

Okay. So even though they have all the factual credibility to support it, I guess they can still say it depends as long as there’s the three things on the backside. So let’s pivot and focus on getting buy-in. Your title says Business Value at Every Step. This approach talks about delivering value incrementally versus the Big Bang rebuild, where it takes forever to see anything. Talk to me about that.

Melissa Roberts:

Yeah. I mean, simple terms that you’re no longer scoping the effort around rebuilding the application. You’re scoping it around improving your capabilities. And a capability can be improved in increments. A process changed here, a targeted refractory there, a piece of automation somewhere else. Each one delivering value on its own without waiting for some grand unifying rebuild finish. And the heat map lets you sequence those in increments by where the value performance gap is widest. So the business sees improvement step by step instead of holding its breath for three years and going, “Did it give it to me? I don’t know. Three years are up. Do I have it?”

Stacy Gordon:

Well, I like too that the heat map helps you understand where to focus first. So again, contributing back to this business value at every step, moving things into production faster rather than waiting for 18 months. I mean, by 18 months, half the people on the team could have moved on to something else, but that’s another story for another day. Another day. In your article, you quote, “Tune and parent on needing stakeholder buy-in and a clear line to strategic priorities.” In practice, how does the heat map become the artifact that gets a skeptical executive to actually say yes?

Melissa Roberts:

Well, first and foremost, it speaks the executive language instead of an architects. They don’t get excited about microservices. Shoot, I don’t get excited about microservices or refractory patterns at all. They get engaged when you show them a visual that says this right here, this is where your strategic priorities and your actual performance are furthest apart. And here’s where it’s costing you to leave it that way. So the heat map turns in architectural conversation, which is important into a business conversation. And that’s what earns the buy-in, not the technical elegance of the plan, but the clarity of the trade-off.

Stacy Gordon:

Well, and it’s so different than probably most of the conversations they’re having. I mean, the premise of this whole conversation is that application modernizations fail and there’s billions of dollars that people are contributing to year over year in that failure. And so it’s just nice to see that the heat map is at the core of all of this. And it’s allowing the team to have more informed, better researched, just better conversations in general and very different than they’ve probably ever had when it came to tackling an event like this.

Melissa Roberts:

Oh, absolutely.

Stacy Gordon:

When I think of why customers modernize, a lot of times it’s something that’s forced. So it’s more of a vendor end of life. There’s a skills gap that we have, a compliance deadline, maybe We just acquired another company and we have two tech stacks colliding. Does this framework actually survive contact with a forced timeline or is it a luxury for organizations that just aren’t under the pressure yet?

Melissa Roberts:

It does survive, but it’s going to change its role. Like you said, you’re forced. You don’t have the luxury of doing a full capability assessment before you act, because deadline’s a deadline. If it’s compliance, you’ve got to get it done. If it’s an M&A, you’ve got to understand what you’re doing. What the framework does give you in that situation is a faster, sharper way to scope the forced work. So even under pressure, you know which capabilities the force change touches. Then you know which of these are strategic, which are utility. It helps you decide where to invest the extra care and where it’s fine to do the minimum to get compliant or supported. Doesn’t remove the forcing function, but it stops the forced work from sprawling into capabilities that didn’t really need the attention.

Stacy Gordon:

Okay. So the basic message is, hey, be more proactive. Don’t get into a forced situation, but you’re lucky. If you do, you can still use this same methodology to help you. But just again, like you said, it changes its role a little bit. Yes. So kind of another question here. The framework exists to stop wasted spend, but okay, we got to build the model, the heat map, we got to do the domain alignment, especially if you’re starting from scratch. That’s a lot of work and effort and expense before you actually even modernize one little thing, even in your prioritized work effort thought process. So how do you avoid this analysis by paralysis a year of just mapping and you deliver nothing?

Melissa Roberts:

Well, first of all, you scope it like anything else ruthlessly. So you don’t need an entire enterprise-wide capability model before you do anything. You start with the highest pressure business unit or domain and build that model and that heat map in that area and make the decision, deliver something, and then move on. The model expands as you go and is informed by real decisions rather than built in a vacuum. So if the mapping exercise itself has taken a year, that’s assigned the scope was wrong to begin with. And you are not using the right approach that I am stating here, which is small chunks. What is that highest business value business domain going after? So if you use this approach, you can complete the scoped heat map in weeks, not years or months.

Stacy Gordon:

Well, I think that’s something that executives definitely love and just like this conversation, probably something that they don’t hear very often. So I do believe that there’s people out there that are going to say, “I have a core system that can’t be modernized incrementally. You can’t half migrate a ledger or a system of record.” So where does this value at every step break down? And what do you tell someone whose hardest problem is this monolith that resists slicing? How do they go about it?

Melissa Roberts:

So I have a really cool example of someone who, an organization who did training or who is doing training. And they needed to replace their legacy monolithic system. It was a third party vendor and they were going to replace it with another vendor that was more core to what they were doing. But the cool thing was, is at first they were going in thinking they had to replace everything at once and they wouldn’t get anything for several years. But once we started breaking things down and building those domains and attaching them with the capability heat map, what we saw is we could do bits and pieces for them. We could do an upfront customer, let’s just say it’s an upfront customer inquiry system where they wanted to know what kind of things they could take and what would be beneficial for the customer to take.

They could fill that out and then they can see what was available. That’s part of the larger legacy system that was easier to put in, or it will be easier to put into production.

Stacy Gordon:

So sometimes they just have to have a little trust in the beginning to say, even though it seems foreign to them, that listen, we’ve seen it all. We’ve seen the largest of monoliths where people say there’s absolutely no way we can do it. But once we apply the approach, the Liminal Arc approach to this, what you’ve been so eloquently talking about, it’s like the light goes on and they’re like, “Oh my gosh, I would’ve never thought I could do this. You’ve helped me. You’ve given me kind of the keys to the castle or you’ve given me the insider’s tip on really how to do this.” It’s just so interesting.

I think it’s probably ultimately going back to why even like we’ve said a few times we’re having this conversation is that so often these modernization efforts fail, but they don’t have to if you just take a different approach. And just your example showed how you had a customer sitting there going, “There’s no way we can do it.” And the lights went on for them and they were like, “Oh my gosh.” And I’m sure they felt it like it was their birthday and they got such good news and information. So you’ve given so much great insight. So as we start to kind of close it up, help me here. If there is a leader who has budget, he’s got some money and his instinct is to rewrite, “I’m going to go tackle the oldest, ugliest system first because I got my money. I’ve been putting business places together for this for the last nine months.” What would you tell them they do before they ever touch a line of code?

Melissa Roberts:

Stop. Put the brakes on. If you don’t have your capability map, which like we said, most organizations don’t, what is that business problem you’re trying to solve? What is the value prop you’re going after? What is that strategic need that needs to be met? Then hone into those business capabilities. I keep bringing up customers are on my head lately. I don’t know why. If you’re customer service, if you need to get more market, then look at that customer aspect and find out. If it’s for whatever reason HR, probably not strategic, so you don’t need to refactor that right now unless you’re out of compliance, then you might need to. So it’s asking those right questions and determining where you actually need to go. Not the whole, it’s all ugly and I have to do it right away.

Stacy Gordon:

From your lips to God’s ears, girl, I hope everybody heard that. The answer is stop. Melissa, I want to say thank you so much. You have really opened my mind. There is a better and different way to approach application modernization. And just, I hope everybody listening, make sure that you are not one of those companies that continue to fund the bloodbath of failed modernizations. You don’t have to. So Melissa, help me share with the folks out there, where can people find part one of your article, the rest of your work? How can they get in contact with you?

Melissa Roberts:

So part one and part two of my article, you can find on the LiminalArc website. So feel free to look there. And you can contact me. You can reach out via LinkedIn if you’d like to talk to me more about this.

Stacy Gordon:

Oh, awesome. Well, again, thank you so much everyone. That’s a wrap. If you found this valuable, please give us a like. How about a comment as well? We’d love to chat with you. And really, if you found it valuable, please share it with your friends. And as always, the team here at Luminal Arc is here to help and chat with you about your upcoming modernization efforts. Reach out to me and I’ll be glad to get the team together for an initial call. Until then, enjoy the long days of summer. See you next time.

This video comes from our management consulting practice, which specializes in designing and implementing operating models that align governance, processes, and technology to drive measurable business outcomes.