How to build on old IT systems

[Rss Bot 1]

'Oh, that'll take months to replace.' 'We can't touch that… [in a whisper]... we really don't know what it does, let alone how it works.' I've lost track of the number of times clients have said these kinds of things to me. But all is not lost. You can innovate with your existing tech solutions; you don't have to throw everything away and start from scratch.

• Web design automation: tune up your design process

Imagine this scenario – quite a few years ago, a factory created piecemeal systems to support its internal functions, such as finance, manufacturing, dispatch, marketing and dealing with visitors. As customers' expectations have grown, its website has not been kept in check. Now more than half of the business's traffic comes from mobile or small-screen devices but the website does not properly adapt. 

And the IT solutions are all glued together but still work in silos, similar to the physical teams – making it almost impossible for them to all serve the same customer. This means that five, 10 or 20 years down the road, the business' IT systems and lack of attention to responsive web design are now inhibiting its growth.

It is possible to build something out of old ruins

So how do you adapt? Use the same principles you take while refurbishing a building. Think about when you've walked into a meeting room that has just undergone an almost overnight refresh. You are startled and pleased by the instant transformation but if you think about it, you know the building itself has all the same structure, heating, water and electricity.   

A plasterboard stud partition can hide a whole load of history and messy plumbing, cabling and ducting. Look a bit closer and you will see the same services but modernised with the help of now-universal sockets. The meeting room now has things such as USB power sources, VGA and HDMI ports for displays. However, behind the scenes, they all feed into the same tangled mess of electrical cables.

We can take this same approach to old IT systems. The goal would be to connect these systems so that we can deliver a seamless user experience across channels. But what could be some of the challenges working with legacy systems? Let's take a look at some of the hurdles that you might face along the way.

• Duplicate customer information: multiple instances of the same individual could exist across different systems such as finance, web, visitor marketing or dispatch. In our fictitious example, there would be six different versions of the same customer across the six different systems.
• Depth of data: systems hold information in different ways and to different depths. For example, the operational side of business will often use code numbers for products with the shortest of English descriptions and contain data about things like composition, source of materials and weight. Conversely, marketing material tends to contain copious amounts of text to advertise the features of the product, in addition to including images and consumer pricing.
• Different methods of exporting data: in this case you might find some systems will only offer a data export, while others use a 20-year-old standard like SOAP or others use a modern interface like REST.
• Interface: some of these systems may have no web interface. Even if they do have one, it may fail to meet accessibility standards or adapt to mobile devices, let alone look consistent from a brand experience.
• New channels: there is no way to deliver a service to a new channel such as a Chatbot. 
• Scale: some systems will be designed to service a small number of users, while others will be designed to be used at internet scale.
• Reliability: depending on how they were built, some of these systems may not be reliable or even available all of the time.

Build modern facades to legacy systems

A lick of fresh paint can make the world of difference

To build a modern web or mobile experience for a business that will better stand the test of time, we look for the frontend to concern itself only in the experience, adapting to the medium the user chooses. The frontend should be flexible enough to be composed of multiple independent functions.

In building refurbishment, we put up new plasterboard and paint the walls, while the superstructure, electricity supply and plumbing behind the scenes stay the same. We can follow the same approach for breathing new life out of your old IT systems: we can put up a new facade that connects to the back-end functions like product data or order management.

Overcome technical complexity

Despite the seemingly insurmountable barriers to accessing monolithic old systems, there are still ways that enable you to create clean connections between the backend and the modern frontend. Picture that faceplate that exposes the modern meeting room sockets we require: HDMI, USB, etc – this is what you need to overlay over your 'legacy' systems.  

We call these APIs (Application Programming Interfaces). The importance of APIs as a concept cannot be overstated. One of the factors in the success of Twitter, for example, is that it launched its platform along with an API and openly encouraged developers to create rival frontends or apps with the ability to tweet directly from developers' own products.  

Your organisation, like the factory, should be creating APIs like product API, order API and account API. Initially, these APIs would be for internal use (but a bold organisation will make them available to outside parties).

Design API contacts

The design of the API is the most critical phase – your stakeholders need to consider what information would be needed for all cases and ensure the API is scoped to deliver it (this is called an API contract). This can then be filtered so that a consumer won't see all of the manufacturing data and instead only receive the information they need.

Implement APIs

Apigee can help implement API

With the APIs decided upon, it's then about implementing the API and retrieving the data from the one or more underlying systems. This is often the hardest part of the process but there is a wealth of software ready to assist with this, for example Apigee and IBM DataPower. Some other software options, while still being enterprise-grade, are free to use, such as WSO2's API Gateway and WSO2 ESB. These tools are capable of translating between SOAP to REST, file-based transfer (exports), handling concurrency, caching results and transforming them. That alone ticks several of the requirements we've already covered.

Once the API contracts are approved, you can start building new services – such as an Alexa skill or an order-tracking app – upon them. You'd will no doubt expect multiple consumers to access the same API; a mobile app, Chatbot or website would all need access to the product API, for example. A separate part of the website would give access to authorised users for historic orders via the order API and so on.

If the original backend doesn't offer a function to, say, issue a tweet or send a mobile phone notification, then a new function can be added to the API. If you want to add a new website function, app or new channel to market, just set these up as new consumers to your APIs. And you can be sure there will be new consumers: social media applications, Alexa skills or AI Bots. Whatever is next around the corner.

Working with legacy technology is similar to refurbishing an old building. The general idea is not to throw out your legacy IT systems but merely wire them into a new API – transforming data along the way as necessary – to give them new life.

Illustration: Kym Winters

This article was originally published in issue 308 of net, the world's best-selling magazine for web designers and developers. Buy issue 308 here or subscribe here.

Related articles:

• 10 tips for better testing
• The web designer's guide to Flexbox
• UX for emerging experiences

View the full article