Skip to content
Alpha

This site is an alpha version and is still being developed in the open - your feedback will help us improve it. See the roadmap. Last updated: 14 October 2026.

Version in force: 0.3.0 (6 October 2026).

Choosing technology

How to decide whether to reuse, buy or build - and how to avoid being stuck with the choice.

Who these guardrails apply to

The core department. Whether the choosing technology guardrails also apply to Defra's arm's length bodies is still to be confirmed.

GR-TECH-01 Look for something to reuse first

Must Before buying or building, check the technology capability catalogue and cross-government components for something that already meets the need.

Why: Duplicate capabilities multiply cost, security risk and support effort.

How to meet it: Record in your ADR which strategic options you considered and why they did or did not fit. If a strategic option is close but not quite right, talk to the owning platform team before building around it.

Phases, evidence and status for GR-TECH-01
Status
Draft
Phases
Discovery, Alpha
Led by
Technical architect
Evidence
  • Discovery: Existing Defra and cross-government options for the need identified from the technology capability catalogue
  • Alpha: ADR recording the reuse options considered and why they did or did not fit
  • Significant change: ADR showing reuse options considered for any new component
Automated check
Manual
Maps to
Service Standard 13; Technology Code of Practice 8
DDTS doctrine
1, 2, 3
Owner
Architecture team, last reviewed 2026-10-01, since v0.1.0

GR-TECH-02 Buy commodity, build differentiating

Should Buy or use SaaS for commodity needs (email, HR, finance, CRM, document management). Build only where the capability is specific to Defra's mission and no product fits without heavy customisation.

Why: Heavily customised products combine the cost of building with the constraints of buying.

How to meet it: If you are configuring more than you are using out of the box, stop and reconsider. Prefer configuration over customisation; avoid modifying vendor code.

Phases, evidence and status for GR-TECH-02
Status
Draft
Phases
Discovery, Alpha
Led by
Technical architect, Product manager
Evidence
Buy or build options appraisal in the ADR or business case
Automated check
Manual
Maps to
Service Standard 11; Technology Code of Practice 11
DDTS doctrine
1, 2, 3
Owner
Architecture team, last reviewed 2026-10-01, since v0.1.0

GR-TECH-03 Plan your exit before you enter

Should Any new product, platform or significant supplier dependency has a documented exit plan covering data export in open formats, contract terms and an estimate of switching cost.

Why: Lock-in is sometimes a sensible trade-off, but it must be a deliberate one.

How to meet it: Include an exit section in your ADR or business case. Make sure contracts give Defra ownership of its data and the right to export it.

Phases, evidence and status for GR-TECH-03
Status
Draft
Phases
Alpha, Beta, Live
Led by
Technical architect, Delivery manager
Evidence
  • Alpha: Draft exit plan for each new product, platform or significant supplier
  • Beta: Exit plan agreed, with contracts giving Defra its data and the right to export it in open formats
  • Live: Exit plan reviewed at contract renewal, with switching cost estimated
  • Significant change: Exit plan updated for any new product or supplier
  • Retire: Exit plan carried out - data exported in open formats and contracts ended
Automated check
Manual
Maps to
Technology Code of Practice 11
DDTS doctrine
1, 2, 3
Owner
Architecture team, last reviewed 2026-10-01, since v0.1.0

GR-TECH-04 Assess SaaS before you adopt it

Must SaaS and third-party hosted products are assessed for security, data protection, data location, accessibility and integration before contract.

Why: Supply chain risk is one of the biggest sources of security incidents in government.

How to meet it: Use the Secure by Design supplier assurance activities, complete a DPIA if personal data is involved and confirm the product supports single sign-on with Microsoft Entra ID for staff (GR-IAM-02).

Phases, evidence and status for GR-TECH-04
Status
Draft
Phases
Discovery, Alpha
Led by
Security architect, Technical architect
Evidence
  • Discovery: SaaS and third-party products under consideration listed, with the assessments they will need
  • Alpha: Security, data protection, data location, accessibility and single sign-on assessed before contract
Automated check
Manual
Maps to
Service Standard 9; Technology Code of Practice 6, 7, 11; Secure by Design principles 2
DDTS doctrine
1, 2, 3
Owner
Architecture team, last reviewed 2026-10-01, since v0.1.0

GR-TECH-05 Prefer open standards and portable technology

Should Choose products and components that use open standards and can be run on more than one provider.

Why: Portability keeps our options open and our commercial position strong.

Phases, evidence and status for GR-TECH-05
Status
Draft
Phases
Alpha
Led by
Technical architect
Evidence
ADR noting the open standards used and how portable the choice is
Automated check
Manual
Maps to
Service Standard 13; Technology Code of Practice 4
DDTS doctrine
1, 2, 3
Owner
Architecture team, last reviewed 2026-10-01, since v0.1.0

GR-TECH-06 Get spend approval early

Must Spend that falls under the government digital and technology spend control is discussed with the architecture team before procurement starts.

Why: Architecture questions raised at the end of a procurement are expensive to answer.

Phases, evidence and status for GR-TECH-06
Status
Draft
Phases
Discovery
Led by
Delivery manager, Product manager
Evidence
  • Discovery: Architecture team consulted before any procurement under spend control starts
  • Significant change: Architecture team consulted before new procurement for the change
Automated check
Manual
Maps to
Technology Code of Practice 11
DDTS doctrine
1, 2, 3
Owner
Architecture team, last reviewed 2026-10-01, since v0.1.0