In many organizations, the mainframe platform is treated as a separate world. It sits alongside the rest of the organization’s IT landscape and is managed with its special processes, staff, and governance. This view is understandable, and often historically grown, but it is an unnecessary misconception in IT.
Your mainframe platform is a component of your IT landscape, just like any other. It has a typical position, responsibilities, and characteristics. Understanding that position is the starting point for making good decisions about it.
Where the mainframe sits
In most organisations, mainframe applications operate in the back-office layer. They handle high transaction volumes, manage large volumes of data, and combine transactional and analytical capabilities. What they typically lack is presentation logic. Modern z/OS applications are headless and comprise integration, business, and data logic.
They expose business logic and data through well-defined service interfaces such as REST APIs, Kafka events, message queuing, and file-based interfaces.
What surprises many people who think mainframe applications are silos by definition, a layered architecture separating presentation, business logic, and data access, was the mainframe’s best practice long before the web industry reinvented it and called it Model-View-Controller. The principles are the same.
Similar layering principles, applied at the enterprise level, provide a clear separation among front-office, mid-office, and back-office layers. The mainframe applications are mostly in the back-office layer, less frequently in the mid-office. When positioned and built accordingly, they connect cleanly to the rest of your IT landscape through well-defined service interfaces.
What problems arise when you ignore this
Several years ago, I worked with an organization that learned this the hard way. This organization had a premium calculation function tightly built into the presentation layer of its mainframe application, deeply entangled with the front-end processes. This is not a mainframe-specific problem, by the way. I have seen the same pattern in web applications from the early days of the e-business era. The tendency to entangle layers is everywhere.
When the company decided to move to a self-service model, in which customers could calculate their own premiums online, they hit a problem. The business logic they needed to expose was not accessible because it was entangled with the mainframe presentation logic. It was buried inside the front-end, inseparable from it.
The result was that the organization needed to execute a complex and expensive refactoring effort that could have been avoided entirely. The premium calculation logic eventually became a proper service on the mainframe, accessible through a standardised web service interface. The architecture became more flexible and more maintainable. But it took significant time and resources to get there.
The lesson is that the same architectural principles apply everywhere. Modular design, separation of concerns, and service-oriented interfaces apply to the mainframe too.
The practical view and the decision that follows
Understanding where the mainframe fits is the starting point. Now you can better understand its value and reason about it with clear information.
Many organisations make mainframe decisions implicitly. Applications get labelled “legacy” and targeted for replacement without anyone evaluating their actual business value or the real cost of the alternative. That is how organisations end up stuck halfway through a migration, running two systems for the same functionality, with double the cost and double the risk.
The one option that is never viable is inaction. Leaving mainframe applications unattended deepens technical debt and increases risk. Sometimes to the point where decisions are no longer made by choice, but by crisis.
What changes when you understand the mainframe’s position in your IT landscape is that these decisions become tractable. You know what the platform does, what it costs, how it connects, and what it would take to change it. That is not a guarantee of an easy answer. But it is the foundation for an informed one.
I cover these topics in Don’t Be Afraid of the Mainframe: The Missing Introduction for IT Leaders and Professionals. The book is available on Amazon, Barnes & Noble, 24bookprint, and soon on Bol.com, Apple Books, Google Play, and other bookstores. Links in the comments.
Making the transformation decision
When organisations reach the point of making a formal decision about the mainframe, they often approach it as a platform question: should we keep it or replace it?
But the better question is: what do we actually know about this platform, and what would we need to know to make an informed decision?
That means getting clarity on four things. First, the cost. Not just the infrastructure bill, but the total cost of running, maintaining, and developing on the platform, compared to realistic alternatives. Second, the value. What business functions depend on this platform, and what would it genuinely cost to replace them? Third, the technical state. How much debt has accumulated, and what would it take to address it? And fourth, the strategic fit. Does the platform’s position in the IT landscape align with where the organisation is going?
Organisations that keep their mainframe platform and applications well-maintained, up to date, architecturally sound, and free of accumulated debt can host healthy, modern applications that fully exploit what the mainframe does best: transactional throughput, data integrity, security, and reliability at scale. That is a viable and often underestimated path. The alternative decisions, staying too long with a platform that genuinely no longer fits, or leaving one that was working well while underestimating the cost of replacing it, are the ones organisations tend to regret. The platform itself is not the problem. Neglect is. And neglect compounds. The longer maintenance is deferred, the more expensive and disruptive the recovery becomes. At some point, the backlog grows so large that the organisation loses the ability to choose its own path forward.
The starting point is understanding where the mainframe fits in your IT landscape, what it does, and how it connects. From there, the transformation question becomes a business decision rather than a technology prejudice.
These topics — architecture, integration, transformation strategy, and the mainframe-versus-cloud decision — are covered in depth in my book Don’t Be Afraid of the Mainframe: The Missing Introduction for IT Leaders and Professionals, available on Amazon and via seneqa.nl/dbaotm.