While nearly two-thirds of mainframe shops use DevOps, ‘bottlenecks’ in the delivery pipeline persist. If only there were a way to unblock it…
The problem with building complicated software
Interestingly, a Software Testing Benchmark Report revealed that 38% of those surveyed think that testing comprises over half the total time of the software delivery lifecycle (SDLC). Over two-thirds of the respondents think testing comprises at least 31% of the time or higher.
This might not be news to some, but these numbers highlight how much of the SDLC focuses on validating changes rather than implementing them—even in the age of automated testing.
The promise of mainframe DevOps
Built on the back of the early 2000s era agile manifesto, DevOps was born to allow a means to fast-track application delivery using an agile methodology, but with enough operational savvy to ensure the deliverables were of genuine value. While born in a distributed environment, the idea quickly took hold in the mainframe world. I remember vividly the major mainframe vendors nodding furiously in agreement about the value of mainframe DevOps over a decade ago as the community considered, planned, and largely executed their evolution from ISFP- and waterfall-driven development processes.
Fast forward to today, where, according to the 2024 BMC mainframe market survey, 62% of mainframe organizations use DevOps. However, the same report conceded, “As organizations have realized significant improvements in development speed and agility through adopting DevOps practices, many have identified bottlenecks further down the software delivery pipeline.”
The DevOps Dilemma
The report suggests a pandora’s box moment with mainframe DevOps implementation – what’s behind the continued concerns around mainframe DevOps?
Surely isn’t the tooling: you can’t move in the mainframe space for innovative solutions being announced, up and down the DevOps toolchain, by a gallery of vendors. In recent years, the mainframe world has evolved towards a new look and feel, DevOps-style – GUI overtook ISPF, automation was introduced across many aspects of the SDLC to reduce effort, keystrokes and mistakes. AI-infused or not, activities from application assessments, data discovery, and requirements management, right through developer IDEs, compilers, build systems, source control, unit testing, test automation, application deployment, and many more, have benefitted from mainframe DevOps tool innovation. Many are API-driven, plug-and-play, allowing development teams to work with what makes the most sense.
Yet the mainframe market looks far from done in terms of necessary improvements. Mainframe modernization investment is set to rise even further in 2025, according to a recent Gartner study, suggesting that improving mainframe delivery is far from over.
Where’s the real bottleneck?
Let’s go back to those testing stats again from earlier. If testing uses up to half the project effort, even a two-week sprint – for example – that is 1 week of the 2 weeks of a short iteration. But that week can (and will) need to be spread across the duration, so the availability must be instantaneous.
For mainframe administrators, making LPARs available ‘on demand’ for anything up to half the time of a delivery cycle (and repeated for each such cycle) is likely an impossible request to support – that’s not how mainframe LPAR time slots are allocated. Typically, the time is pre-allocated on a rigid schedule, so teams get some time at fixed points in the cycle. It is not ad-hoc and cannot be requested as such.
Furthermore, it is extremely rare in my experience that there is sufficient ‘spare’ capacity on the mainframe to offer mainframe LPAR availability for development and testing for up to half the time of the whole project. The mainframe is crucial to business operation, and getting value for money from it means we don’t want it sitting idle just in case we need ad-hoc testing done. The way the mainframe is set up and the way it is cost-justified makes it hard for the ‘ad hoc’ allocation of resources.
Put simply, the opportunity of mainframe DevOps is undermined by how the mainframe time is managed. And no amount of new tooling fixes that.
Until now.
Enter stage left, Mainframe ‘DevPops’
Mainframe DevOps teams need instantaneous access to the right resources (machine time, tools, processes, skills) at whatever point in their delivery cycle their project dictates. That’s true whether the iterations are 2-week or 6-month. Teams need a sandbox, a fresh build, relevant data, and some processor time, and they need to test as quickly as the project dictates.
Mainframe DevOps teams need mainframe resources to pop up whenever they require them.
PopUp Mainframe’s raison d’etre is to solve that problem: the need for technical staff to access a working mainframe environment whenever needed, without the undesirable cost, effort, or bureaucracy of using normal methods.
PopUp Mainframe provides an immediately available, fully-loaded mainframe dev and test environment in a matter of minutes, including CICS, DB2, and all the necessary language environments, and which can also include a selected and masked subset of the right data to support appropriate, compliant testing.
Using PopUp Mainframe, delivery teams have the innovative means to help them deliver on the promise of DevOps.
DevOps, meet DevPops, so to speak.