A technology radar is a technique popularised by ThoughtWorks for evaluating an organisation’s technical landscape. The premise is simple: you identify tools and technologies in play and categorise them according to their desired level of adoption. This gives rise to a radar-style visualisation where items are arranged in discrete rings.

The process of putting a radar together can be a great way of initiating conversations about technology. You can build a view of your entire technology landscape, spread the good ideas and discourage bad practice.

However, the “radar” metaphor tends to be a better fit for consultancy-based organisations as opposed to in-house shops such as SaaS business, corporates, or software houses. Consultancies or agencies can survey trends across multiple customer organisations and projects. In-house organisations generally face a more static landscape that can often be defined by legacy technologies.

There are times where a radar can feel like a consultancy marketing tool as much as a technology survey. It allows the authors to present themselves as thought leaders by demonstrating their command of the cutting edge. An in-house organisation can feel at a natural disadvantage as there are likely to be fewer people whose job it is to spot new trends and research new approaches. Many engineers are labouring on long-lived systems where the time and space for research is limited.

Adapting radars for in-house landscapes

These obstacles can be overcome, but you may have to dig deep to find content for the more speculative rings of the radar. The “adopt” and “hold” areas tends to be obvious and well represented. The outliers in “assess” and “trial” often require a bit more effort to identify.

An inclusive and broad-based approach to defining the radar is important here. Relying on a “council of elders” made up of senior engineers or architects may result in a skewed view the technology landscape. Some of the most interesting stuff can often emerge from engineering teams, especially if you encourage teams to choose their own tools and techniques. Facilitating cross-pollination of innovation between teams is where a radar can really come into its own.

It is important not to confuse a radar with a catalogue that enumerates every technology in play around an organisation. This implies a that you will need to make a lot of scope calls, especially if you are working in diverse, component-driven ecosystems such as Python and Node. You will probably want to capture the high-level frameworks but be less interested in single-purpose libraries.

As a ballpark, a radar typically seems to contain somewhere around a hundred items. If you go too far beyond that it can become difficult to reason about, but too few items can give rise to an anaemic analysis.

Note that a radar is not a governance tool. It is more effective as a means of prompting conversations about technology rather than defining policy. It may be tempting to anoint technologies by marking them for adoption, but this is too much of a blunt instrument to provide clear policy definition or standards around preferred usage.

“Hold” can be a broad church

The “hold” ring that discourages adoption tends to be lightly used in ThoughtWorks radars, mainly because the emphasis is on emerging technologies that solve problems in new and interesting ways.  There is the occasional anti-pattern to disapprove of, but the overall emphasis is on positive and novel solutions.

“Hold” tends to be used more widely for in-house radars, mainly because there’s just more stuff to discourage. There are the obvious “legacy” technologies that have no future value. Sometimes these are used out of habit, but they can often include those technologies that the organisation must live with given the cost of any replacement.

A radar can often throw up duplicate provision that may be resolved by holding some perfectly viable technologies – e.g. Terraform preferred over Chef. On top of this there will be anti-patterns and lessons learnt, outliers, one-offs and dead ends that should be discouraged.

In this sense, “hold” can also mean “endure”, “accept”, “prevent” or even “disown”. It can be quite a broach church.

Capturing nuance

The descriptions and narrative for each item are vital. Part of the fun of a radar is making bold and often provocative assertions about technologies. It is one of those rare occasions where that old cliché about “strong opinions loosely held” can add value.

A lot of in-house attempts at radars seem to skip this part of the process. I think this may be a mistake. The descriptions are where you can state more nuanced opinion, explain context, and even provide a bit of guidance. The radar feels incomplete without some carefully considered narrative.

The radar is only one way to organise the items that you capture. It can be interesting to start grouping the items according to other criteria to identify some of the emerging trends within your own organisation. It can reveal some genuine food for thought. The last radar I produced identified an emerging cloud stack, a strong UI consensus, a worryingly anaemic test ecosystem, a set of cutting-edge ideas that we wanted to encourage and a bunch of anti-patterns to kill.

Building a visualisation

The familiar ring-based interactive visualisation is probably the best way to present a Radar and ThoughtWorks have open sourced a generic implementation based on Node.

This isn't the only way you can present a radar, and it's important not to fixate too much on the interactive diagram. A written report is probably more valuable as this is where you get to capture all that nuance, insight and debate that should emerge during the process. A written report can also help to get the radar out to a wider audience and propagate a wider understanding of the landscape, which is kind of the whole point.

Filed under Architecture and Strategy.