# Technology Radar: [Organisation name], [Edition YYYY-MM]

> An organisation's view of the technologies it uses or is considering,
> grouped into four quadrants (techniques; platforms; tools; languages and
> frameworks) and placed in four rings (adopt, trial, assess, hold), with
> the reasoning, owner and movement since the last edition. Based on the
> technology radar concept popularised by Thoughtworks; all text here is
> original. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- A radar records opinions backed by experience in your organisation. Each
  blip needs a short rationale that a newcomer can understand.
- Keep the radar small: 40 to 100 blips. A blip that has not moved for
  several editions and is uncontroversial can be dropped.
- Build it in a session with practitioners from several teams, then let
  the governance group (section 6) confirm it.
- Publish the edition date and keep previous editions so movement can be
  traced. Many teams render the table into an interactive radar with an
  open-source tool; the table remains the source of truth.
-->

| Field | Value |
|---|---|
| Edition | [2026-10] |
| Scope | [All engineering teams / Data platform / Mobile] |
| Owner | [@architecture-guild] |
| Contributors | [Names or teams] |
| Previous edition | [Link] |
| Next edition due | YYYY-MM-DD |
| Status | [Draft / Published] |

## 1. Purpose and how to read the radar

<!-- Guidance: Tell readers what the radar is for and what it is not (it is not a procurement list or a mandate). -->

This radar helps teams pick technologies with confidence and shows where
the organisation is heading. A blip's ring is advice based on experience
inside [organisation]. It is not a mandate: teams can use technologies in
any ring, but technologies in Hold need a recorded reason (section 6.3).
Anything not on the radar is neither approved nor forbidden; propose it
(section 6.1).

## 2. Quadrants

<!-- Guidance: Keep the four classic quadrants unless you have a strong reason. Define them so placement is consistent. -->

| Quadrant | What belongs here | Examples of kinds of blips |
|---|---|---|
| Techniques | Ways of working, practices, architectural and process approaches | Trunk-based development, architecture decision records, threat modelling |
| Platforms | Things we build and run software on: cloud services, databases, runtimes, infrastructure | Managed Kubernetes, PostgreSQL, a message broker |
| Tools | Software that helps us build, test, deploy and operate, but is not the platform | Build tools, linters, observability tools, IaC tools |
| Languages and frameworks | Programming languages and the frameworks and libraries we build on | TypeScript, Spring Boot, React |

## 3. Rings

<!-- Guidance: Define rings in terms of what a team should do, with evidence required. The definitions below are a starting point. -->

| Ring | Meaning for teams | Evidence required to place a blip here |
|---|---|---|
| Adopt | Default choice. Use it unless you have a good reason not to. Supported by shared tooling and knowledge. | Used in production by several teams with good results; support and skills exist |
| Trial | Worth using on a real project where you can manage the risk. Share what you learn. | At least one team has used it in production or a serious pilot with positive results |
| Assess | Worth exploring to understand how it could affect us. Spikes and prototypes, not production. | Credible promise for a known problem; someone willing to investigate |
| Hold | Do not start anything new with it. Existing use may continue, with a plan where needed. | Poor experience, better alternative, risk, or end of support |

## 4. Blip entries

<!-- Guidance: One row per blip. Movement: New, Moved in (towards Adopt), Moved out (towards Hold), No change. Rationale in two or three sentences, from your own experience. Mistake: copying an external radar's placements without local evidence. -->

| ID | Name | Quadrant | Ring | Movement | Rationale | Owner |
|---|---|---|---|---|---|---|
| TR-001 | *Example:* Architecture decision records | Techniques | Adopt | No change | Used by all teams since 2024; onboarding feedback says ADRs explain past choices well | @architecture-guild |
| TR-002 | *Example:* Contract testing for internal APIs | Techniques | Trial | New | Payments and Orders cut integration incidents by half in two quarters; needs wider tooling support | @qa-guild |
| TR-003 | *Example:* Long-lived feature branches | Techniques | Hold | No change | Merge pain and late integration; use trunk-based development with feature flags | @eng-excellence |
| TR-004 | *Example:* Managed PostgreSQL | Platforms | Adopt | No change | Default relational store; platform team operates it with backups and upgrades | @platform-data |
| TR-005 | *Example:* Self-hosted message broker cluster | Platforms | Hold | Moved out | Operating cost and two major incidents; use managed streaming service | @platform-runtime |
| TR-006 | *Example:* Serverless containers for batch jobs | Platforms | Assess | New | Could remove idle cluster cost for nightly jobs; cold start and quota limits unknown | @platform-runtime |
| TR-007 | *Example:* OpenTelemetry SDKs | Tools | Adopt | Moved in | Replaced vendor agents in 80% of services; vendor-neutral and well supported | @sre |
| TR-008 | *Example:* AI code review assistant | Tools | Trial | New | Two teams report faster reviews; watch false positives and data handling rules | @dev-experience |
| TR-009 | *Example:* TypeScript | Languages and frameworks | Adopt | No change | Default for web and Node.js services | @frontend-guild |
| TR-010 | *Example:* In-house UI component library v1 | Languages and frameworks | Hold | Moved out | Replaced by design system v2; migrate when touching screens | @design-system |
| [TR-NNN] | [Name] | [Quadrant] | [Ring] | [New / Moved in / Moved out / No change] | [Rationale] | [@owner] |

## 5. Edition summary

<!-- Guidance: Three to five themes that explain the most important changes in this edition. Readers who skip the table should still get the message. -->

| Theme | Summary | Related blips |
|---|---|---|
| *Example:* Fewer self-hosted platforms | We move operational load to managed services where cost allows | TR-005, TR-006 |
| *Example:* Testing earlier | Contract testing and preview environments shorten feedback loops | TR-002 |
| [Theme] | [Summary] | [IDs] |

Blip count by ring in this edition:

| Quadrant | Adopt | Trial | Assess | Hold |
|---|---|---|---|---|
| Techniques | [n] | [n] | [n] | [n] |
| Platforms | [n] | [n] | [n] | [n] |
| Tools | [n] | [n] | [n] | [n] |
| Languages and frameworks | [n] | [n] | [n] | [n] |

## 6. Governance and cadence

<!-- Guidance: How blips are proposed, decided and published, and how often. Keep the process lightweight or people will stop contributing. -->

### 6.1 Proposing a change

Anyone can propose a new blip or a move by opening a pull request against
the radar data file with name, quadrant, proposed ring, rationale and
evidence (links to ADRs, incident reports, pilot results). Proposals for
Adopt need a named owner willing to support other teams.

### 6.2 Deciding

The radar group ([architecture guild plus one representative per
engineering area]) reviews proposals in the edition session. Decisions are
by consensus; when there is none, the blip stays where it is and the
disagreement is recorded in its rationale.

### 6.3 Using technologies in Hold

New use of a Hold technology requires an ADR stating why the alternative
does not fit, approved by [@chief-architect]. Existing use is reviewed when
the system is next significantly changed.

### 6.4 Cadence

| Activity | Frequency | Owner |
|---|---|---|
| Collect proposals | Continuous | Anyone |
| Edition session (half day) | Every [6 months] | @architecture-guild |
| Publish edition and summary | Within 2 weeks of the session | @architecture-guild |
| Review stale blips (no movement for 3 editions) | Each edition | Radar group |

## 7. Change log

<!-- Guidance: Editions and major decisions. -->

| Edition | Date | Blips added | Blips moved | Blips removed |
|---|---|---|---|---|
| *Example:* 2026-04 | YYYY-MM-DD | 8 | 5 | 6 |
| [Edition] | YYYY-MM-DD | [n] | [n] | [n] |

## Standard and licence note

Based on the technology radar concept (four quadrants and four rings:
adopt, trial, assess, hold) popularised by Thoughtworks through its
Technology Radar publication. No text or blip placements from any published
radar are reproduced; all definitions, guidance and examples are original
to this collection. Template licence: MIT.