Select Page

Dan Blundell

Technologies Manager

Building a platform, brick by brick

When designing services we start with users. We research what they need and how that fits with local government services. This is useful because it focuses the design of a service on things that are going to be valuable to users.

Behind those services there’s often an awful lot of technology and we’ve been working on a way to make better use of that technology so that our teams can build services quicker and more consistently. This is good because it means that services can be prototyped and improved more quickly, which means users will have a continuously improving but consistent way of interacting with different services across the Councils we work with.

The model we’re working on is based on a combination of Tim O’Reilly’s Government as Platform and the GDS version of Government as a Platform, we’ve set out to find a solution to repeated development and procurement of very similar technologies as well as building Government services on more open platform. We often find ourselves needing to replicate very similar functionality from one service to the next, copying and pasting code between projects or taking functionality we used on another project, tweaking it a bit and using it again. We have the same problem when it comes to buying software, lots of systems all providing email notifications, case management, mailing lists, payments, bookings, reporting and so the list goes on.

Instead of copying and pasting code or buying similar functionality over again, we’re using some of the Government as a Platform principles to bring together common datasets and technologies so that our delivery teams at LGSS can work with Government services to build better experiences for users.


We’re working on a way to make better use of that technology so that our teams can build services quicker and more consistently.

Visualising the technology

We created a map of the services that have been the most technically challenging, similar to a Wardley Map. We used the initial maps to help visualise the parts of a few services that could be considered functions. So ‘book an appointment’ becomes ‘booking’ and ‘send confirmation’ becomes ‘notification’. This helps us understand the types of technical functionality we need to build local government digital services.

Now that we have an idea of the types of functionality we need, we’re working out which pieces we already have and which ones we need to borrow, build or buy.

As much as we’d love to spend the next weeks and months building, borrowing or buying the components for everyone’s benefit, by no means are we abandoning digital services to concentrate on the pieces of the puzzle.

Instead, we’re bracing ourselves to do most of that work in the background whilst we work with Government services to deliver change.

This may seem an impossible task but as with everything, we started small and are working our way up. We’ve already put in place a common verification service as part of working with Cambridgeshire County Council to redesign their Apply for a Blue Badge service and we’re doing similar work on the GOV.UK Verify pilots to add to that level of assurance.

The Lego model

What’s next?

When we’ve talked with services about this approach, it gets referred to as the ‘Lego model’ and, for the most part, that’s a pretty good name for it; varied components with individual purpose and a common way of connecting them together. The real challenge is defining the common way of connecting things together, that’s something we’re learning as we go.

We’re continually working on ways to design responsiveness, adaptivity and scale into the way in which we design digital services. This means that each brick in the Lego model has to be able to scaleable and flexible enough to adapt of it’s own accord. We’ll be sharing more about how we’re going about that over the coming months.

By separating the responsibilities of each piece of technology, we’re able to share the benefit far more widely than typical license costs. Shared or common components mean shared skills for support and operations staff, knowledge of products and technologies has more depth rather than breadth which we intend to lead to improved recovery times and more reliable services. Not only can things like payment and postcode lookup functionality be shared between an Booking an Adult Learning course and Apply for a Skip License but between local authorities too which means the way a website looks visually to a user can be bespoke for each service or organisation but the functionality under the hood is shared, reusable and scalable.