Application Modernisation through API Gateways

Application Modernisation through API Gateways

The vast majority of organisations have an endearing investment in legacy applications, and due to architectural limitations, are finding that it is increasingly difficult to integrate these legacy applications with modern “born in the web” systems.

Developed in 1998, SOAP (Simple Object Access Protocol) is an XML-based protocol that was used heavily by applications from that era (2000’s). SOAP specified a language and mechanism for the exchange of structured information when integrating applications. The verbosity of the protocol, slow parsing speed of XML, and lack of a standardised interaction model led to the eventual demise of SOAP in favour of the more flexible REST (Representational State Transfer) API framework, which is simpler, performs better, and is more scalable, portable and reliable.

In most cases legacy apps are deeply entangled with other applications and deeply engrained in business processes. These are the applications that are holding organisations back from realising their strategy to move to a micro-service/cloud-based/digital-first architecture, and are therefore holding the whole organisation back, or worse, making it lose market share.

By way of an example; you may want to start using Salesforce to manage your customer relationships. Having made a sale to your customer, you need to send them an invoice. This is easily achieved with Salesforce, but you need to deal with the financial elements of the invoice and the receipt in your legacy accounting or ERP system. You could create the customer data in the legacy system and then invoice from there, but this means maintaining your customer master data in two systems. The invoice will probably look different to the other correspondence generated from Salesforce, which will not please your branding and marketing people. Somehow you also need to push the receipting data into the legacy system to show that the invoice was paid.

There is clearly a need to integrate with your on-premises legacy system to pull billing data out and push receipting data back in. Your legacy system is only capable of integration via SOAP, so how can you connect a modern, cloud-based application like Salesforce to it? Bring in the developers and start writing some hefty cheques (not forgetting that any development of the SOAP services will only be a tactical spend).

SOAP services are difficult to consume for developers working with web and mobile applications; the older legacy applications were never really designed for integration via the web, so SOAP services were not designed for public consumption. The architecture was designed for internal use, and crafting a valid call to a SOAP service can be complicated.

Migrating to a modern application with the capability of providing RESTful APIs so that newer applications can consume data or services may well be/seem impossible, or a long way off (i.e. expensive).

As part of our Application Modernisation service, Emerging Technology Partners have developed a solution that provides a RESTful API in front of your existing legacy applications’ SOAP service. This means that you can leave your legacy app in place (for now), continue to implement your micro-service/cloud/digital-first strategy and consume data and services from the legacy app using a RESTful call.

Continuing the Salesforce-legacy app example, we can provide a RESTful API for the legacy apps’ SOAP web service. So now you can connect to it from Salesforce with significantly less developer effort using Salesforce’s in-built RESTful client to retrieve the billing data. Now you can provide your customer with an invoice straight from Salesforce. This approach also allows you to migrate off the legacy system without redeveloping the integration from Salesforce – or swap from Salesforce to SugarCRM without the need to have developers build an integration to the legacy system all over again.

The ETP solution is deployed as a software based, inline proxy/gateway virtual appliance, and other than the initial deployment charge, is billed based on the number of API transactions per month; this unique billing model means that there is very little committed investment to modernise your legacy application, and charges only start to apply once usage of the gateway increases.

In summary, if you have a legacy application, which only has SOAP services for integration, and if you need to consume its data or services from newer web or mobile apps, talk to Emerging Technology Partners about emerging technologies that can unlock the potential in a very cost-effective way.