An introduction to our enterprise architecture team and their legacy challenges

Within the team of enterprise architects, we see that many companies have to face the same challenges when it comes to managing their application landscape. Many of these landscapes consist of a wide variety of COTS (common-of-the-shelf) solutions, custom-developed business applications, various integration systems, data and communication systems, etc. many of which can be categorized as legacy systems.

At Archers, we see our clients trying to deliver new business functionalities, building on top of old systems and external packages, and being constrained by budgets, outdated technologies, limited integration possibilities, etc. Legacy systems within our client’s application landscape are a huge blocking point for IT teams that are involved in building new business applications, introducing new technologies or integrating COTS solutions, etc.

As architects we have an important task in managing these brownfield architecture landscapes within companies, so we better have a good understanding of what legacy systems are and how we can avoid creating them for the future.

Although the term is widely used, it is difficult to clearly define what legacy systems are exactly. In contrast, we should also have an understanding of what non-legacy systems are, and this is probably an even more challenging task.

A common reflex is to define legacy systems as systems based on old or outdated technologies are difficult to replace. They are still in wide use and as such, most critical to day-to-day operations. In practice, it is often easier to understand and identify legacy systems based on the issues that arise related to these systems.

Common characteristics of legacy systems:

• hard to maintain, improve and expand as it requires a high cost, effort and expertise;
• general lack of understanding of the system, without proper documentation and easy to understand structure or design;
• the growing complexity and technical debt, due to design and architecture decisions, implementation choices and not following common or accepted/best practices;
• written in legacy code without proper testing;
• alarming shortage of available workforce and expertise within the market;
• security vulnerabilities due to old and not upgraded components;
• operational risks, with an enormous loss of capability or business continuity if the legacy system were to fail;
• limited integrations within the overall application landscape,
• limited possibilities for integrating with new technologies (e.g. REST, SOAP, messaging, OAuth, …);
• backward compatibility;
• no clear roadmap for upgrades, replacements, migrations, or nonexistent entirely

In contrast, we would define non-legacy systems with the following characteristics:

• based on new, proven and future-proof technologies and standards;
• easy to replace/upgrade/migrate, which also should apply to dependent system components (e.g. infrastructure);
• easy to integrate within the overall application landscape, based on open or accepted market standards;
• with good up-to-date documentation and available expertise in the market;
• low complexity (modular, easy to understand, easy to modify, common practices and no customizations) and sufficient testing to guarantee correct functioning;
• and less critical to day-to-day operations, with a reduced security risk as they are less dependent on old technologies, infrastructures, etc. and apply the most recent security measures.

From our experience, we see clients giving insufficient priority to the necessary technology evolution, upgrades and application refactoring. Short-term quick fixes are chosen over long-term architectural solutions, resulting in increased technical debt. Most existing systems are becoming a burden to continued operation because cross-dependencies have grown with other systems which creates the need to evolve and upgrade those dependent systems accordingly. However, the cost and impact this generates on business operations become a hurdle for many IT managers and it prevents them to take action. As architects, it is our conviction that we should evaluate and detect the creation of legacy components as early as possible, for which we want to propose the use of clear guidelines and architecture principles.