This year, we’ve published our 5 objectives for GOV.UK and our roadmap shows how we are delivering against them. More widely, the Government Digital Service (GDS) has published its strategy for 2021 to 2024, with a focus on joined-up services, reusable platforms and personalisation - all tied together through a GOV.UK account and a single sign-on.
When we launched our GOV.UK Account work, we wrote about how the way people interact online has changed a lot since GOV.UK launched in 2012. Shopping, banking and media services are increasingly personalised, proactive and seamlessly available across multiple devices.
We want to meet this raised expectation by providing an experience that is just as tailored and relevant to the user - meeting them where they are. At the very least, we want to be able to test these propositions with users.
In this blog post we'll set out how we intend to transform GOV.UK's infrastructure and architecture to deliver a proactive and personalised experience across different devices and channels, while improving accuracy and accessibility and offering a stable and secure service. We'll cover how and why we'll be making these changes and how it will improve the overall user experience on GOV.UK.
Explaining platforms
This is a strategy centred on platforms and services. Let’s cover what we mean by platforms. The word “platform” seems to be everywhere these days. What does it mean?
Broadly speaking we mean:
“...a group of technologies that are used as a base upon which other applications, processes or technologies are developed,” as defined by Techopedia.
Essentially this is functionality you can build on top of, functionality that delivery teams don’t have to build themselves because it is made available in an easy to use, supported and reusable way. You don’t have to know about its inner workings. Someone else has taken care of the hard work - leaving you to focus on delivering what’s distinct and valuable about your product or service.
Good examples of this outside government include:
- Twitter is a social media platform which has APIs and also supports syndication of its content via embedding
- Amazon Web Services, Microsoft Azure and Google Cloud Platform are examples of on-demand cloud computing services - compute, databases and other backing services, available as a platform of infrastructure and managed components you can build on top of easily
Some platforms are live services, others are simply well supported reusable patterns and components.
We recognised the value of platforms in GDS early on with our government as a platform (GaaP) work, and began to solve the most common needs with notifications, payments and cloud hosting. We also have the GOV.UK Design System, a set of styles and patterns actively maintained and supported as templates and components.
Our GaaP products are used by thousands of services across government, leaving their teams to focus on delivering value which is distinct to their users while we take care of the “undifferentiated heavy lifting”.
Platforms expose functionality and data, through open and standardised APIs, which teams can use to deliver their services quickly and easily. Some of those services may in turn be platforms themselves, with others building on top of them, or reusing them; for example, our payments platform uses our notifications platform, which in turn runs on our cloud hosting platform. Platforms emerge to encapsulate and solve common problems, and can provide a growing ecosystem of applications and features which are built on top of them.
Past and present
The changes we’re talking about in this post concern the 70 or so publishing and frontend applications/components that make up GOV.UK. These applications serve the more than half a million pages on www.gov.uk, but not the hundreds of individual services that are hosted and run by respective departments.
While GOV.UK may look like a single website, it’s made up of several different domains which are detailed in the GOV.UK proposition. Our plans are to improve the architecture for www.gov.uk - the publishing platform for government.
The foundations of this were put in place nearly a decade ago. At a very high level this is made up of:
- frontend content presentation which is cached by a Content Delivery Network (CDN) so it can be speedy and available
- applications for authoring, publishing and managing different types of content, used by content designers in GDS and across government
- a content store and APIs for putting content in and pulling it out as needed
- the infrastructure - virtual machines, data stores and other backing services
It has grown and evolved over time, and additional frontend or publishing applications have been added to meet emerging needs.
Duplication has crept in as the applications and architecture have evolved, making it difficult to add new features; it can be difficult to know how many places a single change may impact, or how many applications need to be updated. This is technical debt.
The infrastructure was designed to serve static content which did not change frequently, rather than automatically scaling to meet demand by adding new machines. We've been able to use a CDN to serve cached pages at scale, rarely needing to serve them directly ourselves.
That setup has worked well, especially during the coronavirus pandemic when we saw tremendous traffic spikes. It is a simple and robust design which has stood the test of time and a testament to the architecture and engineering skill of the original teams on GOV.UK.
However, users and technology have moved on since GOV.UK first launched; there are more ways to be connected than before, and where and how content is delivered has changed. We need to test proactive and personalised propositions to meet these new needs across different channels.
We need an architecture and infrastructure which can support dynamic, tailored content at scale. The “page” is no longer the only unit of content. It is “structured information” breaking down into reusable “chunks” of content, reusable and applied based on context.
This is a big change. A fundamental rethink and redesign of the architecture and infrastructure of the GOV.UK publishing and presentation applications, as well as a change in how the teams sustaining all of this are organised and work. Our cross-government publishing users will see improvements through a more cohesive and intuitive set of publishing tools, and public users will have a more personalised and relevant experience.
Future platforms and services
In the future we want to think about our content publishing and presentation technology as platforms and services:
- infrastructure - the underlying infrastructure and backing services which everything runs on
- publisher - the user interfaces and workflows used across government to create, publish and manage content
- content platform - the engine doing the heavy lifting, providing APIs for search, notifications and other functionality for managing and serving content
- presentation and experience - the public facing site and other channels, such as www.gov.uk
We’re taking time to think and plan how this could work over the next few months, and what that means for how we currently support our applications and infrastructure. It will change and evolve as we explore and experiment.
This is a wholesale change to how we handle presentation, personalisation, publishing and content. We want to:
- be more reliable, secure and able to respond to change through loosely coupled, well bounded, services
- minimise dependencies and handoffs and set service level objectives and other performance indicators per service
- be better organised around long-term value propositions (services!) giving long-lived teams ownership, agency and continuity for us and our users
We’re taking an incremental, iterative and open approach and will be “zooming in” on the areas touched on here in future blog posts.
These are exciting times for GOV.UK! Get in touch via email if you want to talk more.
Subscribe to Inside GOV.UK to keep up to date with our work
GOV.UK is hiring. Apply for roles, read why we’re hiring more technologists and discover 4 tips for your job application
