What is a technology radar for, and what makes one useless?

What is being tested

Whether you can distinguish an artefact that aligns decisions from one that decorates a wiki.

What it is for

Making the organisation's technology position explicit — adopt, trial, assess, hold — so that hundreds of independent choices align without each one requiring review.

That is the leverage: a team choosing a database consults the radar rather than the architecture team, and the decision is already made.

The entry that does the most work

Hold. Naming what you are moving away from is what stops a contained technology quietly acquiring new adopters — which is how a system scheduled for retirement in 2019 is still load-bearing.

"Adopt" is easy and pleasant. "Hold" requires saying something is not the future, which is where the real value and the real difficulty are.

What makes one useless

• No owner, so nobody maintains it.
• Never revised. A radar unchanged in a year describes an organisation that no longer exists, and people stop consulting it.
• Produced by people who do not build, so it reflects opinion rather than operational experience.
• Aspirational rather than descriptive — listing what someone wishes the estate used, so it does not help anyone reason about what actually exists.
• No rationale. An entry without a reason cannot be argued with, so it is either obeyed blindly or ignored.

What makes one work

Entries with reasons, so the position can be challenged and updated. Revision on a cadence, with changes visible. Contributions from the teams, so it reflects reality. And a connection to the paved road, so "adopt" means "there is a supported module and a template for this" rather than merely "we like it".

The relationship to standards

A radar is softer than a standard. It signals direction; a standard constrains. Both need a waiver path, because a technology position with no exception process is broken quietly rather than formally — and invisible exceptions are worse than granted ones.