Credit: Kirsty O’Connor/PA Wire/PA Images
In the four-month period from the beginning of March almost three and a half million people have claimed for Universal Credit. Hundreds of thousands more have applied for Jobseeker’s Allowance and other benefits.
While almost agencies across the public sector have faced huge challenges in the last few months in just maintaining service delivery – let alone dealing with the impact on demand caused by a public-health crisis – few have been as busy as the Department for Work and Pensions.
The DWP’s staff were described by work and pensions secretary Thérèse Coffey as the “hidden heroes” of government’s crisis response.
The department’s digital services and platforms, meanwhile, have faced a huge test of their capacity and efficacy, while staff have been required to build new tools or augment existing systems – often under tremendous pressure of time, and in support of major national programmes.
This response has been helped by a library of application programme interfaces (APIs) that the DWP created 18 months ago. The repository of reusable code and templates – which can be also used by other government agencies has enabled the department to respond to crisis with the necessary speed and scale, according to Jacqui Leggetter, integration lead at DWP digital.
“Historically, the process of building the underlying infrastructure could take months; we deployed new APIs, or extended throughput on existing APIs within two days.”
We asked Leggetter (pictured below right) how the DWP’s approach to services is evolving towards reuse, APIs, and micro-services, and how this philosophy has helped the department in its coronavirus response.
PublicTechnology: What role does an API play in a digital service, and why are they important?
Jacqui Leggetter: APIs, or application programme interfaces, is critical to modern digital services as they allow systems to communicate with each other. This enables developers to re-use and share data and technical components, making it quicker to develop new systems, this enables a more joined up service for citizens and front-line colleagues.
What was the genesis for DWP starting, 18 months ago, to build up an API library?
APIs are only useful if they can be discovered for re-use. We found that one of the key barriers to re-use in a large organisation like DWP was that developers didn’t know what already existed. Creating a self-service API library gives all developers one place to look for re-usable APIs. It enables them not only to discover re-usable information and services, but they can also test them using mocking services before developing any code for their system. This means that they can create and test their designs before and during building their own code. This helps accelerate development, enabling faster, and more accurate, delivery. It also allows us to focus our efforts on building new components rather than replicating capabilities and features that already exist.
What is the rationale for – and benefits of – creating ‘micro services’ rather than broader, more feature-heavy applications?
The real benefit of creating micro services rather than feature-heavy applications is that they can be built faster and are more re-usable. A micro service is normally a small service that does one thing well. They are loosely coupled and communicate with each other through APIs to support an end-to-end process. Being small, discrete services, they are easier to maintain and change; they are also easy to scale up and down using cloud hosting solutions. Deploying regular small changes is less intrusive and therefore much lower risk and lower impact. This enables continuous, small change, deployment rather than the larger release-based deployments we would historically deploy.
When we build feature-heavy applications there are lots of different rules and validations built into the code making it difficult to integrate and therefore reducing re-usability. It is also more difficult to apply change as even minor changes require the full system to be tested before deployment. Deploying change takes longer and any defects can break the whole system which means any change needs a full regression test which can be lengthy and expensive.
3.4 million
Approximate number of Universal Credit claims during coronavirus process
October 2019
Date of GDS launching API catalogue for government
Two days
Length of time in which an API could be deployed to meet a service request – compared to months previously
23 March
Date on which the UK went into lockdown
How important are reusability and interoperability? Are there examples of other government entities making use of tools developed by DWP?
As one of the largest government departments, supporting in excess of 20 million citizens at any given point; re-use and interoperability are critical to DWP to ensure that we not only gather information from citizens, but also to enable us to share information between government departments where we have consent to do so. Citizens, quite rightly, have increasing expectations in their interactions with the different services in DWP and across various government departments. We strive to improve their interaction by securely sharing and re-using information, with their consent. A good example of this is when someone tells us about a bereavement; sharing the bereavement information helps us to provide a much better, joined-up, outcome for citizens as we can take the information once and process it across all of our product lines.
Delivering great service to citizens across government involves an extensive data gathering and sharing ecosystem; the whole ecosystem relies on interoperability and consent. We have a number of other government departments that use our APIs, and we use theirs. One example of another government department using our shared APIGateway is when the NHS undertakes a real-time check for prescription charge exemption, assessing entitlement based on the benefits that we pay. They call our passport benefit API which validates the enquiry and, once validated, we call a number of APIs to verify the citizen’s benefit entitlement and we use this to tell the NHS whether someone is entitled or not. We also perform this check for the Department for Education for free school meals entitlement and for local authorities for the disabled Blue Badge award.
What did the API library enable the department to do in its Covid-19 response that it wouldn’t otherwise have been able to?
Having the API Library available meant that, as soon as we got requests into our Covid-19 rapid response team, we had a single registry to go to that enabled us to identify, within an hour of the request, if we had an API that could meet the requirement already or not. It also helped us assess if we didn’t have an API that exactly matched, whether we had one that could meet most of the requirement.
Once we identified – or built – the API that met the requirement, we deployed it onto our current shared API Gateway which was already hosted in our internet-facing cloud. This meant that all the infrastructure was already in place so, once the API was tested and proven to be suitable, it could be deployed really easily through the existing shared infrastructure. Historically, the process of building the underlying infrastructure could take months; we deployed new APIs, or extended throughput on existing APIs within two days. This would not have been possible without the API Library or the shared API Gateway.
How well did DWP’s digital services cope with the huge spikes in demand, and what role did APIs – and other existing, reusable tools – play in that?
As soon as we went into lockdown, we anticipated a spike in volumes across all of our systems. A task force was set up to assess and increase capacity where it was needed. When we completed the assessment of the forecasted API volumes, we were able to quickly review volume thresholds, as they were clearly defined in the API description pages held in the API Library. As the API Gateway is hosted in our cloud environment we were able to scale up quickly, using the shared API Gateway throttling levels to protect some of the underlying systems. This helped us increase our throughput whilst protecting the underlying systems.
How quickly was the DWP able to create new APIs and services for use in supporting Covid-19 response?
APs are used to expose or connect services. We were able to build new microservices that exposed new APIs very quickly. One of the new APIs we built enabled digital medical reports to be uploaded automatically from an external provider into a DWP system; from requirement to deployment took around four weeks. This automated a manual process that was no longer available due to lockdown.
Other more complex services took around 6-8 weeks to build from start to finish, for example adding a new Universal Credit benefit rate check to support our passport benefit checking service. This was much quicker than building in the traditional heavy-weight services we used to build. This new passport benefit service API is also now available for other uses such as Free School Meal checks.
How will the department’s approach to the use of APIs – both for itself and for wider use across government – develop in the future?
DWP will continue to build and expose new micro service APIs, and make our current APIs more re-usable. Although we already share a number of APIs with other government departments, there is a real effort being made to join up services across government and one initiative is that we’re creating a central cross-government API Registry that will enable us to share what APIs we already have available, as well as being able to see what APIs other government departments have available. This is key to providing more joined up, richer, cross government experiences for citizens.
What is the ‘next stage of transformation’ for the DWP, and how will APIs and micro-services help achieve that?
We have spent a lot of time transforming our services to meet individual citizen interactions aligned to the DWP policy products; for example, Retirement Pension, Bereavement Benefit, Universal Credit, Carers Allowance and others. Whilst this has created great citizen interactions, it is fragmented based on the policy product line. However, more often than not, citizens engage with us on more than one policy product, so the wider interaction can be confusing and frustrating as they can be asked to interact with each policy product in different ways, and be asked to provide the same information multiple times.
Our next phase of transformation is to provide a more holistic interaction for our citizens and our front-line colleagues by creating common technical components that can be re-used across multiple policy products, supplemented by a thin layer of bespoke rules needed for each policy product. This means a single experience for citizens that allows us to base their interaction on their overall needs rather than product specific. It also enables us to use the information provided effectively across the product lines to support their overall needs in one interaction rather than the multiple routes which they do now. In addition to meeting the citizens’ holistic needs, it also enables us to deliver transformation faster as we get more re-use of common components built on a standard data model and API- and event-driven architecture. It is the APIs and events that enable us to connect the micro services to provide a rich end-to-end service for our citizens and colleagues.
