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.

What Is IBM UrbanCode Deploy?

IBM® UrbanCode™ Deploy (commonly abbreviated as uDeploy) is an application-release automation tool that orchestrates and automates application deployments, middleware configurations, and database changes across on-premises or cloud-based development, test, and production environments. Teams can deploy on demand or on a schedule, with built-in role-based access control and self-service release management.

UrbanCode Deploy is available in several licensing tiers and as a hosted service. For current purchasing options, see the IBM Marketplace.

Core Capabilities

• Automated, consistent deployments and rollbacks of multi-component applications
• Automated provisioning, updating, and de-provisioning of cloud environments
• Orchestration of changes across servers, tiers, and components
• Environment-specific configuration and security management
• Clear inventory visibility: what version is deployed where, and who changed what
• Pre-built integrations with middleware, provisioning tools, and service virtualization platforms

Typical Use Cases

• Continuous Delivery: Integrate with build and test tools to automatically deploy, test, and promote new builds through the pipeline.
• Production Deployments: Orchestrate complex production deployments of applications and their configuration in the correct order and with appropriate approvals.
• Self-Service Releases: Grant individual teams the rights to trigger deployments for specific applications and environments without requiring centralized operations involvement.
• Incremental Updates: Deploy only changed components or missing incremental (patch) versions, rather than full application re-deployments.

Key Features of IBM UrbanCode Deploy

1. Multi-Tier Application Models

Modern applications typically consist of many interdependent components — for example, a three-tier application with database, application server, and content layers. UrbanCode Deploy tracks which components make up an application so they can be deployed and tracked as a unit. Snapshots allow teams to capture the exact versions of all components at a point in time, ensuring that what was tested together is released together.

2. Visual Drag-and-Drop Process Designer

Deployment processes are defined in the browser using a drag-and-drop graphical designer — no scripting required for common workflows. Component processes are assembled from automation steps delivered by integration plugins. Application processes then compose those component processes. Steps can run sequentially or in parallel, and transitions between steps are governed by conditional rules (for example, proceed on success, branch on failure). This makes it straightforward to convert a manual runbook into a repeatable automated flow.

3. Hybrid Cloud Deployment

The blueprint designer lets you model cloud environments graphically — connecting to cloud providers, modeling virtual images, and mapping application components to those images. Environments can then be provisioned and components deployed automatically and on demand. The blueprint designer supports public and private clouds including IBM Bluemix (now IBM Cloud), IBM SoftLayer, Amazon Web Services, Microsoft Azure, VMware vCenter, and OpenStack-based clouds.

4. Inventory Tracking

UrbanCode Deploy maintains a real-time inventory of what component versions are deployed to each target environment. The inventory system tracks both the desired state and the actual deployed state, and raises graphical alerts when an environment is out of compliance. This is valuable for audit, for testers who need to know exactly what build they are testing against, and for troubleshooting environment discrepancies.

5. Scalable Distributed Automation

UrbanCode Deploy is designed for mission-critical deployments at scale. Master server clustering provides high availability and horizontal scalability. Lightweight deployment agents are installed on or near target servers and communicate back to the master. Remote agents can connect through an agent relay — a communication proxy that simplifies firewall management and manages load for large, distributed environments.

6. Quality Gates and Approval Processes

Deployments to sensitive environments can be gated by conditions — for example, requiring that a component version has passed a defined test suite, or that multiple stakeholders have approved a change window. UrbanCode Deploy provides configurable Environment Quality Gates and Approval Processes per application and per environment. Early test environments can be configured with no approvals for speed, while production environments enforce full governance.

7. Plugin Integrations Replace Custom Scripting

IBM provides tested integration plugins for a wide range of tools, covering application servers, load balancers, databases, testing tools, and build servers. Utilities for managing configuration files and registry settings are also available. Teams with existing deployment scripts can still use them — either by calling them directly within a process step, or by wrapping them in a custom plugin. Plugins are available through the IBM UrbanCode Plugins Portal.

Installation and Configuration Overview

The following is a high-level walkthrough of the UrbanCode Deploy installation sequence. Consult the official IBM documentation for version-specific details and exact commands.

Step 1: Obtain the Software

Log in to your IBM account and navigate to the UrbanCode Deploy trial or licensed download page. Select the package appropriate for your operating system and download the installer archive.

Step 2: Review System Requirements

IBM UrbanCode Deploy runs on both Windows and UNIX/Linux systems. Before installing, review the official system requirements documentation for your specific version — including supported Java versions, minimum RAM and disk space for the server, and network port requirements. Following IBM’s sizing guidelines can significantly improve server and agent performance at scale.

Step 3: Install the Database

UrbanCode Deploy requires a relational database to store its configuration and audit data. Supported databases include Apache Derby (for evaluation only), Oracle, Microsoft SQL Server, and MySQL. For production use, Derby is not recommended. Install and configure your chosen database server and create a dedicated database and user for UrbanCode Deploy before running the server installer.

Step 4: Install the Server

The UrbanCode Deploy server provides the web-based user interface, the workflow engine, the security service, and the artifact repository. During installation, you will specify configuration parameters including:

• Server hostname and HTTPS port
• Agent communication port
• Database connection details and JDBC driver location
• Initial administrator credentials

Step 5: Configure Cloud Systems (Optional)

If you plan to provision dynamic cloud environments using the blueprint designer, you must install the appropriate script package on your cloud system and configure the connection from the UrbanCode Deploy server to the cloud provider’s API endpoint.

Step 6: Install Agents

Agents must be installed on each target server where deployments will run. Agents can be installed:

• From the command line: Run the installer batch file (Windows) or shell script (UNIX) and provide the server hostname and communication port.
• Remotely from the UI: The server can push agent installations to remote targets if SSH or WinRM access is available.

Step 7: Install Agent Relays (Optional)

For agents located behind a firewall or in a separate network zone, deploy an agent relay. The relay acts as a communication proxy between the agents and the server, reducing the number of firewall rules required and helping manage network load in large deployments.

Step 8: Configure SSL

UrbanCode Deploy uses SSL/TLS to encrypt all communications between the server, agents, and the browser-based UI. By default the installer creates a self-signed certificate. For production environments, replace this with a certificate signed by a trusted certificate authority and configure the server’s keystore accordingly.

Step 9: Start and Verify the Installation

Both UNIX and Windows installations require the server and at least one connected agent before you can run a deployment. If you are using Oracle or MySQL, ensure the appropriate JDBC driver JAR is placed in the server’s library directory before starting the server. Once the server is running, log in to the web UI, verify that your agent appears as Online, and run a simple test process to confirm end-to-end connectivity.

Next Steps

After a successful installation, the typical next steps are:

• Define your first Component and configure its source configuration (artifact repository, build tool, or file system).
• Build a Component Process using the drag-and-drop designer to install, start, and stop the component.
• Create an Application that groups your components and define an Application Process that coordinates their deployment order.
• Create Environments (Dev, QA, Production) and map your agent resources to them.
• Trigger your first deployment and review the inventory to confirm the component version is recorded correctly.

For full documentation, tutorials, and plugin downloads, refer to the official IBM UrbanCode Deploy documentation.