Products and platforms¶
Defra builds and runs technology as long-lived products on shared platforms, not as one-off projects. These draft guardrails describe what that means for teams.
Doctrine: 1. Platforms before projects. Built as products, 2. Standards and guardrails before exceptions, 3. Reuse before buy
Principles: 1. Delivery-focused architecture, 3. Maximise value, minimise waste
Who these guardrails apply to
The core department. Whether the products and platforms guardrails also apply to Defra's arm's length bodies is still to be confirmed.
Applies the DDTS doctrine platforms before projects.
Draft guardrails
These guardrails are new drafts from the guardrail backlog. Comment on them by opening an issue.
GR-PROD-01 Fund and run products, not projects¶
Should Build and run digital services as products, owned by a long-lived team that keeps improving them, rather than as projects that end at go-live.
Why: services are used for years. When the team that built a service disbands at launch, knowledge is lost, technical debt grows and the service slowly fails its users.
How to meet it: plan funding and team continuity beyond go-live from the start. If a project model is unavoidable, agree before go-live which product team will own the service in live (GR-OPS-05).
GR-PROD-02 Name the product owner and service owner¶
Should Every product has a named product owner, and every service a named service owner, who are accountable for it throughout its life.
Why: decisions about priorities, risk and retirement need someone with the authority to make them.
How to meet it: record both in the service catalogue and in the repository README, and keep them current when people move on.
GR-PROD-03 Contribute to platforms rather than working around them¶
Should When a shared platform does not meet a need, raise it with the platform team and contribute to fixing it, rather than building a local workaround.
Why: every workaround becomes something else to secure, support and eventually remove, and other teams have the same need.
How to meet it: talk to the platform team first. If you must work around a gap to meet a deadline, record it in an ADR with a plan to move back on to the platform.
GR-PROD-04 Plan for the end of a product's life¶
Should Know where each product is in its lifecycle - growing, stable, being replaced or retiring - and plan its retirement as deliberately as its launch.
Why: products that linger after they are replaced keep costing money and carrying risk.
How to meet it: record the lifecycle stage in the service catalogue, and follow retire a service when the time comes.