← Back to principles

Platform

Provide Capability Led, Opinionated Defaults with Conscious Deviation

Statement

Provide Capability Led, Opinionated Defaults with Conscious Deviation

What this means in practice

Clear, supported paths are defined around capabilities and outcomes, not specific vendors or hosting models. The platform provides opinionated defaults that work well for the majority of use cases, reducing decision fatigue and ensuring consistency. Where context or constraints require deviation, this is explicitly supported through a conscious, documented process rather than being blocked or ignored.

Why this matters

Opinionated defaults accelerate delivery by reducing the number of decisions teams must make, while ensuring consistency and supportability across the organisation. Without them, every team reinvents the wheel, leading to fragmentation and increased maintenance burden. Equally, rigid enforcement without a deviation path creates friction, workarounds, and shadow IT. Conscious deviation balances standardisation with the flexibility needed for real-world delivery.

Practices that meet this principle

  • Platform capabilities are defined around outcomes (e.g. "run a container", "store data securely") rather than specific products

  • Default technology choices and configurations are documented and actively maintained

  • A lightweight, documented process exists for teams to request and justify deviations from defaults

  • Approved deviations are recorded with rationale and reviewed periodically

  • The platform team regularly reviews defaults to ensure they remain appropriate and well-supported

Validation

A project meets this principle when:

  • Teams use platform-provided defaults for standard capabilities without needing to make bespoke technology choices

  • A documented deviation process exists and has been used where needed

  • OR:

  • Teams are not blocked from legitimate deviations, nor do they bypass defaults without documentation

Scoring Guide

  • Score −1 — Disagreement / Rejected: The team acknowledges this principle is applicable but has explicitly decided not to follow it for this product. A rationale and decision record exist explaining why opinionated defaults with conscious deviation are not adopted.

  • Score 0 — Not doing: No defined defaults or standard paths exist. Every team makes independent technology choices. No deviation process; teams either go rogue or are blocked without recourse.

  • Score 1 — Planned: The team has committed work to define opinionated defaults and a conscious deviation process. An owner and target date exist for documenting standard paths and establishing the deviation workflow. The plan is tracked.

  • Score 2 — Adopted for new work: Documented, opinionated defaults exist for standard capabilities and are used by all new work. A lightweight deviation process is in place and has been used where needed. Platform capabilities are framed around outcomes rather than specific vendor products. Any exceptions are explicit and reviewed.

  • Score 3 — Enforced for new work + migration plan: Opinionated defaults are systematically enforced for all new work through process or tooling (e.g. automated policy checks, standard templates). A tracked migration plan exists to bring legacy systems and undocumented deviations into alignment with the defaults framework.

  • Score 4 — Fully adhered: Defaults are comprehensive, actively maintained, and used across all work. Deviations are recorded with rationale and reviewed periodically. The platform team regularly reviews defaults for continued appropriateness. Teams are neither blocked from legitimate deviations nor bypassing defaults without documentation. Remaining gaps are minimal, known, and time-bound.