Mainframe

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.

Trevor Eddolls

CEO at iTech-Ed
Regular Planet Mainframe Blog Contributor
Trevor Eddolls is CEO at iTech-Ed Ltd, and an IBM Champion for the eight years running. He currently chairs the Virtual IMS and Virtual CICS user groups, and is features in many blogs. He is also editorial director for the Arcati Mainframe Yearbook.
Trevor Eddolls

Latest posts by Trevor Eddolls (see all)

Share this article: Share on Facebook
Facebook
0Tweet about this on Twitter
Twitter
Share on LinkedIn
Linkedin
Email this to someone
email

This Post Has One Comment

  1. Avatar
    Chris O'Malley Reply

    Your points are well taken, but you miss a crucial perspective. Current DevOps artisans must urgently master mainframe code and data and full-stack developers, in solving digital use case requirements, must be effective all the way through to the far side of the mainframe. Simply said, the mainframe, in order to thrive in the digital economy, must be remade to be different only in syntax from other platforms.

    As you state, the transformational chemistry requires brining DevOps culture and process to the mainframe, but it’s also requires enabling the preferred DevOps tools for the mainframe. Tools such as Jira, Confluence, SonarQube, SonarLint, AppDynamics, Splunk, DynaTrace, Jenkins, … have earned raving users within the DevOps community. Contrastingly, IBM’s Rational business is in a precipitous, revenue free fall due, in part, to DevOps artisans increasing influence on tools decisions. In the previous two reported quarters, IBM’s Rational YOY quarterly revenue declined 11% and 28% respectively. Interestingly, but not surprisingly, IBM has now decided to stop disclosing Rational financial performance to investors. Such a large revenue decline puts Rational, as a business, in a league with the likes of Wang and Kodak. Truth be told, DevOps artisans can smell unjustifiably-expensive, mixed-bag-monolith, over-engineered, unnecessarily-complex, impractically-architected, painfully-maintained, services-heavy tools from confused and conflicted technology conglomerates from a mile away.

    DevOps is about relentless ideas, speed, agility, throughput and improvement. Rube Goldberg need not apply.

    Again, smart ideas and extraordinarily helpful insights, but oddly bad tools example given the realities of DevOps and IBM’s “no longer so” Rational business.

    Best regards,

    Chris

Leave a Reply

Your email address will not be published. Required fields are marked *