The challenges of digital transformation and making sure APIs are fit for service

Over the last 18 months, we’ve seen significant acceleration of digital transformation initiatives and while this trend is here to stay, it isn’t without its challenges.

Often this is because consumer expectations have been set by the digital pioneers such as Netflix, Uber and Amazon.  These companies specialise in creating highly intuitive, easy-to-use interactive websites or apps and as a result, consumers are used to this experience. However, when they go to a more traditional organisation - a bank or government-owned entity for example - and processes are still semi-manual or just not intuitive, they switch off.

The digital pioneers have created a frictionless experience which has made life easy for customers. However, it’s a very different environment for enterprise systems, compared to consumer phones and other lifestyle devices.

So how do organisations deliver a similar frictionless experience?

Looking at a traditional enterprise model, i.e., a bank, the customer talks to a teller, presents their ID, and they work with the IT system designed to operate in that bank. Here the customer is expected to adapt to how the bank does business. The system is not designed to interact with the public, it's designed to interact with the organisation’s employees.

Digital pioneer applications and systems adapt to the individual. Uber makes it easy to get a ride. Netflix makes it easy to stream a programme. As a result, customers now expect applications to adapt to them rather than having to adapt to the organisation’s processes. However, the difference here is that employees are a captive audience; they are trained to use these systems.  But, you cannot train a millennial customer or somebody who is on a web browser how to use that app, you don't have the luxury of enabling them to take 30-days training on the app, it must be usable right out of the box.

Here at WSO2 we encourage our customers to view the world through the eyes of their customers and here are a couple of examples where digital transformation was driven by customer needs:

Transport for London (TfL) have a solid plan to improve their services and make commuting safer and better for citizens.  WSO2 is part of one of their projects, called London Works. London Works holds the history of all their works and looks at how it can improve the coordination of road maintenance to cause minimum disruption and therefore deliver a better experience to its citizens.  Another example is Madrid and the Andalucia government. They adopted WSO2 to help implement a platform to deliver services to their citizens during lockdown.  Now, 30% of the citizens in Spain can use the platform to generate new services, so if citizens need a certificate or a passport, they can obtain this through the platform.  This enabled the Spanish government to streamline its processes by as much as 30%.  

To do this, organisations need a back-end-as-a-service for these great GUIs that power systems to be flexible, intuitive, and enable the data to be available when customers need it, and this is where we come in.  However, often companies don’t think about how they are going to externalise their internal systems and just expose them to the web without a thought about how they can be integrated and utilised. The digital pioneers think about this right from the outset. They set up those back-end APIs knowing they want to enable great GUIs and experiences.

Unfortunately, a lot of the first, second and even third generation APIs were designed for developers to build internal systems. Companies have tried to clean these up and make them available to organisations outside the company, but this has merely created security issues, scalability issues, but more importantly, massive usability issues.  This requires a change in mindset and thought process when moving from a proprietary world of closed systems or closely integrated systems out to the worldwide web, where everything must follow the same standard. Beyond that, organisations must put themselves in the shoes of the customer, to make sure they have the right data in the right place at the right time, to make it useful and usable.

It is also hard to build scalability into APIs. When websites first came out, such as eBay, Foursquare and Amazon they had very simple server-based applications. They rapidly gained adoption and some of these companies witnessed huge spikes in demand and websites crashed. So, they had to re-engineer, put in more hardware and software and figure out new load balancing algorithms, caching techniques, and faster data stores. This is ultimately what led to the invention of Cloud Native Computing, to help solve scalability issues where organisations can dynamically add to the basic capability whatever they need, and the system keeps going.

We therefore encourage organisations who are looking to provide great digital experiences to customers to move to cloud native applications in a cloud native infrastructure. The reliability, the scale, the always-on capability, the resiliency, outweigh any downsides.  However, we recognise that often customers, when they first come to cloud, will have had a very varied journey to get there. Some have simply put their systems into virtual machines and uploaded this into the cloud, while others have gone full cloud native right from the start.

The same is true for their APIs. Their APIs may be written with an assumption that there will be a degree of on-premises systems, but over time they need to start to look at a cloud first, API first environment.  Whilst there will still be on-prem and various hybrid environments, organisations want to be able to build and engineer APIs for the cloud and re-engineer their applications to take advantage of micro services to help with scalability, flexibility and reliability. In many cases, digital transformation projects are going to require a new capability, a new service, another way of accessing data than the organisation had before, so they’re going to need to build new functionality to create great services for customers.

To do this, organisations will want to have a cloud native development toolkit, low code, no code templates, cloud native engineering-based integrations, language and syntax that abstracts this and provides the programming model required to make it easy to deploy.

This all requires a huge culture shift which is often difficult to achieve, therefore here are three activities we highly recommend organisations stop doing to help them make that shift:

1.       Stop exposing APIs without thinking how they're going to be consumed by the customer. In the digital world, organisations must think differently. It's not the employee they’re building applications for, it's the external customer who won’t receive any training, so it must be intuitive and easy to use, out of the box.

2.       Stop exposing APIs without securing them, because when you’re under attack, you’re in a rear-guard position and it is difficult to recover from an unsecured API.  Bake security in from the outset. 

3.       Don’t just lift and shift your on-prem application to the cloud and expect to get all the benefits of the cloud. There's some investment and effort required, and this involves changing how apps are engineered to get these benefits.