The key to a successful API strategy

My integration teams enable systems to connect with each other and share data, we share lots of data and information across DWP, with other government departments, and with private sector partners.

I have around 110 people in my team at the minute, organised into agile squads of between 10 and 12 people. We build, maintain and run our services in product based teams, using mostly Kanban or Scrum methodology.

We’ve currently got 23 integration systems, but we’re transforming and rationalising them, moving towards a new API event-driven architecture.

An API is an application programming interface. Essentially, it’s a way of enabling systems to share data and information with each other. It enables systems, and organisations, to share data in a seamless, organised and consistent way.

In DWP Digital, we promote around 100 reusable services through our central API platform. We also share our APIs with other government departments, and we’re a key contributor to the cross-government API library that all departments can use.

We have four layers in our new reference architecture:

1. The user interface – a combination of web user, telephony and video, where we consider how people want to interact with us, for example through GOV.uk. This layer will enable a common experience for customers and agents; it will enable DWP to meet the holistic customer needs, rather than supporting policy product based silo contact.
2. Policy product specific components –where we capture the data and build the rules and customer interactions that are specific to a particular welfare benefit.
3. Shared components – where we build the common, re-usable, technical components for example; identity, residency and address checking.
4. Third party – where we use services provided outside of DWP, for example GOV.UK, GOV Notify, Experian Credit checking and HMRC Earnings.

Our API gateway is where we expose APIs that enable access to the common, re-usable components and services. We have an API library that can accessed by all staff. If we’re building a new service, we look in the API library first to identify if there’s a common component that does what we need for the new service.

Our APIs are key to building and enabling data sharing and re-use of services.

Additionally, we have four core areas that make up a common customer journey:

1. Entry point to gather initial information and provide advice to the user
2. We gather information and verify their identity,
3. We use the information provided to consider and calculate entitlement based on specific benefit rules
4. We make a notification and payment, if one is due

In the new architecture, there’s a lot of real-time interaction with the customer. Gathering the right information at the entry point, and playing back some of the information we already hold, helps us ensure we gather the right information and evidence to support their full needs. This could be based on needs for a single benefit or several.

The key change for the customer is that, as well as having real-time interaction with DWP systems, they don’t need to undertake separate journeys to claim multiple benefits. We gather information once and share as needed to support more complex needs.

We’re using APIs to enable various customer or agent experience layers to interact with common components, to collect data once and make it easily re-usable for multiple services.

Security is incredibly important for us and our customers. It’s essential that we verify that the person is who they say they are, during a real-time interaction between them and the service.

In addition to rigorous network and infrastructure security solutions, each API has its own security wrapper controlling who is authorised to use it. Each API has a minimum standard based on security guidelines and compliance, which can be supplemented with anything specific to sensitive information.

The main benefit for a large organisation is their potential for reuse. We’re working to an agreed set of standards and best practice on how we build APIs, so that we can maximise reuse. We’re building granular microservices as much as we can, which helps increase the re-usability of our APIs.

For example, instead of thinking about where a customer might live and the residency rules, we’ll break that down into components, such as ‘residency’, ‘check address’ and ‘validate that the customer is at that address’. Breaking down what was one service into three microservices makes them much more common, and much more reusable.

APIs save organisations time, and make interactions with customers and agents more efficient. During the first lockdown, when Universal Credit applications were dramatically increasing, we exposed an API that enabled us to validate users through automated checks.

That simple change meant that two and a half million cases in the Universal Credit backlog could be processed through an automated service. And that meant we could pay all of those citizens their first Universal Credit payment within four weeks.

APIs have been around for a long time, but historically we’ve built them on the back-end of the service. Now we’re evolving an API strategy in government, promoting a contract-first mind-set across digital.

We start by thinking about who’s going to use the APIs. We write human readable contracts that start with outlining which data we need, and compare these to the data already available.

This process can be carried out by a business analyst or delivery manager to help accelerate delivery. Agreeing the ‘request’ and ‘response’ in an API contract upfront means engineers can start to build with a good understanding of data sharing requirements.

So both sides of the data-share can develop their systems in parallel, breaking dependencies and helping teams be more autonomous, while reusing components.

Our initial goal in DWP is to bring our application reference architecture to life through the use of a fully functional, self-service API portal. This enables all teams to easily discover, test and re-use data and common components.

Thinking further ahead, we’re also helping to share and drive API best practice with other government departments, helping government to provide a more joined up service for our citizens.

We’re also looking at how we open up some of our APIs to third-party partners, to provide a more secure way of sharing information. For example, with local authorities and utility companies.

Get news and job updates from DWP Digital delivered to your inbox.