As Neil explained in the GOV.UK 3rd birthday post, we’re focused on 2 main priorities for the rest of this financial year.
This post is about the first of those 2 priorities and why it’s so important:
To consolidate the publishing tools and page templates we built so quickly into a coherent platform, which we and others can build on more easily
We’ve had a small team of developers dedicated to this platform consolidation work since we set out our goals at the start of the year, and we’ve been reporting our progress every two weeks. Now we’re increasing our focus on this work, with several teams collaborating on it until the end of March.
Background to the problem
GOV.UK has been built while striving to meet 4 deadlines:
- the closure of Directgov and BusinessLink on October 17 2012
- the transition of the 24 ministerial departments and 2 executive agencies by the end of April 2013
- the transition of over 300 government agencies and public bodies, by the end of 2014
- the 2015 general election
All of these, particularly the agency transition, placed a great strain on our ambitions to build a lasting, needs-led platform. In order to meet the deadlines for each of these phases we elected to build the smallest thing that could meet users’ needs and iterate from there, conducting the user needs identification, product development and software design in parallel and across separate teams working apart from each other. This was a pragmatic decision that allowed us to protect the teams involved and to get on with the hard job of bringing the government's public digital estate together.
But working fast in parallel teams to meet consecutive deadlines has meant that we’ve accumulated a lot of product and technical debt. GOV.UK today is made up of 3 separate and disconnected publishing systems spread over 70 applications, each with their own versions of common features, with variable user experiences. Between them, these systems have been used to publish over 180,000 pieces of content using 70 different templates.
The impact of all this accumulated complexity and variance is that the system is now becoming difficult to maintain and improve, as developers are forced to context-switch between multiple, different ways of making things. It also makes it more costly than it should be to build new tools to meet new needs, as we need to keep duplicating rather than reusing our own functionality. So it’s vital that we increase how much effort we’re investing in repaying our debt, to bring it back to manageable levels, and to get more value from the things we have built.
The GOV.UK publishing platform
GOV.UK is already a platform - it’s the cross-government publishing system used by thousands of writers around government every day to reach their users. But unlike the traditional technical definition of a platform, GOV.UK is not easy to build on, or to re-use.
We’re rebuilding the core architecture of GOV.UK to be easily reusable, easy to build on, and easy for third parties to integrate with - a single publishing platform for government services and information.
This will allow our publishers to more easily go where their users are (not always on GOV.UK), make it easier for other services to re-use the canonical information from GOV.UK, and make it simpler for our colleagues across government to build their own applications to meet their own needs. And it will centralise our core functionality, giving all our existing publisher users a consistent and well-designed experience.
We’ve split this work into several missions on the GOV.UK roadmap, and it will be done in phases:
Phase 1: a common API for serving citizens
The first part of this platform work is the creation of a single Content Preview system which allows editors to see draft content and navigate around it exactly as they can the live site. We’ve built this and it’s already been rolled out to our Specialist Publisher application, allowing publishers of manuals (like the Highway Code) and the specialist formats which appear in finders (like MHRA’s drug and device alerts) to preview their content without resorting to workarounds.
The next part of this work is a new universal tagging/linking system, which will be used to power the new search and browse functionality we need to join up all of the content on the site. You can read more about our navigation plans on this blog.
Soon after that we’ll be migrating what used to be called Mainstream publishing onto the new platform, helping us to design and build the features and functionality needed for Whitehall, our most used publishing tool.
We’ve already started development and migration into this new system. As we migrate the public-facing parts of the site, we’ll take the opportunity to make our systems consistent by re-using common components.
Phase 2: APIs for publishing
Centralising this functionality allows us to rapidly add new features to publishing tools, and more importantly to provide consistent features across all of our tools and for all of our users.
We expect to see the benefits of this platform approach accelerate as more functionality is built into the single system, and importantly for publishing users we can ensure a consistent user experience no matter where they’re writing their content.
Our plan to deliver all this is to build a new central publishing API that handles workflow and other publishing features on behalf of publishers. This API will store change history for every piece of content on GOV.UK, and will push that content out to a new document API (called the Content Store) which serves the public site.
We’re going to start this work by building centralised workflow on top of the Specialist Publisher.
The user benefit
We believe strongly that this work will enable our teams to go faster and provide better features for our publishing users, as well as providing the benefits to the public and the government that open, supported APIs will bring. We're really excited about the potential this work has, and will blog regularly about our progress as it unfolds.
Brad Wright is the Head of Technology across GOV.UK and other projects. Keep in touch: follow Brad on Twitter and subscribe to email alerts from this blog.
Want to join our team and help us with the next phase of GOV.UK? We're hiring.
1 comment
Comment by E. Brown posted on
Hi Brad,
Thanks for the update.
What's an API? Seems an important part of this post and of your plans, but isn't explained anywhere. The links to GitHub don't explain it.
Cheers,
EB
PHE