This article is based on guidance originally published in the Arcati Mainframe Yearbook and attributed to Compuware (originally sourced via it.toolbox.com). It has been rewritten and expanded for a DevOps engineering audience.
Why Mainframe DevOps Matters
Mainframes continue to run the core business processes of banks, insurers, retailers, and governments worldwide. Yet the software delivery practices surrounding them have, in many organisations, changed little in decades. As enterprises adopt Agile and DevOps across distributed and cloud workloads, the mainframe risks becoming an island — a bottleneck that limits the speed and reliability of the entire value stream.
To remain competitive, enterprises must bring the same DevOps disciplines that accelerate cloud-native delivery to bear on their mainframe applications and data. The following ten steps provide a practical, phased roadmap for doing exactly that.
Step 1 — Modernise the Developer Workspace
Most mainframe development still happens inside 3270 green-screen ISPF environments. These tools require highly specialised knowledge and are immediately alienating to developers who have grown up with modern IDEs. The productivity gap between experienced mainframe engineers and newer staff widens every year.
The first step is to give developers a workspace that looks and behaves like the Eclipse-style IDEs they already know. A modern, GUI-based mainframe IDE lowers the barrier to entry, allows developers to move fluidly between mainframe and non-mainframe codebases, and makes it practical to build cross-functional Scrum teams that include mainframe components without requiring every member to master ISPF.
Step 2 — Introduce Unit Testing
Unit testing is a cornerstone of Agile delivery. Frequently testing small, isolated increments of code allows developers to verify that their work aligns with immediate objectives and to catch defects at the lowest possible cost — before they compound.
Many mainframe developers have spent careers in waterfall environments where testing happened late and infrequently. Introducing unit testing therefore requires both tooling and a shift in working habits. Teams must learn to decompose their work into smaller, testable units and to run tests continuously as they code rather than at the end of a development cycle.
Step 3 — Add Functional and Integration Testing
Unit testing confirms that individual code units work correctly in isolation. Functional testing validates that those units satisfy their specified requirements — that the system does what it is supposed to do from a business perspective.
Once functional testing is in place, integration testing extends coverage further: it verifies that two or more programs work together as expected. On the mainframe, where large COBOL or PL/I applications interact with DB2, VSAM, CICS, and IMS, integration testing is particularly important. A defect in a cross-program interface can cascade into failures across core business processes.
Step 4 — Make Application Logic Visible and Understandable
Mainframe applications are often large, complex, and poorly documented. A single COBOL program may have grown over decades through dozens of hands, with little consistent commentary. New contributors — and even experienced ones working in unfamiliar areas — can spend the majority of their time simply trying to understand existing code before they can safely modify it.
Tooling that automatically visualises application logic, program interdependencies, data structures, and runtime call sequences dramatically reduces this orientation time. When developers can see how a system behaves at runtime — including which programs are called, in what order, and what data they read and write — they can work on unfamiliar systems with far greater confidence and speed.
Step 5 — Implement Continuous Quality Controls
Mainframe applications typically support core business processes that have very low tolerance for error. Transitioning from waterfall to Agile delivery cycles makes continuous quality control not just desirable but essential, for three reasons:
- Error tolerance is low. Failures in core business systems — payments, claims processing, inventory — carry immediate and significant business consequences.
- Cost of defects rises with time. In Agile cycles, a defect caught in the current sprint costs far less to fix than one discovered during system integration testing or, worse, in production.
- The developer talent pool is changing. As experienced mainframe engineers retire, less experienced developers are increasingly responsible for maintaining and evolving these systems. Automated quality controls compensate for the loss of institutional knowledge.
Continuous Integration (CI) is the enabling mechanism here. A CI pipeline that triggers quality checks — static analysis, unit tests, security scans — every time code is committed ensures that quality is maintained continuously rather than assessed periodically.
Step 6 — Adopt Agile Planning and Cross-Platform Scrum Teams
The goal is to move away from mainframe-only development silos and toward unified Scrum teams that include developers working on mobile, web, and mainframe components simultaneously. Work should be captured in stories and epics that represent specific units of business value — not technical tasks tied to a waterfall project plan.
This requires formal Agile training for all team members. Technical leads and Product Owners need in-depth coaching on backlog management, sprint planning, and the role of acceptance criteria. All team members should at minimum understand how to read a Scrum or Kanban board and participate in sprint ceremonies. Without this foundation, Agile tooling becomes overhead rather than an accelerator.
Step 7 — Leverage Operational Data Throughout the Lifecycle
Writing correct code is necessary but not sufficient. Mainframe applications must also perform efficiently under production load, because mainframe compute is typically billed by MIPS or MSU consumption. Inefficient code that works correctly can still be extremely expensive to run.
Integrating operational metrics — CPU usage, I/O rates, response times, database call patterns — into the DevOps lifecycle gives both development and operations teams a shared, data-driven view of application behaviour throughout its lifecycle. Early visibility into performance characteristics allows teams to identify and eliminate inefficient code before it reaches production, reducing both risk and cost.
Step 8 — Modernise Software Configuration Management
Traditional mainframe Software Configuration Management (SCM) tools were designed to support waterfall delivery: they provide version control, change tracking, and audit trails, but they are not built for the rapid, iterative workflows of Agile and DevOps.
Modern SCM for the mainframe must do more than automate and audit the SDLC. It must integrate with the broader DevOps toolchain — linking to CI/CD pipelines, issue trackers, testing frameworks, and deployment automation — so that the mainframe participates in the same end-to-end workflow as every other platform. The transition from waterfall SCM to Agile-enabling SCM is a significant change and should be carefully planned to avoid disrupting work in progress.
Step 9 — Automate Deployment with Reliable Rollback
Fast, reliable delivery requires automating the promotion of code and related artefacts across all targeted environments in a synchronised, repeatable way. Manual deployment processes introduce delay, inconsistency, and human error — all of which are incompatible with the release cadences that DevOps demands.
Equally important is automated rollback. When a deployment fails or a defect is discovered in production, teams must be able to revert quickly and automatically to the last known-good state. Automated rollback is not just a safety net; it is a prerequisite for accepting the higher deployment frequency that DevOps targets, because it contains the blast radius of any individual failure.
Step 10 — Integrate the Mainframe into a Unified, Cross-Platform DevOps Model
The ultimate objective is a de-siloed environment in which the mainframe is treated as one platform among many — distinguished by its scalability, reliability, performance, and security, but managed through the same DevOps processes, pipelines, and dashboards as distributed and cloud systems.
This unified model extends to IT Service Management (ITSM) as well. As more business-critical user journeys span multiple platforms — from a mobile front end through a web API layer to a mainframe system of record — ITSM teams need a single pane of glass for incident detection, triage, and resolution regardless of where the root cause lies.
The payoff is significant: when mainframe delivery velocity matches the rest of the organisation, the entire business becomes more adaptive. Conversely, if the mainframe remains a bottleneck, the agility gains achieved on other platforms will always be constrained by the slowest part of the value chain.
Summary
| Step | Focus Area |
|---|---|
| 1 | Modernise the developer workspace (replace green-screen ISPF with Eclipse-style IDE) |
| 2 | Introduce unit testing practices and tooling |
| 3 | Add functional and integration testing |
| 4 | Make application logic and runtime behaviour visible |
| 5 | Implement continuous quality controls and CI |
| 6 | Adopt Agile planning and form cross-platform Scrum teams |
| 7 | Leverage operational data (MIPS/MSU, I/O, latency) throughout the lifecycle |
| 8 | Modernise SCM to integrate with the broader DevOps toolchain |
| 9 | Automate deployment with reliable, automated rollback |
| 10 | Integrate the mainframe into a unified, cross-platform DevOps model |
Mainframe modernisation is not a single project with a finish line — it is a continuous journey of incremental improvement. Each step in this framework builds on the last, progressively closing the gap between mainframe delivery practices and the DevOps standards now expected across the rest of the enterprise.