Replacement of business-critical software systems
Legacy software systems are critical to most businesses. These software systems are the heart of the existing IT architecture. Their interfaces are closely linked to the rest of the IT landscape and provide indispensable data for business services.
Over the decades, these legacy systems have been gradually modernized or additional functionality has been added to the system. Usually these extensions have increased the complexity of the systems. With the incremental development of these software systems, additional programming languages and technology stacks have been added.
Existing software replacement projects or software modernization projects are often large-scale projects lasting several years. Due to the complexity of the systems that have grown, there is an extraordinary risk that these replacement projects will fail. On the other hand, the business services provided by these systems are critical to business success and modern organizations have no choice but to modernize these grown software systems.
Sysparency recommends one of the following strategies to modernize essential legacy software systems:
- MAINTAIN
Maintaining the status quo and operating the legacy system
- WRAPPING
Wrapping components in a new environment (e.g. virtualization)
- MIGRATION
Convert the system to a new environment or programming language
- RE-IMPLEMENTATION
Rewriting components with the same design
- REPLACEMENT
Replace with a newly developed or purchased software system
Software archeology (software reverse engineering) is the first step towards the successful replacement of legacy software systems. The purpose of software archeology is to map and measure software to better support the documentation, maintenance, and development process of existing software systems. Before a system is replaced, the scope of the system must be fully recorded and the structure of the systems must be better understood. The impact assessments for the proposed changes are carried out and the costs for the different replacement and modernization strategies are calculated. A calculation period of over 10 to 15 years is recommended for creating business case invoices for critical software legacy applications. On average, the business-critical software applications are in use for up to 20 years and experience shows that they only pay off after ten years of use.
The next step in the replacement of existing software systems is the generation of the documentation for the existing software solution. The purpose of the automatically generated software documentation is to provide the analysts, software and maintenance engineers with detailed information about individual software components. Each part of the documentation shows a different view of the existing software program. This describes the structure of the program and the functionality. Calculations are represented by mathematical formulas. The user interfaces are graphically prepared from the source code and the data structure and batch elements are shown as diagrams.
Which parts and depth of documentation a stakeholder needs in the replacement project depends on the task at hand. Rebuilding the application, analyzing functionality or finding the source of the problem, or looking for the best place to make a change. Only with proper system documentation of the existing system can risks be minimized and problems with the changeover to a new system avoided. The subsequent documentation is then not only required for the conception of the replacement system, but often also for the training of new employees, since the legacy system still has to be maintained for some time.
Following the documentation of the existing systems, suitable standard software systems are selected. The standard functionality of these systems is prepared in a generalized function catalog and the gaps to the existing system are recorded. Now the department, technology and management decide whether the previous additional functionalities will also be required in the future and whether they are business-critical. The tender documents are now created from the function catalog and the result of the gap analysis and the right product with the right integrator is selected on the market. Should an individually developed software solution arise, the existing functionalities are converted into requirements for the new system. Due to the complete documentation of the existing system, there is no risk of forgetting functions and requirements.
Strong scope governance is required during the implementation of a replacement project. Ultimately, the new system must completely contain the existing and required functionality and should be enriched with modern enthusiasm factors.
