Will Mainframers adopt DevOps?

Mainframes are under siege. You might like to picture the mainframe department as some medieval castle surrounded by invading troops. There’s no actual fighting going on, but gradually the forces of distributed computing are waiting for the survivors inside the fortress to die of hunger (or in our case, retire through old age). One day, there will be no-one left to defend the castle – one day, there will be no-one left to run the mainframe.

It’s a frightening thought. OK, you may imagine that some tunnels under the besieging army are being built and some expensive consulting staff are getting in to keep some kind of defence going on. What can the king of the castle do? Could he outsource his castle – build smaller castles around his protectorate?

We all know that our expert mainframe staffs are getting older and are either looking forward to a well-earned retirement or they are already enjoying it. And, sadly, very few youngsters are being tempted to enter the world of green screens. But we also know that many business-critical applications are running on the mainframe. This convoluted code was developed over the years and none of the original teams are still on the payroll. This makes it very hard to rewrite the code, either for the mainframe or any other platform. We also know that speed at which the mainframe can perform work is better than other available platforms. Mainframes provide superior performance, capacity, security and scalability; other platforms are less good at these things.

But maybe our medieval metaphor is wrong. Maybe the siege is more like something from the start of World War I. In this case, we have balloons that can fly over the heads of the army surrounding our mainframe castle. We can drop in supplies to keep the soldiers going. In this case, we’re dropping off things like WSDL and Web services. We might even be dropping off Liberty z/OS. We’re providing a way for the mainframe to be accessed and used from a browser, or from a smartphone or tablet, or even the Internet of Things (IoT). We’ve found a way to prolong the siege – to keep the mainframe going. But we’re still dependent on core staff who understand the mainframe – and that’s what we’re running out of.

Not to stretch this metaphor too far, but what if the siege were more like the Berlin Airlift. In this case, we can airlift in the supplies that are needed for the siege to be resisted indefinitely. What’s the equivalent of our metaphorical supply aircraft? It’s the ideas and technology behind DevOps.

DevOps is an enterprise capability for continuous software delivery that enables organizations to seize market opportunities and reduce time-to-customer feedback. DevOps is not a product, it’s a way of working, across the entire life-cycle for all technologies and platforms. This new software imperative is for fast delivery with quality.

IBM’s proposed solution delivers a continuous integration software stack that enables application development for the mainframe and beyond. The developer-integrated development environment is RDz (Rational Developer for z Systems) or Rde for full Enterprise IDE facilities. For automated unit test there’s zUnit (a fundamental capability of RDz). For off-mainframe z/OS environment there’s Rational Developer and Test. For collaboration and integration there’s RTC (Rational Team Concert). For environment mirroring there’s Optim (TDM), Urban Code, and GreenHat. For continuous delivery there’s Urban Code. And for a quality dashboard there’s RTC.

One of the secrets of this new agile way of working is the re-use of APIs. We used to say, “Don’t reinvent the wheel” and then go away and write some code that did the same job (more or less) as older code that already existed. Now Developers can share, re-use, (re)combine, and deliver new capabilities much faster. They can do this by composing new capabilities using internally shared APIs and external APIs.

Another benefit of moving to an agile team environment is that it breaks down silos. It means disparate teams can now start to work well together. Going back to our siege idea, embracing the ideas behind DevOps means that the besieged mainframe silo and the armies surrounding them can all work together in what’s got to be a win-win situation.

So maybe I asked the wrong question at the beginning. Perhaps it’s not whether mainframers will adopt DevOps – clearly, it’s in their interest. The question should really be- will management accept a DevOps culture? The sooner they do, the sooner they will get the business advantage that comes with it. And they will avoid the problems of their mainframe castle being destroyed by invading armies. DevOps gives them a business advantage and takes away the high risk of going out of business altogether.