Exploring the Technology Stack Behind DWP Digital Universal Credit Program

DWP Digital deliver tech services for the UK's largest public service department – the Department for Work and Pensions (DWP), responsible for supporting citizens in various aspects of their lives. From managing welfare benefits and pensions to providing employment services, DWP Digital play a crucial role in promoting social and economic well-being across the nation.

With over 10 years of experience in Software Development, we knew we had to hear from Thomas Chamberlain, a Digital Java Developer at DWP Digital. He’s been hooked on tech since he was a child and ended up pursuing his passion through school and university, before finally landing a role at a top tech consultancy in London. When the pandemic hit, however, he wanted to challenge himself to something new, and ended up joining DWP Digital’s new hub in Birmingham.

Meet Thomas!

In this article, we’ll dive into Thomas’ most recent projects at DWP Digital, touching on topics such as Universal Credit app, and the use of microservices, as well as his tips for you, directly from him. Let’s get started!

The tech that powers Universal Credit

Universal Credit is one of DWP Digital benefit systems that handles £200m daily across 700 jobs centres in the UK and work coaches serve around 6million claimants. With volumes as high as this, ensuring our tech systems can accurately handle data and the demands of the benefit system is of utmost importance. The application that underpins this work consists of a number of microservices. These microservices are built with Java, utilising Mongo database, and are event-driven utilising Kafka.

The magic behind the job search engine

Our team developed a search engine that allowed work coaches to find and discuss suitable job vacancies with claimants during their work search review, removing the need for the manual spreadsheets they were using. During discussions, work coaches can send any interesting jobs to a claimant's journal and track whether the claimant applied to a role or needs more support to access job opportunities through the universal credit system.

How it works is that the work coach will use keywords and filters to generate a list of vacancies that are suitable to the claimant's needs. For example, filters such as “remote work” or “with a 10-mile radius from home” can be used. We may use external APIs to plot how far a job would take to travel to based on public transport, including bus schedules or train timetables, to better match jobs to the claimant's travel needs. It’s all quite intuitive.

Tips for successful front-end and back-end collaboration

At DWP Digital, we wanted to be true to microservice architecture and make sure that our new microservices could be deployed independently, rather than as part of a monorepo. That's where consumer-driven contracts come in – and that's why we use Pact. Pact is like the glue that holds everything together. It’s the tool that keeps the contracts, and also keeps track of what version of a microservice is compliant with those contracts.

Say the front end needs the back end to produce a list of jobs. The front end creates a Pact that specifies what the fields are and what kind of data each of those fields contains. The back end then tests itself to make sure it can provide that URL if it's called. If the test passes, the results are uploaded into the Pact Broker, which knows exactly what version of the back end will work with what version of the front end. This way, the Pact Broker is like a matchmaker for microservices.

Before you deploy a microservice into an environment, you can check with the Pact Broker to see if this version of the front end will work with the back end and that’s already deployed in the environment. If it says yes, you're good to go! If it says no, you’ll need to figure out why. This saves us so much time and hassle as we don't always have to do end-to-end testing across the entire set before moving up to an environment. (We still do end-to-end testing across all microservices.)

Navigating the deployment pipeline

At DWP Digital, we believe in the power of trunk-based development. We commit all work to the master branch and deploy it straight to production. Any work in progress is committed behind a feature toggle, meaning it can sit in production without being activated until quality assurance is completed. This approach ensures everyone's code is close to master, and we avoid issues like merge hells.

Previously, we used a mono repo that was deployed weekly, but we found it was too slow and made tweaking microservices difficult. That's why we switched to continuous deployment for our new job search engine. Now, every commit is deployed to production, making it easier to pinpoint any issues. With multiple commits, it's hard to tell which one is causing problems. But with a single commit going through each time, it's obvious which one may have caused a problem. Plus, automated checks like performance tests can help identify any issues.

Our goal is to make tweaks and get feedback more quickly, and continuous deployment allows us to do just that.

Overcoming technical challenges

Building our job search engine was a challenge. We merged code directly into production, which some team members were sceptical about. But we addressed these concerns and implemented control mechanisms to reduce any potential risks.

We took a meticulous development approach, testing each code upfront to prevent future issues. We identified necessary tests for each user story and implemented visual snapshot testing to prevent visual changes. We also ensured that the program would gracefully degrade if external services were unavailable. Performance was crucial, so we utilised the tool K6 to test endpoints and ensured that tests were only run against code with the same set of feature toggles enabled as the code in production.

We used blue-green deployment strategies and implemented health smoke checks to ensure everything was functioning as expected. These measures allowed us to move code straight to production with confidence and pay off our hard work.

Debunking misconceptions about DWP Digital technology

I’m happy to debunk common misconceptions. For example, unlike other government organisations that rely on external companies or consultancies for their IT systems, we mainly build our systems in-house. This means we have the freedom to choose the best technical options without being constrained by frameworks or consultancies. We're not afraid to push the boundaries with our tech.

We're talking advanced microservices, Java with event-driven concepts – you name it. In fact, our tech is more advanced than some of the non-government organisations I've worked with in the past. So if you want cutting-edge tech, look no further than DWP Digital.

Advice for breaking into government organisations

My advice would be to focus on transferable skills. Don't just rely on technical experience – hands-on apprenticeships and other relevant experiences can be just as valuable. We had a recent hire who moved from being a Work Coach to a Business Analyst, and she was hired based on her transferable skills and how she worked with people, so anything is possible!

What’s next?

If you’d like to join the team at DWP Digital, then create a profile on the Hackajob platform, where they’re currently hiring for a variety of roles or log in to your profile here.

You can also keep updated with them on social media, and check out their Hackajob profile.

Like what you've read or want more like this? Let us know! Email us here or DM us: Twitter, LinkedIn, or Facebook, we'd love to hear from you.