Legacy Systems are the products of their time. The simple fact that they are our problem now means they achieved their goal: lived and served long enough to get old. Not every system has that opportunity. That’s why we always should treat them with deserved respect, even if the only thing that we can offer them is to replace them now.
Using the example of a significant project at a market-leading retail customer, we shed light on several aspects involved in digitally transforming an enterprise environment.
100 years in business
Our customer — we’ll call them “RetailGiant” — has been running a successful business for over a century. They had already recognized the benefits and the market leadership through digitalization in the early 1980s and hosted their applications on the most modern IBM mainframes of that time. Many innovation projects were started on this platform, but unluckily, some of them had disastrous results.
Unfortunately, their troubles didn’t stop, because keeping mainframe-based application systems up to date is costly. Additionally, new systems were regularly integrated through acquisitions, leading to complex dependencies that made maintenance almost impossible. They had to act.
Then in the 1990s and 2000s, new competitors had the advantage of being able to start on a technological greenfield. They had no ballast of obsolete technologies, had easier access to state-of-the-art technologies with faster implementation of new ideas, new functionality, and flexible reaction to demanding customer requirements. But unlike the competition, RetailGiant used a functioning system landscape that helped the company to earn their bread daily.
At the beginning of our project, it quickly became clear that a lot of time had to be invested in the initial analysis so as not to drown in a digital adventure. After the initial research, the decision was made to take a step-by-step approach to enrich every department’s daily work with digital added value.
“Quick and dirty” doesn’t work
Prior to our working together, the team was urged to simply transfer the old code into a new, more powerful one. However, this has nothing to do with “digital transformation”, in which faster software is only one aspect. Doing this is like trying to force a horse to run faster when what you really need is a car.
Instead, one must first consider the business model as a whole, and only then consider the transformation of the individual business processes. The technology is secondary. This is the only way to create a reliable decision-making basis for design and implementation, leading to a flexible, expandable, and well-scaling system. This is a lesson for all team members.
From one generation to the next – a first success
One of the transformation project goals was to restore the innovative strength that our RetailGiant had lost. We started with an important domain in retail: location management. The relationships between the stores and the warehouses or distribution centers are constantly changing. Because of the growth of the system, there was no “master data source” that reflected the truth for these circumstances, which often led to costly inconsistencies.
Therefore, at an early stage, a master data source was set up in the new system and various legacy data sources were well-integrated. Since the legacy systems needed to continue to run, we split this project cornerstone into two phases. First, we manually replicated the existing Lotus/IBM Notes database, and in the next phase we defined two simultaneous processes for data integration:
- Creation of the new “master data source,” covering all non-functional requirements that are to be provided in the new cloud environment — what we dubbed the “Strategic Solution.”
- Implementation of a technical process that enables older consumers to absorb data from the Strategic Solution.
After the new system proved its worth, Lotus Notes was retired.
Before we began the process, we thought carefully about how deeply and extensively the existing system had to be cut. And then during the layer-by-layer redevelopment of the application landscape, we worked like surgeons, using a fine scalpel on an open heart. During this time we kept a constant eye on the patient — the ongoing business — to ensure its health.
Mapping unknown lands
Due to the nature of how software systems used to be created, legacy systems often present themselves as a jumble of architecture and functionality. As a result, it’s difficult to assess the scope of a transformation and the amount of work that needs to be done in advance. For situations like this, precise scoping is impossible.! In piecemeal legacy systems, relationships between the components often cannot be seen through in every detail. In particular, this applies to dependencies on external applications and services. It’s also often unclear whether certain system components are still relevant.
However, a complete and precise picture of the legacy system is exactly what’s needed for a successful transformation. As a result, one of the main challenges we had to deal with were the many system layers that had grown over the years in RetailGiant’s old infrastructure.
Analyzing how all the components are interwoven from both a technical and a business perspective was critical to the success of the mission. During the analysis process, the system architect slipped into different roles:
- Archaeologist: Patiently observing the behaviour of the old system over a long period of time. Historical documentation? Not useful in a system that has been neglected for decades.
- Criminologist: Ongoing conversations with developers, users, supporters, and opponents of the legacy system. This process is usually more informative than any documentation, and hidden cross-references become clear.
- Philosopher: As an external person looking at the system with fresh eyes, one is detached from a “we-have-always-done-it-this-way” view. The question “why” is easier to ask.
A flexible, scalable & resilient result
In the end, we have successfully created a master data source for RetailGiant, which meets their current and future flexibility and scalability requirements. Older data structures are also supported by efficient isolation measures. In this way, our customer was able to guarantee complete consistency of their production systems for the first time.
Our new system went into production three years ago with three internal users at <10 transactions per second (tps). Today, over 100 user groups are using the new applications. At peak times, hundreds of tps are handled entirely stress-free.
Additionally, thanks to the resilient system architecture, the applications also run with 99.99% availability.
The project’s technology was specified as follows:
- Cloud-native system design
- Real-time capability
- High resilience, performance and scalability
- REST / GraphQL API
- Reactive system architecture (reactivemanifesto.org)