During my career, I’ve had to work on the challenge of modernizing several software products. As explained in my article, “Balancing Technical Debt,” we should develop a plan for moving forward. The effort to raise the bar must be continuously evaluated in order to be ready to make any “do or die” decision.
In our rapidly evolving digital world, all software companies must face this situation!
Software modernization, otherwise known as legacy modernization, refers to the work of converting, rewriting or porting a legacy program to bring it up to the latest standards in computing and software. This includes such things as modern programming language, software libraries, protocols, cloud technologies (Serverless architecture, Microservices, etc.), hardware platforms, etc.
Perhaps this is a good place to define legacy software, to help us better understand what is at stake when we talk about software modernization.
Legacy software is any business application based on older technology that is still used to support the core functions of a business or organization. They are monolithic, having no reusable modules or code, and are difficult to understand or modify.
Legacy software is often heavily patched, wrapped and built on top of, meaning that any attempt to modernize them could have catastrophic effects (it means a high TCO). Furthermore, such ancient “hieroglyphics” often require ancient hardware which is no longer manufactured new. Maintenance of such systems often requires hours of searching by IT for obsolete hardware in online auctions and forums, which, frankly, can hardly be considered professional, especially for large corporations.
Software modernization is not a project to enter into lightly or carelessly, nor is it something that can be ignored. Far too much is at stake in this very volatile and rapidly evolving digital world to ignore this critical area.
While it’s easy (and completely erroneous) to think that the vast majority of today’s systems are built solely on Java and web based systems, the reality is that most large organizations are still running their critical applications in legacy environments.
While progress is slowly being made out, often when necessity finally trumps executive stubbornness, trillions have been spent on COBOL applications in the early 21st century, alone, and tens of billions of COBOL transactions continue to occur, every single day. According to a February, 2017 article by Alexander Ziegel on the IBM training and using blog, 80 percent of the world’s daily business transactions rely on COBOL.
While COBOL, originally designed in 1959, is no longer popular for the creation of new software, due at least in part to the declining number of experienced programmers, it is still the backbone of many business applications. Much of the programming work being done with COBOL in 2017 is focused on modernization and migration to new systems.
Furthermore, with some recent estimates suggesting that from 60% to 80% of an average company’s IT budget is being spent just on maintaining existing mainframe systems and application, it is becoming too expensive and time consuming not to consider software modernization.
At the same time, the fact must be considered that while a business develops over the years, it builds in a large and even somewhat priceless accumulation of experience and strategy in its existing legacy software that can’t simply be discarded for the sake of modernizing. Oftentimes, these are the very things that give a company its competitive advantage in its niche.
There are a number of factors that have hindered or slowed the progress of software modernization from what some have accurately labeled as “ticking time bomb” of heavily patched programs. The cost of upgrading these often proprietary behemoths to run in the cloud and SaaS systems is very daunting, yet the cost of not upgrading can no longer be ignored. Many of these systems have been running on IT life support for too long already, and are at imminent risk of dying at any given time.
Therefore the steps taken in the modernization process often need to be incremental, dealing with the most pressing risks first.
Some of the risks that simply must be considered that exist in virtually all legacy systems are:
- The hardware (infrastructure) is obsolete and parts are becoming more and more difficult to find
- It is getting more and more difficult to find engineers who even know the language
- The technology is no longer supported by its vendors
- The cost of maintenance is increasing beyond acceptable levels in an increasingly competitive marketplace
Perhaps the number one reason, today, in the 21st century, that many companies have not dealt with the issue of software modernization, or have simply “kicked the can” even further down the road, is because they have failed to properly assess their situation. The fact is that any company with plans to continue beyond this year need to assess the risks and rewards involved in keeping the status quo versus modernizing.
In many cases, simply assessing and appraising the existing system with all its flaws and potential for catastrophic failure should be enough incentive for software modernization, regardless of what it will cost, as the cost of not doing it is unthinkable.
Therefore, the first step any company running on a legacy system but planning to continue beyond 2017 must take is a full assessment of their systems. This must include both the legacy applications and infrastructure, as they are co-dependent. The cost of doing nothing must be carefully weighed against the cost of doing something. Future expectations for the longevity of the organization obviously are a very important factor in such an assessment. If the company is expected to exist far into the future, it is more important than ever to ensure the system will take it there.
Therefore, any realistic assessment must include:
- a proper, sober evaluation of applications based on existing and future requirements
- identification of existing, ongoing and future operating, maintenance and and replacement costs
- the risks involved with any kind of failure
- the potential benefits of using managed, share or cloud services
Of course, for any kind of business strategy, the cost of implementing a plan, such as software modernization, must be weighed against the value of the business. Will the plan increase profitability, while reducing overall costs?
After a thorough and thoughtful assessment, some organizations may simply decide to do nothing but maintain the status quo, determining that the cost of upgrading is too high.
However, there are steps that can be taken to reduce the cost of software modernization.
Moving the entire legacy system to a new, more flexible and cost effective platform, rather than replacing the existing infrastructure can be a very cost effective first step to modernization. This removes the issue of hardware costs from the equation.
There are software technologies that can sometimes be deployed to rewrite existing code to modern language while maintaining existing logic, data and naming conventions.
It is worth looking at commercial, off-the-shelf software that can be bought, leased or licensed before proceeding to hiring someone to do a custom rewrite, another possible choice.
Today, a choice that is increasing rapidly in popularity is private or public Cloud solutions, such as a SaaS (Software-as-a-Service) which can be leased without all the expense of proprietary development and deployment.
The costs involved in software modernization may seem high at first glance, but should really be one of the last items considered. Modernizing optimizes your organization’s ability to adapt and be responsive, thus maximizing your ability to adapt and evolve for existing and future conditions. In a nutshell, software modernization may be the most important thing you can do to ensure your organization’s continued existence and profitability.
Obviously, no plan for any progress can be implemented without action. The assessment should lead to a plan, and the plan then must be implemented.
One of the dangers for many software modernization plans that is very tempting to allow in is the danger of working without a deadline for implementation. While the idea may seem to have merit, considering the rapid changes and evolution inherent in modern systems, the reality is that without a definite deadline for implementation of a real plan, it may never happen. There will always exist the natural human tendency to put off until tomorrow that which does not absolutely have to happen today.
On the other hand, setting a definite goal for the implementation of software modernization to a certain predetermined point by a certain predetermined date will bring the entire system into the 21st century. Once that goal is reached, further assessment may demonstrate a need for further modernization, but the distance will be considerably shorter, less costly, and less likely to leave the organization open to immediate and catastrophic failure.