Don’t make the biggest mistake in application modernization projects

Application modernization isn’t simply a trend; it’s the mandate for every IT organization.  The cost of running old applications and the infrastructure that supports them is problematic.  They also lack new features and capabilities, making them a competitive liability. 

Simply lifting and shifting current code to the cloud doesn’t help and can cost much more.  To make a difference, applications must be fundamentally “rebuilt” to gain the desired benefits.  This is the path that our attendees at CIO roundtables consistently identify. 

However, most of these applications aren’t just important to the business; they are mission critical, and any failures or downtime is far worse than doing nothing at all.  Stability and availability are non-negotiable.  So, while application modernization is required, it must be done carefully.

Based on the discussions and opinions shared at these CIO events, there is a palpable fear of trying to modernize these large applications in one shot.  The old analogy of eating an elephant in one bite is spot on. 

So, what to do?

The approach that gets the discussion going and gains substantial traction is to take a modular approach to modernizing these business-critical applications.  The idea of upgrading individual components or services within the application and then linking them back to the legacy application via a message bus or API is not only attractive; it is “doable.”  In fact, the benefits of taking the modular approach to application modernization get a lot of approval among senior technical professionals who attend these events.  Some of the benefits they cite include:

• Timing – It is possible to modernize one application service or module in a few months or less.  This means that the functional specs aren’t moving and changing, the project staff will be more consistent, and the costs are less because the effort isn’t endless.
• Application reliability and testing – Using this approach, it is possible to focus first on components or services that are “secondary” in nature, and if they don’t work exactly right, don’t blow up the entire system.  If issues are found, they can be remediated without customers or employees being impacted.  This also reduces the scope of the testing environment to something much more manageable.
• Simplify the learning process – One of the most challenging parts of application modernization is figuring out what a programmer did and was thinking, sometimes more than 20 years ago.  Documentation is routinely lacking, and deconstructing what exists is hard.  Starting with a simpler module and less likely to crash, the entire app is extremely attractive.  It gives the current technical team a chance to learn more about the legacy app with far less risk.
• Reduce the scope and number of new capabilities that are part of modernization – Modernization is also a code word for “enhancement.”  That is expected.  Starting with a component or sub-service makes the scoping of new features simpler and leads to less demand for these features.  This makes it easier to complete the effort and have success.

This component-focused approach to application modernization is gaining momentum.  Taking on a monolithic COBOL and IMS-based monstrosity built in 1989 isn’t a challenge; it’s suicide.  However, taking on the customer tracking function of such an app is quite doable.  Our CIO event attendees agree everyone wants to get things done, but they don’t want it to cost them their jobs.