Rebuild development methodologies to achieve de-legacy

Need for Rebuild Development

The Ministry of Economy, Trade and Industry's DX Report has proposed the "2025 cliff" problem, and the report points out that aging existing systems are a stumbling block to DX promotion. In general, aging existing systems tend to be huge, complex, and black boxed, and in some cases, legacy technologies such as COBOL and mainframes are used. Since these systems cannot be easily migrated, many companies have no choice but to continue using them by adding functions one after another, resulting in huge maintenance and upkeep costs.

To solve these issues, NTT DATA recommends migration using the Modernization Journey^*1. By migrating existing systems in stages along the modernization journey, the benefits of each stage can be reaped as early as possible.

To solve these issues, NTT DATA recommends migration using a modernization journey. By migrating existing systems in stages along the modernization journey, you can enjoy the benefits of each stage as early as possible.

For example, consider a time when the existing system was in a "legacy" state in terms of modernization journey. The state of the art is that the COBOL application is running on a mainframe, and the application itself is a tightly coupled, spaghetti-coded, non-modular system. Rehosting or rewriting these systems will result in "open legacy" or "server legacy" status. In this state, breaking away from the mainframe can be achieved, and the cost benefit of the infrastructure part can be obtained. On the other hand, if rehosting is selected, COBOL will remain, and even if rewriting is selected, a Java source will be created with COBOL instruction specifications and dependencies with the mainframe infrastructure. Therefore, simply rehosting or rewriting does not completely remove the legacy, and the problem of maintenance costs for the application portion will continue to exist.

Therefore, rebuild development (including refactoring, re-interfacing, and re-architecture) is necessary to solve these maintenance cost problems. The rebuild development process is introduced in the next section.

• *1 Defined system statuses and routes from legacy to microservices.

It is intended to be used to formulate a development roadmap that considers the amount of investment required and the benefits that can be obtained from each status.

Rebuild Development Methodology Process

NTT DATA maintains an N-shaped development process as a method for conducting rebuild development. Rebuild development involves updating the current design documents, redesigning for the next system, and developing in the usual waterfall development flow. By going back to the design once, discarding the existing program, and then rebuilding the program again based on the design documents, it is possible to break away from the existing low-maintainability construction and improve the maintainability of the application.

N-shaped development process

In the redesign for the next system, the current design documents are redesigned based on the development policy of the next system. Details are presented in the next section.

Redesign Policy for the Next System

There are three options for the next system redesign, depending on the combination of application and database redesign or not. A summary of the characteristics of each is shown in the table below. Details of each feature and its advantages/disadvantages are explained below.

Comparative Table of Redesign Policies for Next System

For application-only redesign

The first option is application-only redesign. Application-only redesign is a policy of reviewing only the application without changing the database table design. In the case of legacy systems, the structure from the mainframe era, when the number of columns in a table was huge, will be inherited in the next system.

Overview of the policy to redesign applications only

The advantage of this approach is that it does not require major changes to existing business specifications, allowing partial diversion of design elements from existing systems that are language-independent. In addition, since database migration is not required, the database can be shared before and after migration, allowing applications to be migrated in stages.

The disadvantage of this method is that it does not review the database structure, so if the current system has a structure in which a single table is updated by multiple subsystems, the subsystems cannot be easily split up. As a result, the effect of loosely coupling subsystems is limited to the extent possible by application refactoring.

To redesign the database only

The second option is a database-only redesign. In the case of database-only redesign, the application does not modify the parts that call the database access process, but the database access process converts the database access to access the new normalized tables.

Overview of the policy to redesign the database only

The disadvantage of this approach is that the risk of performance degradation is very high. While legacy systems tend to throw one query per record, the RDB (relational database) used in the next system tends to deteriorate as the number of queries issued increases, so there is a significant performance degradation when there is database access processing in the loop processing. In addition, the performance of the current table and the next table will be significantly degraded. In addition, the larger the difference between the current table and the next table, the larger the scale of the conversion process, resulting in response delays due to the conversion process and increased development costs.
The advantage of this method is that the tables are normalized, which improves data usability. However, it has significant disadvantages, so if there is no prospect of avoiding performance degradation and increased development costs for the conversion process, it is safe to avoid selecting this method.

When redesigning both the application and database

The third option is to redesign both the application and the database. Redesigning both the application and the database involves normalizing and partitioning the database, and then partitioning the application into subsystems so that it is one function and one table update at a time, with the ultimate goal of achieving loose coupling.

Overview of the policy to redesign both the application and the database

The advantage of this approach is that it is more loosely coupled by revising the structure to update only one subsystem per table. It also increases functional cohesion, making it easier to replace method calls with Web APIs. It also normalizes the database, which improves data utilization.

The disadvantage of this method is that the business specifications change as the database structure changes, so the design must be redesigned from scratch, which is costly. Also, it should be noted that database migration is required in conjunction with database changes, which makes gradual migration difficult and development time large.

Also, attention must be paid to the feasibility of subsystem partitioning. Particular attention should be paid in terms of transaction boundaries. Generally, transaction boundaries are not set across subsystems. Therefore, if a process that is currently updated in one transaction is divided into multiple subsystems and the transaction boundaries are separated, it is necessary to conduct a thorough feasibility study to determine whether the specification change is acceptable and, if not, what design changes should be made. If not, what design changes will be made?

Summary

In rebuild development, we introduced three different rebuild methods: application-only redesign, database-only redesign, and both application and database redesign, and the characteristics, advantages, and disadvantages of each.

NTT DATA offers consulting services^*2 that provide development roadmap formulation and cost-effectiveness calculations based on evidence, and will continue to contribute to customers' DX promotion by proposing optimal development methods in response to customers' issues such as inability to envision what IT should be, inability to improve maintenance costs, and so on. We will continue to contribute to the promotion of DX for our customers.

• *2 Application Development & Management