The IT architecture of the future is here

One of the biggest impediments to accelerating pace of innovation is that older legacy systems are not geared to becoming part of a modern, scalable, and digital omnichannel solution. Legacy systems have a raison d’être but cannot become a bottleneck that prevents a business from adapting to increased requirements for digitalisation and pace of innovation.

Many businesses have legacy systems that can be almost impossible to replace. They are often systems that are key to the business, as they were developed in the infancy of digitalisation in the 1990s (or even earlier!). Back in the days when using technology to replace and perform routine key tasks was essential. The main task of legacy systems is often the same nowadays, but the surrounding landscape has changed, and much of it has become plastered with a patchwork of solutions that try to use data in these legacy systems or ensure that the data can be extracted.

Such legacy systems were never designed to be scaled in line with digital business becoming more and more extensive. They can therefore form a bottleneck to innovation and represent a growing degree of technical debt for businesses.

Microservice as an IT architecture principle represents a break with traditional development, in which monoliths and multiple integrations were part of hard connections between integration points.

A microservice architecture seeks to obviate the problem of businesses not knowing what they will build in the future. Microservice architecture can help businesses build on their existing system landscape. A microservice architecture is designed to ensure that businesses do not build in silos, nor fail to exploit years of investment in an existing application landscape.

By definition, microservices are decoupled from each other and operate as independent units. You cannot point at a microservice and say “that’s the application” – as the application is a product of the interaction between the various microservices. A microservice must be a business process that the business will reuse in various contexts. Microservices have their own processes and can interact. By incorporating business applications and core applications into a microservice architecture, scaling is ensured without it being necessary to replace what are often highly specialised legacy systems.

Legacy systems are often logically decoupled from the systems that handle transactions, leads and orders via the various channels of the business in a microservice architecture.

In this way, a microservice architecture can ensure that data to and from legacy and core systems can be used in the customer-oriented channels (B2C and B2B), and that administrative applications or business applications can use business data to optimise working methods (B2E).

Narrow microservices can be established on legacy systems in a microservice architecture, each of which handles an independent service providing a business capability. By making such narrow business-borne services key to what the channels provide from core and legacy systems, pace of innovation can be accelerated with a microservice architecture.

The business will then find that its legacy systems can be scaled in line with its need to provide good customer-oriented solutions.

By superimposing a microservice architecture on legacy systems, businesses can prevent their legacy systems from becoming bottlenecks. One of the most effective means that businesses can use to accelerate a microservice architecture is cloud-based queue systems. Decoupling between microservice and legacy systems can be achieved by sending messages to a cloud-based queue system instead of microservices calling the legacy system directly. This can be done by using Microsoft service bus or AWS SQS as a ‘load-levelling queue’.

To avoid bottlenecks, businesses can use the ‘queue workers’ principle. Messages from the queue are handled by sending them to the legacy system at a rate it can process.

This is merely one example of how cloud services can be used to handle a relatively well-known phenomenon: that legacy systems are a bottleneck for innovation, and that no allowance has been made in many legacy systems for the speed and data volumes that IT systems now require.

This principle illustrates how to utilise cloud service to enhance pace of innovation in its effort to bring core- and legacy systems into play when working with digitalisation. It also solves the potential issue that the legacy systems can be overloaded.

When businesses go from having a monolith to a microservice architecture, problems arise concerning observability.

Because the application now consists of many small services capable of communicating with each other, getting an overall picture of the status of the components becomes a problem. The same can be said about being able to trace a request down through all the services, and obtaining a picture of how the individual services are performing, or to see a report on response times for individual calls in the entire flow.

This is where the services AWS X-Ray, CloudWatch or Azure Application Insights can be used. These cloud services allow you to concentrate all your telemetry and logs in one place, making it possible to create an overview of all your microservices and systems. Monitoring and reporting are included without having to build them from scratch.

There are several cloud-based monitoring and reporting tools that can improve your ability to incorporate legacy systems packed in a microservice architecture for good customer solutions. You can obtain details on performance, API calls, number of transactions that went well/badly etc., and which can be used to further optimise your platforms and accelerate innovation.