WavebreakMediaMicro - Fotolia
The Department for Work and Pensions has created an internal portal based on MuleSoft’s Anypoint platform to manage and promote reuse of a growing number of common application programming interfaces (APIs) that can be shared across different areas of the organisation.
Before beginning a journey on the approach it takes to reuse the software it develops, the DWP had hundreds of point-to-point integrations between multiple systems. These were accessed programmatically using APIs, but as Jacqui Leggetter, head of integration at the department, explains, often the API represented a single connection into a large system and had complex data requirements.
“We were looking at APIs two years ago in 2017, but we were coming at it from a technology perspective, and saw the API as a technology solution,” she says.
Leggetter says these APIs previously used a naming scheme based on numbers, so if an API went down, it was hard to understand how critical the system exposed by the API was. “We have been on a learning journey,” she says. “The value of the API is the business service.”
Describing how the team reworked its view of APIs, she says: “Through the first year of the team’s API journey, we stopped talking about APIs as numbers. Every API should start with a verb.” This, she says, changed the mindset associated with the API.
Making APIs reusable
The next milestone came when the team began moving to make APIs reusable. The DWP developed an HM Revenue & Customs (HMRC) microservice that bundles checks on name, address details, benefit awards, and other data points. These are then combined in the microservice to perform a calculation.
Although this was what the HMRC needed, Leggetter says: “The service we built for the HMRC wasn’t reusable, because we exposed five things in a single API.”
The Scottish government needed a similar API, but it did not require all the parameters used by the HMRC, she says, adding: “This was the lightbulb moment.”
The team realised it would get better reuse if the microservices it developed were more granular, says Leggetter.
So for its next project – a free NHS prescription entitlement check service, which had similarities with the HMRC microservice – the team looked at developing granular APIs. Leggetter explains: “We split the microservice into separate APIs for the NHS prescription check service we developed for the NHS Business Service Authority [NHS BSA].”
The check for free NHS prescription entitlement is done six weeks after a prescription has been dispensed. Although the DWP has a data-sharing agreement with NHS BSA, from a General Data Protection Regulation (GDPR) perspective, it did not have direct agreements with the software companies that manage prescription stock.
In terms of data security, a microservice accessed via an API avoids the risks associated with transferring data. Leggetter says: “We could have sent the data, but the rules are quite straightforward and so we just built a microservice. Instead of sending them the data, the NHS BSA makes a call to a real-time prescription entitlement check service.”
This microservice uses the DWP’s reusable passport benefit check microservice, which then calls several system APIs to validate the citizen, check their national insurance number and the benefits they receive. All the data from these API calls is then passed up to the NHS microservice layer, which runs the calculation for free prescription entitlement. “The pharmacist then gets a yes/no answer right at the point of sale,” says Leggetter.
In Leggetter’s experience, encouraging developers to reuse code is often a challenge. “When we promoted reuse at the DWP, there was pushback,” she says.
She says there was a sense that if someone else had developed something, it was not going to be very good, adding: “There is no glory in building something that already exists. We ran a lot of sessions across the digital community.”
This was used to encourage the adoption of a common set of standards and a single set of business practice, says Leggetter. “We often see the same thing being built in business silos, such as an address checker,” she says. “Each product group does its own address lookup and pays for the use of the address-checker API. We have created a common API for address look-up using Ordnance Survey; it is maintained and managed by us. You can just come along and consume it.”
Read more about the Department for Work and Pensions
- Juan Villamil, director of enterprise infrastructure and production operations at DWP Digital, discusses how the Department for Work and Pensions tests out new tech ideas.
- The DWP uses a machine learning algorithm on Microsoft Azure to identify associated skills, based on the skills specified in online job adverts.
Using this API means the business groups do not have to pay an extra fee for licensing a third-party address look-up service. To date, three business areas in the DWP have started using this new API – but there are six to go, she says.
According to Leggetter, if something is nearly right, the API can be adapted. For example, she says the Scottish government needed to identify Scottish postcodes, and this requirement did not require a new API. “We could just adapt our existing [address look-up] API,” she says.
Leggetter says that internally, her team has changed the way it manages and prioritises the backlog of work for new APIs. “One of the first things we capture when we get a new project in is the data items the project needs,” she says. “We have a matrix of 26 common data items and we are starting to drive our project work by demand, looking at how many projects require a given data item.”
The matrix provides a way to identify which data items are most used. The data item translates into a requirement for an API, and while the largest projects may need only one API, by using the matrix, Leggetter says the team can identify upfront a need for a data item and its associated API. “We can demonstrate value if we can show that five or six projects need the same API,” she says.
Older systems at the DWP are operated using batch runs, which tend to run overnight. Given the way these systems are interconnected, updating the various systems with, say, a date of death notification can take up to six days. The department’s ambition is to become more real time by moving from batch processing to an event-driven architecture.
“We have to find a way to unlock data in these old systems in order to interact with digital system,” says Leggetter.
To achieve this, the DWP has built an API to a tactical piece of middleware called Legacy Bridge. This links legacy systems with the new systems being built by converting messages to batch messages and enabling Restful APIs to call Soap XML APIs, and vice versa.
Leggetter says the DWP’s new state pension system still relies on calculations from legacy batch processing systems. She says the Legacy Bridge makes it easier for developers to access the business logic that runs in the batch systems.
For Leggetter, APIs promote the DWP’s digital strategy to break down silos and have the potential to drive truly transformational change. “Across our products, we could have common components, with a thin bespoke business layer, and share a single use experience, so people can be multiskilled and service more than one product line in the business,” she says.
By promoting API reuse, she believes the DWP would no longer need to develop applications focused on an individual business area. So whereas today there are separate applications for child support and pensions, the next transformation at the DWP could be driven by common application opportunities.