Poor digital business support

The function of a software system is to support business. Some systems do the job better than others. By definition, a functional system will meet the needs of business. But it doesn’t bode well if your business is stacking up on overtime to meet the needs of your system. There are multiple drivers that explain why a business might consider technology modernisation. The starting point in every case is a systematic analysis of the legacy components in the system (see Legacy Systems Assessment).

Data means digital

Digital business is reliant on supplying customers with huge volumes of data and in multiple formats. Customers require immediate, online and personalised access to data. That means self-care zones, customer portals and 24/7 service. As well as providing omnichannel capabilities, digital business also needs to collect and store as much information as possible. As we’ve already learned in Legacy Systems Modernisation, the key to resolving issues with a non-agile system is to identify the friction points and work from there. Because a legacy system is typically business-critical, the essential data needed is usually entirely available. The problem is this information is often:

1. Stored in an impractical format (file interface vs. REST or GraphQL)
2. Not readily accessible (e.g. due to overnight batch processing) or
3. Completely invisible to the outside world (often having no interface whatsoever).

Thankfully, transitioning through these complex challenges is made easier with the following straightforward solution.

Stabilise with an API proxy

One of the best practices of applied software engineering is to set up an API proxy (or mediation layer) as described below:

The API proxy provides a contract-based modern interface for any application that needs to access the system. In other words, it acts as a go-between, hiding all the complexity while enhancing connectivity to the system. Of course, these interfaces don’t act independently and require other supporting technologies such as ESBs, message queues and caches to stabilise operational flow.

And because outer services linked to a well-defined API are isolated by the mediation layer, the monolith behind the proxy can be slowly transformed or “strangled” behind the scenes (see Strangler Fig. Application). So, for any business looking to refactor or rearchitect an obsolete system, establishing an API proxy is a recommended first step on the way to leveraging new functionalities.