Data as a public asset

A headshot of Andy Theyers Andy TheyersFounder

Around ten years ago I had the pleasure of attending a public consultation on the Supplier Standard for digital and technology service providers. For the uninitiated the Supplier Standard is a set of goals published by GDS it hopes both suppliers and public sector customers can sign up to when agreeing on projects.

You can read the current iteration of the standard on GOV.UK (it’s blessedly short), but the 6 headlines are:

  1. User needs first
  2. Data is a public asset
  3. Services built on open standards and reusable components
  4. Simple, clear, fast transactions
  5. Ongoing engagement
  6. Transparent contracting

Ideologically I remain massively behind a lot of it. These goals go a long way to breaking the traditional software industry mindset of closed source software backed up with hefty licence fees and annual support and maintenance agreements. Projects meeting these standards genuinely help move public sector IT purchasing to a more open – and hugely more cost effective – model.

The conversations within the event were rightly confidential (and I’d struggle to recall them correctly after all this time anyway!), so I won’t report what anyone said, but I would like to make some comments on point 2 – Data is a public asset.

The standard says:

"Government service data is a public asset. It should be open and easily accessible to the public and third-party organisations. To help us keep improving services, suppliers should support the government’s need for free and open access to anonymised user and service data, including data in software that’s been specially built for government."

That first sentence is fantastic. Government service data is a public asset. What a statement of intent. OS Maps. Public asset. Postcode databases. Public asset. Bus and train timetables. Public asset. Meteorological data. Public asset. Air quality. Health outcomes. House prices. Labour force study. Baby names. Public assets one and all.

But can we talk about the rest, please?

"It should be open and easily accessible to the public and third-party organisations."

What do we mean by open and easily accessible? The idea is a great one, with rich APIs and spreadsheet downloads of key data, but we need to be careful not to end up with a bunch of poorly planned, hurriedly implemented and unmaintained APIs.

Open data is a living breathing thing. Summary downloads need to be curated by people who understand data and how it might be used. APIs need to be well planned, well implemented and well documented, and the documentation has to be updated in line with any changes to the software. Anything less than that fails to meet any sensible definition of open or easily accessible.

And if nothing else a poorly planned or implemented API is likely to be a security risk. Which leads me to my next point:

"[…] free and open access to anonymised user and service data […]"

Woah there for a second!

We all know how hard genuine anonymisation is. And we all know how often well intentioned service owners and developers leak information they genuinely believed was anonymised, only to have it pulled apart and have personal information exposed.

This goal, like the others, is genuine, laudable and well intentioned. As suppliers to publicly funded bodies we should absolutely be signed up to all of them. But, now that GDS standards have spread out to the wider public sector, we need to make sure that everyone understands the concept of proportionality. A £20k to £40k budget put aside for a vital application to support foster carers, for example, is best spent on features that users need, not on APIs and anonymisation.

Proportional. Proportionality. I do remember saying those words a lot throughout the consultation meeting. I continue to do so.

A decade later, is it time for another consultation on these standards? Or do they still outline best practice for technology suppliers and public sector customers working together to create good value? I’d be interested to know your thoughts.

Join our mailing list

We don't send many emails, but when we do you'll want to read them.
Make sure you're on the list.