What Is Shift-Left Testing?

Shift-left testing refers to the practice of moving software testing activities earlier in the development lifecycle. The name comes from the idea of a traditional pipeline visualized as a left-to-right timeline: development on the left, deployment on the right, and testing historically clustered near the right end just before release.

Traditionally, most testing occurred in a dedicated QA phase immediately before deployment. This late-stage testing is valuable for verifying production readiness, but it carries a significant cost: defects discovered at that point are expensive to fix. By the time a bug surfaces in a pre-deployment test suite, the code that caused it may already be deeply intertwined with other modules. Diagnosing the root cause, isolating the affected code, applying a fix, and re-verifying that nothing else broke can consume days or weeks of engineering time.

Shift-left testing addresses this by running tests as soon as individual units of code are written—well before integration, staging, or deployment phases. The earlier a defect is caught, the smaller and cheaper it is to fix, because the developer who wrote the code still has it fresh in mind and the surrounding codebase has not yet grown around it.

This approach is especially important in CI/CD pipelines, where teams aim to release application changes on a near-continuous basis. Late-discovered bugs create bottlenecks that undermine the entire goal of continuous delivery. Shift-left testing keeps the pipeline flowing by surfacing problems while they are still small and localised.

Shift-Left Does Not Replace Late-Stage Testing

A common misconception is that shift-left testing means eliminating pre-deployment testing. It does not. Tests performed earlier in the pipeline complement—rather than replace—integration tests, system tests, and acceptance tests run closer to release. The practical effect is that far fewer serious defects survive long enough to reach those later stages, which makes the end-to-end testing phase faster and less disruptive.

Think of shift-left as adding layers of defence earlier in the pipeline, not as removing layers at the end.

Why Shift-Left Testing Matters Even More on the Mainframe

The general benefits of shift-left testing apply to any platform, but several mainframe-specific factors make its adoption especially valuable in that context.

Legacy Languages and Coding Discipline

Most mainframe business logic is written in COBOL, PL/I, or Assembler—languages designed decades before modern software engineering practices became mainstream. These languages do not enforce the same kind of structural discipline as more recent languages. A language like Python, for example, uses indentation as syntax, encourages modular design, and has a rich ecosystem of linting and static analysis tools that steer developers toward fewer mistakes. COBOL and its peers were designed for correctness of computation rather than for guiding developer behaviour. That does not make them error-prone by nature, but it does mean that early automated testing plays an especially important role in catching mistakes that the language itself will not flag.

Legacy Codebases and Complex Dependencies

Many mainframe applications run on codebases that are decades old, with layers of patches, extensions, and dependencies accumulated over time. In environments like these, a seemingly minor change can have unexpected effects on code written years or even decades earlier by engineers who are no longer available to consult. Shift-left testing—particularly automated unit tests and component tests run on every commit—provides a safety net that catches regressions as soon as they are introduced, before they propagate through the pipeline.

The Skills Gap Between QA Engineers and Mainframe Developers

Many QA engineers working in modern enterprises have limited experience with z/OS, COBOL, or mainframe tooling. When a pre-deployment test fails against a mainframe application, a QA team without mainframe expertise may be able to identify that a problem exists but lack the knowledge to diagnose or triage it effectively. This creates a handoff delay: the issue must be routed back to a mainframe developer, who must then reconstruct the context of what was being tested.

Shift-left testing shortens this feedback loop by returning test results to the mainframe developer who wrote the code, immediately after they write it. The developer still has full context, the code change is small and recent, and the fix can often be applied in minutes rather than days.

How to Implement Shift-Left Testing for Mainframe Applications

Tooling for mainframe shift-left testing exists and has matured considerably. The following options are worth evaluating for teams working on IBM Z platforms.

IBM Z Unit Testing

IBM offers Z Unit, a unit-testing framework for z/OS programs. Z Unit is available as part of IBM Z Open Unit Test and IBM Developer for z Systems. It allows z/OS developers to write and automatically generate unit tests for batch and CICS programs as part of their normal development workflow. Tests can be stored in any standard source control management (SCM) system and executed independently of the runtime environment, making them straightforward to integrate into a CI pipeline.

Testing Mainframe Code on Non-Mainframe Hardware

IBM’s Z Development and Test Environment allows teams to create virtual IBM Z environments on standard x86 hardware. This means developers can write, build, and run unit tests for mainframe applications on commodity servers or developer workstations, without requiring access to dedicated mainframe capacity for every test run. Reducing the dependency on shared mainframe LPAR time for early-stage testing is a meaningful enabler of shift-left practices, since it removes a scheduling bottleneck that would otherwise slow down the feedback loop.

Integrating Mainframe Tests into CI Pipelines

For shift-left testing to deliver its full value, tests need to run automatically on every code change, not just when a developer remembers to run them manually. This means integrating mainframe unit tests into the same CI tooling—Jenkins, Azure DevOps, GitLab CI, or similar—used for the rest of the software delivery pipeline. Modern mainframe DevOps tooling increasingly supports this integration, allowing z/OS builds and tests to be triggered by the same mechanisms as any other pipeline stage.

Key practices to implement alongside the tooling include:

• Writing unit tests alongside new code: Developers should write tests for new COBOL or PL/I components at the same time as the components themselves, not as an afterthought.
• Storing tests in source control: Test cases should live alongside production code in the same SCM repository so they are versioned, reviewed, and maintained together.
• Running tests on every commit: CI jobs should trigger the full unit test suite on every push to the main branch, not only on scheduled builds or release candidates.
• Tracking test coverage: As the test suite grows, monitor which code paths are covered to identify areas of the codebase that remain untested and therefore carry higher risk.

Conclusion

Shift-left testing is not a practice reserved for greenfield cloud-native applications. Whether your mainframe codebase was written last year or has been in production for decades, moving testing earlier in the delivery pipeline reduces the cost and disruption of defects, speeds up the CI/CD feedback loop, and helps bridge the skills gap between QA teams and mainframe developers.

The tooling to support this approach on IBM Z platforms exists today. The barrier to adoption is rarely technical—it is organisational. Teams that invest in building shift-left testing habits into their mainframe development culture will find it considerably easier to achieve the kind of continuous, reliable delivery that modern business demands.

This article was originally based on content published at devops.com.

The Mainframe Skills Gap Is Blocking DevOps Adoption

Despite decades of predictions to the contrary, the mainframe remains central to enterprise computing. A study cited by Forrester at the time of this report found that 64 percent of enterprises planned to run more than half of their critical application workloads on the mainframe. Yet only 37 percent reported being able to keep pace with the demand for skilled mainframe professionals.

That gap between mainframe reliance and mainframe expertise is a significant barrier to modernization. As workloads grow—driven by analytics, blockchain integrations, and increased mobile traffic—enterprises face pressure to accelerate mainframe application delivery using the same Agile and DevOps practices already standard on distributed and cloud platforms.

Compuware Updates zAdviser with AI and Real-Time Metrics

To address this challenge, Compuware announced updates to its zAdviser platform, a solution designed to help mainframe development leaders track, measure, and improve development velocity, quality, and efficiency. zAdviser applies artificial intelligence and machine learning to surface connections between individual developer behaviors and key performance indicators (KPIs), and to identify DevOps trends and patterns across the organization.

The updated release introduced several notable capabilities:

• Improved dashboard interface built on Elastic’s Elastic Cloud Service, providing a more accessible and unified view of mainframe DevOps data.
• Advanced behavioral and operational metrics to give teams deeper visibility into how developers interact with their toolchains.
• Near real-time data streaming, enabling faster detection of issues and quicker response cycles.
• Expanded AI and algorithmic correlation, helping teams identify whether high defect rates follow specific code changes and whether developers are making effective use of their DevOps tooling.

The practical outcome is that engineering managers can make data-driven decisions about training, tool adoption, and process improvement—rather than relying on anecdotal evidence or delayed retrospective reviews.

“Enterprises that have put off their mainframe modernization efforts must move quickly to bring their DevOps practices on the platform up to par if they want to stay competitive in a marketplace where continuous digital innovation has become table stakes. Rich, fact-based insight into their current state—and into whatever might be impeding them from achieving their desired state—is essential for accelerated adoption of mainframe DevOps.”

— Daniel Howard, Senior Researcher, Bloor Research

Partnership with CollabNet VersionOne: Value Stream Management Comes to the Mainframe

Alongside the zAdviser updates, Compuware announced a new partnership with CollabNet VersionOne to extend enterprise DevOps automation to mainframe environments using a Value Stream Management (VSM) approach.

The integration connects two complementary tools:

• Compuware ISPW — a DevOps-enabled source code management solution purpose-built for mainframe environments, handling version control, build automation, and deployment pipelines on z/OS.
• CollabNet VersionOne Continuum — an enterprise pipeline orchestration and value stream management platform designed to track, automate, and coordinate software delivery workflows across heterogeneous environments.

By connecting ISPW’s mainframe source control capabilities with Continuum’s orchestration layer, enterprises gain end-to-end visibility into mainframe software value streams alongside their distributed system pipelines. This helps break down the historical silo between mainframe and non-mainframe development, moving away from waterfall-bound delivery cycles toward iterative, Agile-aligned practices.

“As large enterprises digitally transform to compete in today’s fast-moving markets, the smart ones are aggressively transforming their mainframes away from siloed, waterfall-bound development, leveraging the Agile and DevOps best practices they’ve brought to their other platforms. This announced partnership combines Compuware’s modern take on mainframe tooling with the cutting-edge enterprise value stream management from CollabNet VersionOne.”

— Jason Bloomberg, President, Intellyx

Why Mainframe DevOps Matters

For organizations running core banking, insurance processing, retail transaction systems, or government workloads on z/OS, the mainframe is not a legacy curiosity—it is the production system of record. Yet many of these organizations struggle to apply the same CI/CD, automated testing, and pipeline tooling that their distributed platform teams take for granted.

The combination of AI-driven observability (via zAdviser) and value stream orchestration (via the CollabNet VersionOne integration) represents a practical path forward: make the mainframe a first-class citizen in the enterprise DevOps toolchain, rather than treating it as an exception that requires entirely separate governance and delivery processes.

As Forrester noted at the time, customer-obsessed enterprises need to modernize application delivery across all platforms—including the mainframe—to remove roadblocks to innovation and keep pace with digital transformation demands.

Key Takeaways

• The mainframe remains critical infrastructure for a majority of large enterprises, but the skills gap threatens their ability to modernize delivery.
• Compuware’s updated zAdviser platform uses AI and ML to surface actionable DevOps metrics specific to mainframe development teams.
• The Compuware–CollabNet VersionOne partnership integrates ISPW with Continuum to bring Value Stream Management to mainframe software pipelines.
• VSM on the mainframe allows organizations to achieve end-to-end pipeline visibility across both mainframe and distributed environments.
• Enterprises delaying mainframe DevOps modernization risk falling behind competitors who are already applying Agile practices across all platforms.

Why Mainframe DevOps Matters

Traditional mainframe development often relies on batch-oriented processes, proprietary editors, and manual promotion workflows that were designed long before continuous integration and continuous delivery (CI/CD) existed. When the rest of your delivery pipeline moves at DevOps speed, a slow mainframe development cycle becomes the bottleneck that limits the entire organisation.

Key challenges teams typically face include:

• Knowledge silos: Mainframe expertise is concentrated in a shrinking pool of experienced engineers, while new hires lack exposure to COBOL, PL/I, JCL, and related technologies.
• Poor documentation: Legacy applications are often underdocumented, making it risky for anyone other than the original author to modify them.
• Toolchain fragmentation: Mainframe teams use ISPF panels and TSO commands while distributed teams use Git, Jenkins, and Jira — with no shared workflow connecting them.
• Performance bottlenecks: Without modern profiling tools, identifying and resolving performance issues in COBOL or Assembler code is a slow, manual process.

How Compuware Addresses Mainframe DevOps

Compuware positions its product suite as a way to bring Agile and DevOps principles to z/OS mainframe development. Its toolset targets three core areas:

1. Source Code Management and Version Control

Compuware ISPW provides mainframe-native source code management with automated promotion pipelines. It integrates with Git-based repositories, allowing mainframe code to participate in the same branching and merging strategies used by distributed teams. This means a single CI/CD pipeline — orchestrated through tools such as Jenkins or Azure DevOps — can include both mainframe and non-mainframe components.

2. Understanding and Working with Underdocumented Applications

Compuware Topaz Workbench provides a modern Eclipse-based IDE for mainframe developers, replacing the green-screen ISPF interface. Its program analysis features help developers understand complex, poorly documented COBOL programs by visualising data flows, copybook usage, and call chains — reducing the risk of unintended side effects when modifying legacy code.

3. Eliminating Performance Bottlenecks

Compuware Strobe is a mainframe application performance management (APM) tool that profiles CPU consumption at the statement level for COBOL, PL/I, and other z/OS languages. Rather than guessing where a batch job is spending its time, developers can pinpoint the exact lines of code responsible and make targeted, evidence-based optimisations.

Cross-Platform Collaboration

One of the more significant aspects of the Compuware approach is its emphasis on integration with mainstream DevOps tooling. Plugins and APIs connect ISPW and Topaz with:

• Jenkins — triggering mainframe builds and deployments from shared pipelines
• Git / GitHub / Bitbucket — synchronising mainframe source with distributed version control
• Jira — linking mainframe change sets to the same issue-tracking workflow used by the broader team
• SonarQube — running static code analysis on COBOL programs alongside analysis of Java or Python code
• XL Release / ServiceNow — including mainframe deployments in enterprise release orchestration

This integration layer is important because it removes the need for separate approval gates and manual hand-offs between mainframe and distributed teams, which are common sources of delay in enterprise release cycles.

Onboarding New Mainframe Developers

A recurring concern in the mainframe industry is the demographic gap: many experienced COBOL developers are approaching retirement, and universities rarely teach mainframe skills. Compuware targets this challenge by providing a development experience that looks and feels like a modern IDE, reducing the learning curve for developers who are unfamiliar with the traditional z/OS toolset. Features such as syntax highlighting, code completion, and integrated debugging in Topaz Workbench are designed to make the mainframe accessible to developers whose background is primarily in distributed or cloud environments.

Key Takeaways

• Mainframe systems are involved in the vast majority of enterprise business initiatives, making mainframe DevOps a strategic necessity rather than a niche concern.
• Compuware’s toolset — including ISPW, Topaz Workbench, and Strobe — addresses source control, code comprehension, and performance profiling on z/OS.
• Integrations with Jenkins, Git, Jira, and SonarQube allow mainframe development to participate in the same CI/CD pipelines as distributed applications.
• A modern IDE experience lowers the barrier for new developers entering mainframe roles.
• Eliminating the mainframe bottleneck is often essential for organisations that want true end-to-end DevOps delivery speed.

If your organisation runs critical workloads on IBM Z and is struggling to align mainframe delivery with the pace of your cloud and distributed teams, evaluating a dedicated mainframe DevOps toolchain is a practical starting point.

Today’s mainframe is not obsolete. It remains the infrastructure backbone for a significant share of enterprise transaction processing, mobile back-end services, and payment systems. Yet mainframes are routinely left out of DevOps conversations because of their historically limited release cycles, constrained automation capabilities, and slow build-and-deploy pipelines. Closing that gap — bringing continuous integration (CI) and continuous delivery (CD) to the mainframe — is both achievable and strategically valuable.

Why Mainframes Still Matter in a DevOps World

Despite the growth of cloud-native and distributed platforms, mainframes continue to handle workloads that demand extreme reliability, security, and raw processing throughput — mobile transaction back-ends, batch payment processing, and large-scale data management among them. Ignoring the mainframe in a DevOps transformation means accepting a two-speed delivery organisation: agile everywhere except where it matters most.

The business consequences are real. Slow mainframe release cycles lengthen overall time to market, limit the organisation’s ability to respond to change, and reduce return on investment for software initiatives. Bringing DevOps discipline to the mainframe directly addresses these constraints.

Executing CI/CD on the Mainframe

DevOps on the mainframe rests on the same three pillars as anywhere else: people, culture, and automation. Getting all three right on the mainframe requires a deliberate approach to tooling and collaboration.

IDE Tooling for Mainframe Developers

Modern integrated development environment (IDE) tools — including Eclipse-based environments tailored for mainframe languages such as COBOL and PL/I — bring several capabilities that directly enable CI/CD:

• Automated code review — enforces coding standards without manual gatekeeping, catching issues before they reach the build stage.
• Automated unit testing and code coverage — surfaces defects early in the development lifecycle, reducing the cost of fixing them.
• Continuous integration hooks — connect mainframe builds to the same CI servers (such as Jenkins) used for distributed workloads, enabling a unified pipeline.
• Automated deployment — replaces manual, error-prone promotion steps with repeatable, auditable automation.
• Developer productivity features — auto-completion, real-time syntax checking, offline compile, cross-program flow analysis, dead-code identification, and unused-variable detection all reduce the cognitive load on mainframe developers.

These tools are not mainframe-exclusive. The same toolchain can extend to distributed application deployments, helping teams address cross-platform dependencies and improving collaboration between mainframe and distributed development groups.

Virtualization to Accelerate Testing

Test region availability is a persistent bottleneck in mainframe projects. Physical test regions are expensive to provision and compete for MIPS capacity. Virtualization addresses this directly: teams can simulate mainframe environments on distributed infrastructure, reducing dependence on scarce physical test regions, shortening provisioning times, and lowering the cost of test cycles. Simulated environments also support more flexible test data management, allowing teams to massage and condition data without touching production or constrained physical regions.

What to Look for in a Mainframe DevOps Tool Vendor

When evaluating tools and vendors to support mainframe DevOps, prioritise the following:

• A published DevOps roadmap that builds on your existing mainframe landscape rather than replacing it wholesale.
• Integration with your current mainframe tool stack (compilers, change management, job schedulers).
• Integration with existing supply chain and release management products.
• A CI pipeline that connects to your existing CI server on the distributed side, enabling a single, end-to-end pipeline across platforms.

A Real-World Example: Mainframe DevOps in Practice

Infosys has publicly described using DevOps practices on mainframe projects to accelerate time to market. Their approach combined Eclipse-based development tooling, automated code reviews, automated unit testing, code coverage analysis, continuous integration, and one-click automated deployment into a seamless pipeline. The outcome was earlier defect detection — most bugs were caught during the build phase rather than in late-stage testing — and significantly shortened development cycle times.

Their experience also demonstrated the value of migrating mainframe test environments to distributed simulations: target regions mimicked the mainframe environment, removed the bottleneck of region unavailability, and reduced both the time and cost of test provisioning. This pattern is broadly replicable for enterprises operating similar mainframe workloads.

A Phased Approach to Mainframe DevOps Adoption

Attempting a big-bang transformation of mainframe delivery is high-risk and rarely necessary. A phased approach is more practical and less disruptive:

1. Phase 1 — Leverage existing tools. Implement CI/CD services using tools already present in your mainframe environment. This is the least intrusive starting point and maximises return on existing investment.
2. Phase 2 — Select and provision specialised tooling. Based on your mainframe landscape, business strategy, and development processes, introduce purpose-built DevOps tooling to close capability gaps identified in Phase 1.
3. Phase 3 — Broaden scope. As your team’s DevOps maturity grows, expand beyond CI/CD to encompass the full DevOps lifecycle — monitoring, feedback loops, security integration, and continuous improvement practices.

Throughout each phase, the cultural dimension is as important as the technical one. Development, test, and operations teams that have historically worked in silos on mainframe projects must be brought together with shared goals, shared tooling, and shared accountability for delivery outcomes.

Key Takeaways

• Mainframes are not legacy liabilities — they are active, business-critical platforms that deserve the same DevOps investment as distributed systems.
• CI/CD pipelines are achievable on the mainframe using modern IDE tooling, automated testing frameworks, and integration with existing CI servers.
• Virtualization reduces the test region bottleneck that has historically slowed mainframe delivery cycles.
• A phased adoption strategy, beginning with existing tools, is lower risk and more sustainable than a wholesale transformation.
• Culture change — specifically, breaking down the silos between mainframe development, test, and operations teams — is a prerequisite for any of the technical improvements to deliver lasting value.

Original source article published on TechBeacon (techbeacon.com).

This article explains what DevOps means in practical terms, why extending it to mainframe environments is worthwhile, and what concrete steps and tooling can help engineering teams close the gap between MIPS-based workloads and modern CI/CD pipelines.

What DevOps Actually Means

DevOps is the practice of breaking down the organisational and tooling barriers that have historically separated software development teams from IT operations teams. When developers and operators work in silos, code changes accumulate, feedback loops lengthen, and deployments become high-risk events. DevOps addresses this by aligning people, processes, and tooling around a shared goal: shipping reliable software quickly and continuously.

The key outcomes DevOps is designed to deliver include:

• Continuous integration (CI): Developers merge code changes frequently, with automated builds and tests validating every change.
• Continuous delivery (CD): Software is always in a deployable state; releasing to production becomes a low-friction, routine operation rather than a stressful event.
• Faster feedback: Automated monitoring, alerting, and observability tools surface problems quickly so they can be fixed before users are affected.
• Agility: Teams can scale workloads, adopt new frameworks, and respond to changing requirements without being blocked by manual processes or organisational handoffs.

None of these outcomes are platform-specific. They apply just as meaningfully to COBOL batch jobs on z/OS as they do to Python microservices running in Docker containers.

Why Mainframes Belong in Your DevOps Workflow

The DevOps conversation has understandably centred on distributed, cloud-native infrastructure. Containers, orchestrators, and hosted CI/CD platforms are all relatively new and genuinely benefit from DevOps practices. However, focusing exclusively on these technologies means ignoring a substantial portion of enterprise computing infrastructure.

As Compuware CEO Chris O’Malley has argued, there are several strong reasons to bring DevOps discipline to mainframe environments:

1. Business-Critical Workloads Live There

Core transaction processing, large-scale batch analytics, and record-of-system databases in many large enterprises still run on mainframes. If development and operations teams cannot apply CI/CD practices to those workloads, they create a two-speed IT organisation: rapid delivery for greenfield applications and slow, risky releases for the systems that matter most. That inconsistency undermines the value of DevOps across the board.

2. Mainframes Are Infrastructure — Not Magic

A mainframe is ultimately a hardware and software platform. It has source code, build processes, test suites, deployment pipelines, and operational runbooks — all of which can be versioned, automated, and measured. The languages (COBOL, PL/I, Assembler, JCL) and the operating environment (z/OS, CICS, IMS) differ from those on distributed systems, but the engineering principles that govern good software delivery do not change.

3. Mainframes Offer Scale and Security That Complements DevOps Goals

Modern mainframes are highly scalable, fault-tolerant, and built with security as a first-class concern. These properties align with what DevOps teams want from infrastructure. Integrating mainframes into a DevOps toolchain can therefore extend those reliability and security guarantees to workflows that previously lacked them.

The Real Challenges of Mainframe DevOps

Recognising the value of mainframe DevOps is easier than implementing it. Several genuine challenges must be addressed:

• Tooling gaps: Popular CI/CD platforms, version control systems, and observability tools were built for distributed, Linux-based workloads. Many do not natively understand z/OS job control, VSAM datasets, RACF security, or SMF records.
• Language and skills differences: Developers who work in Java, Python, or Go are rarely familiar with COBOL or JCL, and mainframe specialists often have limited exposure to modern DevOps tooling. Bridging this skills gap requires deliberate cross-training and shared tooling.
• Cultural inertia: Organisations that have operated mainframe workflows for decades have established release rhythms, approval processes, and change control gates that predate DevOps thinking. Changing those processes requires organisational will, not just technical tooling.
• Observability and data access: Mainframe diagnostic data — SMF records, RMF metrics, SYSLOG output, and job logs — is typically stored in proprietary formats and isolated from the observability platforms that distributed teams use for monitoring.

How to Integrate Mainframes into DevOps Workflows

Despite these challenges, a practical path to mainframe DevOps exists. The following approaches address the most common barriers.

Version Control for Mainframe Source Code

COBOL and PL/I source, JCL procedures, copybooks, and configuration members should be managed in the same version control system used by the rest of the organisation — typically Git. Tools exist to synchronise z/OS Partitioned Data Sets (PDS) with Git repositories, enabling standard pull-request workflows, code review, and branch-based development for mainframe code alongside distributed code.

Automated Build and Test Pipelines

CI pipelines for mainframe workloads should trigger automated compiles, link-edits, and unit or integration tests whenever source changes are committed. Vendors such as Compuware (Topaz), IBM (Dependency Based Build), and others provide tooling that can be invoked from Jenkins, GitLab CI, or similar orchestrators. The goal is identical to distributed CI: catch defects early, in an automated way, before code progresses toward production.

Streaming Mainframe Data into Modern Observability Platforms

One of the most practical integration points is getting mainframe operational data — SMF records, job logs, performance metrics — into platforms that DevOps teams already use for monitoring and analytics. Solutions designed for this purpose can stream mainframe machine data into platforms such as Splunk, enabling operations staff to monitor mainframe workloads alongside distributed services in a single pane of glass. Syncsort’s Ironstream product (referenced in the original source article) is one example of a commercial tool built for this use case.

Integrating Mainframe Data with Big Data Pipelines

Many organisations need to combine mainframe batch output with data held in Hadoop, cloud object storage, or streaming platforms such as Apache Kafka. ETL and data integration tools that understand both mainframe data formats (EBCDIC, packed decimal, VSAM) and distributed data formats can bridge this gap without requiring manual extract-and-convert steps. This is relevant not just for analytics but for end-to-end delivery pipelines where mainframe jobs are one stage in a larger data workflow.

Shared Observability and Application Performance Management

Abend codes, transaction response times, and resource consumption on the mainframe are as important to measure and act on as error rates and latency in a distributed system. Integrating mainframe APM data — from tools such as Compuware Abend-AID or IBM OMEGAMON — into shared dashboards and alerting systems ensures that mainframe incidents are visible to the whole team, not siloed in a specialist team’s ticketing queue.

The Cultural Dimension

Technology alone will not deliver mainframe DevOps. The organisational change required is significant. Teams that have operated under a traditional change-management model — where mainframe releases go through lengthy approval cycles measured in weeks — need to adopt a different mindset. This means:

• Treating mainframe engineers as full members of the software delivery team, not as a separate silo accessed only through formal change requests.
• Establishing shared definitions of done, deployment checklists, and post-incident review processes that apply equally to mainframe and distributed workloads.
• Investing in cross-training so that mainframe specialists understand modern DevOps tooling and distributed engineers understand enough about z/OS to contribute meaningfully to shared pipelines.
• Starting small: pick one mainframe application, instrument it with version control and automated testing, connect its logs to a shared observability platform, and use that experience to build organisational confidence before scaling the approach.

Summary

Mainframes are not going away. For many large organisations they remain the authoritative system for the workloads that matter most. Leaving them outside the DevOps boundary creates a dangerous inconsistency: fast, automated delivery for lower-stakes applications and slow, manual releases for the systems that underpin core business operations.

The path to mainframe DevOps is technically achievable today. It requires integrating mainframe source code into standard version control, building automated CI/CD pipelines that understand z/OS artefacts, streaming mainframe operational data into shared observability platforms, and — critically — making the organisational and cultural changes that allow mainframe and distributed teams to work together rather than in parallel silos.

The organisations that get this right will have a meaningful competitive advantage: end-to-end delivery velocity across their entire technology estate, not just the newest parts of it.

The Mainframe Is Not a Legacy Problem—It’s a DevOps Opportunity

Most DevOps discussions assume that “dev” means modern programming languages—Java, Python, Go—and that “ops” means cloud or distributed infrastructure. The mainframe, running decades of COBOL, PL/I, and Assembler code, rarely enters the conversation. That omission is a serious strategic mistake.

There are at least three compelling reasons why mainframe environments deserve their own dedicated DevOps strategy—plus a fourth that makes the case practically undeniable.

Reason 1: Necessity

Much of the world’s most economically critical code still runs on mainframes. Every time someone hails a ride, completes a bank transfer, or processes an insurance claim, there is a good chance a mainframe is executing the underlying transaction. Global banks and large enterprises continue to process billions of transactions worth trillions of dollars on platforms running COBOL and related languages.

Despite repeated predictions of the mainframe’s demise, mainframe owners consistently report that their workloads are growing, not shrinking. The platform itself continues to evolve: IBM’s mainframe line supports Linux and Java workloads alongside traditional COBOL applications, and its economics for high-volume, compute-intensive workloads are often more favorable than equivalent distributed or cloud deployments.

Leaving this volume of high-value application logic outside the DevOps discussion is indefensible. If it is worthwhile to apply continuous delivery practices to consumer-facing web applications, it is at least as worthwhile—arguably more so—to apply them to the code that powers international finance and critical infrastructure.

Reason 2: Unique Challenges That Require Their Own Strategy

In principle, code is code. The cognitive difference between managing the lifecycle of a COBOL application and a Java application is largely syntactic. In practice, however, mainframe DevOps involves a specific set of challenges that don’t appear in most cloud-native pipelines:

• Complex, underdocumented codebases. COBOL programs are often large, heavily modified over decades, and poorly documented. Inter-application dependencies are deep and non-obvious. Code-parsing, runtime analysis, and automated dependency mapping become critical capabilities rather than nice-to-haves.
• Tooling mismatch. Mainframe development teams have historically used toolsets that bear little resemblance to the IDEs, version control systems, and CI/CD pipelines used by modern application teams. Integrating mainframe code management into a broader enterprise DevOps toolchain typically requires deliberate re-tooling and integration work.
• Cultural inertia. Mainframe shops have spent decades optimizing for stability and hyper-rigorous change management—with good reason, given the criticality of their systems. Shifting that culture toward Agile iteration, fast feedback loops, and continuous delivery is a significant leadership challenge, separate from any tooling or process change.

None of these obstacles are insurmountable, but they do require a targeted discussion, a clear strategy, appropriate tooling choices, and sustained leadership commitment. A generic DevOps playbook written for cloud-native teams will not transfer directly to the mainframe environment without adaptation.

Reason 3: Significant Business Upside

The strongest argument for mainframe DevOps is commercial. The COBOL codebase running on a mainframe is, in many cases, the digital DNA of the business—encoding how it operates, measures performance, and serves customers. A business whose core systems are slow and unresponsive cannot compete effectively in fast-moving markets, regardless of how modern its customer-facing applications appear.

Conversely, a mainframe-centric organization that successfully adopts DevOps practices gains a meaningful competitive advantage over peers that have not. This is especially relevant as mainframe applications increasingly serve as backends for mobile apps and analytics platforms. The ability to update core transaction logic quickly and safely translates directly into better customer experiences and more actionable data.

The economic case extends beyond agility. The mainframe platform offers a cost-effective foundation for any workload that demands high throughput, reliability, and security at scale. But organizations will only route new workloads to the mainframe if they can develop and maintain those workloads efficiently. DevOps enablement is therefore a prerequisite for realizing the platform’s full economic potential.

Reason 4: It Is Already Happening

Forward-thinking IT organizations are already running DevOps on the mainframe and reporting tangible returns. This is not a theoretical future state—it is a practical, actionable initiative that organizations are executing today. The existence of real-world success stories means that best practices, tooling, and organizational patterns already exist to learn from.

If your organization has a mainframe and has excluded it from your DevOps initiatives, you are leaving competitive advantage on the table. The platform is not going away. Mainframes have outlasted multiple generations of technology predicted to replace them, and there is no credible evidence that the next wave will be different.

Key Takeaways for DevOps Engineers and Architects

• Do not treat the mainframe as someone else’s problem. If your enterprise has one, it belongs in your DevOps pipeline.
• Audit your mainframe toolchain. Version control, automated testing, and CI/CD integration are achievable on the mainframe but require deliberate tooling decisions.
• Invest in dependency mapping and code analysis. The complexity and age of COBOL codebases make automated analysis tools more valuable here than in greenfield environments.
• Plan the cultural change explicitly. Stability-focused mainframe teams need a different change management approach than cloud-native teams.
• Look for early wins. Mainframe DevOps initiatives can and should demonstrate ROI quickly to build organizational momentum.

Original opinion piece by Chris O’Malley, CEO of Compuware, via DevOps Digest.

What Is Continuous Delivery?

Continuous Delivery (CD) is a software engineering discipline in which teams produce software in short cycles, ensuring that code can be reliably released at any time. The core idea is to replace the traditional, phase-gated release process — where code travels through isolated stages of development, testing, staging, and production over weeks or months — with an automated pipeline that moves changes toward production continuously and safely.

In a mature CD practice, every commit that passes automated tests is a candidate for release. Deployment becomes a low-risk, routine activity rather than a high-stakes event. The business benefit is faster delivery of value to users and quicker feedback loops for development teams.

Why Mainframes Are a Special Case

Mainframe systems — IBM z/OS environments being the most prevalent — power mission-critical workloads in banking, insurance, retail, and government. These platforms process enormous transaction volumes and are held to extremely high availability and auditability standards. That context shapes every decision about how software is developed and released on them.

The tooling, languages (COBOL, PL/I, Assembler, CICS, JCL), and operational models on mainframes evolved decades before Agile and DevOps became mainstream. As a result, several structural differences make applying standard CD practices non-trivial:

• Different version control conventions. Mainframe source code has historically lived in Partitioned Data Sets (PDS) rather than Git repositories, making integration with modern SCM tools a first hurdle.
• Compiled artifacts and load modules. Mainframe programs must be compiled and link-edited into load modules before they can run. Managing these binary artifacts through a pipeline requires tooling that understands z/OS object formats.
• Heavyweight change management. Regulated industries operating mainframes often require manual change advisory board (CAB) approvals, audit trails, and separation of duties — processes that must be encoded into, rather than bypassed by, a CD pipeline.
• Shared environments. Mainframe LPAR (Logical Partition) environments are expensive, so development, test, and pre-production stages often share resources. This complicates environment isolation strategies common in CD.
• Skill gaps. COBOL and JCL expertise is concentrated in experienced staff; DevOps and pipeline engineering skills are concentrated in younger teams. Bridging that knowledge gap is an organisational as much as a technical challenge.

Core Principles of CD Applied to Mainframes

Despite those differences, the fundamental CD principles still apply and can deliver measurable value on the mainframe:

1. Version Everything in a Modern SCM

Migrating mainframe source into Git (or another modern VCS) is the foundation. Tools and plugins exist to synchronise z/OS data sets with Git repositories, allowing mainframe code to participate in the same branching, pull-request, and code-review workflows used for distributed systems. This single change dramatically improves traceability and collaboration.

2. Automate the Build

Compile, link-edit, and package steps that were previously triggered manually via JCL jobs can be automated and invoked from a CI server such as Jenkins or Azure DevOps. Successful builds should produce versioned, immutable artifacts stored in an artifact repository — treating load modules the same way a Java pipeline treats a JAR file.

3. Shift Testing Left

Unit testing frameworks for COBOL (such as IBM’s zUnit/CBLTDAST or the open-source COBOL Check project) allow developers to write automated tests that run as part of the pipeline. Integration and regression test suites that previously ran only late in the cycle can be parallelised and triggered automatically on every commit.

4. Automate Deployment with Auditability

Deployment automation on z/OS typically involves IBM’s Software Delivery Pipeline tooling, Broadcom’s Compuware or ISPW, or open standards such as Ansible for z/OS. The goal is repeatable, scripted deployment that generates an auditable record — satisfying compliance requirements without manual steps that introduce delay and error.

5. Pipeline Visibility Across Platforms

Many organisations run hybrid applications where a mainframe back-end services distributed or cloud-based front-ends. A holistic CD pipeline should surface the status of mainframe builds and deployments in the same dashboard used for other components, giving teams a single view of system health before any release proceeds.

Organisational and Cultural Challenges

Technical tooling is only part of the story. Organisations pursuing mainframe CD typically encounter several cultural obstacles:

• Siloed teams. Mainframe and distributed development teams rarely share practices, stand-ups, or pipelines. Breaking down those silos requires deliberate organisational change as well as tooling integration.
• Risk aversion. The consequences of a production outage on a mainframe processing millions of financial transactions per hour are severe. CD adoption on mainframes must be incremental and demonstrate reliability improvements, not just speed.
• Knowledge transfer. As experienced mainframe engineers retire, capturing their implicit knowledge of system behaviour into automated tests and documented runbooks becomes urgent.

The Business Case

Organisations that successfully implement CD on mainframes report benefits consistent with those seen on distributed platforms: fewer defects reaching production, shorter lead times from code commit to deployment, and reduced toil for operations teams. In regulated industries where change windows are constrained, the ability to deploy smaller, better-tested changes more frequently also reduces the risk associated with each individual release.

The mainframe is not going away. An estimated proportion of the world’s commercial transaction volume still runs on IBM Z hardware, and organisations that treat mainframe delivery as a second-class concern relative to their cloud-native work create operational and competitive risk. Extending CD principles to the mainframe is no longer an exotic project — it is a mainstream DevOps priority.

Getting Started

A pragmatic starting point for teams new to mainframe CD:

1. Audit current source code management practices and identify the gap between PDS-based workflows and Git.
2. Select a pilot application — ideally one with a well-understood test suite and moderate change frequency.
3. Automate the build and a basic smoke-test suite, integrating with your existing CI server.
4. Instrument the deployment process to generate an audit log, and get sign-off from compliance stakeholders that the log satisfies their requirements.
5. Expand coverage iteratively, measuring lead time and defect escape rate as lagging indicators of progress.

Mainframe CD is a long journey, but each incremental step towards automation, visibility, and repeatability delivers value — and reduces the risk of the next release.