Mainframe Migration? Why?

November 29th, 2017

This is part 1 of a series of articles investigating why organisations should consider  Mainframe Migration, the options they have and the steps they need to take to transform their mainframe workloads to run on the cloud.

Lets set the scene a little bit for a typical large organisation that runs business critical applications on the mainframe.

  1. Your mainframe and your mainframe applications just run.
  2. It causes no heartache, no troubles, when was the last time it “went down”?
  3. If it wasn’t for the pesky leasing payments and the endless contract renewal discussions you probably wouldn’t give it too much thought.

But there are a few vague, uneasy, feelings :-

  1. Perhaps you are not as responsive to your customers’ requirements as you could be.
  2. At month end, quarter end, year end, the batch jobs are only just completing in the batch window
  3. There are a lot of grey beards in the PL/1, COBOL teams
  4. Adding a new type of customer contract takes months with the mainframe screens and seemingly minutes with the web team.
  5. Lets face it a green screen does not have the possibilities to represent data that a modern web browser supports

Would you rather be working with this green screen? A COBOL/CICS application that has been deployed to Pivotal Cloud Foundry using Heirloom PaaS.

mort greenscreen

Or with this Angular and D3 application that is also running on Pivotal Cloud Foundry and using exactly the same back end COBOL/CICS program to run the amortization calculation?

mort angular

 

Your companys’ “front-end” applications are being delivered using industry best practices, continuous integration and continuous deployment, CI/CD, of the applications is de rigueur and perhaps most importantly your customers are extremely happy with the features the responsiveness and the look and feel. These applications and the teams that create them are agile in a way that the Mainframe group is not.

At the same time these web applications are now capable of the same reliability as your mainframe environment, not because every single component works all the time, but because every component has fail-over redundancy built in. It is a different reliability model to be sure but one to which the organisation is gradually becoming accustomed.

Your company is also becoming accustomed to hardware costs for running the non mainframe applications to actually fall each year and yet still eke out higher and higher performance. Need to have a little performance kick for black Friday, just automatically scale out some more application instances, and pay for the extra throughput performance ONLY when it is needed.

So now the scene is set, check back here for the next post where I will lay out various Mainframe Migration options and the pros and cons of each one.