A big challenge public sector bodies face when it comes to digital transformation is the ambivalence to changing legacy systems; ‘what’s the need to replace existing systems?’ some say.

Government departments have done well in changing the front-end services citizens use, but not tackling legacy back-end systems will lead to problems over time. 

As discussed in evidence to the Science and Technology Committee earlier in January, progress on delivering more joined-up services to citizens is proving problematic because many organisations just don’t know where or how to start overhauling their unwieldy and complicated legacy systems. 

The existing, siloed systems are poorly understood and highly complex. All too often this results in them being considered too big and too hard, despite large sums of money being spent.

Over the coming weeks, we’ll be looking at some foundational principles that will let you dare to re-open your ‘too-hard’ box. Today: the opportunities of taking an ‘API first’ approach.

An API first approach

First, what is meant by ‘an API first’ approach? APIs (Application Programming Interfaces) are essentially a contract that allows digital systems to work together whilst remaining independent and therefore able to evolve at their own pace. In principle, it is like the guidance system that allowed the Channel Tunnel to be dug from both sides simultaneously and yet meet in the middle seamlessly. 

Fostering innovation

We all approach our work with a certain perspective borne out of our experience and limited by our available resources and skills. One of the most positive disruptive influences APIs bring is the ability for in-house teams, third-party companies, indeed anyone to create new ways to access your service. Unleashing these new perspectives and ideas on your data and services expands those perspectives and maybe even capacity.

Enable change

Part of the reason legacy systems are too hard is that they are generally monolithic. There is always pressure to hold off any replacement or modernisation effort until such time as every last feature of the old system is available in the new. And that pressure is all too often irresistible. Entrepreneurial thinkers should call that out for the nonsensical rubbish it is. What we need is a way to isolate parts of the monolith so that we can experiment with new solutions in reasonable timeframes and with acceptable risk. APIs provide a mechanism to do that. 

By wrapping a given part of the legacy system, we create a break point between the user and back end systems responsible for delivering a service. Once the API is in place, we are able to limit the number of users or time during which the replacement is used. This way, we can undertake legacy transformation in a manageable way, with a more modest risk. 

However, that break point is not sufficient. An API-centric architecture does not simply take those existing too-big problems and put a shiny new wrapper on them. APIs, well-designed ones at least, are independent so that we do not have dependencies that resemble a ball of wool after the cat’s been playing with it. Also, it must be right-sized so that there is enough value in improving that one component.

Support continuous improvement

Once we have right-sized components with formalised API contracts, we can test each one in isolation. This simplifies that testing, making it cheaper and more robust. In turn, this drives quality and speed.

Respond to new requirements

If Benjamin Franklin had been in the software industry he would doubtless have added ‘changing requirements’ to death and taxes in his list of inevitabilities. If each component is focused on doing one thing, and doing it well, then it can easily be modified or changed when requirements change. And when the time comes to retire today’s legacy, we will be able to do it in a rational and predictable way.

This API-first approach provides a way to transform legacy systems when – or hopefully before – they become prohibitively expensive and/or too brittle to maintain. 

Next week, I will look at process platforms and how they help you coordinate these APIs and their implementations, as well as providing the flexibility to respond to change.

Follow us on Twitter or LinkedIn to get our latest blogs or sign up for our newsletter below

Related content

• 

  Digital government: Why liberating users and data from spreadsheets matters to me

  Published on: 17 January, 2024
  Blog
• 

  Document redaction: A secure approach for UK police forces

  Published on: 10 January, 2024
  Blog
• 

  Secure futures: A concept for national security vetting

  Published on: 15 December, 2023
  Blog
• 

  Home Office DDaT strategy 2024 — building better, more efficient services

  Published on: 15 July, 2021
  Blog