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:
- Three- to five-year roadmaps are dead. Consider this: spending one year, using a dozen developers at a cost of $1 million to build applications is no longer feasible. Modernizing is about quickly changing direction for new opportunities. To achieve this, a healthy interplay between platform and services is critical. Services alone can’t cut it anymore.
- Enterprise IT has to do more with less. The recent 2018 Connectivity Benchmark Report from MuleSoft stated that IT decision-makers report an average of 27 percent more projects for 2018 over 2017, while IT budgets, on average, will either increase by less than 10 percent or stay the same. Something must give.
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.
- They offer full-stack visual development and application management capabilities. They enable enterprises to quickly build, test and run enterprise-grade mobile and web applications with minimal code. Enterprises can experiment and innovate with less risk of traditional methods.
- Applications built using low-code platforms are modular by nature, so the cost of an application change is reduced.
- Open standards-based stacks give low-code platforms the openness that 4GLs lacked, and they let enterprises avoid expensive vendor lock-in. Low-code platforms can be used for a range of requirements, from simple automation of paper-based processes to creating new systems from the ground-up.
- Applications built using a low code approach are robust, secure and can be a seamless extension of existing data sources and legacy systems. These platforms also offer pre-built connectors and pre-fabricated components. This makes applications extensible and customizable, and helps leverage the power of API economy.
- Built-in DevOps and container management capabilities help low-code platforms deploy applications into, and between, existing infrastructures. This accelerates the code into the customer journey.
- Low-code platforms help enterprises better align with the future of software development. Today, the answers to most business problems are in the data owned, not in the software used. Hence, spending a year and a million dollars to build enterprise software cannot be justified. Model-driven, componentized assembly of software is the future and low-code platforms aid such emerging ways, making development efforts future-proof.
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:
- User experience and app usability
- Functionality in line with customer demands
- Cost of maintenance
- Level of security required
- Ease of finding relevant skill sets to effect change
2. Evaluate what types of system these are, be they systems of record, differentiation or innovation3. 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.
- Wrapping: The application is not modified per se, but a connectivity layer is added on top, enabling web/mobile deployment. Wrapping is non-invasive, it costs less, and allows a quick UI refresh. In the long run, wrapping has no impacts in terms of functionality improvements or reduction of maintenance costs. However, note that wrapping won’t solve the problem of legacy skills shortage: even after wrapping, enterprises would need those legacy skills.
- Packaging: Here the entire legacy application is replaced with a COTS (Commercial Off-the-Shelf) solution. Picking this method is often part of an organization-wide effort to embrace a cloud-first approach, moving to an SaaS model. Note that this approach is expensive. Additionally, it has proven to have no impact on an enterprise’s competitive advantage.
- Re-platforming: For re-platforming, cost reduction is the dominant driver. An existing code base is taken as such and moved from one platform (e.g., mainframe) to another (e.g., client-server).
If the code base needs to be modified, approaches such as refactoring, rewriting and re- architecting should be considered.
- Refactoring: Via this approach, duplicate and redundant code is identified from an existing code base with the help of technology, and the overall code base is simplified to achieve reduced maintenance and hosting costs. This is also referred to as remediation.
- Rewriting: The application is rewritten from scratch in the code of the new target environment. This approach can create long-term competitive advantage, but the associated risks are significantly higher.
- Re-architecting: This involves transforming the legacy code base into a new target environment, typically a multi-tier architecture. This is achieved using a combination of technology and services. Rearchitecting is invasive but less risky than a rewrite and has greater impact on building competitive advantage.
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:
- There are new system architectures to embrace virtually every day
- Modernization must be accomplished with no loss of existing data
- Developers must strike a balance between user experience and system functionality
- Extended support may still be required for older applications
- Transitioning to new, modern applications must be done with no risk of downtime
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