An introduction to our enterprise architecture team and their legacy challenges
Enterprise Architecture

At Archers, we tackle challenges that different organizations are facing, such as budget constraints, outdated technologies and limited integration possibilities. Before we move on to other important parts such as the 8 principles for (non-)legacy systems, we’d like to highlight the main characteristics of those systems first. This way, we’ll take you on a journey of our business story and our way of working.

Within Cronos Group, Archers is part of Integr8 Consulting (i8c). Archers is specialized in integration architecture, in which we offer services in the field of API management, service architecture & design, microservices, and architecture strategy and roadmap. In the previously mentioned domains, our team of integration and enterprise architects take action and support multiple clients in improving their application and integration landscape. With a focus on integration challenges, we help them build their architecture practice. Although in this blog, we’d like to explain the work of our enterprise architects in the context of legacy.

Legacy challenges for our Enterprise Architects team

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.

Understanding (non-)legacy systems

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.

Clear guidelines

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.


So we gave our understanding of what legacy and, in contrast, non-legacy systems are, in order to get a grip on the problems that architects (and others within the IT organization) face when managing the application landscapes of an organization. Conclusion: it’s not necessarily the newest technologies that help to avoid the creation of legacy systems. Non-legacy systems are mostly determined by the use of future-proof technologies and standards, and the ease of understanding, maintaining, upgrading and changing the system over a longer period.

If you enjoyed this post, please share your insights or feedback on the elements we discussed in this blog! We’d be happy to see any use of our proposed architecture principles in your architecture work to build great non-legacy systems for the future of your organization!


We’ll be happy to get to know you.