In 2013, we introduced the Technology Code of Practice. This gives guidance on the best way to design, buy and build technology and digital services to meet user needs.
We've used the Technology Code of Practice to examine and challenge government spending on technology through the spend controls process. It’s given us a way to engage with departments and agencies and help them revise and improve their technology plans.
Staying relevant
Government technology has changed a lot and huge progress has been made since the Technology Code of Practice was originally published. Our new draft takes this progress into account, while continuing our focus on the user needs that have been at the heart of the transformation of government technology.
In drafting the new Technology Code of Practice, we’ve tried to write a document which provides:
- a clear statement of what a good approach to technology looks like
- a flexible, context-sensitive framework to assess technology plans against
We want government to continue to be a smarter user of technology, and to do that government needs to be a smarter customer. The new document reflects an increased focus on good commercial behaviours.
We also want to recognise the variety of strategic, commercial and business contexts in which government technology work happens, and enable departments and agencies to deliver great technology that meets their needs.
Our goals
We want the new Technology Code of Practice to:
- encourage a more mature approach to sourcing IT in government, supporting departments moving away from large aggregated contracts to the preferred multi-supplier contracting model
- continue to promote competition and diversity of technology suppliers to government, both by improving buying practices and by making government a more attractive and willing customer of innovative, new technologies
- help people determine the ideal target state for their technology services and make better decisions on when to design and build solutions and when to use off-the-shelf products or commodities
- promote a more adaptive approach to technology, based on clear principles of good practice as well as the context in which technology will be planned, bought and used
Updating the controls process
Alongside reviewing the Technology Code of Practice, we’re also looking at the spend controls process and how we assess departmental technology plans. We’ll be publishing more details on that in the future.
We need your help
This is an important document. So, we’re publishing this draft version, to give you the opportunity to help us make it better.
We need your input on:
- whether you understand what this document is for
- whether you understand what we think a good approach to technology is
- whether you agree with our view of what a good approach to technology looks like
- whether you think you could use this document to inform your technology plans
- whether you understand what the GDS spend controls will be looking for
Tell us what you think. Tell us what you think is good and what you think is bad, where we’ve got it right and where we’ve got it wrong. Email us or comment below, and we’ll make sure to take those views into account as we iterate the Technology Code of Practice.
Please note the deadline for feedback is Friday 8 July 2016
20 comments
Comment by Julian Harris posted on
"We are now updating it to ensure it stays as up to date possible."
You could probably just remove this whole line
Comment by David Mead posted on
Thanks Julian, just goes to show that no matter how good a job you think you've done on something there's always someone out there who can help you improve it!
Comment by Russell Cosway posted on
This is not an easy read and feels more like a checklist or index than a Code of Practice. Many of the links used, which I accept are not in scope of your review - but if you reference them you have an extended responsibility, are themselves wordy and non-dynamic. This clearly straddles a lot of other initiatives and the consistency and deep interconnectivity is sadly lacking.
The document referencing is not good for directing comments, so i'm forced to say 'One of the links under "Designing the solution" heading, 4th bullet of "2. Making things secure by" points to a withdrawn page (https://www.gov.uk/government/collections/cloud-security-guidance). Saying link in 3.2.4 would have been so much easier. In fact, in consulting on these documents a paragraph commenting system would be better so I could embed my feedback while reading instead of hopping between pages.
Comment by David Mead posted on
Hi Russell, thanks for taking the time to comment! One of the main uses of the Tech Code of Practice is to be a framework against which technology plans and projects can be assessed, that's why in places it feels like a checklist. Re: other links, we're always looking at how we can improve the quality of the guidance we provide so if there are any specific pieces you feel are lacking please do let us know!
We've changed the withdrawn link you found, thanks for pointing it out! As to your wider point about the ease of commenting on this draft, we'll certainly look at how we can make it easier for people to contribute.
Comment by Dr Alue posted on
It's really good to see GDS working aloud in a very public way.
It's also good that the TCOP is meant to be understood as always evolving - that's important.
My initial thoughts are that after a fantastic first phase of reform, change and support, the next steps are building on that:
1. Open Data - the perception is that digital services can be built and no regard given to the opportunity to publish open data created directly or incidentally as part of the service. The Scottish Government has prioritised open data by placing it firmly in their own digital service standards.
2. Commercial Design (not just procurement). Technology, security, user experience design .. and many other pillars of a digital service have all been reformed massively. But I do feel commercial thinking and doing haven't as much. To be clear - procurement is simply the process of fairly buying something - it should be boring. There is much broader set of issues above and around procurement - such as treated a differentiated market in a differentiate away (multi-sourcing commodity vs special products), maximising the value IPR, transparency into (sub)contracting, contracts designed for user needs not copied-n-pasted from a legally-defensive template, intelligent responses to supplier behaviour .. and so much more. ... GDS have been great at explaining that designing security, technology, ux, .. are all about explaining a story .. "what did you do, how did you do it, what will you do after go-live" and this is precisely how commercial design should be done, not a 1-shot-hope-for-the-best procurement.
3. Spend Controls - I wonder if the reach of spend controls should be extended? You won't be surprised to hear of some that try to engineer coming just "under" the thresholds. Similarly some bodies feel they are beyond reach - public independent inquiries, for example. If arguments of independence from spend controls are not valid for whitehall departments, they are similarly invalid for inquiries.
A related point around spend controls is follow up of conditions where a department was allowed to proceed with a non-ideal but pragmatic approach subject to conditions which required them to be in a much improved position next time round.
4. PSN - I really think the case for PSN is difficult. The internet is the commodity - not a bespoke special version of it. At a technical level - it is no different to the internet offered to the many many enterprises out there - from banks to supermarkets, from airlines to demanding modern on-line digital services we all consume. The PSN suppliers use the same equipment and data paths. From a security point of view there is no difference - it's the same commercial grade security. And anyway, the trajectory of good architecture is applications and data not replying on a special bespoke network to provide security. ... So think start to encourage the building of secure application and services that work perfectly fine "on the internet" - and yes, it is possible, and CESG have been very happy with many of them.
Comment by David Mead posted on
Dr Alue, thank you for taking the time to comment, we will take your suggestions into account.
Comment by Steve posted on
David Mead - we'd appreciate a more considered response than that!
There are lots of considered ideas that Dr Alue provided. What do you think about them?
People won't engage if they feel you're ignoring their responses.
Comment by Lucy D posted on
Hi Steve
Thank you for your comment. We are currently at a stage where we are bringing together input from a lot of different groups. As such any and all comments including those made by Dr Alue will be taken into account. We are't yet at a position to determine exactly how that information will inform developments of the Tech Code of Practice but we will be sure to provide a follow up blog post which will explain how we have made use of everyone's input.
Hope that helps?
Comment by Ian Charlton posted on
I'm getting "This page can't be displayed" from the link to the draft.
Comment by Lucy D posted on
Hi Ian
Thanks for letting us know. We will email you a document version. We have had this issue raised a few times. It could be the format we have chosen to use - we will take this into account for the future!
Comment by Mark posted on
Could you clarify 'objectively evaluating potential public cloud solutions first – before you consider any other option' you do mean public cloud by the NIST definition, rather than community clouds? i.e. using clouds open for use by the general public, such as the like of Azure, AWS, Google Cloud Platform, rather than community clouds such as provided by Skyscape?
Could you also clarify how this relates to future of PSN, is it likely it'll become less relevant over time or is the intention to put PSN connectivity into public clouds, either ones deployed in the UK or outside of the UK?
Thank you.
Comment by David Mead posted on
Hi Mark. Thanks for your comment.
The short answer is yes, we are talking about public cloud according to the NIST definition. We could probably be clearer here, thanks for pointing it out!
With respect to the PSN: this is all a clarification of current policy (such as the Cloud First policy) and nothing is changing as regards PSN use cases.
Hope that helps?
Comment by Daniel Bromley posted on
Re: 'suppliers must not provide either systems integration, service integration or service management services at the same time as providing a component service within that system'
The desire for independence from 'systems integration' and provision of the component seems potentially counterproductive (or more clarity is needed). For example, are you saying that IBM in delivering a system, can never use a DB2 database? Does that really give the customer leverage in the market?
I think the point of this original red-line was to prevent a supplier marking its own homework i.e. back in the SIAM model, having the service integrator try and police its own services. Is systems integration a step too far/counter productive?
Comment by David Mead posted on
Hi Daniel, thanks for your comment.
We'll look at how we can clarify our intent here, as you say we want to ensure good governance of disaggregated systems and services while not imposing counter-productive limits. We'll have another run at this in the next iteration.
Comment by Tom posted on
How about requiring some defined point-of-no-cancellation for each new technology project, beyond which it must be committed to being completed, tested and deployed, and contractors may not withdraw - even if there is a change of government?
The British government has a very long and embarrassing history of cancelling expensive technology projects when they were very nearly finished, or sometimes actually finished and merely in need of running-in and having the bugs ironed out - up to and including the cancellation of our fully-functional satellite delivery rocket which performed a perfect launch and orbital insertion immediately after its cancellation was publicly announced - thereby spending the maximum possible amount of money for the least possible return. This always results in a colossal waste of time and resources, followed by a desperate scramble for alternative solutions to the problem the original project was going to solve.
Comment by Tariq Rashid posted on
My contribution - hopefully a clear setting out of the problem and a simple understandable principles of what good looks like, and a remedial strategy for commercial design.
https://medium.com/@postenterprise/commercial-design-3a6c1e1943ba
In short:
1. We want long term value. Beyond this procurement.
2. To do that we need sustained competition and actionable choice, both.
To get from 2 to 1 we need the support of 4 pillars:
1. Diverse supply - eg oss, SMe, cloud, different business models
2. Disaggregation - remove shield to market competion, increase choice, incl time disaggregation
3. Autonomy - keep ownership of destiny, eg easy contract exit, incl assets eg IPR
4. Transparency - drives better buyer and seller behaviours, informs wider market
Commercial thinking (not procurement) is sorely lacking in government. Simon Wardley also speaks of different buying behaviours and "gameplay". This "savvy navigation" is much needed - because the market of sellers is doing it ... but the government buyers are not.
This has fallen between stools which is why it hasn't really been fixed. Finance provides money. Proxuremebt helps the process of spending it. Yet no-one takes the micro and macro view of why and how.
Comment by Jenny M posted on
There feels like a bit of potential conflation between the promotion of a cloud-first strategy and the recommendation to use commercial off the shelf products and services where possible. e.g. the last paragraph of https://www.gov.uk/government/news/government-adopts-cloud-first-policy-for-public-sector-it which says "Off-the-shelf products from the Cloud can be up to 30% of the cost of bespoke solutions."
Would it be simpler to combine these into a single recommendation to use cloud-based OTS products?
If buyers cannot find suitable cloud-based OTS products, is there any guidance over which would be preferred - a non-cloud-based OTS product or a cloud-based bespoke solution? Or does it just come down to the value for money in each case?
Comment by Jenny M posted on
Relatedly, we would find it helpful if buyers could make it clear in their requirements (preferably in the high-level description of a tender, rather than within a detailed requirements document) whether they prefer OTS solutions, or have already considered OTS solutions and are now looking for a bespoke solution.
Comment by David Mead posted on
Thanks for your comment Jenny. We want government to enjoy the advantages that embracing cloud solutions can bring. Denise's point back in 2013 was that OTS cloud solutions can be far, far cheaper than bespoke solutions, and that's even truer today. As the cloud first policy says, if public cloud solutions aren't the answer then alternatives need to be justified on a value for money basis.
We'll be publishing a new draft of the Tech Code of Practice next week, hopefully clarifying some of these issues and others that have been raised with us. I hope you'll feed back on that too!
Comment by Dr. Hassan posted on
How the Cloud First Policy applies to sectors like Health Sector (NHS), Financial etc. NHS especially still lives in old ages and due to data protection legislations etc they are and will not move over to the Cloud. How does these sectors align with TCOP and interact with other Gov. departments.
By reading TCOP, it sounds more like a theoratical nice to have document without practical approach.
Is there any presentation or Video or seminar /webinar discuss explaining the TCOP in digital services ?