Application Programming Interfaces, better known as APIs, are critical to modern digital services as they enable systems to communicate with each other.
In the third episode of the DWP Digital podcast, Jacqui Leggetter, Head of Integration and Dean Clark, our Technical Lead, discuss how we’re using APIs in DWP Digital.
As well as talking about how we build, manage, implement and monitor our API usage, they’ll also share insight into how APIs are integral to providing holistic citizen journeys across government services.
A full transcript of the podcast can be found below.
Join us on our journey
Over the next few months we’ll be speaking to more of our in-house digital experts and leaders about some of the exciting projects we’re working on that are helping transform experiences for millions of people.
Make sure you don’t miss an episode, by subscribing to the DWP Digital podcast on Apple Podcasts, Google Podcasts and Spotify and by following #DWPDigitalPodcasts.
And if you like what you hear, don’t forget to give us a 5-star rating.
Transcript
Stuart Money
Welcome, everybody to another episode of DWP Digital's podcast. My name is Stuart. And today we're asking the question, what is an API? And how do we implement them across our services? And don't forget, if you're interested in technology and the types of things we do, hit the subscribe button now to make sure you don't miss an episode.
So let's kick things off. Jacqui and Dean, would you mind introducing yourself?
Jacqui Leggetter
Hi. So, I'm Jacqui Leggetter, and I'm one of the Deputy Directors in DWP Digital. I'm currently Head of Integration in digital group, and working on transforming our integration services.
Dean Clark
Hi, I’m Dean Clark, I'm the Technical Lead within Integration and I'm currently working with a number of squads to deliver and implement the new next generation API platform. We're also creating a community focused on accelerating the development of APIs with a view to share best practice, standardise and introduce tools to increase collaboration across providers and consumers.
Stuart Money
Thank you both. So Jacqui, just before we jump into what's an API, it would be good to know more about your team and what they do within DWP Digital.
Jacqui Leggetter
So my team sits at the heart of integration and we deliver the integration solutions across the whole of DWP. So we enable systems to talk to each other and share data across each other, across not only DWP, but out into other government departments, and with other third party partners, so utility companies, insurance companies, job agencies, those sorts of things. So sitting at the heart of moving and sharing all of that data in a secure and authorised way, is what my team does.
I currently have 110 people on the team. And we are largely organised into agile squads of between 10 and 12 people within each squad. We run our services as product teams using mostly Kanban or Scrum methodology. And within the team, the services that we support, we've got 23 integration systems or services at this point in time. But we are transforming and rationalising, moving towards the new API event-driven architecture. So APIs really sit at the heart of us transforming our citizen services, and the integration systems that underpin all of that.
Stuart Money
Thanks, Jacqui. That's great. Now we know what you guys do, let's talk about what is an API? What purpose do they serve? And how are they typically used within the private and public sectors?
Jacqui Leggetter
So an API is an application programming interface. And it's basically used to define how systems talk to each other, and enables us to share data in a seamless and organised and consistent way.
Dean you want to talk a little bit more about how we're using APIs in the public sector, aligned with how they're used in the private sector? Yeah, thanks, Jacqui.
Dean Clark
So you might hear terminology such as Rest or Soap, but basically these are design paradigms that is used to create APIs. And we focus primarily within DWP or have aspirations to be Rest first. So that is a way that we design consistent services and the look and feel, naming standards, version and etc. And we have various different services within DWP. So it could be something as simple as you know, get me information about citizen. We obviously apply the relevant security controls around that service to ensure that the data being accessed is accessed by the right people or person or system. And to be honest, there isn't that much of a difference between public and private APIs, you know, we are aligning to a best practice - an industry best practice -through the use of Rest. And we apply the same practices and standards in terms of security, authentication and authorisation as you would in the public sector. However, I do believe we as DWP put a lot more scrutiny around what data can be accessed given the sensitivity.
Jacqui Leggetter
Just building on that, if we think about how we use APIs in DWP, and how we're using them to help transform our citizen journeys. Currently, when citizens come into the DWP service lines, we're very policy product driven. So you may come in through our pensions service or through our working age service, or our disability service. And those are unique product based citizen journeys using different user interfaces, and it may require citizens to provide data more than once the same day or multiple times. And we're using APIs now to help transform that journey into a more holistic journey for citizens. So that when they access the DWP services through the YouGov web page, it feels much more seamless. They can provide that information once and we can reuse that information meaningfully with the citizen’s permission. So if we think about, for example, if we use an Amazon service and we register our payment details with Amazon, we don't have to re-register those payment details every time we buy something, because it holds on to them, if we give it permission to do so. And then we can reuse them. And if we think about that, from a DWP perspective, as we gather perhaps, payment information for benefit payments, when a citizen would want their benefit, which account they want paid into, we can hold on to that information with the citizen’s consent and we can reuse that regardless of the benefit type or they can change it as they need to. But it means that the citizens can control more of the data that we hold on them. And they can adapt and use that in the same way that they would expect to in their online interactions with private sector. So it really gives the citizen much more control over the data that we hold and how we use it as well as underpinning those holistic citizen journeys. So there's not really a great deal of difference between how we use APIs in the private sector and in the public sector.
Stuart Money
So Dean, what sort of APIs are we using within our team? Are we building our own? Are we integrating third party APIs? How does it work?
Dean Clark
Within DWP, we have the API catalogue, which is a central place to allow discovery of services which have been built for the use with DWP. So the aim of this solution is to give a rich developer consumer experience sharing documentation, key context, security mechanisms on how to use the API and also the ability to test and mock responses. So currently it within integration, we host around 100 reusable services through the central API platform. Such services include the in-house built NHS charge exemption service, the purpose of that was to allow the determination of whether or not a citizen was eligible for free prescriptions. So the impact of deploying that service which utilises data that we hold within the DWP boundary, has meant that there's been a significant reduction in fraudulent claims in the NHS. I think the highlight figure was around £250 million saved so far, which is, you know, absolutely phenomenal by just exposing data to allow the automated process to happen. We also have third party services which we as integration have deployed because they are central and reusable within DWP. We will host an expose them on our gateway, those might be an address validation service where, you know, teams can essentially call that service to implement that functionality instead of having to rewrite the same thing over and over again. Or it could be a bank validation, where we can quickly use a third party to tell us whether or not this bank account is valid for a particular citizen before we make a payment.
Stuart Money
You mentioned an API library, is our library exclusive to us? Do we share our APIs with other government agencies? Do we build APIs for other agencies to interact with, you know, like HMRC, for example?
Jacqui Leggetter
So over the last 18 months to two years, we've certainly focused on our internal APIs in DWP, in aligning and streamlining journeys within DWP and enabling lots of reuse of services as Dean just mentioned. But over the last six to 12 months, we've been focusing on sharing those APIs cross government so the library is fully available to DWP staff and partially exposed to other government departments. We're working with Cabinet Office now on providing a common cross government API library that will hold APIs that other government departments would be interested in, not only from DWP, but from HMRC, Home Office, Department of Education, NHS, where we share lots of data, all the time supporting access to benefits and access to free prescriptions, free school meals.
This came into its own as we went into the COVID lockdown in March. We all know that there was a significant spike in requests for government services. And we had to respond really, really quickly in terms of sharing information across government departments. So not only in the NHS prescription exemption charge service that Dean just mentioned, but we also had a real drive for driving licences for HGV drivers, using DWP data to validate part of the citizen validation process. And we also had a drive to provide some benefit information to Department of Education for a qualifying condition for free school meals. We also have the EU exit work going on where we have to help validate whether people have a right to remain in the UK. And the more we can share that data across government the better holistic cross government services we can provide to our citizens. So we're working now on a next phase of transformation, which is very much about sharing that information cross government, taking some of the learnings that we had in exposing those APIs through the early days of COVID, and how we can start to share the library so we can build cross government services, that is very much in line with our ongoing Civil Service Reform and better use of citizen data across government. But of course, that brings with it a significant amount of responsibility. And we have to make sure that we remain in line with GDPR compliance, and also that we hold and share data securely and meaningfully. And with the citizen’s approval to do so.
Stuart Money
Thank you, Jacqui. So Dean, it would be interesting to know which process you use to identify which API to make. Is it a case of the service requesting one? Or does your team carry out research into what's needed? How do you decide which ones to work on?
Dean Clark
Sure. So we use integration host and expose APIs onto the platform to enable them to be consumed within government and to external trusted parties. So we personally work with various teams to onboard the service so that it can be reused on the gateway. But service creation and API design in general. So the creation of a new API usually happens based on the demand from a potential consumer of the data. So we identify custodians of that data. And they will then work with the requesters if you will, who want to expose that data for their upstream system. So typically, the provider and the consumer will generate a contract, which describes the API in a human readable form. And then this is taken to various governance bodies to ensure that it's the right thing to be built. So there's extra checks upon that, but fundamentally, what we're doing is taking a contract first approach. So before we've written any code, we will design and implement the service that can be mocked against, and it look and feel like the real thing. And that can help engage that conversation about what actually is needed within that piece of work. So one of the checks in this process is to ensure the teams have reviewed the API library first, to make sure that we can actually reuse something.
So the fundamental goal of any API organisation is to make sure that we can reuse the services that have been built, and not keep building and building and building the same thing. So we check to see if it actually exists. So if an API does exist, the conversation then turns into how can we evolve this specific service to meet our needs, if it can't be immediately used straight away. So then we start talking about effective versioning strategies for that service, in a more granular discussion about what data needs to be added in. We’ve just undergone a large transformation piece within DWP, where we're really focusing more on breaking down those organisational units to be more fine grained, reusable components, which can iterate a lot faster, largely around, you know, a microservice architecture. And API design is core to that because the API is effectively just an abstraction layer over the complexity. And it'll allow us to design those components. So what we're going to see is many, many, many, many more APIs being built to serve a specific purpose. So having that contract first communication between the consumer and the provider allows us to have that link, but not a hard dependency on the development, so the contract can exist and the teams can just go away on their merry way and develop a service anywhere they need to providing that this contract has been met.
Stuart Money
One of the big questions I have is, how do we build them? What languages are we using? What goes into making one from a coding perspective?
Dean Clark
So as we mentioned earlier, an API is simply an application programming interface, which essentially allows us to design a standard ways of interacting with systems or clients. So we use industry patterns, nothing that DWP or government, promote or produce, it's industry standard. So that standard is Rest. And that helps us standardise the way that we structure and format the interface to achieve consistency across the API contracts.
So we then promote, as we talked about earlier, the contract first approach to design the service was close collaboration for both the provider and the consumer. So that an agreement on what will be produced is available, so everyone can go away and build a service in the time that they need to. But from this contract, and this is the really important thing, we can then automatically generate the client and server code to accelerate the development process and ensure that what is built actually meets the expectations that were agreed in the contract.
But as for languages, we in DWP have a really strong engineering community. We have a lot of opinions about what is the best tool for the job. And rightly so, we do have some kind of standardisation to ensure that we're not just going away building things that aren’t maintainable. So the core languages that we use are, touching on a few, Java, NodeJS, Python, etc. But it's really up to the teams to use whatever is best for the job at hand. And by having the abstraction layer, through the API and the contract, it means that we can ensure that we don't get too coupled, and allows us to change and iterate in the future.
So once we’ve built the solution, then comes the complexity of testing. So when we have an API in the wild, we may have many, many consumers who are consuming it, and how do you have that visibility, and have effective assurance that when you make future changes, they're not going to break? So what we're doing is we're promoting some new testing frameworks within DWP, such as Pact io. And Pact will allow teams to create a stronger contract at a more granular level based on what part of the service the customer is actually using. So we might have a specific endpoint and this consumer’s actually using two or three fields out of 10. So without that information, it would be really hard to see the impact of any future changes on those fields if we didn't know who was actually consuming it. So what we do then is we create a Pact. And it's programmatically held in a central repository where every team developing against the service can then validate against in real time. It's non-blocking, so it's really useful, and it shortens the feedback loop if there's any changes that may introduce problems. What we also get, as I mentioned, is a really good view of what service is being used, and what elements of that service is being used. So if you want to make a change, if you want to deprecate and completely close it down, you know that the impact is either minimal, or you need to speak to these teams.
Stuart Money
Jacqui, once you've built your API, and it's published, how does it improve a customer experience? Or how do you evaluate its effectiveness after launch?
Jacqui Leggetter
I'll talk briefly about a couple of examples where we've used an API to improve a user experience. Thinking about how we use APIs in DWP particularly to create the holistic citizen journey and for process automation, there’s a couple of really good examples where we've used APIs to help that process automation, which ultimately drives a better outcome for the citizen.
So when we first went into lockdown back in March, we had a significant increase in the number of our Universal Credit claims. Within the first month, we had something like two and a half million new claims to Universal Credit. And our normal process would have been to do a face to face interview with those citizens, validate who they were, and then process the claim through to payment. Obviously, in lockdown, we couldn't pull people in for face to face interviews, so we switch that to a telephone interview. But the sheer number getting through two and a half million phone calls would have meant it would have taken such a long time, we wouldn't have met our commitment to pay people on time.
So we introduced an automated API that enabled us, it was building a connection to a service in our identity and trust hub, where we could expose an API that enabled us to validate the citizen through some automated checks in the background. And by promoting our API and bringing that into use it meant that all two and a half million cases sat in the Universal Credit backlog could be processed through an automated service. And for the most part, those were successfully validated. Those that couldn't be fell out into a manual process. But just by being able to validate the majority of those enabled us to meet the targets for paying all of those citizens their first Universal Credit payment within four weeks.
We also had another case where we were looking at medical records that are needed to support some of our working age, disability benefits. And the traditional method is that the medical records are created and parcelled up and sent across by paper, we scan them and then put them into a system. Moving paper and having the whole people involved in that process was a challenge because everyone was self-isolating during lockdown again. And what we did was enabled these medical records to be sent to us digitally through the call-on of a new API, which was then able to be picked up by the DWP system for automated processing into the workflow. So it meant that what traditionally would have taken at least a week or so to process those papers and get them to the teams that needed to work with them to make assessments on benefit, were happening same day as the report medical reports were made available. So again, really seamless system to our citizens and much better experience for our agents that are administering them.
And taking those APIs are now available on our register and on our shared gateway for other areas to pick up and reuse. So we've seen the identity and trust API, particularly being picked up by a number of new digital services. And as we move forward, we will see more and more of those types of APIs, particularly where there are common processes or common services that sit behind them, that can just be picked up and reused through adoption on the central gateway.
Dean do you want to talk a little bit about how we review and evaluate once the API has been launched using the MI from the portal?
Dean Clark
Thanks, Jacqui. That's a good point. The benefit of bringing in an API lifecycle management platform is that you're able to get those rich metrics. So like any product, what motivates anyone is to see that their product in the wild is been used at scale. And we've been able to do that, especially with the services that we host centrally in DWP. During COVID, we had some incredible results coming back in regards to metrics, and the scale at which the services were being used, as Jacqui alluded to, was, you know, incredible. Fortunately, our systems were able to benefit from the elasticity of our deployments. But we did see some phenomenal numbers there, which if you can directly tie that back to how much of a positive impact it's having on the citizens in this time of crisis, then that's a really motivational thing. So we get those metrics through the API platform so we ca see at a consumer or service level, that level of granularity, and we can easily identify the services that aren’t potentially being utilised. And what we can then do is we can organise the portfolios within the teams to say actually, we might want to do something about these, we might want to deprecate, we might want to look at how potentially the service can be enhanced, so that it might be getting used more often.
Stuart Money
Today, we've talked a lot about what we're doing at this point in time. But what does the future hold for APIs across government and other private sectors?
Jacqui Leggetter
So I think talking about the cross government and our future, our goal for our APIs is that we can create an API economy across government. So we can take some of the best practice that we have across DWP and in other government departments that have started the API journeys, and bring us all up to the same level of competence. Creating a de facto process of building loosely coupled services that interact through APIs and events and the cross government catalogue will be key to that. So creating a cross government API catalogue that will enable self-service for discovery and test of the APIs, with some automated processing around approval for actual use of the APIs because we need those data sharing agreements in place. In government, we are held to a higher account, to trust people trusting us with their data and information. So we need to make sure that any cross government catalogue is in line with the trust that citizens placed within us to use their data securely, and in a relevant manner. So that's really important. But I think moving forward, being able to provide more holistic citizen journeys across government services is where our aspirations are, and citizens have higher expectations of us to be more joined up in government services. So that's where we'd like to be. And I think in terms of private sector, like government, I think what we will see is more joined up services, and more self-service. So moving away from back end office processes, and using APIs and more interaction with the consumer of the service, the citizen, or the member of the public to self-serve and actually using back end systems without realising it, they're exposed through APIs to manage their own processing and straight through processing for claims be that in DWP, mortgages, finance sector buying industry, I think we'll see a lot more of that self-service coming in.
Dean Clark
I fully support that Jacqui, I think you're exactly right. And that's the trends that we are seeing, you know, there's more and more asks for data to be shared externally to government. And if that can help citizens in different ways, then why shouldn't we be looking to expose our services and data safely and securely and in line with GDPR, and all the other regulations that we need to adhere to? We also see that there's emerging trends from an engineering and architectural perspective. So we want to be ensuring that we are continually providing the best possible service from a technical perspective to all of these new consumers and customers. And does that introduce additional changes or requirements that we would have in our solutions? Probably yes. And that's why we continue to look towards the trends to ensure that our products can cope with that.
Stuart Money
So that ends our podcast for today. Hit the subscribe button if you want to make sure you don't miss the next episode. And I'd like to thank Jacqui and Dean for taking part today. I certainly found it interesting to learn about our APIs. And I hope you did too.
So thanks for tuning in. I'll see you next time on the DWP Digital podcast.