Monday, September 1, 2014

Modernizing Mainframe Applications (Part 1)

One of the things I see being done across the mainframe landscape is the trend to 'modernize' mainframe applications. There are three popular options in the industry. I will discuss the three options over three installments.


The first option is to re-write the application using modern technology. With this, there are two sub-options. One is to re-write the application and the other is to choose a Commercial Off-the-shelf (COTS) application. A lot of organizations have moved their applications off the mainframe and have succeeded. But many people choose this option without realizing what to consider.

There are many reasons why people choose this option. They are concerned that the people supporting their current application are retiring or have retired. The technology is not responsive. It is cheaper to run on servers than on mainframes.

These are good reasons however, it all boils down to money and risks. If an organization is considering re-writing the application, they will need to consider these questions:
  1. How will you get the requirements for your application? Most probably, you will need to get the current state of your application. You may get the business requirements but you will eventually need to dig into the code because there is not one person who really knows how the system works. Some of them may have retired so logic may not even be known to those using the system. A more realistic time frame for this is probably at least 2 years with a project Manager, a group of Business Analysts, a group of Subject Matter Experts and some developers.
  2. Once you have the current state, you do not just re-write your application. You may want to add more features so that will take some time again. You will need the same group of people for possibly another year.
  3. Coding from scratch will take at least another 2 years. Then we talk about testing. You need to make sure the new system works as required. Since this is a new platform, you will need to set it up. How will you test the application? You will need a development, test and production environment to do this.
  4. How will you get the data from your current system to the new one? What software and resources will you need to convert and test your data?
  5. How will you deploy your application? Do you just turn off the current system and deploy the new application?
  6. What is the rollback strategy if the deployment fails?
  7. What do you do when there are changes to the application as you are in the process of converting it? Will you delay your requirements and just roll it out in the new application? What if there is a new legislation or new requirement with a fixed date of implementation? You will need to consider that you will be changing the current system and the new system when this happens.
  8. How many servers do you need to be able to deliver the required throughput? How much is the software cost. Software cost includes, but is not limited to: operating system, database and web server. What is the staffing level needed to support these servers? How much is the cost to support the software?
These are just some questions an organization needs to answer when re-writing from scratch.

When the decision is to use Commercial Off the Shelf (COTS) packages, there are more questions to ask. No matter how companies sell their products, there is no such thing as a COTS package. They will always need to be customized or as some organizations put it, configured. Aside from the questions above, these also need to be considered:
  1. Can the COTS package do what the current system does? Remember that most legacy systems have requirements coded in that no one even knows. You will need at least a couple of years to get all the requirements and quirks of the system identified and documented.
  2. How different is the COTS package from the legacy system. Now that you know the current state of the system, what are the gaps? This will take probably some time to dig through.
  3. How will you reconcile the differences  between the COTS package and the current system? Most of the time, the differences need to be coded into the COTS package.
  4. Who controls the source code? If you consider the COTS option, you end up being tied to the COTS vendor.
Using COTS is not as simple as implementing it in six months and everything will work the same way. It is more complex than that.

Go to Part 2

No comments:

Post a Comment

Follow by Email

Total Pageviews