The mutable mainframe

I recently received an invitation to a webinar being held by MarkLogic, on migrating from the mainframe to NoSQL. I won’t go into all the misleading marketing speak in this particular document but one claim stood out, that “19% of enterprises will migrate off the mainframe”.

I don’t know where MarkLogic got this figure from and I don’t believe it. Well, maybe within the next 20 years but not anytime soon. And maybe individual applications but not en masse.

Of course this is by no means the first time that the mainframe has come under attack. And one of the reasons – there are others – is that mainframe environments are perceived as less than agile. And in today’s cloud-first, agile everything world that’s a hindrance.

In fact, historically, mainframes were pretty agile: database administrators used to sit beside developers in the good old days, but that has long gone as roles have become siloed. Cue the promulgation of DevOps: what goes around, comes around.

Anyway, the point is that right now mainframes are typically not very agile when it comes to development and testing. I’ve run into companies that can take anything between two weeks and two months to provision test data, for example. And the problem is exacerbated by the fact that a lot of processes are only completed in steps: transact data, manipulate it, post it to a ledger, aggregate postings, extract data that you want to analyse, and so on.

Okay that doesn’t sound particularly backward, except when you consider that these are physically separate steps rather than just logically distinct. Moreover, some of the steps are batch-based rather than interactive.

Making an environment like this more agile is tricky. Technologies like service virtualisation help in the sense that you can pretend that the mainframe isn’t there but all this really does is to remove that particular constraint: it doesn’t actually make the environment more agile.

Another issue is that there aren’t many companies out there that are actually interested in making mainframes more agile. Most vendors are either in the MarkLogic camp and want you to move off the mainframe onto their platform, or they want you to use their migration tools (for example, Advanced365) to move to some other environment.

About the only two companies that are seriously interested in wanting to improve your mainframe experience so that you can continue to use it, are IBM and CA. And, in so far as making the mainframe more agile is concerned, CA seems to be clearly taking a leadership role. I guess IBM is happy for them (anyone) to do so.

CA has been significantly adding to its portfolio of DevOps and continuous delivery products over the last year or so. Not only that – I have written about these elsewhere – it is also encouraging best practices.

For example, test data management should not only be able to provision test data for and during each sprint but to predict (based on coverage analysis) what test data is likely to be required, so that it can be pre-provisioned. Further, recognising that mainframes cannot live in splendid isolation CA allows you to access mainframe data via things like Docker or Jenkins, so that your mainframe data can participate in the digital economy in a more agile manner. There’s also an orchestration engine – CA Application Lifecycle Conductor – to tackle the challenge of tracking and governing the application lifecycle from mobile to mainframe. It automates and manages the software development cycle that spans these environments, and creates connections across the lifecycle, allowing developers to plug into software such as JIRA, GitHub and Endevor.

Of course, I have only scratched the surface here but I don’t think MarkLogic’s claims hold up. At least as far as being agile is concerned. If you want to be agile in your mainframe environment, then there are tools available to help you do that.