Application modernization is about reworking or updating an application to better meet current needs. It’s such a simple idea—so, why is it challenging? Modernization can be perplexing for any number of important reasons.
For one thing, the term has been around for decades and some leaders think the practice has run it’s course. They believe that older modernization approaches are no longer relevant and that modernization only happens when you replace an old application with a new one. For them, modernization means application replacement.
Another consideration is that since application modernization requires institutional stability and thoughtful planning, it’s difficult to pull off. Stability and planning are a big challenge in environments where funding is hard to find, where people are continually asked to do more with less or where there’s a lot of staff turnover.
A third consideration is the difficulty behind finding methods of achieving application modernization that do not create unnecessary complexity through the purchase of additional software or the procurement of outside services. These are just a few of the considerations tied to the history and practice of modernization.
The Case for Application Modernization
The truth is that “applications of record” have many advantages as incumbents and are worthy of an approach that breathes new life into them while performing ongoing maintenance and bug fixes. After all, enhancing an existing application offers a much lower risk to the organization compared to an outright replacement of an old and neglected application.
In addition to lower risk, ongoing modernization has lower costs. Consider the millions spent by software companies to enhance their compilers and middleware—isn’t this an invitation to build upon their investment to benefit your existing application? Some of your modernization work can be built upon the investments of others, thereby amplifying the money and time that you invest.
Is There an Application Modernization Method?
Services and software companies have materials like procedures and tools that they use to help customers address modernization challenges. The guidance they provide addresses the difficulties in diverse ways from rewriting the application in a “modern” language, like replacing COBOL with Java. Or, they provide tools to modernize the legacy application with little or no changes to the application itself like when they use API software to create microservices on top and outside of an existing application.
Independent of how and what you modernize, a structured way of approaching the situation is helpful. Figure 1 contains a framework for an in-house driven approach independent of services or software suppliers. Think of it as a tool to help think through both small and medium-sized efforts.
Figure 1. A Model for Approaching Application Modernization
A Quick Summary of the Model
Let’s explore the inputs, changes (transformation) and outputs that are part of the application modernization model, including the feedback loop, which makes sure that lessons learned are factored into the process.
The model recognizes that modernization wants and needs comes from different sources. These are reflected in the “inputs” column of Figure 1. The model doesn’t address how you manage and prioritize those inputs as companies routinely have tools and procedures to handle this.
Software changes are deployed in different ways as reflected in the “outputs” column, including continuous integration or long-standing approaches like implementing new functions in parallel with the previous capability. Since changes come in different size, scope and substance, they’re more thought provoking to address. Size and scope measurements are often used to estimate the cost of changes. Substance is about the expected impact of the change. These are depicted in the “transformation” column of Figure 1.
An Example—Request From the Customer
One example of a modernization input is when the user of the system communicates with the application development team that they want a new way to use the application. This could be something like access to application functionality with a mobile device. They explain that when they get a phone or email inquiry from their customers, they sometimes need the ability to walk into the warehouse and verify assets. This would be easier and quicker if they could work with the application using a tablet device. This is the same function that they can do at their desk but they want to be mobile so that devices like a tablet can be used.
This is a straightforward customer request. That is the nature of the input. The output is well defined—access the function, an inventory look up and verification of the balance on hand. If the balance doesn’t match what’s in the system, then some action is taken, ideally from the tablet in real time. The team may suggest implementing this new approach in parallel with the existing capability or piloting it in one location.
What’s less straightforward is how to achieve the transformation. Some research is required to examine the alternatives. Input from others, like the corporate IT architecture team, can sometimes help with this issue. It might be as simple as using middleware functionality that’s already available in-house, like CICS web support or using middleware that provides access in a different way, like z/OS Connect that gives organizations the ability to call external APIs from mainframe applications and make mainframe application functionality available as easily-consumable RESTful APIs.
Another Example—Input From the IT Architecture Team
Another example of a modernization input is when the company IT architecture team communicates with the application development team that a new release of software is available and it has functionality that they anticipate will be useful in a number of ways. The latest release of IBM Enterprise COBOL for z/OS is an example of this kind of software.
The IT Architecture team is likely making this recommendation because this compiler supports the latest IBM Z architecture and OS features and capabilities. This IBM Z architecture support happens with little effort on the part of the application development team. Other features of the compiler, like new and changed COBOL statements (i.e. the new JSON PARSE statement) will require changes or additions to the application code.
It’s a prudent idea to modernize as much as possible while prioritizing code fixes for many enterprise applications. The burden of modernization can benefit from an open approach that accepts inputs from many sources and seeks to maximize the use of the work that software suppliers complete from release to release.