This article is based on reporting originally published by TechTarget.
The Mainframe Problem DevOps Teams Cannot Ignore
For years, large enterprises tried to build DevOps practices around their mainframes rather than include them in the transformation. The strategy was understandable: mainframes running decades-old COBOL applications felt too risky and too specialized to touch. But as DevOps maturity has grown across distributed systems, the gap between cloud-native delivery pipelines and monolithic mainframe release cycles has become impossible to ignore.
“At companies with core back-end mainframe systems, there are monolithic apps — sometimes 30 to 40 years old — operated with tribal knowledge,” said Ramesh Ganapathy, assistant vice president of DevOps for Mphasis, a consulting firm whose clients include large banks. “Distributed systems, where new developers work in an Agile manner, consume data from the mainframe. And, ultimately, these companies aren’t able to reduce their time to market with new applications.”
Velocity, self-service infrastructure, and ephemeral environments have become standard in cloud-native DevOps. Mainframes are the inverse: extraordinarily reliable, compute-dense platforms, but ones that were never designed for rapid, iterative change. Simply migrating off the mainframe sounds like the obvious answer, but cost, risk, and complexity make that a multi-year undertaking for most organizations.
Mainframe Spending Is Growing, Not Shrinking
Despite the appeal of cloud migration, mainframes are not disappearing from enterprise data centers. According to a Forrester Research Global Business Technographics Infrastructure Survey conducted in late 2017, nearly half of enterprises with mainframes expected their usage to increase over the following two years — an 18% increase from the prior year’s survey. Only 14% expected mainframe usage to decrease, compared with 24% in the previous survey period.
That growth reflects the irreplaceable role mainframes play in financial services, insurance, healthcare, and government — industries where reliability, throughput, and data integrity are non-negotiable. Whatever their long-term architecture strategy, these organizations need a workable DevOps approach for mainframe environments right now, because they compete with agile, cloud-native startups that can ship continuously.
A Real-World Example: Experian’s Mainframe DevOps Limbo
Credit bureau Experian offers a candid case study. The company’s IBM z13 mainframes perform a process called pinning — associating credit data with specific individuals during data ingestion. The resulting identifier is reportedly more unique and reliable than Social Security numbers. Experian’s mainframe environments had not experienced an outage across any of its six mainframe instances in more than three years at the time of reporting, underscoring the platform’s reliability.
But reliability is not the problem. DevOps friction is.
“IBM has recognized what’s happening and is making changes to z/OS and z Systems,” said Barry Libenson, global CIO for Experian. IBM’s UrbanCode Deploy CI/CD tool, for example, supports application deployment automation on the mainframe. “But our concern is there aren’t really tools yet that allow developers to provision their own [production infrastructure], or native Chef- or Puppet-like configuration management capabilities for z/OS.”
At the time of the original reporting, Chef supported z Systems mainframes through integration with LinuxONE, and Puppet offered z/OS support. However, Experian’s senior mainframe expert preferred z/OS over Linux, and Libenson said he would prefer those capabilities to come from native z/OS management tools rather than Linux-layer workarounds.
Facing a tooling gap, Experian developers built homegrown tools to manage production services such as z Systems logical partitions (LPARs), containers, and VMs on the mainframe. These tools monitored utilization and either automatically shut down idle resources or alerted administrators. It was a workable solution, but not an elegant one.
“That’s not the way these systems are designed to behave, and it’s expensive. In commodity hardware, I have lots of options, but if I run out of horsepower on the mainframe, buying additional engines from IBM is my only choice,” Libenson said. “It’s also increasingly difficult for us to find people that understand that hardware.”
Experian’s longer-term plan was to migrate away from the mainframe entirely and had already ceased new product development on mainframe applications. Libenson estimated the full migration would take three to five years.
Bridging the DevOps Gap: Tools From IBM, CA, and Compuware
For organizations that cannot yet afford or justify a full mainframe migration — one insurance firm quoted in the original reporting estimated the cost at $30 million — mainframe vendors have been building out DevOps-oriented tooling.
IBM
- UrbanCode Deploy: Provides application deployment automation and orchestration workflows for mainframe environments.
- Git integration: IBM added support for code deployments to z Systems from Git repositories.
- z/OS connector for Jenkins: Allows teams to include mainframe deployments in Jenkins CI/CD pipelines alongside distributed system jobs.
- z Systems Development and Test Environment: Offers some self-service capabilities for application deployment in lower (non-production) environments.
CA Technologies
- Mainframe Operational Intelligence: Provides AIOps support for mainframe environments.
- Mainframe Resource Intelligence (introduced June 2018): A SaaS tool that scans mainframe environments and delivers optimization recommendations.
Compuware
- Provides tooling for faster updates and provisioning on mainframes.
- Notably, Compuware underwent its own internal DevOps transformation over the four years preceding this reporting, positioning itself to lead customers through mainframe modernization by example.
Third-Party CI/CD Tools
Beyond the mainframe vendors themselves, CI/CD platforms from Electric Cloud and XebiaLabs also supported mainframe application deployments at the time of this reporting. Teams should verify current support levels directly with vendors, as the tooling landscape in this space continues to evolve.
The Biggest Barrier Is Cultural, Not Technical
Vendors and practitioners broadly agree that the most significant obstacle to DevOps for mainframe is not technology — it is organizational culture. This is the classic developer-versus-operations culture clash, but amplified by decades of specialized knowledge, institutional inertia, and a workforce gap that grows wider every year as experienced mainframe engineers retire.
Ganapathy’s recommended approach is to include mainframe experts directly in cross-functional DevOps strategy teams — not to confine them to a single business unit, but to give them a voice in standardizing practices across all infrastructure platforms, from public cloud to back-end mainframe.
“That’s where mainframe knowledge has the greatest value and can play a role at the enterprise level,” Ganapathy said. “It’s important to give mainframe experts a better say than being confined to a specific business unit.”
Redefining DevOps Success for Mainframe Environments
Mainframes may never match the deployment velocity of containerized microservices on Kubernetes. But Christopher Gardner, an analyst at Forrester Research, argued that velocity is only one dimension of DevOps maturity.
“Quality and culture are also part of DevOps, as are continuous feedback loops,” Gardner said. “If you’re releasing bugs faster, or you’re overworking your team and experiencing a lot of employee turnover, you’re still not doing your job in DevOps.”
For enterprises managing hybrid environments that span mainframes and distributed systems, practical DevOps maturity means applying consistent tooling, feedback, and cultural practices across all platforms — not just the ones that are easiest to automate. That requires realistic expectations, sustained investment in cross-functional teams, and a willingness to treat the mainframe as a first-class citizen of the software delivery pipeline.
Key Takeaways for DevOps Engineers and IT Leaders
- Do not exclude the mainframe from your DevOps strategy. Monolithic back-end systems slow the entire value stream if they operate outside your CI/CD pipeline.
- Evaluate existing vendor tooling before building homegrown solutions. IBM, CA, Compuware, and third-party CI/CD vendors offer mainframe-compatible tooling that continues to mature.
- Retain and elevate mainframe expertise. Experienced mainframe engineers are a finite and shrinking resource. Include them in architecture and DevOps strategy conversations.
- Plan migrations with realistic timelines and cost estimates. Full mainframe migrations are multi-year, multi-million-dollar programs. Incremental modernization with DevOps tooling is often the pragmatic interim step.
- Measure DevOps success holistically. Deployment frequency matters, but so do defect rates, team health, and feedback loop quality — especially in high-reliability mainframe contexts.