Any enterprise that got its start before the dawn of the internet era comes equipped with a legacy in its systems of records that are several decades old. These systems have been through multiple patch and upgrade cycles over time, making them inflexible to change. Simply put, these systems may create more problems than they solve.
And yet Gartner predicts that, even by 2023, 90 percent of enterprise applications in use today will still be in use.
These systems of record have proven themselves to be a competitive advantage for the enterprise over the years, and they can’t be wiped off the slate – simply because there’s nothing to replace them. In a recent survey conducted by BT Global Services, 42 percent of enterprise leaders said they would continue using their old systems, and 37 percent said they even planned to upgrade these systems. And, contrary to popular belief, a BMC mainframe survey last year revealed that 91 percent of enterprise leaders expect their workloads on mainframes to grow.
The problem in keeping these systems running is that the Baby Boomer generation is retiring, and the skills needed to maintain them are dwindling. Look at mainframes, for example. They aren’t part of any graduate curriculum today, and are not of interest to the young technical workforce. The skills needed to develop old applications written in programming languages, such as COBOL, FORTRAN, Assembler and even C, are not readily available, forcing enterprises need to spend considerably to train and onboard skilled staff.
Modernization: The New Imperative
Now let’s examine modernization. Modernizing software systems has been a cornerstone of the offshore IT services industry. Modernization today is platform-led, very different from the earlier era in which modernization was a services-led initiative powered by selective platform use. There are two main reasons for this:
From Legacy to Neo Legacy
The move from 3GL to 4GL has been making the modernization rounds for a number of years. Unlike 3GLs (C++, Java etc.), 4GLs allow the developer to focus on an app’s business logic and presentation, and not just on writing lengthy code. Developer productivity was the core promise of 4GLs and platforms, such as FoxPRO, Microsoft Access, and PowerBuilder, enabling rapid application development. The problem is that 4GLs were built for an earlier era.
But 4GLs are proprietary, and inevitably result in in vendor lock-in. Plus, enterprise software licensing costs for 4GLs are continuously increasing. And, despite their promise, they required a lot of manual coding. What’s more, their scope of use is limited to specific application scenarios, which are determined by app vendors. Unfortunately, that leaves little scope for customization and exploration.
Unfortunately, many 4GLs were developed before the “digital era” and long before the need to support the web and mobility. Thus, 4GLs are not suitable for the device, data, and integration requirements of today’s enterprises.
But now, low-code application development platforms have stepped in. Their promise is not only to simplify coding, but to drastically minimize or eliminate the need for massive code bases, and doing so results in faster and future-proof development.
From Traditional Code to Low-Code
Low-code platforms have become one of the tools of the trade for app modernization.
Where to Start
How can you transition to app modernization using low-code development? Here are my recommendations:
1. Evaluate the technical condition of your systems and bucket them as low or high depending on your perception of these five parameters:
2. Decide whether the code base needs to be touched
If applications do not need to be modified but need to be updated, there are three common approaches: wrapping, packaging and re-platforming.
If the code base needs to be modified, approaches such as refactoring, rewriting and re- architecting should be considered.
A packaging approach that replaces legacy software with COTS software is suitable for systems of record but shouldn’t be used for systems of differentiation. This is because all companies have access to apps, such as Salesforce, that erode the opportunity for differentiation. Such systems need to be approached with either rewriting or re- architecting, both of can build competitive advantage.
Systems of differentiation can be approached using a wrapping strategy, which is typically lower cost. However, the benefits of wrapping are temporary and should be used a stepping stone to a rewriting or re-architecting. All other approaches except wrapping reduce the burden of finding skilled legacy resources. Why is wrapping singled out? Because wrapping simply allows new functionality to be developed on top of old systems. Companies still need active mainframe and COBOL development teams post-wrapping.
Finally, enterprises need to acknowledge the technical challenges faced by IT and developers during modernization projects. These include:
Modernization is a practice whose time has come. But perhaps the true test of any modernization platform is that it must not come at the cost of an army of specialists, but instead must set the stage for sleeker, more people-efficient IT organizations.
Originally published by Vinay Murthy, VP of WaveMaker in EnterpriseTech