Implementing the technology code of practice in local government
How the council is applying the code to achieve its ambitions and meet government standards.
As previously mentioned in the croydon.digital blog, Croydon Council has signed up to the Local Digital Declaration which brings a focus and commitment to changing and improving how we design and deliver local public services in the internet age. There are many elements to the Local Digital Declaration but an important one, and the subject of this post, is how we use the Technology Code of Practice to go about building and procuring new services to achieve our ambitions and to meet government standards.
The Technology Code of Practice is a set of criteria that consists of 12 points (rather than principles) that must be considered for all new digital services and which must be met where appropriate. I won’t list all of the 12 points here or expand upon all of the benefits as this is done far better on the GOV.UK and Local Digital pages. What I will cover are some of our early thoughts on how to apply them; hopefully this will be of value to those reading this and you will comment on your own experiences (being open and sharing are part of the Code).
One of the first things we considered was ‘do we create our own Croydon version of the 12 points?’ We’d done something similar before to create some technology principles starting from scratch (which was a useful exercise and prompted much useful discussion) but we quickly decided that the 12 points were all relevant and that there was little to be gained by changing them (it would also of course go against what we hope to achieve by working in this way). What we are doing though is defining principles that sit below the key points and which provide more specific detail.
What we did find was that there was a high degree of common ground between the 12 points and our previously defined technical principles. This was encouraging but not too surprising given the direction of technology in government (and that we had looked at an earlier iteration at the time).
In addition to the 12 points, the Technology Code of Practice site contains lots of useful supporting information on how and why they should be adhered to and also links to a great many other sources of information which I recommend you make good use of.
One of the challenges we face as a Council in following the Code is that the majority of our line of business systems are ‘commercial off the shelf’ systems from third party suppliers so we have little or no influence over some of the points in the Code, for example, the supplier is unlikely to share their technology. The Code does perhaps lend itself more to developing new software but it does also cover buying systems and there are elements that are useful in tendering and evaluations. It’s absolutely not a reason for not following all 12 points, but it is a situation where you need to consider the ‘where appropriate’.
Another question with using the TCoP is how rigorously to apply all of the points and at what stage in the lifecycle. Some points are pretty non-negotiable (for example, make privacy integral and comply with GDPR) but I incline towards some flexibility and pragmatism with others (for example, open source may not always be the most appropriate). In terms of lifecycle, the sooner the TCoP comes into the dialogue the better but at a higher level of detail initially.
We’re also wondering about how TCoP fits into governance, particularly as we move into more agile ways of working and multi-disciplinary teams. Current thinking is that there is an architect in the team and they ensure the points are considered and met then link into the wider technical governance. Also needs to fit into spend control and service assessments. Which also raises a question about the overlap between some of the points in the service standard and the TCoP! But that’s one for another day.