Why Finance and Mainframe Teams Need to Stop Talking About Cost Savings and Start Talking About Business Value
There is an old accounting joke:
An accountant is someone who solves a problem you didn’t know you had in a way you don’t understand.
For decades, many organizations have treated their mainframe teams much the same way.
Mainframe engineers talk about MIPS, MSUs, Db2 access paths, CICS transactions, batch windows, and COBOL optimization. Finance nods politely, writes down a few numbers, and leaves, wondering whether anyone answered the question. Meanwhile, the mainframe team exits the meeting convinced that Finance only cares about cutting costs.
Both sides are wrong.
They are trying to solve the same business problem; they simply speak different dialects.
Finance talks about earnings, margins, revenue recognition, return on investment, and risk. Mainframe teams talk about performance, maintainability, technical debt, and application complexity.
The organizations that recognize the connection discover something important: Optimization is not an IT initiative. It’s a business strategy.
The Optimization Myth
Optimization projects are often justified with a familiar list of goals:
- Reduce CPU consumption
- Lower software licensing costs
- Reduce infrastructure expense
- Cut monthly operating costs
Those are worthwhile objectives and easily approved. Accountants enjoy eliminating unnecessary expenses almost as much as programmers enjoy deleting code. As the old programming joke goes:
Nothing runs faster, is more reliable, or requires less maintenance than code that no longer exists.
However, the problem isn’t with the savings. It’s that organizations often stop measuring there.
The real payoff comes from reducing technical debt, simplifying applications, shortening delivery cycles, and making the business easier to change.
The Hidden Liability on the Balance Sheet
Many of the world’s most valuable business processes still run on the mainframe. We’re talking about:
- Revenue recognition
- Claims processing
- Core banking
- Customer billing
- Inventory management
- Policy administration
These applications aren’t just software. They represent decades of accumulated business knowledge. In many organizations, that knowledge exists in only three places:
- The source code
- Documentation written 10-50 years ago
- Dave
Unfortunately, Dave plans to retire next spring.
Finance routinely measures concentration risk in customers and suppliers, yet many organizations accept enormous concentration risk in application knowledge. When a billion-dollar business processes depend on a handful of specialists, that’s not simply an IT issue—it’s business risk.
Don't miss these other great articles
Technical Debt Is Business Debt
Executives ask questions like:
- Why did this product launch take nine months?
- Why does every regulatory change become a major project?
- Why can’t we integrate acquisitions faster?
- Why does every estimate begin with, “We need to investigate the existing logic first”?
The answer often isn’t capacity. It’s complexity.
Applications accumulate business rules the way attics accumulate furniture. Everything might still matter. Nobody wants to move anything because they’re afraid the floor will collapse.
Optimization forces organizations to understand what their applications actually do — not simply how efficiently they run. That conversation belongs in the boardroom as much as the data center.
The Business Case Nobody Calculates
Imagine two companies. Both spend about the same on their mainframe environment. Both process millions of transactions.
One needs eight months to launch a new product because every enhancement requires navigating decades of intertwined COBOL, undocumented dependencies, and forgotten business rules.
The other invested in simplification, code analysis, optimization, and modernization. The same enhancement ships in three months. What would you predict:
- Which company recognizes revenue first?
- Which responds faster to competitors?
- Which adapts more easily to regulatory change?
Business outcomes often dwarf the infrastructure savings that justified the optimization project in the first place.
A Better Partnership
Historically, Finance and mainframe teams meet when someone needs budget approval. For a better business partnership, they should be meeting much earlier.
Finance understands business priorities. Finance can quantify delayed revenue, operational risk, maintenance costs, governance requirements, and knowledge concentration.
Mainframe teams understand operational realities. They can identify excessive complexity, obsolete business logic, inefficient processing, and opportunities to simplify critical applications.
Together, they can identify where technical debt creates measurable business drag.
The conversation changes from:
“How much CPU can we save?” to “How much faster can the business move?”
The Metric That Matters Most
CPU utilization matters. So does profitable growth. But the most valuable optimization metric may be adaptability.
- Can new developers understand the application?
- Can business analysts explain the rules?
- Can changes be made safely?
- Can institutional knowledge survive retirement?
- Can new products reach the market faster?
Those are technology questions that ultimately determine business performance.
Balancing More Than the Books
Programmers worry about technical debt. Accountants worry about financial debt. Both eventually discover the same truth: Complexity compounds.
One group calls it interest. The other calls it legacy code.
The organizations that outperform over the next decade won’t simply ask their mainframe teams to reduce costs. They’ll ask them to reduce operational risk, preserve institutional knowledge, simplify critical applications, and accelerate business change.
When Finance and IT start measuring optimization the same way, the mainframe stops looking like a cost center—and starts looking like what it has always been: a strategic business asset.
![This Critical System [Just Runs] – But Do You Trust It?](https://planetmainframe.com/wp-content/uploads/2026/06/This-Critical-System-Just-Runs-1080x454.jpg)
I enjoyed this article, Allan. You did a nice job of reframing the conversation away from “How much can we save?” toward “How much more capable can the business become?” That’s an important shift.
One thought I’d add is that there’s an architectural discipline sitting between today’s systems and tomorrow’s business strategy: Transition Architecture.
Simplifying applications, preserving institutional knowledge, sequencing modernization, and reducing operational risk aren’t merely optimization activities. They’re the work of helping an organization move safely from its current state to its future state without interrupting the business. If a business is in a constant state of growth, neglecting any one of those elements eventually slows that growth or stops it altogether.
Organizations have invested heavily in CI/CD to accelerate software delivery, but continuous delivery alone doesn’t make an organization adaptable. Treating Transition Architecture as an ongoing discipline for managing complexity enables organizations to absorb change incrementally, making modernization less disruptive and far less costly over time.
Once you assume growth is continuous, the architecture changes from:
Current State → Future State
to
Current State₁ → Next Current State₂ → Next Current State₃ → …
In my experience, the real return on investment isn’t measured only by lower CPU bills or faster batch windows. It’s measured by how confidently an organization can embrace change while preserving what already works. That’s when the mainframe stops being viewed as legacy technology and starts being recognized as a strategic platform for continuous business evolution.
Bruce, thank you for such a thoughtful addition. I completely agree, and I think you’ve expanded the conversation in an important way.
Your notion of Transition Architecture and, in particular, the progression from Current State₁ → Next Current State₂ → Next Current State₃ really resonated with me. We often speak as though organizations modernize by making one giant leap to a “future state,” when in reality successful businesses are continually evolving. There is never a final destination. There is only the next current state.
There is an old saying that every CIO regrets the technology decision they made two years ago. Not because it was necessarily the wrong decision, but because the business, the market, and the technology landscape moved again. That’s exactly why optimization can’t simply be about reducing CPU utilization or software licensing costs. It has to be about building the partnerships and architectural discipline that allow an organization to continually adapt with confidence.
I particularly like your phrase “confidence in architecture.” It complements something I’ve been exploring in several recent articles around organizational trust. Architecture that is understandable, resilient, and intentionally evolved creates confidence within the organization. Over time, that confidence becomes trust from customers, regulators, investors, and employees because the business can continue to change without compromising the integrity of its core systems.
I think that’s where Finance and IT find common ground. Finance isn’t really investing in optimization. It’s investing in an architecture that gives the business confidence to embrace whatever the next current state demands. Thanks for adding that perspective. It fits beautifully with the broader conversation.
Allan, what struck me most was your connection between confidence and organizational trust. I’d been thinking about Transition Architecture primarily as the discipline that enables safe, continuous change. Your observation adds another dimension: when organizations consistently experience safe, understandable change, confidence accumulates into trust.
It also struck me that we may be approaching the same summit from opposite sides of the mountain. You’re exploring business value and organizational trust, while I’m looking at the architectural discipline that enables organizations to evolve safely over time. Those perspectives seem remarkably complementary.
Perhaps that’s where our ideas converge. Transition Architecture creates the conditions for safer and more understandable change that, in turn, builds organizational confidence. Over time that confidence, as you noted, becomes trust. I suspect organizational trust may be one of the most undervalued architectural outcomes because it enables the business to embrace whatever the next current state demands.