The Nines Don’t Lie—But They’re Not the Whole Truth
The mainframe platform is not the problem. So what is? Mark Schettenhelm, principal product manager at BMC, explores the question
Ask any mainframer what sets their platform apart and the answer comes quickly. Reliability. Scalability. Security. Performance. They’ll say it with conviction, and they’ll be right. The mainframe’s track record on those dimensions is genuinely extraordinary. Decades of enterprise-critical workloads processed without a stumble. Uptime measured not in hours but in nines—five, six, sometimes more. The platform has earned that pride.
So then why does the conversation about leaving the mainframe keep coming up? Why does every IT leadership meeting seem to contain at least one voice asking whether the organization would be better served by moving off the platform entirely? If the mainframe is all those things—and it is—what is driving these calls to leave?
The answers are layered, and I won’t pretend there is only one. But there is a factor that I believe is consistently underweighted in this conversation. It is not the hardware. It is not the platform architecture. It is the state of mainframe applications themselves—and the developer experience that surrounds them.
A Familiar Scene
Picture this. Someone in the organization has a brilliant idea. It is well-scoped, well-reasoned and would deliver real value. It lands in a planning session, and the distributed teams respond quickly. Estimates come back. Timelines are sketched. There is energy in the room.
Then someone asks the mainframe team.
The hesitation is almost palpable. Not because the mainframe team lacks skill or intelligence—far from it. But the codebase they are working with was written in a different era. The tools available to them look and feel like the 1980s. There is no modern IDE, no CI/CD pipeline they can lean on, no clean interface for rapid iteration. So they hedge. They caveat. They ask for time to assess. And in many cases, they struggle to produce an estimate at all.
That moment—repeated across meetings, quarters and years—is quietly doing enormous damage. The initiative moves forward by routing around the mainframe. Then the next one does too. And the one after that. Each workaround adds a layer of complexity and a degree of separation between the mainframe and the business value it is supposed to be delivering. At some point, leadership asks a reasonable question: If we are designing everything to work around this platform, why are we keeping it?
The Risk We Don’t Talk About
The mainframe community has a deeply ingrained relationship with the concept of risk. Change is risk. Modifications to production systems threaten uptime. The caution is understandable—the stakes are real and the responsibility is enormous. But this orientation toward risk has a shadow side that the community rarely examines directly.
The number of nines you have doesn’t matter if you aren’t delivering value.
Availability is a means to an end, not the end itself. An organization does not stay in business because its mainframe ran for eight consecutive years without an unplanned outage. It stays in business because it delivered products and services and experiences to its customers. If the platform is highly available but functionally stagnant—if it cannot keep pace with the rate at which the business needs to move—then its uptime becomes a feature in service of very little.
What the community underweights is the risk of standing still. There is a tendency to frame all change as dangerous and all stability as safe. But stagnation carries its own risk—the risk of irrelevance, of being sidelined, of watching the organization build its future somewhere else.
The Application Layer Is the Problem
Let me be direct about what I mean when I talk about the lack of application modernization. I am not advocating for ripping out COBOL or abandoning the platform. I am talking about the layers that surround those core workloads—the interfaces, the integration points, the development tooling, the deployment practices. These are the things that have, in many shops, not meaningfully advanced since the era in which the original systems were built.
Developers working on distributed platforms today have access to an ecosystem that accelerates nearly every aspect of their work. Version control is ubiquitous. Testing frameworks are mature and integrated. Deployment pipelines allow for frequent, low-risk releases. Feedback loops are tight. Errors are caught early. The pace of delivery is fast enough to match the pace of business need.
Mainframe developers, in too many organizations, are still working in environments that predate most of these practices. The green screen is still the primary interface. Development, test and production pipelines are manual and fragile. The concept of continuous delivery exists somewhere else, on some other platform. The result is not just slower delivery; it is a developer experience that makes it genuinely difficult to attract and retain talent, to onboard new team members and to build the kind of momentum that modern software development requires.
This is not the fault of the people. Mainframe developers are often extraordinarily skilled. The problem is the environment they are asked to work in, and the applications they are asked to maintain and extend. When those applications have not been modernized—when interfaces are brittle, integration is complex, and the only people who truly understand the system are those who built it twenty years ago—agility becomes almost impossible.
Reclaiming the Seat at the Table
I have written before about mainframers not being invited to the table. A decade on, the invitation is still not automatic—but the reason has shifted. It is no longer just about cultural separation or the perception that the mainframe is a legacy curiosity. It is increasingly about whether the mainframe team can deliver at the pace the business demands. If the answer is “not as fast as the other teams,” the business will draw its own conclusions.
The path forward is not to abandon what makes the mainframe exceptional. The reliability, security and throughput at scale are genuine competitive advantages. The path forward is to pair those platform strengths with a modern application architecture and a modern developer experience—to make the mainframe as easy to deliver value on as it is reliable in delivering it.
That means investing in modernization of the applications that run on the mainframe, not just the platform itself. It means treating the developer experience as a first-class concern rather than an afterthought. It means building pipelines, adopting practices and creating the kind of environment where a talented developer can do their best work, whether they’ve been in the mainframe world for 30 years or 30 days.
And critically, it means changing the response in that planning meeting. Not the reflexive hesitation that signals “we can’t keep up,” but a confident, informed estimate that signals “we are part of this.” That response does more to secure the mainframe’s future than any number of uptime metrics ever could.
The Platform Is Ready. Are We?
The calls to leave the mainframe are not fundamentally about the mainframe. They are about speed, agility and the ability to deliver. The platform has been answering the reliability question for decades. It is time for the community to take equally seriously the questions of velocity and developer experience.
The mainframe is not holding itself back. The question is whether the ecosystem of practices, tooling and applications that surrounds it has kept pace with what the business needs today. In too many organizations, it has not. That gap, not the platform, is what is putting the mainframe’s future at risk.
Closing that gap is hard work. It requires investment, organizational will and a willingness to challenge practices that have been in place for a long time. But it is far less expensive—in every sense—than the alternative.