Integrating legacy systems with new software, services and systems
Overview
Over time, organizations invest a lot of money and other resources into their existing software systems. But things move forward, new business needs appear, new technologies arise, development and support personnel change positions and companies, and so on.
To survive and remain competitive, it is often necessary to develop or acquire new software, while preserving the invested value and people’s expertise in using the existing one. How to do it in the right way, how not to waste time and money while achieving the set goal, how to keep key people happy and engaged – these and others are substantial pains companies face when deciding on the most appropriate way to protect their existing investments and at the same time to move forward.
In this article, we want to analyze different aspects of integrating with a legacy system from technological and human-related perspectives. Let’s have a look at what a software system is, on which levels it can be interfaced and reused, and how to approach this technologically. Last but not least, let’s touch base on the sensitive point of how to deal with the human factors associated with the move.
Architectural analysis of a software system
To structure our discussion and break down the integration possibilities, let’s take a look at this simplified diagram of a typical software system:
System User
This is a person interacting with the software system via its user-facing screens and user interfaces.
In cases when we have a non-human-interactive software system, where software performs some functions, but does not provide a user interface for organizational personnel to use on a daily basis, then this element can be skipped.
It means that if we want these users to keep being happy when moving to another software service, we have to take into account their usual interactions – both visual elements and processes. Thus, it must be part of this analysis and future efforts for introducing a new system into the organization or business.
Application Frontend
Now, there is a curious piece. Most integrators do not dare consider it, but there are ways of reusing old user interfaces when moving over to a new system.
Today, most of the applications are written in such a way that users interact with them via their Internet browsers: Chrome, Safari, Microsoft Edge, Firefox, etc. And the curious thing about the modern browsers is that they are scriptable, which means that one can develop a plugin, let’s say using the Javascript language, which would allow hosting the legacy system user interface in an iframe, while automatically scripting it to simulate end-user behavior without a human presence.
To visualize how it would work, let’s look at this diagram:
In this diagram, on the top, we see the hidden automation agent, which loads the legacy system interface into the internal browser and then uses browser scripting capabilities to affect the user elements and invoke different user actions, like clicking buttons, etc.
Effectively, what we can achieve is simulating end-user actions on the legacy system user interface to get the desired output or affect the underlying legacy data, so it can be used by other pieces of the new software (we will consider this in more detail later in this article).
One additional point is, that in the new system, we could directly embed legacy system interfaces, into our new workflow, again using the great integrability of Internet browsers. So a human user could simultaneously interact with the old system as well as utilize the new software enhanced capabilities.
Application Servers
Now, we’ve approached the heart of any system – here sits the software, which receives input requests and data, here resides the computing logic, and from here the output can be either received back by the requester or data can be stored in some kind of data storage. This will be discussed below.
Companies pay the biggest amounts for implementing their business processes within this computing logic and for the ability to ask requests and get back responses and data.
In the majority of cases, such application servers know how to interact with some kind of an API interface, which, among others might involve:
- Authentication of the requester with a username, password, and certificates, or even multi-factor authentication which includes biometry
- Adhering to specific data formats, proprietary or open, like XML, JSON, and others.
Some API calls might come only after others have been made, preventing out-of-sequence free invocation in order to avoid data corruption of unauthorized usage.
All in all, the main point here is that those APIs can be reused by the newly integrated software. What usually is required is:
- Knowledge and understanding of the legacy APIs, what they do, how to access them, security measures involved, etc. It might require having or obtaining the relevant documentation, and, optionally, having or hiring a relevant specialist, who can give the missing answers to these questions.
- An ability to actually develop against these APIs in some kind of an integration environment and have the legacy system open to such integration. It can involve opening the relevant Network Firewalls, providing the endpoint Internet address and security means, and finally an ability to check the logs in order to resolve any problems with developing the integration software code.
In the end, walking this path is the surest way for integrating with the legacy system in a healthy and manageable way, without risking breaking something or becoming dependent on underlying changes, like changes in UI or a data storage structure, which do not assume such external access and usage.
Data Storage
As a final measure, we should not forget that most systems store their data in some kind of persistent storage, one or many, be it a Database or a File Storage.
Having knowledge of the internal database structure, schemas, tables, columns, etc, or folders structure where files of interest are kept, can provide a leeway into an otherwise closed system to gain insights into the business outcomes, generated or managed by this legacy system.
This path has a lot of risks, as, if the legacy system is still alive, the structure and format of the data might change without any prior notice, making it critical to closely track any software updates and integration errors.
Pros and cons of going for the integration vs rewriting from scratch
When organizations know some primary possibilities of accessing the functionality and data of the legacy system, many of them have even a bigger question: Should we invest in preserving the older software, or is it better to fully rewrite or completely migrate to a new one?
As usual, there is no “one fits all” decision here.
We would fully agree that from many perspectives, it is considered easier and more appealing to rewrite an old system. But only those who undertook this path would know what it entails:
- Full analysis of the legacy system data and flows by someone who actually knows it.
- Complex migration of the old data to the new system, which includes mapping of data and processes, possibly complex conversion between data formats and storage, and even loss of some data.
- The necessity to stop using an old, familiar system and to move to a new, unfamiliar one.
- Potential loss of “forgotten” critical business data, including historical “memory” of the organization.
- Time that is necessary for covering all the areas the legacy system.
- Possible misimplementation, functional gaps, fixes, and other pains of bridging new software to serve a running organization.
Taking this into account, it is wise to closely analyze the situation in order to be able to estimate the efforts involved in both paths:
- Completely rewriting or installing a new system with the most probable migration of the old data to the new system.
- Partial and gradual introduction of the new system, while integrating to the old one, to keep utilizing it along the way for getting access to its functionality and data.
People and personal agendas – how to deal with them
The last aspect that we would like to touch on in this article is people. People, in their majority, do not like changes, especially if they themselves are not acknowledged, or consulted, and their opinion was not taken into account.
With that, most people wish all the best to the organization they work at and whose team they belong to.
This means that when a change is to be introduced, it is critical to come to this conclusion together with the people, whom it directly involves – the primary users of the legacy system and future users of the new one.
It is good to run some surveys, discover worries and fears, and understand preferences and existing work arrangements.
Then, take it all into consideration, when making the decision around integration or moving away from the legacy system.
And finally, when it is time to introduce the new one, it is required to take the feelings and the cognitive preferences of its future users into account, to make the transition smoother and the general atmosphere lighter. As a result, you can avoid bad feelings or even loss of key people.
Summary
We do hope that this article opened some practical paths and helped you to better understand the peculiarities of integrating legacy systems with new software, services, and systems. All in all, software and product analysis and discussing things with key stakeholders are the key points that are necessary for coming to the best decisions possible and succeeding with such complex projects.
Organizations and businesses either stop and stagnate or move forward and progress. And if you choose the second option, in today’s technological world it is obligatory to know how to deal with both legacy and new software systems.
by Alexander Stern, senior content contributor at Amberteq
