Legacy Systems Aging Risk

Claudio Dobniewski

By the simple passage of time, everything ages.

We call legacy systems (or legacy) ones that have achieved a relative degree of success, but that are difficult to maintain because the knowledge that would allow their maintenance is lost. Having fallen into this category may be due to one or more of the following reasons:

  • They have been developed by work teams that no longer work on it.
  • There are no acceptance tests or techniques to test how the code works or understand how it works.
  • They have little functional, technical, or user documentation.
  • Many features are unknown by developers and users.
  • They maintain a large volume of technical debt that prevents them from testing and understanding them. 

 We will call them monolithic systems those whose modules cannot be deployed and run independently. These systems continuously increase the size of their applications, the applications steadily increase their complexity and size, and their development, testing, and deployment speed decrease.

Peter Naur argues that programming is to build knowledge. If a product no longer has the equipment that had the knowledge that it represents, the program must be considered dead, so that we must face it is a process of ‘resurrection.’

The software, its hardware, and the context in which it was designed, implemented, and used undergo changes over time, as well as the people involved in the different aspects of the project. For its cost, we try to maximize the use of resources (CPU, memory, data transmission). On the other hand, due to its critical aspect, its stability is prioritized.

Anyone who has been in contact with a so-called “legacy” or “inherited” project will feel in retrospect as a time traveler, who sees how quickly projects on this software are born and die. Some are reaching the final objective, others remaining truncated before that, allowing you to appreciate that the project continues, with few changes in general in inverse proportion to its size and complexity. The people involved change completely in a short period (a few years). Usually, very few people, who have actively worked on the project at some previous stage, remain in the organization.

Here are the difficulties, which eventually become threats, that increase the risks, and extend the gap towards the solution/evolution you need to lower your costs/risks:

  1. Hardware obsolescence (maintenance, updates, performance, expert staff)
  2. OS obsolescence (EOL, updates, critical fixes, new features)
  3. Language obsolescence (EOL, security fixes, new features and fixes, dependency improvements/installation modules and plugins, internal performance)
  4. Obsolescence of plugins and framework/language dependencies (no more updates, disruptive changes for current versions of the language or framework due to the number of intermediate versions over the years)
  5. Paradigm changes, disruptive (PaaS, IaaS, SaaS)
  6. High code coupling limits functional testing, integrative BD is complex and expensive in time to have for testing
  7. Unit testing limited by code coupling and non-use of the “dependency injection” pattern
  8. Low and outdated development documentation
  9. Functional documentation (business logic) limited and outdated
  10. Knowledge of software and centralized business logic in a few people
  11. Rotation of people involved in the project over time

These topics have a different impact on the continuity, risk, and cost of these projects and their possibility of modernization.

For example, point F implies a higher cost (staff-hours) of manual or semi-automated tests (this excludes CI processes) vs. increased uncertainty of effects on the rest of the code. Point B and C imply that customers, who currently migrated to the cloud or are planning to do so (in any of their SaaS, PaaS, IaaS modalities), require that the software and infrastructure and suppliers comply with the computer security audits, deployment conditions, scalability, and operation. But an OS or language that reached its EOL will not have security patches for issues discovered after the EOL. Then instead of applying an update on the OS or moving to a larger version of bugfixing, we must now plan an upgrade of the whole system because the requirements of a component (newer libraries, kernel, even hardware) drag the entire set when the software is older.

No doubt considered state-of-the-art in their day, the continued use of such legacy systems, often large and cumbersome IT infrastructure, makes it increasingly difficult for FIs to meet the stringent demands of customers, regulators, and other stakeholders. Exacerbating the situation is the contention that an estimated 70 percent of corporate business systems today are legacy applications with limited functionality and usability.  (4)

It is estimated that 60% of the IT budget is spent on maintaining legacy systems. (5)

Graph 1 – degree of uncertainty and higher costs over time.

 

From the moment of its birth, a system has associated costs and risks, according to the design decisions, quality of the organization/team’s processes, and experience. These conditions may vary throughout the system’s life, but it’s a basis that we always find.

Hardware obsolescence can be accumulated over the years, which can be anticipated. A maintenance window is scheduled to replace with more convenient and controlled hardware, or simply a hardware failure can occur and force us to carry the system on more modern hardware. In addition to the cost involved and risks of service drop, the existence of services compiled and configured for 32 bits, can complicate the task, but decide on the fly that it is a good time to move to 64-bit architecture, without the backing of work previous necessary, increase costs and also risks.

Eventually, about OS and software in general, there will be new features, security patches, and bug fixing that we need on our platform… but releases for our software are no longer generated. It will be more expensive to apply, or simply unfeasible, leaving us with security vulnerabilities, bugs without a solution, and not accessing functionalities that could be both operational and strategic critical.

Legacy Systems
Graph 2 – Red Hat Enterprise releases timeline

 

Redhat offers support for around ten years by RHEL version.(6)

On the one hand, a “long” support gives us security on the platform on which we mount our system. But, if we do not see beyond, the moment when the support ends will come inevitably, and as time passes, the greater the gap between the system’s characteristics and state of the art.

Migrating a system, or part of it, to the cloud changes how the system is deployed and operates, how its components interact, and how they scale.

The more “old” our system is in any of its aspects, the more difficult it is to update it, and get further away from adapting or carrying it.

Some practical aspects are (7):

  • Launching and rewriting the code/project is not profitable (economic restriction)
  • In general, customers are not willing to expect the development of a new system without continuing to require changes to the previous one (continuity).
  • The approach of some authors, who argue that, since what we have to understand is observable behavior, we should resort to user manuals and programmatic interface documentation (API), we see it as risky. One of the usual documentation problems that have survived separated from the code for a long time is that it is outdated or not synchronized with the code. Therefore, it is dangerous to take documentation for granted, knowing that the system works well and that what works is represented in the code, not necessarily in the documents (documentation maintenance)
  • The unit-based approach, or at most components, is not entirely satisfactory either. We need to know what the user expects from the system, and for this the most appropriate tests are acceptance. On the other hand, in the case of legacy software, although we know that the system as a whole fulfills its function satisfactorily, we cannot say the same for each piece of code and the particular implementations of functionalities, which is what the unit and component tests. That is why we need evidence that demonstrates the behavior from the perspective of real user interactions (agnostic regarding use)
  • The organization’s culture is a critical aspect and directly affects the processes and their results in the organization. To obtain changes in processes, culture must be changed, and this is always progressive. (9)

There are strategies to deal with these problems (8). There is a lot of material available, but there are no magic solutions. They all have a cost in resources and risks.

As time goes by, the problem worsens and results in the deadlines being put by customers or suppliers. The clients’ technical area will eventually be concerned with the continuity of operations, the security and the cost, and the cost and ability to introduce new features or modifications that the business requires. Suppliers will eventually cease support on products or services that have completed their programmed life cycle, passing (as seen in the graph) a stable level of cost/risk, initiating an increase in them that will always be increasing.

Who does not initiate the change in the part of the plateau on a scheduled basis, must face the force in the stage of increase.

References

 

You may also like

No results found.

Menu