Technology Radar Template
Technology radar: quadrants, adopt/trial/assess/hold rings, blip table with movement and rationale, governance and cadence
Як використовувати: Use it to share the organisation's technology choices every few months. Define rings and quadrants first, then add blips with local evidence. The main pitfall is copying placements from a public radar instead of your own experience.
Перегляд
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.
| 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
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
| 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
| 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
| 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
| 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
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
| 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.
Схожі шаблони
Technical Debt Register Template
Debt register with Fowler quadrant taxonomy, interest, principal, risk-weighted priority score, triage, budget and reporting
Архітектура та системний дизайнArchitecture Decision Record Template (Tyree-Akerman, Y-Statement)
Detailed ADR – Tyree & Akerman fields (assumptions, constraints, positions, argument, implications, related items) plus Y-statement
Архітектура та системний дизайнAPI Versioning and Deprecation Policy Template
API lifecycle policy: versioning scheme, compatibility promises, breaking changes, timelines, Deprecation and Sunset headers