I recently had the pleasure of attending a public consultation on the latest iteration of the Supplier Standard. 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:
- User needs first
- Data is a public asset
- Services built on open standards and reusable components
- Simple, clear, fast transactions
- Ongoing engagement
- Transparent contracting
Ideologically I am 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 will genuinely 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 won’t report what anyone said, but I would like make some public 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 if we’re not careful all we’ll end up with is 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, as GDS standards spread out to the wider public sector, let’s make sure that everyone understands the concept of proportionality. The £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 said them a lot throughout the consultation meeting. I hope they stick.
*I use this as an example only; Isotoma didn’t bid for that particular project, it’s just a great example of a vital application with a small budget generating exactly the kind of data that would fall under this requirement
