Skip to content

CONCEPT Cited by 1 source

Tech Radar as language / framework governance

Definition

The Tech Radar model — popularised by ThoughtWorks in 2010 — is a ring-based classification used by engineering organisations to govern the lifecycle of a technology (language, framework, platform, tool) inside the company. A technology sits in one of four rings:

  • ASSESS — worth exploring, not ready for production. Typically a pilot team is doing early evaluation.
  • TRIAL — worth pursuing on low-risk projects. Multiple teams are using it; platform-level integration may be partial.
  • ADOPT — recommended for use in production. Platform teams provide full support: service templates, CI integrations, documentation, reference projects.
  • HOLD — avoid / stop starting new work with it. Usually because a successor has been promoted to ADOPT.

As a governance primitive, the Tech Radar is more than a list — it's a commitment of platform-team investment. An ADOPT entry is a promise that the platform team will carry the technology forward (operate the CI integration, the template, the reference app, the observability wiring) so that product teams can default to it with minimal risk.

The Zalando instantiation

Zalando publishes its Tech Radar openly at opensource.zalando.com/tech-radar and uses it as the gating mechanism for language lifecycle decisions (sources/2021-06-30-zalando-how-we-use-kotlin-for-backend-services).

In 2021 Kotlin moved TRIAL → ADOPT. Four things triggered the promotion:

  1. Internal adoption signal — 100+ new applications written in Kotlin in a year.
  2. Qualitative community feedback — Guild-surveyed developer experience.
  3. Documentation / standards readiness — Kotlin Guild produced coding standards, template projects, reference applications.
  4. Central infrastructure support — platform teams committed to integrating Kotlin into the shared toolchain.

The promotion then operationalised by publishing the default backend stack (Spring Boot, Gradle, Ktlint, etc.) the Guild had converged on.

Ktor sits in ASSESS/TRIAL on the same radar ("growing adoption, predicted to gain popularity, possibly with GraalVM") — a lower commitment tier; product teams may use Ktor but shouldn't assume platform parity with Spring Boot.

Why ring-based governance works

  • Signal to product teams — a team choosing between "Kotlin (ADOPT)" and "Ktor (ASSESS)" knows the support cost delta without having to interpret tribal knowledge.
  • Decoupling experimentation from standardisation — ASSESS allows genuine exploration without implicitly committing the platform team.
  • Signal to the platform team — TRIAL → ADOPT is a decision to take on production-support cost. The platform team can explicitly say "not yet" by keeping something in TRIAL.
  • External artefact for hiring / external perception — an open Tech Radar is a recruiting and ecosystem-signalling device. Zalando publishing it means candidates know the stack before applying.

Trade-offs

  • Only works if the rings actually gate platform work — many orgs publish a Tech Radar but don't invest differentially by ring. Then the radar is documentation, not governance.
  • Slow to react to fast-moving ecosystems — a yearly or quarterly radar cadence can lag behind rapid library/framework churn.
  • Risk of TRIAL permanent parking — technologies that never graduate to ADOPT but never get HOLD-demoted accumulate as background noise.
  • Governance by exception — explicit HOLD entries require organisational courage; frequently easier to let a technology quietly rot without a HOLD ring.

Seen in

Last updated · 476 distilled / 1,218 read