I spend a lot of time talking to organizations about disruption and the fact that no matter what industry they’re in, there is an equivalent to Uber breathing down their neck just waiting to destroy them. Normally these conversations end up with defensive legacy IT practitioners finding a million reasons why agile and innovative couldn’t happen in their setting—to much compliance, too many core systems, too much of a “slow and steady” business.
Don't get me wrong: While I’m a huge fan of webscale approaches to IT, commodity infrastructure, and moving up the value chain, I’m still well aware that many of the world’s most critical systems—from banking to air travel—run on big old traditional mainframes and that forklifting these applications onto new architectures is hard.
+ Also on Network World: Mainframes and the API economy +
So, yes. There is still a need, for at least the mid term, for mainframes and all the inefficiency and heft they bring. And this is where Compuware is going with an announcement suggesting that they are delivering “mainframe DevOps.” Oh, Lordy me.
DevOps is, of course, the move towards bringing development and production operations together—developers start to think about the realities of running their applications in production, while operations teams start to think about building more flexible and agile infrastructure. So, the very notion of “mainframe DevOps” sends shivers down my spine. Mainframes are, by definition, the antithesis of flexible infrastructures, and the idea that a 20-something developer is going to start getting involved with running mainframe infrastructure seems bizarre to me.
So, what is Compuware getting at here? The company is offering a series of new APIs for ISPW, a source code management and release automation, that it acquired earlier this year. The APIs are designed to allow organizations to integrate mainframe and non-mainframe DevOps tools together and create tool chains that cover all of their infrastructure.
As Compuware points out in its briefing materials, traditional mainframe development, test and code promotion processes are simply too slow to meet the demands of today’s fast-moving markets. So, given the central importance of mainframe applications and data to a sad and even more sadly overwhelming majority of global enterprises, those processes must be accelerated to compete successfully with new, digitally nimble market disruptors. Ergo apply some nimble magic jelly beans to a generally rigid architecture, and you have (at least as Compuware spins it) the best of both worlds.
In some ways, this does feel like a “better together” solution—the APIs are architected as REST web services. As such, no expertise in specialized mainframe technologies is required. And the fact that mainframes are involved is, at least to an extent, abstracted away from the developers. The Promote Release and Deploy Release APIs support Webhook notification and, therefore, can enable integrations with popular agile/DevOps tools such as Jenkins, Slack, HipChat and XebiaLabs’ XL Release.
And who is going to argue with excited customers talking up the value of the offering:
“As our business increasingly depends on software, we have to be able to get more software of higher quality into production faster at less cost,” said Simon Hu, Senior Advisor, Mainframe Delivery for AARP. “Technologies such as ISPW and Topaz that help streamline our DevOps processes and make them more agile are thus of greater business value to us than ever.”
You could look at this in a couple of ways. The protagonists would say by wrapping mainframe infrastructure with DevOps tools, you essentially create an operating model not entirely dissimilar to that of the cloud: a large pool of infrastructure that developers interact with programmatically and don’t have technical oversight into.
But everything I know about mainframes and the sort of systems and processes that run them make me skeptical that even with all this DevOps goodness, developers will really be able to provision and de-provision resources at will. The great thing about the public cloud, for example, is that I can stand up a testing sandbox, move to production, scale, autobalance, and create and maintain multiple redundancies, and all of that stuff that builds big, strong, secure and fail-safe infrastructures.
That isn’t what is on offer here. Yes, it allows organizations to move a bit faster within their existing context, but if my assessment is correct and many of these organizations indeed have an Uber staring them down, this isn’t going to be enough to avert that threat.
This article is published as part of the IDG Contributor Network. Want to Join?