Digital service standards and platforms

In spring 2014, the Government Digital Service published the Digital by Default Service Standard. I co-wrote it with Andrew Greenway, with input from people across the Government Digital Service. The aim was to define the minimum standard a government service should meet before it was allowed to appear on the GOV.UK website.

You can still find the 2011 version on the National Archives website.

Subsequently, the standard has been updated through a couple of iterations, been renamed the Government Service Standard, and is currently under review.

One reason I’ve included the link to the original version above is that, with the benefit of hindsight, I think we missed a couple of tricks when it came to encouraging the development of shared capabilities across government.

The UK service standard and government sharing

The UK service standard contained two points aimed to encourage sharing across government:

15. Make all new source code open and reuseable, and publish it under appropriate licences (or have provided a convincing explanation of why this cannot be done for specific subsets of the source code)

16. Use open standards and common Government platforms (eg Identity Assurance) where available

When it comes to the development of government platforms, those are both are important. Opening code means others in the organization can find and build on the work. It’s what Google does internally.

Requiring the use of existing platforms and standards saves time and money, and hopefully provides a better experience to users.

However, what those points fail to address is what types of thing should be worked on collaboratively, and how sharing code can be made into an active process, rather than a passive one.

They also fail to say how new platforms might emerge, especially platforms that can be used beyond, not just within, government.

Finally, they place no commitments on teams across government to play their part in developing the shared data infrastructure that platform government is going to require.

Influence on international standards

The other reason I included the link to the original service standard above is that it had an impact beyond UK central government. Anecdotally, and evidenced though licensing statements and use of similar language, digital service units in other countries have been influenced by the UK standard.

For example, if you look through the list of service standards from around the world, you can find similar statements to point 16:

Adopt a reusable solution that meets the open standards and introduce private innovation capability to reduce the overall cost of digital service ….. Use reusable common platforms and components, which meet open standards and have passed testing, to improve service rapidly. — Government Digital Service Guidelines (Beta Version), Taiwan

Reuse existing technologies and common components. Make use of technologies that provide scope to develop and scale easily and that are cost effective. — Digital design principles , States of Jersey

Use open standards and common platforms — Digital Service Standard , Government of Ontario

Use open standards, existing authoritative data and registers, and where possible make source code and service data open and reusable under appropriate licenses. — Local Government Digital Service Standard, LocalGovDigital

We will make full use of the existing public and private online services. — Principles of digitalisation, Government of Finland

In my opinion¹, eight of the thirteen standards I looked at include something broadly equivalent on reuse (Taiwan, Jersey, Ontario, Finland, Scotland, LocalGovDigital, Austalia, New Zealand). As in the UK, I think they can also be characterised as passive: if stuff exists, you should reuse it.

There are fewer examples of explicit requirements for open code (and that point has, sadly, never been adhered to that well in the UK either ²). Only two standards have an explicit top-level requirement to open code (Australia and Scotland):

Make all new source code open and reusable, and publish it under appropriate licences (or provide a convincing explanation as to why this cannot be done for specific subsets of the source code). — Scotland

Make source code open — Digital Service Standard, Government of Australia

However, a further four (Canada, LocalGovDigital, USDS and New Zealand) make some mention to open code as part of a general commitment to openness ³:

…new code developed in delivery of services open to the outside world for sharing and reuse under an open licence. — Government of Canada Digital Standards, Government of Canada

… where possible make source code and service data open and reusable under appropriate licenses. — LocalGovDigital Service Standard, LocalGovDigital

When appropriate, publish source code of projects or components online — Digital Services Playbook, US Digital Service

Share source code where possible, proportionate to risk. — Digital service design standard, New Zealand Government

As with the UK standard, most of these come with some sort of caveat: ‘where possible’, ‘proportionate to risk’ etc ⁴.

With a couple of exceptions listed below, international standards also fail to place clear, explicit requirements on either the creation of new platforms, or the active co-development of shared code and data infrastructure.

What should change? Examples from the US, Mexico and the UK.

So, to recap, I think we missed a couple of tricks with the UK service standard back in 2011 and that has mostly been repeated by the other standards around the world.

However, there are a couple of examples that show a slightly different approach – two from the US Digital Service Playbook, and one from the Principios generales de diseño de servicios digitales by the Federal Government of Mexico:

Provide datasets to the public, in their entirety, through bulk downloads and APIs (application programming interfaces) — Digital Playbook, USDS

Ensure that data from the service is explicitly in the public domain, and that rights are waived globally via an international public domain dedication, such as the “Creative Commons Zero” waiver – Digital Playbook, USDS

Government as a platform: Create reusable components, content, transaction services and rules for reuse in government. — Principios generales de diseño de servicios digitales, Federal Government of Mexico, (Translation via Google Translate)

While I can’t find any examples online of the impact this has had in Mexico, the approach of the VA Digital Service (part of the Veterans Administration in the US) in creating APIs for its services and the developer resources avaliable for the FOIA.gov service demonstrate the approach set out in the USDS Playbook ⁵.

Back in the UK, the development of the GOV.UK Design system shows a new approach to developing shared components, as a cross-government community effort with dedicated support. I’d imagine learnings from that approach will feed into the upcoming changes to the UK standard.

Taking these as a basis, I think future service standards should probably contain something along the lines of the following three points:

1. Expose all services via an API that can be used within and (wherever possible) beyond government ⁶
2. Catalogue all the data used in a service and identify what can be developed as shared infrastructure
3. Actively identify and support reusable components, tools and design patterns

Footnotes

1. Not all of these documents are 100% comparable, some of them are serving slightly different functions (e.g. Singapore says much more about design specifics), and were developed by different people in different political contexts. As such, this inevitably comes down to opinion and interpretation, so please get in touch if you think I’ve misrepresented something.
2. I’d love someone to do a study of what percentage of services passing the assessment process in the UK actually opened up any code.
3. On the canonical web page for the standard. There may be other mentions in guidance elsewhere.
4. I have a hunch one reason for this is the extent to which an organisation sees itself as an ‘engineering’ organisation vs a ‘policy’ or ‘design’ organization. Shared code can be seen a nice to have, rather than a way of working.
5. As with the value of open code, I also wonder how much the focus on APIs is also down to how much an organisation sees itself as an engineering organisation
6. See the Bezos memo

You can find the list of service standards here and search them using this Google custom search.