Is It Time to “Modernize” your Modernization Plans?

Over the last several decades, I have spoken to many organizations about their mainframe application “modernization plans.” Many claim to HAVE plans, but few report any progress toward completion!

Why is that? Why are modernization plans so difficult to start and complete? Perhaps it’s best summarized in the line from a Robert Burns poem – “The best-laid plans of mice and men often go awry”!  In other words, no matter how a project is planned, accidents, misfortune, business distractions, or myriad other “interruptions” can wreak havoc on these “best laid” modernization plans.

Over the last decade, much has changed in the mainframe and application modernization world. Modernization plans based on “then” available options may no longer reflect the best or lowest risk approaches available today. 

So now what? March inexorably forward with an existing plan that has a diminished chance of succeeding?  Or, update these plans based on the current modernization options available?

So, I ask: If your answer is to revisit and update (the right decision), what would you do differently in your modernization plans, knowing what you know now?

Would you consider packaged software solutions in scope for modernization now where in the past you wouldn’t? Would you write a new solution to the business problem instantiated in a legacy application? Would you retire the application in its entirety?

As often is the case, it depends.

Several changes have occurred in the marketplace and your organization since you first put pen to paper and wrote your modernization plans. Advances in traditional server performance have continued to grow. Expanded I/O capacities are readily available. Most importantly, the acceptance of cloud computing infrastructure has become more readily accepted than in the past.

If an application reflects current business practices, then your modernization plans need to consider migrating some or all of your application portfolio to modern computing infrastructures.

For this to happen, particularly for legacy mainframe COBOL applications, a couple of considerations need to be understood.

It IS possible to execute COBOL applications off the mainframe on distributed platforms, whether in-house servers or deployed on the cloud. Still, the number of vendors that provide support for the COBOL language is limited.CloudFrame is one of the few exclusively focused on COBOL.

We would not suggest the death of COBOL any more than we would predict the end of the mainframe, but the continued dependence on technologies with limited innovation options does not bode well for the future. The future is to modernize COBOL applications.

That stated, the risks of completely rewriting an application from one language to another are well understood. Rewriting an application currently implemented in COBOL, a procedural-oriented language, to any modern language, which is more likely an object-oriented programming paradigm, is non-trivial. Rewriting COBOL to Java, for example, is not simple and brings a significant risk when attempting to produce functional equivalence. If one chooses to change the functioning of an application at the same time it is converted, the risks are even greater!

However, it is possible to migrate a COBOL application incrementally. Transforming a COBOL application to Java using automated code conversion technology is a more viable option than it has been in the past. Improvements in conversion speed and, most importantly, the QUALITY of the generated code is significant. Using a transformed application as the basis for subsequent modernization and extension can reduce the time, cost, and risk of such a modernization option.

The difficulties of modernizing legacy applications are real! The recognition of these challenges is often the reason why modernization plans have become stagnant. More extensive and invasive modernization strategies may yield a better result, but the risks of failure are more significant! Recognize that modernization is a continuum and that reducing the chances of calamity through smaller steps is a better path to success than trying to move forward in one giant step.

– Guest content from Dale Vecchio, Mainframe Modernization Thought Lead