As well as endorsing and advising on specific data standards, the Data Standards Authority (DSA) aims to develop more general data best practice across government. We also focus on putting in place assurance mechanisms to ensure these best practices are followed, and we blogged about some of these plans when we introduced the DSA in August.
As part of this, the DSA has just published new data guidance to help teams, which approve spend on technology and services, assess how data is managed. We’ve also published guidance for practitioner teams who are working on data exchange projects using APIs.
The new guidance has been put together with input from subject matter experts across government. It forms part of the Technology Code of Practice (TCoP) guidance collection on GOV.UK, which technology teams across government must follow.
Updating the spend control process to focus more on data
One of the aims of the DSA is to improve how data is assessed in the spend controls process. The spend controls process is there to ensure departments get the best value in any technology or service they purchase for their programme or project.
Spend controls are a central process that is managed by the Government Digital Service (GDS) and is supported by the TCoP. When GDS spend control technology advisors are looking at department spend on a particular project, they will analyse this against the TCoP to ensure the spend meets best practice guidelines.
The DSA worked with the Technology Policy team at GDS to update point 10 of the TCoP, “Make Better Use of Data”. We have also produced a related guide detailing how teams in government should manage data for access and reuse.
Teams going through spend controls will need to be aware of these new areas relating to data, including the need to:
- form stronger exiting arrangements within supplier contracts - if you buy a technology or service, you should ask the supplier to provide access to all data in an open data standard format and through an API that follows the GDS API standards
- provide access to your data at the database level to ensure your data is accessible and can be reused
- manage your data as an asset by providing a record of your data set in your information asset register and by following government data standards
New guidelines on API development
The new delivery guidance on API development is aimed at ensuring APIs meet user needs and is published as part of the GOV.UK API design collection.
The guidance was developed by subject matter experts at the NHS, HM Revenue and Customs and Department for Work and Pensions, but also received input from the wider government API community. It is intended to help those who have worked on frontend services understand what they will need to consider if they move to roles within API development teams. Tony Heap, NHS Digital API Management Product Owner, made the case for this guidance in his post on the GDS Technology blog back in March:
“The GDS Service Manual includes plenty of guidance on agile software delivery, including details of the specific phases of an agile project. Initially it’s not obvious how these phases should apply to delivering APIs. With a bit of interpretation the phases do fit quite well, but this relies on having strong experience in developing APIs…
…adding guidance on API agile delivery to GOV.UK will recognise that APIs are services too. It’ll also recognise that agile API delivery teams need different skills than teams working on citizen-facing services, and may need to focus on different areas.”
We’d like to hear from you
We are putting together some further guidance with the API community on the subject of API management while also updating the Government API Standards. If you feel you could contribute to guidance in this area, please get in touch.
We know that teams across government are looking for guidance on specific data problems, and welcome suggestions on what we can provide in that area. To get in touch with the DSA, you can email us or leave a comment below.
2 comments
Comment by suman posted on
What is an API? sorry, if I am a but thick. It mentioned every other acronym but not what is an API.
Comment by nickmanton posted on
Hi Suman, thanks for asking and apologies for missing one of the explanations. API stands for Application Programming Interface, which is a set of instructions that tells two or more computers how to communicate directly with each other