How code reuse drives business change at the DWP

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.

Promoting reuse

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.”

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.

Legacy access

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.