Held Back by Legacy Software? Reengineering Can Help To Fuel Change

Legacy applications are at the core of many large businesses. However, they are difficult to maintain because of multiple workarounds that have been growing for years. Their support requires significant investments. For example, according to the latest estimates, the federal government spends up to 80% percent of their IT budget on maintenance of existing legacy systems. What’s more, legacy applications can be a real impediment to the digital transformation of a company due to their inflexibility and inability to get new features or harness emerging technologies.

Software reengineering is one of the viable ways to mitigate issues with legacy applications. In this article, we highlight its area of use, explore activities it comprises, and look at why and when you may need each of these activities. On top of that, we reveal possible risks of reengineering and advise on how to organize a working reengineering process.

What is software reengineering exactly?

Software reengineering enables the examination and modification of legacy software code, which helps to maintain, reuse and alter it in the future. The full software reengineering process can be broken down to three main activities.

The starting point of any reengineering project is reverse engineering of the existing system. At this stage, software engineers and business analysts restore the lost info about application design and its specifications and requirements.

Further, the improvement of the system structure and small software enhancements may optionally follow. These modifications include code restructuring and modularization, wrapping code with explicit interfaces or removing unneeded parts of code. However, software reengineering doesn’t include major architectural changes, such as splitting an application into microservices, so its high-level architecture stays intact. The introduction of new functionality lays outside the reengineering scope as well. Still, the recovered transparency greatly facilitates changes and improvements in legacy software.

To find out how far these interventions should go in your project, we’ll dwell a bit more on all related reengineering activities.

Reverse engineering

When may you need it?

• To identify if further changes are feasible or if the system has to be substituted.

• To allow for smoother and faster substitution of the original system with a new one, in case the revival of a legacy application turns out to be too complicated or even impossible.
• To help to predict the effect of future enhancements and changes in software.
• To shorten the learning curve for a new support provider.
• To identify potentially re-usable components for future integrations.

Reverse engineering involves the exploration of the existing system to recapture current requirements (including all connections and interdependencies), interfaces between software components, data structure, and data design. To extract the lost info about the application state, business analysts interview stakeholders, and programmers, study the existing application documentation, perform its lexical and syntactic code analysis, investigate control and data flows, explore use and test cases.

Code re-structuring

When may you need it?

• To improve the code readability.
• To facilitate testing.
• To facilitate further transformation activities, such as re-architecting.
• To improve the application’s failure rate.

Legacy code can be either badly structured from the very beginning or become, so after multiple changes introduced in the course of a long application life cycle. In the course of code re-structuring, the programmers will simplify conditionals, remove unneeded code parts, improve the code structure, and review complex or memory-intensive algorithms.

Code modularization

When may you need it?

• To further simplify changing and reusing application components by other systems.
• To improve software performance.

Code modularization is used to combine related code parts in modules. Better software performance becomes possible due to the elimination of redundant calls between different modules.

Code covering

When may you need it?

• To enable the provisioning of web and mobile experience.
• To allow the reuse of the application’s functionality by external systems.

Developers come up with interfaces for legacy software (or its part) to integrate it with other systems, ensure its availability over the network and on the go. To open the application’s functionality to an external system, programmers complement a legacy application or its part with REST/SOAP APIs. Adding a mobile-ready service-level interface can enable access to the data or functionality of the legacy application from mobile devices. By complementing the back end of the legacy application with the web front end (UI) or web-enabling the existing one, developers make the application available via web and mobile browsers.

The increased need to expand the application’s reach makes redevelopment of interfaces one of the most popular business drivers for software reengineering.

The bad of reengineering projects and why we still speak about them

Reengineering projects have a reputation for being largely expensive, taking up to several years, and possibly causing long system downtimes. Moreover, the risks and benefits of reengineering activities are hardly predictable beforehand due to the incomplete legacy software documentation.

However, legacy software is often business-critical, so often you cannot simply remove these too demanding and rigid obsolete systems. Replacing them with SaaS is rarely an option as it lacks agility in customization required by large companies with complex business processes. And while another option of developing a new application from scratch can be tempting, such projects are vulnerable to multiple risks inherent to new software creating. Moreover, you can lose essential hidden functionality not mentioned in the specification and not obvious to applications’ users or administrators as it couldn’t be accessed through an interface or a command sequence.

Common risks of a reengineering project

• The loss of managerial support – senior managers can easily lose interest in supporting reengineering projects and make them first in line for funding termination in case of budget cuts. The reason is that the damage of legacy systems is not vivid, and the benefits of reengineering projects are remote. Thus, it’s important to clearly communicate the expected improvements and show the results as early as possible (this goal can be achieved, for example, by opting for incremental or iterative reengineering if possible).
• Effort and cost estimation risks – the incomplete documentation makes legacy applications quite dark horses, and the lack of experience in legacy estimation processes on the part of the project team may lead to incorrect predictions about the project costs, expected ROI and needed efforts.

What can simplify the reengineering task?

• Maximum automation. Automation is what rocks and offers fewer risks and lower costs for the reengineering project. The project team can use ready and custom-made automated tools for reverse engineering activities (to investigate the application structure), code structuring, and code modularization. However, automation doesn’t help to significantly reduce project time as the complex algorithms used for re-structuring are too demanding even for modern hardware.
• Involvement of knowledgeable employees. With the help of the current support staff or proficient users from relevant non-IT departments, the developers will much faster restore the requirements of a legacy application.

Sample reengineering workflow

The reengineering process model may look as follows. At the planning stage, you:

1. Identify the key modernization drivers and formulate your needs for the target application.
2. Sort out the required investments, assess the expected ROI and analyze the project feasibility.
3. Form the reengineering team from in-house resources or hire a reliable service provider (including the project manager, modernization engineers, application maintenance team, etc.).
4. Develop the modernization roadmap.

At the development stage, the reengineering team proceeds to:

1. Extract source code and database structures.
2. Gather all valuable data (available documents, requirements hidden in code, and employees’ knowledge).
3. Reverse engineer the application.
4. Re-document the application.
5. Introduce further enhancements (re-structuring, modularization, interfaces).
6. Optionally reengineer the database.
7. Test the reengineered application.
8. Implement the application.
9. Validate the application’s work in the production environment.

Reengineering is an important part of software evolution

Reengineering is almost inevitable if you want to significantly reduce maintenance costs for your legacy software, gain a competitive advantage with its extended reach and functionality as well as get a good ground for further modernization activities like moving software to the cloud and splitting a legacy application into microservices. However, reengineering of legacy software is an intensive activity with high costs and often unknown results, so it is hard to decide on. To justify expected substantial efforts, consider for the reengineering project only business-critical applications that yet have a potential to stay with you in the long run, and make sure the reengineering costs are balanced against the profit you plan to achieve from their improvement.