Two earlier pieces in this series made connected arguments. The first, Product Ops is Necessary but Insufficient on Its Own, argued that improving delivery execution rarely fixes a value realization problem on its own, because the real constraint is usually upstream: in the operating model, and specifically in how the business allocates capital and accountability. The second, Decision Friction is a System Design Problem, argued that even the right operating model will seize without governance: the deliberately designed system of decision rights, evidence flows, and shared visibility that connects strategy to execution.

Both are necessary. Neither, on its own, is sufficient. There is a third layer that neither piece addresses. It sits above the delivery system, above the governance, above the operating model itself. This piece is about that layer.

One note on timing. If your delivery system is still unpredictable, slow, or structurally unreliable, fixing it is the right priority, and the arguments in the earlier pieces apply directly. This piece is for a different inflection point: organizations where delivery is working, governance has tightened, and value realization still isn’t moving in proportion to the investment made in transformation.

The Diagnostic Gap

At some point in this version of the problem, a difficult conversation happens that nobody quite knows how to have.

Your transformation has taken hold. Teams are shipping consistently. The operating model has been redesigned around stable product teams with clearer ownership. Governance is more deliberate. By most available measures, the hard work is done.

Value realization still isn’t moving.

The temptation is to return to the delivery system: tune the cadence, clarify decision rights, improve feedback loops. This is the wrong diagnosis. The constraint isn’t inside any of those systems. It sits upstream of all of them, in a question the transformation was never designed to answer: which capabilities should this business be building, and why?

That question is harder than it sounds, particularly in large enterprises. Many operate in B2B markets or at one remove from the end customer, where products have been in maintenance for years. Capability investment has long been driven by feature requests, client commitments, or internal efficiency agendas rather than systematic inquiry into where the market is actually moving. In many of these organizations, researchers, designers, and product managers believe it is their job to answer this question. Their work is not integrated into the investment decisions the business is actually making. Customer evidence sits in product teams. Capability priorities are set at the portfolio level. And the two rarely meet in a way that materially changes where capital flows.

This is a structural condition, not a capability gap. Designing the integration is the fix. Hiring better researchers or running more discovery sprints won’t close it.

What the Delivery System Presupposes

Teresa Torres makes an argument I find compelling: that Discovery and Delivery are co-equal disciplines. Delivery asks whether we can build something and sustain it. Discovery asks whether we should, and whether it will create value.

Enterprise transformation has, rightly, invested heavily in Delivery. Not from ignorance of this duality, but from necessity. The delivery system in most large organizations is genuinely broken: unpredictable, expensive, and slow to surface what isn’t working. The predictability gains from fixing it are real, and the operating model changes that enable reliable delivery are worth making on their own terms.

But the systemic implication of Torres’s framing is that organizations haven’t yet accounted for the other side of that duality with anything close to the same rigor. Organizations have invested in building the thing right without matching that investment in building the right thing. That asymmetry isn’t incidental. It’s the structural condition that produces the value realization gap.

And the consequences become visible in competitive markets. Smaller companies and startups, unburdened by the delivery complexity that large organizations have spent years trying to solve, are often closer to the market precisely because they can’t afford not to be. They don’t have the luxury of a capability brief that was written two years ago and never revisited. They build, observe, and adjust, and in doing so they compound capability advantage in the segments where the large enterprise has stopped looking closely. By the time the enterprise notices the gap, the startup has the differentiation and the customer relationship. The delivery system the enterprise spent years perfecting executes at scale in a direction the market has already moved on from.

The Integration Layer

The gap between customer evidence and capability design doesn’t close itself. Closing it requires specific work. In a well-designed organization, that work sits with the Portfolio layer.

Portfolio teams are positioned to do something neither product teams nor executives can do in isolation: integrate the market signal with the strategic frame. Product teams are closest to the customer evidence. Executives own the investment thesis. Portfolio is the interface between them. It translates what the market is telling the business into the capability priorities the business should be betting on, and directs those priorities back into the delivery system as an explicit brief. This is precisely the kind of evidence-informed, hypothesis-driven prioritization that the prior pieces argued governance should enable. The operating model creates the structure for it. Governance creates the forum. The integration layer is the evidence that makes the decision real rather than assumed.

But this work requires more than positional access. It requires craft.

Discovery, done with rigor, is not a matter of collecting customer requirements or documenting feature requests. It’s a discipline of investigation: understanding the pain points and gain creators that matter to customers at root cause, not just the surface-level asks that get escalated. A customer who asks for a faster report is often telling you something about a decision they need to make more quickly, or a process they are trying to stop managing manually. The surface request isn’t the problem. The underlying need, and whether solving it creates something the customer cannot easily find elsewhere, is what makes the evidence strategically useful.

That distinction matters because it connects directly to the investment question. Discovery evidence only becomes valuable to the business when it is filtered through a commercial lens: not “would customers value this?” but “would solving this create monetary value: through differentiation, retention, or the ability to serve a segment the business is currently locked out of?” Customer benefit and business value are not the same thing. Conflating them leads to products that are genuinely useful but commercially irrelevant, and to capability investments that are hard to justify when the business case is examined.

This is where human-centered design practice, user research, and product management discovery converge on the same function: producing the evidence that grounds Portfolio-level investment decisions.

What Good Discovery Signals Look Like

You don’t need certainty to change direction. But you do need evidence that points clearly enough to justify the investment. Four signals that do:

Five different customers. The same root problem.

One complaint is noise. The same underlying issue surfacing across five separate segments, in different forms, from different people, is a pattern worth acting on. It usually means the market has moved in a direction you haven’t designed for yet.

They say one thing. They do something else.

When customers build workarounds, use a competitor for one function and you for another, or quietly abandon features: that’s your real discovery data. Behavior tells you what surveys and roadmap requests don’t. Trust the workaround over the stated preference.

“Good enough” has become their dealbreaker.

Some capabilities have quietly become the price of entry in a segment you already serve. Being behind on those is a retention risk, not just a product problem. The urgency is different, and so is the investment case.

A smaller competitor is growing in a space you’ve ignored.

This is usually the last signal to arrive, because it requires looking outward. A startup winning in your market with something you don’t offer has found a customer need you deprioritized. That gap has a commercial price tag, and it compounds while you’re looking inward.

The weight each signal carries will vary by market maturity and where your organization is in its transformation. All four are worth scanning for regularly, not just when value realization is already in question.

The test across all four is the same: if you addressed this, would it create monetary value for the business, not just a better experience for the customer? Customer benefit matters. But it doesn’t make the business case on its own. Discovery done well produces both.

When the Signals Point Somewhere the Business Doesn’t Want to Go

The four signals above assume discovery is pointing you toward better investment within your current direction. Sometimes it doesn’t. Sometimes the evidence points somewhere the business isn’t organized to go: a market your existing customers don’t represent, a capability set your current products don’t support, a direction that requires cannibalizing what you’ve built rather than extending it.

Consider a business that built a platform to serve an entire market, including competitors of its own core business. The platform generates real revenue. The customer relationships are established. But the discovery evidence is increasingly clear: the highest-margin, highest-growth application of the same capability is not the external market. It’s the parent business itself, which has been systematically under-served because the platform was designed for neutrality rather than for the use case where it would create most value. Exiting or deprioritizing the external customer base isn’t a complicated technical decision. It’s an organizational one: abandoning certain revenue in pursuit of a higher-margin direction, and acknowledging that years of serving the broader market were quietly constraining the business’s most valuable capability.

This pattern repeats in different forms across industries. A financial institution that offers its payments infrastructure to competitors because the external revenue looked attractive, while its own products run on a slower, less capable version of the same thing. A media business that has optimized its technology platform for third-party publishers, at the cost of the features its own editorial teams most need. In each case, the discovery signal isn’t ambiguous. The margin profile, the growth trajectory, and the strategic coherence all point in the same direction. What makes it hard is not the evidence. The system was designed around the customers it currently has: the existing contracts, the account relationships, the revenue forecasts it has built around them.

This is structurally uncomfortable in ways that have nothing to do with the quality of the discovery. Large enterprises are, by design, optimized for the customers they already have. The investment thesis, the governance, the sales motion: all of it runs toward the customers who are already paying. Discovery that challenges that direction isn’t just inconvenient. It’s hard to act on, because the system wasn’t designed to fund investment against its own base.

This is also, frequently, how disruption takes hold. Not because the enterprise missed the signal; often they didn’t. It’s because the signal contradicted what the business had organized itself to do. The startup found the gap precisely because they weren’t carrying the weight of an existing customer base that needed to be protected.

The honest implication of taking discovery seriously at the enterprise level is that the evidence will, periodically, point not to a gap within the current model but to a question about the model itself. Whether the existing customer base is the right one to optimize for. Whether the margin on that base justifies the opportunity cost of not pivoting. Whether the capabilities being invested in are becoming commodities while a higher-value direction goes unexplored.

Discovery is working exactly as it should. The harder question is whether your organization, with its governance, its investment logic, and its appetite for cannibalization, is designed to act on it.

The organizations in this position, with delivery working and value realization lagging, are not failing at execution. They are succeeding at the wrong thing.

The diagnostic question for your organization is not how to make the delivery system more effective. It is: what is the delivery system actually delivering toward? And who, in your organization, is formally responsible for ensuring that answer is grounded in evidence rather than assumption?

If you cannot name that clearly, not as a function but as a practice with methodology, rigor, and a deliberate integration point into the capability decisions the delivery system executes, the delivery system is a precision instrument pointed at a target that someone chose without enough information.

The discipline that closes that gap isn’t new. It is the oldest idea in product development. What is new is the recognition that it belongs not just inside product teams, but inside the investment logic of the enterprise: the upstream input that makes every downstream decision better.

This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.

Nearly 80% of enterprise application modernization efforts fail, and the reason has nothing to do with choosing the wrong technology. In this conversation, Melissa Roberts, business architect and value engineer at LiminalArc, explains why modernization programs are designed to produce technology outcomes instead of business results, and why that design flaw is what kills them.

Melissa and Stacy Gordon walk through the four primary drivers forcing enterprises to modernize, the IT/business alignment problem that stalls most programs before they start, and how a capabilities-driven strategy changes what a modernization program is designed to deliver. If you’re leading or influencing a legacy modernization initiative, this is the diagnostic you’ve been missing.

Video Transcript

Melissa Roberts

I’ve worked with companies that did not even create benefits cases. They didn’t have strategic goals. They didn’t have your OKRs and KPIs and they just funded whatever they thought was the best thing to fund because they had feelings that it was a good thing to do. And that’s both on the business side and the IT side. And I’ve been in organizations where business is pretty solid. They may not have their business capabilities. That’s easy to do for them. But what isn’t there on the IT side is that connection because they have their own goals. So those goals and business goals don’t come together. So you’re at odds there. So that also makes the modernization difficult if you can’t get on the same page of what you’re trying to solve.

Stacy Gordon

Hi everybody. My name is Stacy Gordon and I lead our strategic growth initiatives at Liminal Arc. Today I’m joined by my colleague, Melissa Roberts, one of our business architects and value engineers at Liminal Arc who wrote an awesome new article titled Why Most Application Modernization Efforts Fail and How a Capabilities Driven Strategy Can Stop the Billion Dollar Bleed. I don’t know about you, but whenever I hear a billion dollar bleed that an organization is suffering, I’m going to stop and take note. Sounds pretty stressful. I’m going to kick us off, Melissa, by focusing on a pretty startling statistic that you call out at the beginning of your article and it states nearly 80% of modernization efforts fail. You’ve got to help me here. Why do you think organizations keep spending billions of dollars on something that fails way more often than it ends in success?

Melissa Roberts

Right. So that is the billion dollar question. So the reasons for modernization really don’t change. So an organization will try it, it fails, it’s spent a lot of money, but they still need to modernize. So they have to try it again and they have to try it again. So you either try it, you succeed, or you don’t exist as a business.

Stacy Gordon

Okay. That is just crazy to me that they keep repeating the same old patterns. So I think let’s kind of get into that a little bit. I picked up on a theme in your article and it really resonated with me, to be honest, because I think I do this a lot. But when it comes to modernization, the theme was most organizations seem to start with the end tech result. So the answer to our problems must be, let’s move all of our stuff to the cloud. Or now with everybody talking about AI, we’ve got to do AI. Let’s implement some AI. I don’t know where we’re going to do it, but let’s do it. Let’s just make it happen, everybody. So why do you think so many companies seem to start with the perceived solution, the solve to all of our problems versus, okay, wait a minute, why don’t we start with the problems that we actually are trying to solve and go from there?

Melissa Roberts

So the short answer is it’s easy to do it that way. It’s easy to hear, oh, AI is the new thing that’s going to fix everything. So we’re going to do that or cloud. We got to move things up to the cloud because we were told that’s the thing we have to do. But what’s really occurring is traditionally IT is considered not part of the business. So if they’re not part of the business, why do they care about business outcomes? Therefore, the technology and the technology says to move to AI, technology says move to cloud. So you couple that with this whole innovation of the marketing of the hype around everything and it’s not surprising that they just go for it. They go for the solution and not the business value.

Stacy Gordon

I do think it’s interesting that you talk about IT not being part of the business. I’ve only been at Luminal Arc for a short amount of time, but I hear us talk a lot about silos. And in my mind walking in, a silo meant often more about data. Data is in silos and that makes sense to me. So help me understand, is this a silo problem based on how the organization is set up that allows IT to operate over here without thinking about the whole of the business?

Melissa Roberts

Yeah, I think it can be a constructed silo. So culturally it’s a silo. Your IT, you’re in the back of the office. You don’t help us do anything. We are the business. We’re the important ones is what I’ve heard in the past.

Stacy Gordon

Yeah. I’ve read tons of articles just as I kind of sit forward with CIOs and CTOs and kind on the sales front of things. I hear and read articles about this clash between IT and business. And I know that at Luminal Arc, we’re constantly trying to educate people about how you can’t keep these two entities apart, that if you really want to do change and obviously modernization, you can’t keep them apart. They have to be talking to one another, aware of what other people’s pain points and concerns are and issues are to really pull things together. So that kind of leans me into, okay, you’re telling me we have to modernize. If the business is going to survive, be competitive, grow in the future, they have to modernize. And you even estimated that over the next five years they’re going to be spending 51, again, billion dollars on application modernization. And you talk about there’s four primary drivers that organizations are looking at that says, these are problems that we have we’ve got to modernize. Help me understand what this is and talk to me a little bit about more these four core things that organizations are challenged with and why they have to modernize.

Melissa Roberts

Sure. I think they’re all equally important, but some may ring bells with an IT department more than others. So cost. Cost is the one that IT is going to focus on most and probably the entire business. The older or more inflexible your application is, so you can’t make changes quickly, you have technical debt is going to cost you a lot of money and that’s your budget that’s being eaten away that you could be spending on something else. So the other is the scale. I briefly mentioned that when I said it was inflexible. So as market changes and it changes quickly, you can’t change because you’ve got this huge legacy application or this huge, I’ll call spaghetti we’ll talk about in a few minutes, I’m sure, applications that it just doesn’t move at all. You’re losing your market share there. Then another—

Stacy Gordon

One question real quick, what you said I thought was interesting. And I think maybe this is what you’re talking about from a competitive set. You’re like, there’s lots of legacy debt so they can’t change quickly. So it’s like if I’m a retailer and my competitor just implemented a new feature for a better user experience and I’m sitting here as the CEO going, “Okay guys, I’m calling my IT department.” I’m going, “Hey, why aren’t we doing this? I need you guys to figure out how to get this implemented.” Is these the types of problems that you’re talking about when you say they can’t scale or change?

Melissa Roberts

Absolutely. It’s like being, you should be the A team, but you’re really the Z team and you can’t get to A.

Stacy Gordon

Okay, that would be a problem. Definitely. So what about, you talk a little bit about technical debt, do you believe, I thought this was really interesting that you said in your article that once an application is launched from that moment on, it’s considered legacy. Now, okay, that stood out to me. And my question to you is, do you think most organizations realize that literally the moment that they put it into production, they should already start to think about it acquiring technical debt and being a legacy application and now being a maintenance cost center for them moving forward?

Melissa Roberts

Yeah, no, I don’t think they really do. They think they’ve got this great new application that they launched and it meets every single one of their needs right now. So they put it in and then they tend to forget, “Oh yeah, I got to keep looking at this. I got to keep seeing what’s changing in the market. I got to keep seeing what’s the new security feature I have to look out for.” And it just sits there and it just keeps adding onto that debt.

Stacy Gordon

How about on some of the elements and I know you said maybe they are or not all created equal. What do you think about that user experience? So much has changed since I 20 or 30 years ago started using digital applications for online shopping or managing my home finances or whatever and we’ve come to expect a certain type of customer experience. Do you think that that is kind one of the core drivers for why people recognize again, if their organization’s going to stay in business, they better have the best experience?

Melissa Roberts

Absolutely. So this younger generation, they want those same experiences that were shaped by what they’re using every day. So if you have an application that let’s say was built in the ’90s even, you can even build it in 2015 and it’s not that cool slit, you can move from this, you can move from that, you can go to Slack, you can go to Reddit, you can go all that seamlessly, you’re going to lose those potential customers because they just don’t have time for, “I got to click this button, I got to click that button, I got to go over here.” Yeah, you’re going to lose that.

Stacy Gordon

Gotcha. Yeah, I can see that one is one that rings true for me just because I get frustrated all the time when I have a bad user experience and it will cause you to literally take time out of your day to go find a replacement for that service that you’re using in your home. So I can see why that would be a huge driver for an organization to make sure that they can adapt and move quickly and change to stay ahead from a competitive landscape. We’ve talked a lot about why organizations must modernize. What is driving them to fortunately or unfortunately go down the path of modernizing their application, hoping that they are one of the 20% that actually successfully put something new into production. So I want to talk a little bit about why do these modernizations fail. So let’s give people the answer to the test. Why in the world do so many of these modernizations fail? In your article, you focus on a number of different things. I wanted to start first with, I think you called it boiling the ocean, the boiling the ocean problem. This is one I definitely do not understand. Why do organizations try to modernize everything all at once? What is it about this giant transformation program that seems to them that sounds like, oh my gosh, this is an amazing idea. I mean, go big or go home, catapult your personal success and I’m going to get a big raise and a new job and every person in the world is going to want me to come work for them. I mean, you tell me, what is it?

Melissa Roberts

Right. I mean, yeah, it’s appealing. What you said is appealing. Wow, I did this and my organization can reap the benefits for years, but it’s really more nuanced than that. I think there’s a lack of understanding of the impact that these giant transformations mean to the organization, especially if you’re replacing huge chunks of your application, your software systems, then you’re pulling it out, you’re changing your organization itself, you’re changing how the users interact, you’re changing everything all at once and it’s just a hard thing to do.

Stacy Gordon

So it is on one end, this appeal to being the savior and saving the day. How about on the other end? Is there a pressure that’s put on these stakeholders to say, “You’ve got to get in there and fix this problem and I want you to fix it now. I don’t want to take no for your answer.” And so going back to what you’ve stated already, they only know one way to do it. It’s an IT thing. I’m going to go put the pressure on my IT team to say, modernize this stack because I have to have a better customer experience. I’m assuming that has to be as much of a thing or in a back of a person’s mind as the, I’m going to be the big winner.

Melissa Roberts

And now you’re starting to get into how do we put the brakes on this? How do we go back to our leaders and say, “Yes, I know you want to do this and we can do this, but here’s data that’s going to show you what we should be doing first.”

Stacy Gordon

And does that go into this framework discussion? Because again, it’s like I bet you have a lot of the people that are responsible for these transformations and they know that it’s not the right thing and they’re throwing out these questions and they’re throwing out these propositions, but it’s like if you don’t have a framework to anchor it around, that creates a lack of understanding for perhaps people on that side of the business.

Melissa Roberts

That and it’s the loudest voice wins. I say, “I need this. I’m the loudest voice. I’m going to get it.” It doesn’t matter how much it’s going to cost.

Stacy Gordon

So Melissa, paint me a picture of what it feels like to be that person in an organization that has to start this giant transformation or he is charged with modernizing this application. Help me understand what he’s feeling each and every day.

Melissa Roberts

Right. Well, the first thing they would be feeling is it’s stressful. It’s stressful. Like you said, it fails, modernization fails all the time. So it’s on your shoulders to tell your team, this is the right direction, this is the way we’re going. And from an SVP, CIO all the way down to hands-on keyboard, your identity is wrapped up into your career and if this fails, you fail. So there’s a lot of pressure on yourself as well.

Stacy Gordon

And then if you’ve talked a lot about how organizations are structured, if you feel like you’re over here on an island, I mean, it’s got to even exasperate what you feel like you’re going through. Do you find that these leaders feel like they’re carrying this around in a backpack and it’s all on them? Do they feel like they can reach out to their peers within the organization to get support and feedback or do they just further isolate themselves? What have you seen in your experience?

Melissa Roberts

Well, it really depends on the organization itself. I’ve worked in organizations where if you went and asked for help, that meant you weren’t good at your job and you were going to get fired. So you did hold it all. You had to do everything. And then I’ve worked in extremes where it’s open. Everyone’s like, “Yeah, let’s talk about this. Let’s get it done. You have a great idea. Let me help with that idea.” So those are two extremes. I think most of the time you fall in the middle, you have to find out who you can talk to and who you feel you can trust with this. But I still think that most people are going to carry this on their own. They think they can solve this or they have to solve it.

Stacy Gordon

Right. Yeah, that’s a lot of pressure. I guess that’s why they get paid the big bucks to be able to support the weight of the world or the weight of their organization and the success of their organization, which is why it’s hopeful that people are starting to see that there are new ways of thinking or new approaches that they can consider a new journey rather than doing the way that they’ve done things all the time. And so thinking about that, you talk a lot about business-driven capabilities and you talked something about that’s a new way of thinking. So that’s hard. That’s hard for people to start doing things differently and thinking differently. How does someone start to embark on that journey to say, “I know the way that people have been doing it has failed. I don’t want to be that person. I’m going to try something different.” How does that seem to get into someone’s body and say, “We’re going to go down this way.”

Melissa Roberts

I think first you have to sit in that discomfort of failing. You have to acknowledge that I failed, it’s okay. It’s time to try something else. And that’s a really hard step for a lot of people. Once you get past this, you’re like, “Okay, so if somebody is telling me a capabilities-driven approach is the way I need to go, I need to figure out what that is. So what is that capability? What our capabilities makes no sense to me. I don’t understand that. Capability is simply what you do as an organization, not how you do it, the how is your technology, what. I’m running a donut shop and I want to make sure my customers come in and can select it on a kiosk, their donuts, and then check out. Your what is service management, customer service management is your what. How you do it is that kiosk and the technology under it.

Stacy Gordon

Gotcha, gotcha, gotcha.

Melissa Roberts

So those are some—

Stacy Gordon

I think starting with the tech solution rather than the business capability. I see where you’re going with that. That’s a good example.

Melissa Roberts

Yeah. So understanding that. And then another really difficult thing for people to do is what is business value? What am I trying to achieve? So is it I want to increase my market share? Is it I want to have new customers coming in that are the younger generation? Is it I want my internal people to have what they call a single pane of glass when they’re doing customer service, which is on screen where all the information is. What is it that I need to do? So finding that out and how are you going to measure it? What are the success measures for this? What is the cost benefit analysis?

Stacy Gordon

Do you believe organizations have actually … They have that information, but it’s on the business side and it doesn’t get translated to the technical side? Or do you find that even sometimes some of the best businesses seem to get away from the foundational components that they should be doing each and every day? These things sound relatively simple to me on the way that you should be thinking about your business, but people aren’t doing it. So is it one or both? What do you think?

Melissa Roberts

I think it’s both. I mean, I’ve worked with companies that did not even create benefits cases. They didn’t have strategic goals. They didn’t have your OKRs and KPIs and they just funded whatever they thought was the best thing to fund because they had feelings that it was a good thing to do. And then I’ve been in … And that’s both on the business side and the IT side. And I’ve been in organizations where business is pretty solid. They may not have their business capabilities. That’s easy to do for them, but what isn’t there on the IT side is that connection because they have their own goals. So those goals and business goals don’t come together so you’re at odds there. So that also makes the modernization difficult if you can’t get on the same page of what you’re trying to solve.

Stacy Gordon

The interesting thing too, I think probably, and you tell me if I’m right or wrong here, is that you have this modernization, you have an executive that’s willing to think differently and say, “I want to align with business goals so I can determine what to do.” And we talk a lot about frameworks and roadmaps. How do you determine what you should do? You started the process on a new way of thinking, but what’s next? How do you make sure that what you’re deciding to do is the right thing to do?

Melissa Roberts

How do you make it real?

Stacy Gordon

Yeah.

Melissa Roberts

So that’s part two of my article.

Stacy Gordon

No, I always like to go straight for the good stuff. Okay. Well, now you’ve teased it. So everybody, please take note that there will be a part two of this amazing conversation for you to tune into. But before we let you go, if you were going to leave some lessons for leadership, so the biggest takeaways from our conversation today, what would those be? And maybe if there’s one thing that a leader who’s listening to this today that wants to do something different, what should they do today to try to make an impact in changing how they’re going to approach a modernization project in the future?

Melissa Roberts

Well, besides reaching out to you, Stacy?

Stacy Gordon

Well, yes, please call me. Yeah.

Melissa Roberts

I would say take a look back at how you’re approaching your modernization. Do you have a data-driven roadmap? Is it connected to all your spending and then all of the benefits that you should be seeing from that spend? Are your investment options grounded in real data or is it the loudest voice first? If not, then you probably should reach out to us, but also more importantly, you’re not alone. This application modernization is not easy if it was. Stacy and I would not be talking to you right now.

Stacy Gordon

Well, I think one of the things that you wrote in your article that I want to close with is you said the longer you wait to modernize, the further behind your organization falls. So please, everybody, if you’re looking to dive into this topic a little bit further, you can always go to our website and read Melissa’s article, Why Most Application Modernization Efforts Fail and how a capabilities driven strategy can stop the billion dollar bleed. So definitely go check us out and make sure to tune into part two of this interview to where we help you understand how to bring this to reality and put it into practice. I’m Stacy and that is Melissa, and thanks so much for joining us.

 

Read Melissa’s Article: Why Most App Modernization Efforts Fail, and  How a Capabilities-Driven Strategy Can Stop the Billion-Dollar Bleed

Widespread deployment of Artificial Intelligence is forcing companies to scrutinize their cost structures in new ways. News reports of companies laying off thousands of workers due to the impact of AI are increasingly common, such as Megan Cerullo’s CBS News report last month. To her credit, she questions whether layoffs are a “harvesting of value” produced by AI or caused by some other factor.  Ben Cagle, Managing Partner at Cagle Partners, is blunter in his assessment, “The narrative? AI productivity. The reality? AI capital expenditure.” [2]

The truth is that companies are struggling to squeeze investments in AI into their already constrained operating expense budgets.  Who loses that struggle? The workers whose jobs are eliminated to make room for increased operating expenses generated by “pay per use” generative AI tools such as ChatGPT or Claude.

A Common Pitfall: Cost Myopia

The approach of making space for generative AI expenses by large percentage reductions in labor spending is a common, but serious error due to its focus on cost rather than value. It is too easy for an organization’s finance team to solve a cost overrun by mandating a reduction in labor costs. Once these reductions are baked into a budget, they become non-negotiable as Operators in the business are held accountable to achieve the cost numbers articulated in the budget.

A Better Way: Value Engineering

Value Engineering, the analysis of a good or service in terms of the cost of its subcomponents and the relative value they contribute to a finished good, is a concept that has its roots in purchasing and materials management. I was introduced to this style of analysis back in the 1990s via a purchasing management class based on the book, Purchasing and Materials Management – Text and Cases, by Dobler, Burt and Lee, Jr.

The approach has value beyond purchasing and materials management. We can apply the fundamental idea to any business in two specific areas: growing a business by improving its ability to attract more customers or improving the efficiency with which customers receive products or services.

We begin with a simple definition of value: the benefits generated by a product or capability minus its costs.  A key characteristic of this definition is that the benefits must be monetized so costs can be subtracted from them. The definition is important because it forces us to wrestle with ways to monetize things that many leaders consider to be “intangible,” such as functional value, aesthetic value, or environmental value. [3]

What can be “Value Engineered?”

From its inception at General Electric in the 1940s to keep products affordable without sacrificing quality during World War II, value engineering has been most frequently associated with products: finished goods that are sold to external customers. [4] However, the technique can be applied to other elements of a business and at various levels of abstraction, including:

• Value Streams
• Business capabilities and their subcomponents:
  • Roles / People
  • Business processes
  • Assets (both physical and technology [including data])
• Organizations/business units

One of the benefits of evaluating a set of items (e.g. business capabilities, business processes or assets) is that it enables the organization to understand the relative value being created by various elements in its business.

Sometimes this type of assessment unlocks “surprises” that are hidden in the financial and usage data. I once led a value engineering analysis of a suite of e-commerce applications for a large technology firm. We discovered a pattern that the centralized infrastructure function routinely purchased 3x the hardware needed to run an application. Our average utilization was 12%, and workload rarely exceeded 25% of capacity.

Purchase of unnecessary capacity inflated costs allocated to other business units in multiple ways because the centralized infrastructure department allocated cost to business units by number of servers deployed to a business unit. Once discovered, our value engineering team was able to immediately save scores of millions of dollars in annual infrastructure costs by shutting down the unnecessary servers.

Value Engineering in Eight (Not So) Easy Steps

At the highest level of abstraction, value engineering is a combination of eight steps.  The first two are challenging because they set the guardrails for the remaining work.  The last one is challenging because it forces the organization to convert the benefits generated into cash that can be used to fund subsequent improvements.

1. Identify the unit of analysis,
2. Quantify how the unit of analysis generates benefits,
3. Identify subcomponents,
4. Calculate one time and ongoing costs for subcomponents,
5. Find improvement opportunities,
6. Break opportunities into discrete units of value,
7. Prioritize and begin working the list, and
8. Monetize the results.

Identify the Unit of Analysis

 Identify the “thing” to be analyzed: value stream, business capability, process, or set of assets. Effort to conduct the analysis is largely correlated to the number of things being analyzed.  For example, a mid-sized to large organization typically has 8 – 15 “level one” capabilities, the highest-level abstraction in a business capability map. Each capability has multiple business processes, roles and supporting assets. To prevent scope from quickly expanding to an unreasonable amount, it’s often useful to select a unit of analysis based on the degree to which it is underperforming, either financially or against its planned cycle time and quality service levels.

Quantify Benefits

Quantifying the benefits a unit of analysis generates is often the most challenging step in the process, particularly for items classified as “strategic and governance” capabilities.  Generation of value must be quantifiable and convertible to cash. Value must also be generated as the unit of analysis operates its business processes or work is processed by an asset.

The measurable benefits are going to serve an important role in the rest of the analysis, not only for benchmarking current performance, but also placing an upper limit on investments in improvements. For example, an organization would not spend $5 million improving something that only generates $100,000 a year in value.

Identify Subcomponents

Having identified a unit of analysis and its source(s) of benefits, the next step is to identify its subcomponents. For a value stream, its subcomponents are the value stream stages. For a business capability, its subcomponents can be either a more granular business capability, or the combination of the people (roles), business processes, and assets that instantiate the capability. For an asset, its subcomponents are the labor and non-labor elements needed to operate and sustain the asset.

Calculate Subcomponent Costs

Calculate the one time and ongoing costs for each subcomponent, taking care to ensure that the sum of the costs is a valid representation of the value stream, process or capability. One way to do this is to count the frequency with which a process is executed and then calculate the cost per execution. Once the cost per execution is known, then it can be extrapolated based on the daily, weekly, or monthly frequency with which the component is utilized.

Find Improvement Opportunities

Having determined the costs and sources of benefits for the subcomponents of our unit of analysis, we can identify outliers (high cost + low benefits, or where benefits – costs is smaller than the organization’s expected values). Identify potential improvements, structuring them as discrete changes that generate measurable value and can be implemented in less than 90 days.

Define how success will be measured, as well as the mechanism(s) that will be used to monetize the improvements. Develop a high-level cost estimate and expected improvement quantified in cash for each item.  Sometimes this means adding an incremental sales goal to a sales plan when the benefit is an increased conversion rate, and at other times it may mean booking headcount reductions to monetize improvements in efficiency.

Prioritize the Opportunity List and Implement Improvements

Use a technique such as weighted shortest job first to prioritize the opportunity list. The idea here is to solve problems in small chunks and quickly generate value so that subsequent improvements are funded by the value of the improvements we have already deployed to customers and end users.

Monetize the Results

As improvements are delivered to customers and end users, review the success measures relative to their planned values, and act on the results. Aside from establishing the unit of analysis and determining sources of benefits, this is the toughest step. Many companies plan to generate benefits from improvement initiatives, but they fail to convert improvements in productivity to cash, with the unintended consequence of increasing overall operating expenses rather than decreasing them.  For example, customer experience improvements can be monetized in one or more of the following ways:

• Increases in a conversion funnel times an average order value,
• Increased purchase frequency per unit of time,
• Increases in the number of product categories purchased per unit of time,

A/B and Multivariate testing are important tools organizations can use to test actual customer response to changes in capabilities or processes. Successful tests increase an organization’s confidence that the planned improvements are perceived as such by customers and end users.

Case Study: A Focus on Facts Leads to Wise Investments

One of the key benefits of the value engineering technique is that through the assembly of relevant facts, a leadership team makes decisions based on empirical evidence rather than gut feel or personal persuasiveness. For example, I once participated in a decision about whether to spend $20 million in capital to upgrade an e-commerce capability because the line of business owner asserted a system replacement was needed to achieve a 30% sales growth rate.

Another executive didn’t want to spend the capital on e-commerce and pushed back against the proposal. Both executives were looking for facts to support their intuition. A team was assembled to value engineer the e-commerce capability, including its ability to handle a 30% compound annual growth rate in sales over three years.

The team discovered that while the e-commerce software could support 30% annual growth, the customer service center would need to hire 60 additional people to handle the resulting backorders. Instead of spending $20 million on a systems replacement, the organization redirected funds to fix supply chain backorders, generating $2.5 million in annual productivity gains.

Common Objections

Value Engineering of things beyond finished goods has a lot to recommend it. Why do so few companies use it as a tool to accelerate profitable growth?

Objection 1: We don’t have time/data/skills, etc.

It’s true that organizations rarely have idle capacity to analyze the effectiveness and efficiency of their value streams and capabilities. It usually takes pain in the form of serious underperformance in a business area to justify an investment in value engineering. Scoping this form of analysis to one to three underperforming areas will give an organization some quick wins as well as developing experience with the approach.

Objection 2: Value Engineering is old-school Manufacturing – doesn’t apply to SaaS / Digital

Ironically, changes in corporate cost structures have been significantly impacted by technological advancements over the past 30 years, including cloud computing, subscription-based Software as a Service, and now pay-per-use operating expenses associated with the use of Generative AI tools.

Many of these expenses are either out of direct control of the end user departments to which the expenses are allocated, or only indirectly controlled. Therefore, knowledge of the details of sources of costs, as well as the entities who actually control the costs, are increasingly important for line of business executives to maintain predictability in their P&L statements.  As “old-school” as value engineering may be, it is a straightforward way to isolate sources of benefits and cost, and clarify who directly controls the costs.

Objection 3: This is too academic for our organization to adopt

The ability to scale the technique up or down as needed allows teams to value engineer their own areas before making a larger push for department or organization-wide. Value engineering is a much easier sell when a leader presents it to colleagues in a package that includes actual results generated within the organization’s specific context. If it can be proven to improve results, the degree to which the technique is rooted in academia is irrelevant.

Conclusions

Value Engineering is an important technique for leaders to dust off and add to their toolkits to generate profitable growth in companies of all sizes. Its focus on value versus cost, combined with simplicity of implementation, enable it to be implemented at a small enough scale to produce results quickly. Value Engineering is also sufficiently scalable to generate scores of millions in annual value.

Start small this quarter: Pick one underperforming capability or process, assemble a small cross-functional team, and run a focused Value Engineering workshop. The data-driven insights you uncover will quickly pay for the effort – and may fundamentally change how your organization approaches AI-related cost pressures.

References

[1] Cerullo, Megan –  AI Emerges as Top Cause of Layoffs, Accounting for 26% of April’s Job Cuts, CBS News website, retrieved May 17, 2026.

[2] Cagle, Ben – Search for AI ROI. Focus on the Business Impact, LinkedIn article, retrieved May 17, 2026.

[3] Rahman, M. Abdur – A Comprehensive Guide to Value Analysis and Value Engineering, Kindle Edition, self-published, 2025, p. 45.

[4] Ibid., p. 46.

Are our teams actually getting better?

It’s a simple question, and not enough technology leaders are asking it. Some assume the answer is yes. Others are too buried in day-to-day delivery to step back and check. But every leader should be asking it, and that’s more true today than it was even a few years ago.

Teams are moving faster than ever, and AI is a big reason why. AI tools can help a team produce working code at a pace that would have seemed unrealistic not long ago. That speed is an opportunity. It’s also a risk. If you’re not watching whether your teams are genuinely improving, AI just helps you move faster in whatever direction you’re already headed. Including the wrong one.

So it’s worth asking honestly. Are your teams shipping value faster, creating fewer defects, and keeping the system easy to change? Or are they slowly turning it into something nobody wants to touch?

Most of us reach for DORA metrics to answer that, and that’s the right instinct. Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore are some of the best indicators we have for how well a software organization delivers.

But DORA has a blind spot. It tells you what’s happening. It doesn’t tell you why. And if you can’t see the why, it’s easy to spend real time and money fixing the wrong thing.

DORA Shows the Symptoms, Not the Cause

Picture three teams, each with a high Change Failure Rate. All three keep shipping changes that cause incidents or defects in production. On the surface, they look like they have the same problem.

They don’t.

One team might have almost no automated testing, so nothing catches a mistake before customers do. Another might have copied the same logic across dozens of files, so every change risks breaking something far away. A third might be bundling weeks of work into one big release, so when something fails, nobody can tell which change caused it.

Same symptom. Three completely different cures.

This is where a lot of organizations get stuck. They can see something is wrong, but they don’t have the signals to tell them what’s actually holding the system back. It’s worth borrowing one idea from the Theory of Constraints here: in any system, only one or two things are the real bottleneck, and effort spent improving anything else is mostly wasted. Finding the true constraint is the whole game.

Five Signals, and the Questions They Let You Ask

When I want to understand what’s really going on inside a delivery system, I look at five signals. They fall into three groups, and each group answers a different kind of question.

Delivery Signals

These tell you whether value is reaching customers, and whether it’s getting there safely.

When leaders tell me delivery feels slow, one of the first things I ask is: are teams finishing work, or just starting more of it? It comes back to a simple principle: start finishing, stop starting. Deployment Frequency is often less about speed and more about flow. The question for you as a leader: are we shipping in a steady rhythm, or is everything perpetually “almost done”?

Change Failure Rate tells me how safely teams are moving. One of my favorite sayings is “be quick, but don’t hurry.” The best teams move fast, but they stay in control while they do it. The question for you: when we move fast, do we stay in control?

Code-Health Signals

These are the signals DORA doesn’t give you, and they’re usually where the why lives.

When engineers start saying, “I’m afraid to touch that file,” cognitive complexity has usually already won. When cognitive complexity climbs, teams are usually patching around problems instead of simplifying the design. The question for you: is the system getting easier or harder to change?

Churn and Hotspots show you which parts of the system change the most. Churn is how often a file gets edited. A hotspot is a file that’s both changed often and complex. Sometimes a hotspot is the beating heart of the business. Sometimes it’s just a constant source of pain. Either way, it tells you where engineering attention will pay off most. The question for you: where is our risk concentrated?

Flow Signal

This one tells you how work actually moves.

Average Commits to Main per Day tells me whether teams are integrating work in small, safe steps. Higher commit frequency usually points to trunk-based development, which means small, frequent merges instead of long-lived branches. That gives you faster feedback and lower release risk. The question for you: are we working in small steps, or big risky ones?

Back to Our Three Teams

Here’s the payoff. These five signals do something DORA on its own couldn’t. They tell our three teams apart.

The team with no automated testing shows up in Change Failure Rate, paired with near-zero test coverage. The team with duplicated logic shows up in rising Cognitive Complexity and a cluster of hotspots. The team bundling big releases shows up in a low Commits to Main number.

Three teams, one shared symptom, three completely different stories. And now you can make three well-aimed investments instead of one expensive guess.

Signals, Not Targets

One of the biggest mistakes I see leaders make is turning a metric into a goal.

The moment a metric becomes a target, teams start optimizing the number instead of the behavior behind it. You get gaming, heavier process, and a lot of noise. People spend more time explaining the metric than improving the system. In the worst cases, you create an unsustainable pace where engineers are rewarded for chasing numbers instead of building good software.

Metrics should help you ask better questions. They should create understanding. They shouldn’t become a scoreboard.

A Real Example

I recently worked with a team supporting a legacy application that was three to five years old. When we started, it had no automated tests at all. Code coverage was effectively 0%.

Change Failure Rate was high, and so was Mean Time to Restore. Every production issue was stressful because nobody had much confidence that a fix wouldn’t make things worse.

Over time, the team adopted automated testing, trunk-based development, and feature flags. Coverage went from 0% to about 15%. That’s not a high number, but it was the first real safety net the team had ever had. Commits to main went up as work started moving in smaller, safer steps.

The results were significant. Defects dropped 63% quarter over quarter. Mean Time to Restore fell from days to hours, because the team could finally deploy a fix whenever they needed to. That meant customers spent hours, not days, living with a problem.

The DORA numbers improved too. But not because anyone was chasing them. They improved because the engineering system improved.

Why This Matters Even More with AI

AI coding tools can be incredibly effective. They can also produce insecure code, duplicate logic, and changes that are hard to understand and maintain. And they can do all of that faster than any human team ever could.

That’s exactly why these signals matter more in an AI-enabled organization, not less. They’re how you see the side effects. AI-generated code tends to push up Cognitive Complexity, create new hotspots, and raise Change Failure Rate when it ships without strong review and tests. Those three signals become your early-warning system.

Watch them, and AI accelerates good delivery. Ignore them, and AI just helps you create bad software faster.

Here’s the one idea I hope you remember: AI amplifies the engineering system you already have. If your teams work in small increments, keep the code clean, and have meaningful tests, AI speeds them up. If your systems are fragile and hard to change, AI amplifies that fragility too.

What These Signals Don’t Tell You

One honest caveat. Everything above tells you whether your teams are building software well. Safely, sustainably, and in a way that stays easy to change.

None of it tells you whether they’re building the right software. The features and outcomes that actually matter to customers. That’s a separate question, and it’s just as important. I’ll take it on in the next article in this series.

A Practical Next Step

You don’t need a new dashboard. You need a better conversation.

At your next engineering review, ask your leaders to bring these five signals, and ask them to bring the story behind the signals too. Pick the one or two that map to your biggest current pain, and keep asking why until you reach a root cause you can actually invest in.

Because the goal was never to collect more numbers. The goal is to understand the engineering system that produces your software, well enough to improve the right part of it.

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

When transformation isn’t producing results, the first instinct is to look at delivery. Teams aren’t shipping fast enough. The backlog is bloated. The release cadence is inconsistent. The organization reaches for the familiar remedies: new frameworks, better ceremonies, more alignment meetings. Sometimes this helps at the margin. The underlying problem persists.

Look closer, and the diagnosis shifts. Product teams aren’t unclear because they’re undisciplined. They’re unclear because the direction they’ve been given isn’t defined precisely enough to act on. Priorities change without notice. Investment decisions made last quarter are quietly re-litigated this quarter. Teams spend a disproportionate amount of time trying to understand what they’re supposed to be building and why — and not enough time building it.

Go deeper still, and the real constraint comes into focus. The connection between the strategy Executives have articulated and the execution happening in teams is broken. Not because the strategy is wrong, and not because the teams lack capability. Because the system connecting those layers, the governance that should be shaping how decisions are made, at what altitude, with what information, hasn’t been designed. Ambiguity that arrives from above is transmitted downward unchanged. Decisions that should be resolved at the Portfolio layer are escalated or deferred. The organization mistakes motion for direction, and remains, despite genuine effort, largely unchanged.

Nobody intended this. The system produced it.

Governance Is What Connects Every Layer

The four layers of an organization (Executives, Portfolio, Product, and Delivery) are not a reporting hierarchy. They are a system for making and sustaining decisions at different altitudes. Executives own the investment thesis: where are we committing capital and capability, and why? Portfolio translates that thesis into an explicit strategy. A defined set of outcomes, expressed as bets, with measures that make progress visible. Product owns the solution space. Determining what is worth building and why, grounded in evidence from the market. Delivery produces working solutions that test the assumptions underneath those decisions.

What makes this system function is not the existence of these layers. It is governance, deliberately designed, that connects them: the defined decision rights, the evidence flows between layers, the forums where direction is set and updated, and the transparency that ensures every layer is navigating by the same version of reality.

When that system works, value is realized quickly. The path from investment commitment to measurable outcome is short, visible, and actively managed. Disagreement produces better decisions rather than circular conversations. Each layer moves with confidence because it knows what it is accountable for and what the layer above and below it is accountable for.

When governance isn’t designed, or has been left to form by habit, the system seizes. Strategy stays aspirational. Discovery stays disconnected from investment. Delivery stays busy without direction. And the cost accumulates invisibly across quarters, in work that ships without compounding into capability and in investment that continues to flow without evidence that it is working.

Design How Decisions Flow Before You Design the Org Chart

Most organizations design their governance as a reporting structure that presents to whom, which forums exist, and for which updates. That is the wrong starting point. Governance defines how decisions work: who owns what decision, at what altitude, with what information, and what the system does when the evidence shifts.

Each layer has distinct decision rights. Executives own the investment thesis. Portfolio owns the strategy.  The translation of that thesis into explicit, testable bets. Product owns the solution space, determining what is worth building based on market evidence. Delivery owns execution. Building, testing, and learning at a cadence that surfaces results before the budget is spent.

When these rights are clear and the interfaces between layers are designed, the system can move. When they blur, when Executives are making product decisions, when Portfolio is managing delivery detail, when teams are left to infer a strategy that was never made explicit, the system seizes at exactly the points where it should flow.

Good governance doesn’t just define who decides. It defines the quality of information each layer operates with, the cadence at which decisions are reviewed, and the mechanism for updating direction when evidence demands it. Without it, every layer defaults to one of two failure modes: over-controlling decisions that belong at a lower altitude, or absorbing ambiguity from above rather than resolving it.

Discovery is Strategic Intelligence, Not Product Speculation

One of the most consequential flows in the system runs upward. And it is the most consistently underdesigned.

Discovery done well is not a product team exploring possibilities. It is a disciplined, objective inquiry into market opportunity and customer reality: what problems exist, what behavior patterns are present, what unmet needs have commercial consequence. The goal is not to generate ideas. It is to produce a clear, factual picture of where value can be created that the business is not currently creating.

That evidence only becomes strategic intelligence when it is filtered through specific business goals. The question is not “what could we build?” It is “given where we want to compete and what we need to achieve, what does the market tell us about the direction worth pursuing?” That framing transforms discovery from a product function into a direct input to the investment thesis, something that Executives and Portfolio teams need to engage with actively, not receive as a slide summary after the fact.

Which means discovery has to happen in full transparency. Not as a report delivered upward once conclusions have been reached, but as a shared process in which every layer, Executives, Portfolio, Product, and Delivery understand the game being played, the hypotheses under test, the evidence being gathered, and what success looks like at each stage. When everyone navigates by the same evidence, re-litigation loses its raw material. Parallel versions of reality cannot survive shared visibility.

A Bias to Action is a System Design Choice, Not a Team Characteristic

The organizations that move quickly do not have unusually decisive individuals. They have systems designed to produce decisions rather than defer them.

A bias to action, designed into governance, means every layer operates with the information it currently has; it defines what success looks like, commits to a timeframe, runs the experiment, and surfaces what it learned. It does not wait for certainty before moving. It creates certainty by moving. Each tranche of investment is contingent on the evidence produced by the previous one, which keeps risk bounded and learning compounding.

For Portfolio, this means claiming the agency to shape the path when direction from above is ambiguous, rather than waiting for permission to materialize. Waiting is not a neutral act. In a system that requires decisions to flow, deferring them is itself a structural choice to transmit confusion downward. For Product, it means committing the most informed hypothesis to a testable bet rather than continuing to discover in the absence of a decision. For Delivery, it means building toward observable outcomes and surfacing evidence on a cadence short enough to influence the next investment decision.

The governance creates the forum where that evidence is integrated. Not a status meeting. A decision meeting where each layer reports what it expected, what happened, and what that means for where investment flows next. The agenda is consistent. The decisions are different every time, because the evidence is always moving.

From Strategy to Learning Without the Rewrite Cycle

Consider a mid-sized enterprise software business in the middle of a significant shift in its commercial model. The executive team has concluded that long-term growth depends not on serving every customer’s every request, but on investing deeply in a small number of differentiating capabilities that position the business distinctively in the market. The strategic intent is clear at the top.

Three layers below, the picture looks entirely different. Customer-facing teams are measured on retention and satisfaction scores, so they advocate loudly, and understandably, for features that address the most vocal accounts. Engineering teams, operating largely independently, are making architectural decisions optimized for technical coherence rather than commercial outcome. Product teams are trying to build towards broader customer value, but are pulled constantly toward the most recent escalation. Everyone is working hard. Nobody is working on the same problem.

The absence is governance. There are no explicitly defined decision rights: no clarity on who can commit the product to a customer-specific request, who can decline one, or what the standard is for calculating whether a piece of work is worth doing relative to the business strategy. There is no mechanism for surfacing the cost of misalignment. The accumulated drag of investment flowing toward work that doesn’t compound into the executive team’s stated direction. Teams pull in different directions, not because they are misaligned in their values, but because the system was designed to let them.

The fix is not a new strategy deck. It is how the system is designed. Stable, cross-functional teams where customer knowledge, technical judgment, and commercial accountability are integrated rather than siloed. Change the incentive structure at the point of decision. When the team building the product also owns the customer relationship and is accountable for the commercial outcome, the tension between what an individual customer wants and what the business strategy requires becomes a decision the team has to make explicitly, not a conflict they can refer upward or quietly ignore.

Decision rights, defined at the right altitude, make the cost of misalignment visible. Discovery, done in full transparency rather than within functional boundaries, gives every layer, including Executives, the same objective picture of where the market is moving and which capabilities need to express differently to get there. Portfolio works with Executives to translate that picture into a defined set of bets: explicit outcomes, measurable over a bounded timeframe, funded in tranches contingent on what each previous tranche produced. The governance creates the forum where those bets are reviewed on a consistent agenda. What did we expect, what happened, what do we do next with the investment, and where changing course requires engaging with the evidence, not simply calling a new meeting.

The system does not eliminate tension between customer needs and strategic direction. It forces that tension to be resolved at the right altitude, by the right people, on the basis of shared evidence. That is what makes the disagreement productive rather than circular.

What to Look for in Your Organization

If the transformation is moving more slowly than it should, the diagnostic is rarely about individual teams. It is about the system connecting them.

Decisions get re-litigated when governance doesn’t define who owns them and what evidence settles them. Discovery gets disconnected from strategy when product teams explore in one direction while executives invest in another because the system was never designed to make those two things visible to each other at the same time. Portfolio decisions stall when the agency to shape the path hasn’t been claimed, and Product and Delivery teams slow down when they are absorbing ambiguity that should have been resolved one layer above.

The organizations that install durable transformation systems design the system deliberately. The decision rights, the evidence flows, the forums, the cadence, and the transparency that makes it structurally difficult for any layer to operate on a different version of reality than the one everyone is navigating by.

The system does not change itself. Governance does.

This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.

I’ve spent the last 25 years trying to answer one question: how do you actually get a large, complex organization to deliver software predictably? The question hasn’t changed. The technology has changed. The buzzwords have changed. The funding model has changed. But the underlying problem has been the same one the whole time, and right now it’s wearing a new costume called AI.

So when CIOs ask me what they should be telling their board about AI, I tell them the same thing: don’t tell them about AI. Tell them about the preconditions.

The Pattern I Keep Watching Repeat Itself

If you’ve been following our work for a while, you’ve heard me say that agile fails when the structural preconditions for it to work aren’t in place. We’ve been saying that for almost 20 years. It was true when the new thing was Scrum. It was true when the new thing was DevOps. It was true when the new thing was cloud migration. It’s true again now that the new thing is AI.

The pattern goes like this. A new technology emerges that promises a step-change in business outcomes. Leadership gets excited. Pilots get funded. The pilots produce a couple of demos that look great in a boardroom. The demos don’t scale into the actual business. Six months later the conversation turns to how much the team is learning. 18 months later the initiative quietly gets de-funded and replaced with the next new thing.

I’ve watched that arc play out with every major tech wave in the last 25 years. It’s playing out right now with AI. It will play out next with whatever comes after AI. The pattern is a structure problem.

Why Most AI Pilots Aren’t Scaling

A partner of ours said something to me about a year and a half ago that stuck: the move to AI is going to force digital transformation to become real. He was right. There was a lot of room in the cloud-migration wave for a CIO to spin up some containers, claim victory, and tell the board they were digital. AI doesn’t grant that kind of room. AI either solves a real business problem using your actual data and workflows, or it doesn’t.

Most of them don’t, and the reason is structural. Your AI pilot is sitting in a system that wasn’t designed for it. The data it needs is locked inside a system of record from 30 years ago that runs on a different operating assumption. The workflow it’s supposed to accelerate runs through six teams that don’t share a backlog. The output it produces has to be trusted by an executive whose dashboard is wired into a different governance system entirely. The pilot demo works because the demo conditions are controlled. The production reality isn’t, and the production reality is what your board cares about.

I’ve been saying for a long time that the unit of agile delivery is a complete cross-functional team with a clear backlog producing a working tested increment of the product on a regular cadence, with no dependencies they can’t manage themselves. Teams, backlogs, working tested software. That’s it. That’s the whole frame. Every word in that sentence is doing real work, and every word of it applies just as much to AI as to anything else we’ve ever tried to ship.

If your AI team is six engineers spread across three reporting lines, dependent on a data team in another building, releasing into a workflow they don’t own, against KPIs nobody has agreed on, the outcome is predictable. Your AI pilot will behave exactly the way every failed agile pilot has behaved for 20 years. In any useful sense, it’s a structure problem wearing AI clothes.

What I’d Actually Tell Your Board

Here’s what your board needs to hear: we’re going to be predictable.

If I were the CIO, here’s how I’d frame the board conversation. We are going to deliver AI-enabled business outcomes every 90 days, against a small number of capabilities at a time, and we’re going to deliver them predictably. We’re not going to commit to a portfolio of 15 AI use cases on a slide somewhere and then come back in 18 months apologizing for what didn’t ship. We’re going to commit to one capability that we can actually land, ship it, and earn the right to fund the next one with the value we just shipped.

That is a delivery commitment the board can hold us to. It’s the same predictability promise I’ve been trying to get technology organizations to make for 20 years. AI doesn’t change the standard. If anything, AI raises it, because the cost of AI tooling and AI talent makes a slow, unpredictable AI program more financially painful than a slow, unpredictable agile transformation ever was.

The reason this lands at the CIO level is that you’re the one who has to translate the structural reality into board language. Engineering can talk to engineering about modular architecture and complete cross-functional teams. The CFO can talk to the CFO about CapEx and OpEx. You sit in between. You’re the one who has to take “we need to break the dependencies between our systems before AI can scale” and turn it into “we will deliver business outcome X by date Y at confidence level Z.”

That’s a structural conversation, not a tooling conversation. And it’s the conversation our industry has been bad at having for a long time. We tend to want to tell the board about the new thing we bought. The harder, more honest CIO move is to tell the board about the old thing we’re redesigning so the new thing can work, and to commit to a delivery cadence the board can verify against the calendar.

Where to Start

If you take one thing from this post, take this. The structural work and the AI delivery aren’t sequential. They happen inside the same 90 days, against the same capability, by the same team.

Pick one business capability where AI would materially matter. Not five. One. Make it the one you’d most want to win. Then ask three questions about it.

One. Is there a single team that owns this business capability end-to-end, with no external dependencies that they can’t resolve themselves? If not, your first move inside the 90 days is forming that team.

Two. Is the data this AI needs encapsulated in a service that team can call, or is it sitting inside a legacy monolith that has to be touched every time something changes? If the latter, part of the 90 days is extracting and encapsulating just enough of that data for this one capability to work cleanly. Not all of your data. The slice this capability needs.

Three. Does the workflow this AI is meant to accelerate have a clear, measurable business outcome that an executive sponsor will hold their team to? If not, the 90 days include defining that outcome, in operational terms, with the sponsor signed up to it.

By the end of the 90 days, three things are true. The structural preconditions for this capability are in place. The AI is deployed against the capability in production. There is a measurable business outcome that the team and the sponsor agree was hit. That’s your first delivery. That’s what you take to the board at the end of Q1.

Then the next 90 days add the next capability. By the end of year one, you’ve got four capabilities running on the new structural pattern, each with AI compounding on top of it, each with a clean business outcome the board can point to. Most CIOs don’t see this coming. The structural work you did for capability one pays forward into capabilities two and three. The team gets faster. The data layer gets cleaner. The governance model gets more practiced. The cadence becomes the operating rhythm.

That’s a very different story than “we’re not delivering AI this year.” It’s “we’re delivering AI quarterly, against the capabilities that matter, on a cadence you can take to the audit committee.” Same underlying preconditions argument. Very different message in the boardroom.

Most of the CIOs I talk to are already deep into an AI program that doesn’t look like that. The move isn’t to throw it out. The move is to pick the one capability inside it that’s most worth saving, restructure the work around that one, and let the unsalvageable pieces wind down naturally as funding cycles end. Don’t take a year off from AI to prepare. Take 90 days to do one capability right, then prove the pattern repeats.

The firms that figure this out in the next two years won’t be the firms that bought the most AI tools. They’ll be the firms that learned to deliver AI predictably against a small number of capabilities at a time. The rest will spend year three explaining to their boards why the AI bill keeps going up and the business outcomes haven’t moved.

That’s the story. Tell that one.

In my last article, Why Most App Modernizations Fail, I made the case that organizations know they need to modernize but are lacking a framework that removes the ambiguity from the decision making. This article moves us from strategy to practice, walking through how organizations use business capability heatmaps and domain alignment to make deliberate, data-driven, and defensible modernization decisions that delivery business value at every step of the journey.

Breaking Down Silos Through Domain Alignment

Application modernization cannot happen in a silo. Legacy applications in many instances can be considered a bowl of spaghetti when pulling one noodle somehow breaks four in the process. By understanding domains and aligning technical teams to those domains, organizations create a cross-functional structure that ensures modernization efforts consider the impact on various departments and promote an integrated approach. This alignment also follows Conway’s Law [1] where organizations design systems that mirror their internal communication structures, turning an organizational reality into a deliberate design advantage.

Delivering the Value

To begin delivering value during application modernization, organizations must have an established business capability model with corresponding heatmap. In this article, I will not be describing how to establish the model, nor will I be describing how to create the needed heatmap. It is also assumed that a definition of business capability is not needed though one can reference the article Organizing Around Business Capabilities. This article will describe how using capabilities focuses strategic refactoring decision making on changes that increase value rather than simply rebuilding every application.

Precursors to a capabilities-driven application modernization

The first step is to recognize that not all business capabilities have the same significance.  Business capabilities are stratified into three layers [2]

• Strategic – direction setting or typical executive focal points
• Core – customer facing or what an organization does to thrive in the marketplace
• Supporting – what the organization must have to function as a business

For those not as familiar with business architecture, a similar concept can be found with Martin Fowler [3]. He describes how to determine if IT is strategic or utility. Technology is strategic where it contributes or supports capabilities that differentiate the organization. As with Strategic and Core business capabilities, if the business value for the technology is determined strategic then that is the area one wants to be as good as possible.

The stratification of capabilities and Martin’s concept of IT being strategic or utility are keys to unlocking sound investments. An additional key is to establish a capability-driven organization that contains both technical and business operations into the capabilities. These keys will unlock the next steps in determining how to make sound economic application modernization investments. These steps include:

1. Assess the value, performance, and risk of your capabilities using a capability heatmap
2. Align domains to your capabilities

Asses the value, performance, and risk of your capabilities using a capability heatmap

Since many organizations fail with their application modernization efforts, using data to determine what areas of the organization they should focus on should be standard practice. Those who engage in a business capability assessment will have a clear advantage by having data that shows what the organization should focus on for improvements. In Strategy to Reality: Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders, Whynde Kuehn [4] identifies the business capability assessment as offering ‘a data-based view of business performance, at an aggregate level.’

Assessing the value (strategic importance), performance (people, process, and technology), and risk (flexibility/suitability) of business capabilities is the basis of a capability heatmap. Creation of the heatmap should occur before any decisions around application modernization efforts are made.

Align domains to your capabilities

A domain is the activity or business of the end user [3]. A simple explanation is a domain is equal to a business object which includes its behavior, state transitions, and data associated with an element of a business. It is a specific problem space that a software solution is meant to address. Examples of domains are Product, Market, Work Order, and Customer.

There are a few important distinctions between business capabilities and domains. Business capabilities are described at a higher, more abstract level, and they are non-redundant across the organization. Domains can be redundant across the organization. They participate in one or more bounded contexts that facilitate encapsulation of teams and systems from each other that distinguish the distinct meaning and rules inside and outside the area. For a domain the smaller the boundary the smaller the teams and the more modular the service architecture. Larger boundaries will result in larger teams and more complex or monolithic architecture. In other words, alignment of business capabilities and domains follows Conway’s Law [5] where organizations will design systems that mirror their own internal communication systems.

What happens when domains are redundant across the organization? Does it matter? The short answer is it depends.  Redundancy in domains does not mean there should and will be redundancy in data models. Attempting to unify the redundancies breaks the core principle bounded context and will in effect drive accidental complexity and monolithic coupling. For example, ‘Customer’ can appear in both ‘billing’ and ‘shipping’, but has different attributes in each context (e.g. billing address does not always equal shipping address, etc.).

Eric Evans, in Domain-Driven Design: Tackling Complexity in the Heart of Software (2003) [3], explicitly warns against forcing a single unified model across contexts. Each bounded context owns its own ubiquitous language, meaning “Customer” in billing may carry attributes like payment history and credit status, while “Customer” in shipping cares only about address and delivery preferences. The behavior and attributes should differ because they serve different capabilities. The key is to ensure that the domain has a consistent meaning across all contexts in which it participates, and that when needed attributes from multiple contexts can be combined to fulfill a particular business need.

Sam Newman, in Building Microservices (2nd ed., 2021) [5], reinforces this by describing how shared models across service boundaries create tight coupling — the very problem that bounded contexts are designed to prevent. He recommends tolerating some data duplication across services rather than introducing shared libraries or databases that erode autonomy.

With that said, there are instances where a domain should have the same behavior and attributes across capabilities. Take for example ‘Product’ domain.  It is undesirable for calculation of pricing within the Inventory domain to be different than the calculation of pricing in the e-commerce domain. This would lead not only to teams solving the same problem, perhaps leading to different outcomes but also to increased operational costs when resolving any issues and/or updating the calculations. This is the organizational mirror that Conway’s Law predicts: siloed teams produce siloed, inconsistent implementations of logically shared concepts.

In short, if the behavioral difference has no business justification and exists purely because two teams built the same thing independently; refactoring is warranted, but the target is not necessarily a shared service. Often the right move is to designate one context as authoritative (a published language or open host servicein Evans’ terminology) and have the other consume it through a clearly defined application programming interface (API), rather than collapsing both into one monolith.

When aligning business capabilities and domains, ensure the smallest possible bounded context per domain while also taking into consideration if the redundancy within the domains has a business justification or not is critical.  Otherwise, a system that continues to perpetuate dependencies across the organization is created. If the language of the consumer varies significantly from the authoritative context, one can establish an anti-corruption layer to translate an external model into terms that are more meaningful within the consumer’s bounded context.

Pulling it Together

Nicholas Tune and Jean-Georges Perrin point out ‘To get buy-in from stakeholders and maximize return on investment, you must have a solid understanding of the business outcomes you aim to achieve and clearly articulate how investing in architecture modernization will move the business toward its strategic priorities’. [6]

To do this, leverage business capability and domain heatmap. At the most basic level, the tool visually identifies which capabilities are most critical to improve from a strategic level. The heatmap also indicates the impacts that the strategic decisions will have on the organization. Is the strategy to increase speed of innovation, operation costs, or scalability? Will the strategy impact multiple highly strategic capabilities that all have highly inflexible and are performing below average? What is the current technical debt? The executive will know that a higher level of investment will be needed to improve the capabilities and domains.

Conversely, the heatmap will also show areas that are already performing within the needed objectives and goals. The executive will know that investment in these areas is not wise as it is unnecessary to continually improve on a capability that is already performing at a high level.

Companies who may have a good understanding of their distinctive business capabilities fail to associate them with their domains. Ensuring the alignment between capabilities and domains and their associated technologies improves an organization’s awareness of where they are wasting money on non-strategic, overperforming or adequately performing capabilities. Ultimately this prevents the company from hemorrhaging money on unnecessary application modernization efforts.

This article was originally published in Architecture & Governance Magazine in May 2026.

References

[1] Conway, Melvin E., “How Do Committees Invent?” Datamation, 1968, https://www.melconway.com/Home/Committees_Paper.html.

[2] Business Architecture Guild®, A Guide to the Business Architecture Body of Knowledge®, v 13.0 (BIZBOK® Guide), 2024. Part 2, Section 2.2 & Page 79

[3] Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2003.

[4] Kuehn, Whynde. Strategy to Reality: Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders. Morgan Jame Publishing, 2022

[5] Newman, Sam. Building Microservices: Designing Fine-Grained Systems. 2nd ed. Sebastopol, CA: O’Reilly Media, 2021.

[6] Tune, Nick, and Jean-Georges Perrin. Architecture Modernization: Socio-Technical Alignment of Software, Strategy, and Structure. Manning Publications, 2024.

Most Fortune 100 companies aren’t struggling with AI because they lack the right tools or models. They’re struggling because AI fails at the organizational level: fragmented data, misaligned incentives, no clear ownership of outcomes, and legacy systems that weren’t designed to feed production AI. It’s these issues that stop promising pilots from scaling into production. Addressing these organizational issues is key to realizing the potential of AI. This article explains why your pilots aren’t scaling and the five conditions that enable AI to reach meaningful production scale.

You Don’t Have an AI Problem. You Have a Systems Problem.

When we work with CIOs at large, legacy-heavy enterprises, we hear the same story: a lot of AI-focused activity but not much in production at a meaningful scale.

This is what we call pilot stall. And it’s the root causes have little to do with AI itself.

Pilots are typically initiated in a controlled environment. One where the conditions are created for success, and one that typically doesn’t reflect the operational and technical realities of the organization as a whole. The moment you tried to scale it, you hit the constraints of the legacy systems. Your legacy systems weren’t designed to feed real-time inference, so the “last mile” data problem stalls every deployment. The business units that would benefit from the AI don’t own the model, don’t feel accountable for its performance, and don’t change their processes to take advantage of it. Decision rights, funding flows, and governance processes were designed before AI was a real production constraint. None of these is an AI problem. They’re system problems.

Start with the System, Not the Symptom

Organizations are systems. They produce predictable results based on how they’re designed. If you want different results, you have to change the system’s design, not just its components.

For enterprise AI, this means asking a different set of questions before you reach for a solution:

What is the actual constraint limiting performance? Usually, it’s not the model quality. It’s the data pipeline, the decision-making structure, the incentive model, or the lack of mapping of AI capability to a value stream that produces measurable business outcomes.

What must be true for this to work at scale? AI Transformation succeeds or fails depending on whether the necessary system conditions are in place. What are the prerequisites? What has to be in place before you can build on it?

What does the system produce, and why? If your organization keeps generating pilots that don’t scale, there’s a structural reason. The behavior is an output of the system design. Find the design flaw, not the scapegoat.

Treating AI transformation as systems redesign rather than technology deployment changes what you do, in what order, and who needs to be involved.

The Five Conditions That Move AI to Production

Based on our work with complex, legacy-heavy enterprises, here’s what consistently separates the organizations that make it into production from those that don’t. The shape of the work depends on the type of AI problem and the organization’s maturity. The five conditions below are necessary in most Fortune 100 contexts; how you instantiate them varies.

1. Ruthless portfolio rationalization. Most organizations have too many pilots. Start by focusing on three to five capabilities that are connected to improving KPIs that the CFO is focused on: revenue, cost, customer impact, and cycle time. Everything else is noise until you’ve proven you can drive results in production.

2. Encapsulated capabilities, governed interfaces. Not a central AI team that everyone has to coordinate with. Not another tool. An architecture where each business capability owns its own models, its own data pipelines, and its own production lifecycle, connected through governed interfaces rather than central orchestration. Reducing cross-team dependencies is the prerequisite infrastructure that most organizations skip in their rush to build models.

3. Operating model redesign. Who owns the model in production? Who is accountable when performance degrades? How are cross-functional teams funded for ongoing capability, not one-time projects? These aren’t technology questions. They’re organizational design questions, and they’re the ones that determine whether your AI actually sticks.

4. MLOps and governance built in from the start. Model lifecycle management, monitoring, drift detection, and compliance workflows need to be part of the architecture from day one. Don’t bolt them on after a failed production launch. Governance without infrastructure creates bottlenecks. Infrastructure without governance creates risk.

5. Business-defined success metrics. If your AI program is measured by model accuracy, you’re measuring the wrong thing. The right metrics are end-to-end cycle time, EBITDA impact, cost reduction, and customer experience improvement. When success is defined in business terms, accountability follows naturally.

The LiminalArc Approach to Pilot Stall

Most AI consulting work focuses on the wrong layer: the model, the platform, the use case. The firms that consistently get AI to production at scale work at the systems layer instead, where the production failures actually originate. That’s the work LiminalArc was built for.

We work specifically with Fortune 100 enterprises where the bottleneck is organizational: incentive misalignment, cross-functional coordination failures, legacy architecture constraints, and governance gaps. We diagnose the system before we recommend technology. We install the five conditions and one capability at a time, end-to-end, until production AI delivers measurable ROI. Then we expand to the next capability.

If your pilots aren’t scaling, the firms that can solve that are the ones that treat your organization as the primary variable, not the technology. LiminalArc is built for that work.

Frequently Asked Questions

Why do our AI pilots keep failing to scale?

Pilot failure almost always traces back to organizational and infrastructure factors, not model quality. The most common causes are: no unified data layer, no business owner for the outcome, incentive structures that fund projects rather than capabilities, and operating models not designed for continuous AI deployment.

How long does enterprise AI transformation take?

For Fortune 100 companies with complex legacy infrastructure, realistically, 18-36 months to reach a satisfying ROI at scale. The first 90 days should focus on portfolio rationalization, constraint identification, and foundational architecture. Expect measurable production deployments within six months of starting structured work.

How do we avoid pilot stall?

Pilot stall happens when organizations lack unified platform architecture, MLOps infrastructure, governance frameworks, clear business ownership, or ruthless portfolio rationalization. Install all five conditions within a single capability before you build more pilots elsewhere.

What’s the difference between systems thinking and a technology-first approach?

Technology-first starts with “which model or platform should we use?” Systems thinking starts with “what is the constraint that’s limiting performance?” The questions look similar. The answers and the work required are entirely different.

How do we measure AI ROI?

Measure end-to-end cycle time, EBITDA impact, cost reduction, and customer experience improvement. Model accuracy is a technical metric, not a business metric. Build your business case in the language your CFO and board use: revenue impact, cost avoidance, margin expansion.

What’s the right size of an AI portfolio to start?

Three to five high-priority capabilities, each tied to a measurable value stream, with clear production infrastructure and business ownership. That’s it. Every additional initiative dilutes focus and slows execution until you’ve proven you can scale something.

Work With LiminalArc

If your pilots aren’t scaling, we should talk. Not about which tools you need. About why your system keeps producing the results it’s producing, and what it would take to change that.

Explore our AI Readiness work
Talk to a LiminalArc advisor

LiminalArc helps Fortune 100 enterprises move from AI experimentation to real business value by treating transformation as a systems problem rather than a technology problem.

Application modernization continues to be at the forefront of organizations’ concerns as they struggle to respond to the undeniable acceleration of digital transformation and the ability to respond to rapid changes in the market. According to an October 2025 MarketsandMarkets [1] research report, spending on legacy application modernization is expected to grow from $22.67 billion in 2025 to $51.45 billion in 2031. With the increasing investment in application modernization, it is rather astonishing that research conducted by Wakefield Research [2] showed that 79% of the respondents indicated that their application modernization effort failed. How do organizations know that they are wasting billions of dollars on app modernization, and how do they stop the bleed?

In Examining Capabilities-Driven AI, my colleague Len Greski discussed the impact of a capabilities-driven organization on the AI-enabled business. He asserted that a capabilities-driven approach to AI accelerates the delivery of data products and AI capabilities. In Organizing Around Business Capabilities, we articulated the benefits of this approach, including integrating both technical and business operations into a capability. In this article, I explore how the benefits of a capabilities-driven organization enable organizations to make economically sound investment decisions in application modernization.

Organizations Must Modernize

With market spend expected to exceed $51 billion in 5 years and growing at 5x the 2025 U.S. inflation rate, modernization is clearly a strategic imperative. Four primary drivers of this investment consistently emerge across industries:

1. Unsustainable Technical Debt and Maintenance Costs

Legacy systems accumulate technical debt gradually over time, consuming an ever-growing share of IT budgets just to keep existing systems operational. Surprisingly, once a new application goes into production, it IS a legacy application. This translates into 90% of the cost of your new application occurring after the initial deployment to production [3]. As years pass and original developers move on, even seemingly simple updates become complicated and risky. Tasks that in the past took days can drag on for months. This constant struggle not only drains resources, but it also directly undermines an organization’s competitiveness.

2. Inability to Scale and Adapt to Market Changes

Monolithic and tightly coupled legacy architectures make it difficult to introduce new products, enter new markets, or respond to competitive threats at the pace the modern business environment demands. Organizations with outdated platforms find that their technology constrains rather than enables the business. Meanwhile, competitors who have modernized can quickly try out new ideas and grow their services with ease. The longer you wait to modernize, the further behind your organization falls.

3. Escalating Security and Compliance Risk

Many older systems simply cannot keep up with today’s security threats.  It is often difficult, if not impossible, to update them with the latest protections or to comply with new rules like GDPR, HIPAA, SOC 2, and PCI-DSS. The fallout from a security breach or failing an audit can do way more damage to an organization’s revenue than the upfront investment to modernize. Security isn’t just an IT problem anymore; it’s a business risk that leadership can’t afford to ignore.

4. Degraded User and Customer Experience

Legacy systems typically produce slow, fragile, and poorly integrated experiences for both internal users and external customers. In an era where customer experience is a primary differentiator, organizations running on outdated platforms find it increasingly difficult to meet expectations. On top of poor customer experience, productivity and morale of employees are negatively affected in part due to outdated tools and processes, making it harder to recruit and keep top talent.

Most Modernization Efforts Fail

The 79% failure rate cited by Wakefield Research is disconcerting, but it is not surprising when one examines how most modernization programs are structured. The most common failure modes include:

• Technology-led, not outcome-led: Too often, organizations start with a technology decision ‘we are moving to the cloud’ or ‘we are rewriting in microservices’ ignoring the most important question, what is the business value and what business outcomes the investment is meant to deliver. Without a clear tie to business value, projects lose stakeholder support and direction.
• Boiling the ocean: Organizations attempt to modernize everything at once, resulting in multi-year programs that are too complex to govern, too expensive to sustain, and too slow to deliver value. By the time they complete, the business and market has moved on.
• Siloed execution: Technology teams modernize applications in isolation, without sufficient understanding of upstream and downstream business dependencies. This is the ‘bowl of spaghetti’ problem — pulling one noodle breaks four others — and it leads to regressions, delays, and costly rework.
• Neglecting the organizational dimension: Technology transformation without corresponding changes to team structures, processes, and governance rarely sticks. Conway’s Law tells us that systems mirror the communication structures of the organizations that build them, and if we change the software to conflict with the communication structure, the changes will eventually be reverted.
• Lack of prioritization frameworks: Without a structured way to evaluate which systems to modernize and in what order, organizations default to the loudest voice in the room, the most visible pain point, or political priorities ignoring the strategic value.

As an antidote to the failure patterns, consider a capabilities-driven approach.  Use the organization business capabilities to anchor the modernization decisions to the most valuable business outcomes ensuring cross-functional alignment and enabling prioritized roadmap that based on valuable business outcomes and sustainable technical architecture.

How a Capabilities-Driven Approach Improves Success Rates

A capabilities-driven approach addresses the root causes of modernization failure by shifting the conversation from technology replacement to business outcome enablement. Rather than asking ‘what do we need to rebuild?’, it asks ‘what capabilities do we need to perform better — and which of those are truly differentiating?’ This reframing has profound implications for how programs are structured, governed, and executed.

Anchoring Decisions to Business Value

Nicholas Tune and Jean-Georges Perrin point out that ‘to get buy-in from stakeholders and maximize return on investment, you must have a solid understanding of the business outcomes you aim to achieve and clearly articulate how investing in architecture modernization will move the business toward its strategic priorities.’ [4] A capabilities framework provides exactly this — a structured language for connecting technology investment to strategic intent, ensuring that modernization efforts remain legible and defensible to executive stakeholders throughout the program lifecycle, including the cost to operate the capability.

Enabling Value Driven Prioritized Roadmap

Not all modernization investments are equal, and not all capabilities deserve the same level of investment. Martin Fowler describes how to determine whether IT is strategic or utility: IT is strategic if it contributes to or supports capabilities that differentiate the organization. [4] This insight, combined with the business capability stratification model [5] provides a powerful framework for prioritization.

• Strategic – direction setting or typical executive focal points
• Core – customer facing or what an organization does to thrive in the marketplace
• Supporting – what the organization must have to function as a business

Organizations that apply this lens can make confident decisions: invest heavily in modernizing Strategic and Core capabilities where performance gaps exist, and adopt pragmatic, cost-efficient approaches for Supporting capabilities where “good enough” is genuinely good enough. This avoids the costly trap of gold-plating commodity systems while under-investing in differentiated ones.

Reducing Risk Through Incremental Delivery

By identifying capability boundaries and aligning domains accordingly, organizations can decompose large, risky modernization programs into smaller, independently deliverable increments. Each increment delivers measurable business value, maintains organizational support, and reduces the blast radius of any individual failure. This is the opposite of the ‘big bang’ rewrite, and it is why capability-aligned approaches consistently outperform technology-first ones.

The Path Forward

A capabilities-driven approach to application modernization is not a silver bullet, but it is a proven antidote to the failure patterns that have plagued the industry. When organizations use business value to anchor their investment decisions, apply roadmap prioritization, and deliver incrementally, they can break the cycle of costly, failed transformations. The question is no longer whether to modernize; the competitive imperatives are clear, but how to modernize in a way that is economically sound and strategically aligned. In part 2 – Capabilities-Driven Application Modernization Delivery: Business Value at Every Step, we will move from framework to practice: exploring the concrete steps organizations can take to implement a capabilities-driven modernization program and deliver measurable results.

This article was originally published in Architecture & Governance Magazine in May 2026.

References

[1] Application Modernization Services by Service Type (Cloud Application Migration, Applications Re-Platforming, Post Modernization), Application Type (Legacy, Cloud-hosted, Cloud-native) – Global Forecast to 2031. Retrieved March 2, 2026.

[2] Wakefield Research. (n.d.). Why app modernization projects fail. vFunction. https://vfunction.com/resources/report-wakefield-why-app-modernization-projects-fail/

[3] Tornhill, Adam. Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs. Pragmatic Bookshelf, 2^nd ed, 2024

[4] Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2003.

[5] Business Architecture Guild®, A Guide to the Business Architecture Body of Knowledge®, v 13.0 (BIZBOK® Guide), 2024. Part 2, Section 2.2 & Page 79

Twenty-five years of change in the cost structure of technology created a minefield of risk as executives fund software application development, regardless of whether the software is sold or leased to customers or developed for internal use. Conflicting pressures lead to one breakthrough solution: Stop arguing about CapEx versus OpEx. Fund the next increment with the value you just shipped.

An Historical Perspective

Organizations have treated software applications as capital assets since the 1950s, based on early go to market models for computer hardware where the software was included in the price of capitalized hardware. The 1969 U.S. antitrust suit against IBM forced the company to begin charging separately for most software programs. Implementation of the antitrust agreement created an independent software industry as IBM and other companies separated their hardware and software businesses.

As software became a separate entity from hardware, companies relied on existing accounting standards to decide how to treat software expenses. During the 1970s the Federal Accounting Standards Board’s guidance about research and development (including software) was very conservative – costs were to be expensed as they occurred. Beyond R&D the standards were unclear, leading to a diversity of accounting treatment of the expenses to build software for sale or in-house use.

The accounting environment changed significantly with the 1985 introduction of SFAS 86, which allowed capitalization of software development costs for computer software to be sold, leased or marketed after “technological feasibility” was established [1]. Guidance for internal use software took another decade to emerge, eventually articulated in the Association of International Certified Public Accountants statement of position (SOP) 980-1, and later codified as ASC 350-40. [2] The AICPA took a three-stage position on expense vs. capitalization, where preliminary planning and operations are expensed, but application development post-planning may be capitalized.

The goal of these changes was to more effectively align the costs of building software with the benefits generated over the software’s useful life. However, life, for technology executives, was about to get a lot more complicated.

Cloud, SaaS, and Agile Exert Pressure on OpEx Budgets

Cloud computing, an infrastructure model that allows companies to pay for computing as they use it rather than making large up-front purchases of capital assets, had relatively minor impact on budgets between 2006 and 2014.  At the time, cloud consumed a small proportion of IT budgets, usually less than 15% for most enterprises. By 2020, enterprise spending on cloud infrastructure ($130 billion) surpassed spending on data center hardware and software ($90 billion) for the first time. [3] More recently, enterprise spend on cloud as a percentage of IT budgets has grown to as much as 30 – 50% of total IT spend, with Gartner pegging it at 47% in a 2024 research article. [4]

Bottom line: Subscription-based infrastructure moved roughly half of IT spend from the balance sheet to the income statement.

The net effect of these structural changes in the finances of IT is increased scrutiny on infrastructure costs, as the immediacy and variability of cloud spend (often driven by factors outside the IT department’s control) require a different form of financial management than the typical 5 to 7-year capital asset planning, purchase and depreciation cycle.

SaaS Follows the Same Cost Pattern as Cloud

A similar storyline emerged with Software as a Service (SaaS), with Concur (1993), NetSuite (1998) and Salesforce (1999) challenging the traditional way that software was purchased and consumed by companies. The key innovation was a multi-tenant architecture that would enable multiple customers’ workloads to be managed by a single instance of the application. Multi-tenancy was further enabled by cloud computing, as SaaS vendors could build their applications on highly scalable / pay per use cloud infrastructure. Together, these innovations reduced the cost per customer of SaaS applications from $12,000 – 18,000 annually to under $2,000 as of 2026. [5]

That said, as SaaS usage grew, IT departments began to experience the same capex to opex cost migration challenge they experienced with cloud computing. A 2024 Gartner article, Software and SaaS Contracts: New Negotiation Tactics for CIOs, asserted that companies spend as much as 29% of their IT budgets on SaaS and software, with price increases as high as 30%. [6]

Capex: The IT Budget Relief Valve?

If cloud charges consume 47% of the typical IT budget and SaaS / purchased software claims another 29%, that leaves only 24% to fund everything else. Unfortunately, overall personnel costs are running at 35% of total IT spend [7], leaving many IT departments over budget by 900 basis points.

How might a CIO relieve this form of budget pressure? An obvious approach would be to capitalize enough application development labor to reduce operational spending by 900 – 1,000 basis points. I have observed multiple companies address short-term budget challenges in this manner, but after three or four years of increasing labor capitalization to meet an OpEx target, CIOs find themselves squeezed between the rock of the operating expense budget and the hard place of the amortization schedule.

The Straw that Breaks the Camel’s Back: Accounting for Agile Development

Earlier we described how the American Institute of Certified Public Accountants codified an accounting standard for software development into ASC 350-40. It took a stage-based approach, where capitalization is only permissible during the second, “application development” stage. This stage occurs after preliminary planning but before the initial production deployment to customers or end users.

The theory is that work organized in an agile manner can be capitalized as it goes through the ASC 350-40 stages. The reality, however, is that a high functioning Scrum team passes through all three of these stages during every two-week sprint.

The agile emphasis on frequent delivery of working tested product becomes an accounting nightmare when the organization tries to capitalize the expenses. Companies take three major approaches to capitalization, each of which has significant implications for audit defensibility and operational cost.

Approach	Description
Story Level Tagging	Each ticket marked as new development vs. maintenance at story refinement. Pros: Highest audit defensibility Cons: Creates the heaviest process overhead and associated team friction.
Epic Mapping	Capitalize by epic or initiative, not feature or story. Attempts to balance audit rigor with impact to team velocity. Pros: Moderate audit defensibility Cons: Less labor intensive than story level tagging
Percentage Survey	Conduct quarterly surveys of engineering activity to capitalize a blanket percentage of engineering cost. Pros: Least effort required Cons: Least defensible in an audit

n current practice the trend is clear: as firms implement continuous delivery, software capitalization rates are falling. Direct expensing of software development costs simultaneously reduces non-value adding labor and audit risk.

The Breakthrough Solution: Earn the Right to Invest Again

What does “earning the right to invest again” look like? It consists of three steps, including:

1) Ship a thin slice	Working with business partners, identify the smallest unit of value that someone will pay for or measurably reduce cost – targeted in 30 to 60-day cycles.
2) Monetize the slice	Tie revenue, cost reductions, or a binding usage metric to the release. If the value is an increase in revenue, add the slice’s value to the firm’s revenue plan. If it is a cost reduction, cut the relevant labor and/or materials budgets accordingly to force monetization of the savings.
3) Fund the next tranche	Board or Portfolio-level executive approval for next scope of work releases per verified outcomes, not an annual spending plan. Align units of funding with value streams or products.

This approach reframes accounting treatment of application development as a second-order concern, that is, it shifts the conversation from accounting treatment to accountability for value generation.

AI-enabled Software Development: Tilting the Scales towards OpEx

AI-enabled software development is reducing the cycle time and cost of producing working tested product. For example, survey respondents in Google’s 2025 DORA report indicated that more than 80% of respondents reported that AI has increased their productivity. [8] An MIT study of almost 5,000 software developers at Microsoft, Accenture and an anonymous Fortune 100 manufacturer resulted in a 26% increase in the weekly number of tasks completed by users of Github Copilot relative to developers who weren’t using the tool. [9]

When the time it takes to obtain an increment of end user value is measured in days as opposed to quarters, the effort to capitalize a “project” no longer represents the reality of how software is built and deployed.   In this situation the appropriate unit of accounting is an experiment or investment hypothesis, and therefore the correct unit of funding becomes the business outcome.

Furthermore, AI-enabled software development introduces new categories of spending such as AI tool usage charges, content storage in vector databases, and code analysis infrastructure that are all inherently operational in nature because they are not compiled into the “created asset.” The accounting treatment for these items is consistently Opex.

Applying a Strategic Lens

Given the above conditions, the main question about software application for C-suite leaders is no longer “what can we capitalize?” but rather “how do we obtain value most quickly?” A second question, almost as important as the first, is “what funding model keeps us honest about cost and risk?”

A delivery approach that delivers working tested product to customers or end users in 30 to 60-day cycles will generate value more rapidly than one driven by annual planning cycles. A product-focused funding model that considers the useful life of the product is more aligned with reality than a project-focused one [10].  A funding model that explicitly accounts for uncertainty of value will also be biased toward frequent delivery cycles.

The idea of uncertainty of value (described in Kersten 2018) can be combined with the accounting treatment for the useful life of an asset to establish a 2×2 framework for funding decisions as follows.

Experiment	Short life & unproven value When both the useful life and business case are open questions, spend as little as it takes to answer them. Run these as clearly bounded pilots – a fixed dollar spend limit, a defined decision date, and written kill criteria the sponsor agrees to prior to the start of work. The result or output is an answered business question, not a running system.
Expense & Measure	Long life & unproven value When the software is likely to be around for years but the business case is uncertain, develop it as a measured expense rather than a capitalized asset. Book the costs to operating expense, include instrumentation to prove value, and let the evidence decide whether the work earns its keep as a capitalized asset or gets wound down. This is where most strategic ‘platform’ bets begin before they become infrastructure.
Subscribe	Short life & clear value When value is clear but the underlying technology evolves faster than it can be amortized, attempt to rent rather than owning it. Treat these workloads as operating expenses from day one, subscribe to a managed service, and redirect the organization’s engineering capacity on problems the market doesn’t already solve for you. The failure model is “sentimental” – keeping a custom stack alive long after the build versus buy math has flipped to favor “buy”.
Capitalize	Long life & clear value This is the textbook ASC 350-40 candidate – past a preliminary scope phase, has defined users, a demonstrable revenue or cost-savings path. Capitalize application development costs and amortize them across the expected life of the resulting asset. Core platform services, billing, identity management, and foundational infrastructure on which other value streams depend belong here. Highly regulated industries may require a higher capitalization rate for compliance. The leadership challenge is being honest about when a project clears this bar.

The pattern is that leaders should capitalize what is clearly durable. Expense what is honestly uncertain. Fund what can pay for itself. Let the feedback loop – ship, measure, learn, invest – set the pace of everything else.

Beyond the pattern, we recognize that some industries are more highly regulated than others, and these sectors may require more extensive capitalization for compliance. That said, the 90-day cycle for delivery of value is valuable regardless of the accounting treatment of an increment of value.

Moving Forward

The new economics of software development dictate that the sharpest leaders have stopped optimizing the accounting treatment. Instead, they optimize the feedback loop. If this article has provoked fresh thinking about your capital and expense budgets, consider taking the following actions within the next 90 days.

1. Review your capitalization rate
   Measure the percentage of spend that is capitalized. If your organization uses agile development and your capex rate is above industry medians, you have an audit risk and transparency problem.
2. Fund value streams or products, not projects
   Replace annual project capital expenditures with outcome-gated envelopes lasting no longer than 90 days. Reward shipping a slice and monetizing it, not completing work breakdown structure items in a plan.
3. Instrument every release
   No release goes live without a revenue, cost, or usage metric attached to it. This is essential to the monetize-to-fund loop. It also aligns with the measurement guidance provided in The Emperor’s (not so) New Clothes: the scam of corporate performance frameworks and what to do about it.
4. Pre-write your AI policy
   Decide in advance how AI-assisted code, model usage and evaluation infrastructure map to capitalization, before your auditors ask.
5. Make FinOps a senior executive role
   The combination of cloud and SaaS spend are the largest controllable IT expense lines. Treat them like cost of goods sold (COGS) with ownership, forecasts, variance analysis, and accountability for results.

 

This article was originally published in Architecture & Governance Magazine in April 2026.

References

[1] Financial Accounting Standards Board (1985) – SFAS 86, retrieved from FASB website on April 17, 2026.

[2] Munter, Paul (1999) – Accounting for Software Development Costs, The CPA Journal, retrieved from cpajournal.com website on April 17, 2026.

[3] Carey, Nolan (2021) – Cloud spending outstrips on-premises investments for the first time, InfoWorld, retrieved from infoworld.com website on April 17, 2026.

[4] Banerjee, Ashish (2024) – Maximize the ROI of Cloud Investments, Gartner, Inc. Document G00816239, published December 4, 2024.

[5] CloudNuro (2026) – A Brief History of SaaS: from ASPs to the Subscription Economy, CloudNuro, retrieved from the cloudnuro.ai website, published January 12, 2026.

[6] Decker, H., Lozada, C., Alexander, M. (2024) – Software and SaaS Contracts: New Negotiation Tactics for CIOs, Gartner Inc., document G00820833, published December 11, 2024.

[7] Stegman, E., Guevara, J., Sharma, A., Mehta, P., Tyagi, P.  (2025) – IT Key Metrics Data 2026: Industry Measures – Executive Summary, Gartner Inc., document G00840319, December 11, 2025.

[8] DeBellis, D., Storer, K., Harvey, N., et. al. (2025) – DORA Report, Google Inc., retrieved from the Google website (login required), published September 23, 2025.

[9] Cui, K., Demirer, M., Jaffe, S., Musolff, L., Peng, S., and Salz, T. (2025) – The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, Massachusetts Institute of Technology, retrieved from the Economics department’s website on April 18, 2026.

[10] Kersten, M. (2018) – Project to Product: how to survive and thrive in the age of digital disruption with the flow framework, Kindle Edition, IT Revolution, Portland OR. 97210

[11] Greski, L. (2026) – The Emperor’s (not so) New Clothes: the scam of corporate performance frameworks and what to do about it, Architecture & Governance Magazine, January 7, 2026, IASA Global, San Antonio TX, 2026.