The Government Digital Service has published a revised version of the Technology Code of Practice that departments must use when designing, building or buying digital services.

Government departments must adhere to the Technology Code of Practice when designing digital services – Photo credit: Pixabay

A first draft of the revised code, originally introduced in 2013, was published in June this year. GDS said that the update was to encourage a more adaptive and innovative approach to technology use in government.

The new code came into force immediately and all technology services that require Cabinet Office approval – technologies that cost more than £5m or more than £1m if they are also delivered by Independent Shared Services Centres – will be assessed against it.

Related content

GDS updates code of practice for digital projects
Do you know the right class for your data?

In a blogpost, David Mead, who has led on the code’s update, said that the code would remain one of the main ways GDS would continue to drive reform of government technology.

This is possible because the code allows GDS to challenge government spending on technology, and in theory prevent departments from entering into long-term, high-value contracts.

Simplicity for users

When GDS first launched the update of the code, it said it wanted to make it easier for users to understand, and the code now consists of 14 mandatory points – down from 21 elements in the previous version – that must be met by government digital services.

These include rules on defining user needs and sourcing strategies, accessibility, the use of open standards and the cloud and how to make services secure.

Technology projects must also demonstrate that the service is end-to-end and ensure they use common government sourcing routes.

The code also includes a number of points on what GDS defines as a “sensible contract”, for instance, that they are not over £100m in value without an “exceptional reason”, include a break clause at a maximum of two years and ensure competition from the widest possible range of suppliers.

In addition, Mead noted in his blogpost that there were two areas – on cloud adoption and the use of the cloud first policy and on the use of Application Programming Interfaces – that needed more work.

“One of the interesting outcomes of writing the new code is that it’s highlighted some issues where we think our existing guidance isn’t clear enough, or doesn’t go far enough,” he wrote. He added that the use of APIs was a “key component” of the cross-government services GDS wanted to see.

Mead said that work had already started on this, but that GDS wanted any further feedback from users.