The JWorks Technology Radar is intended to showcase our opinion on the most important tech trends we see today. It is based on the Thoughtworks Technology Radar and uses its open source framework for visualization. We adopted the mechanics and methodology from Thoughtworks, as described below.

Our tech radar can be reached through this link.

The Radar

The Radar is a document that sets out the changes that we think are currently interesting in software development - things in motion that we think you should pay attention to and consider using in your projects. It reflects the idiosyncratic opinion of a bunch of senior technologists and is based on our day-to-day work and experiences. While we think this is interesting, it shouldn’t be taken as a deep market analysis.


The quadrants are a categorization of the type of blips:

  • Programming Languages and Frameworks. Quite straight-forward, languages and software frameworks.
  • Tools. These can be components, such as databases, software development tools, such as Versions Control Systems; or more generic categories of tools, such as the notion of polyglot persistence.
  • Platforms. Things that we build software on top of such as mobile technologies like Android, virtual platforms like the JVM, or generic kinds of platforms like hybrid clouds.
  • Techniques. These include elements of a software development process, such as experience design; and ways of structuring software, such as microservices.

We don’t make a big deal out of the quadrants - they’re really just a way to break up the Radar into topic areas. We don’t think it’s important which quadrant a blip goes into, unlike the rings - which generate a lot of discussion.


The metaphor of a radar says that the closer a blip is to you, the sooner it will be on top of you. Like most metaphors, you can’t take it too seriously, but there’s an essential sense to it.

Our Radar has four rings, which we’ll describe starting from the middle:

  • The Adopt ring represents blips that we think you should be using now. We don’t say that you should use these for every project; any tool should only be used in an appropriate context. However we do think that a blip in the Adopt ring represents something where there’s no doubt that it’s proven and mature for use.
  • The Trial ring is for blips that we think are ready for use, but not as completely proven as those in the Adopt ring. So for most organizations we think you should use these on a trial basis, to decide whether they should be part of your toolkit. Typically we’re happy to use trial blips now, but we realize that most readers will be more cautious than us.
  • The Assess ring are things that you should look at closely, but not necessarily trial yet - unless you think they would be a particularly good fit for you. Typically, blips in the Assess ring are things that we’re currently trialling, on our projects.
  • The Hold ring is for things that are getting attention in the industry, but we don’t think are ready for use. Sometimes this is because we don’t think they’re mature enough yet: sometimes it means we think they’re irredeemably flawed. We don’t have an “avoid” ring, but we do throw things in the Hold ring that we wish our clients wouldn’t use.

Unlike the quadrants, we do have some quite passionate arguments about which ring a blip should go into. We don’t tend to have angry debates, but rings are what generate the most energetic discussions. Over the course of making the Radar we’ve come up with some useful rules of thumb to help us put things into rings.

We can only put blips into the Trial ring when we have experience of that blip on a real project. This can mean we sometimes look behind the technology curve, because we may like the look of a technology but haven’t yet persuaded a client to try it out - and until we do that blip cannot pass into Trial.

For the Adopt ring, we only include items when we think it would be a poor and potentially irresponsible choice not to use them given the appropriate project context.

More information can be found on the Thoughtworks website.

Andreas is a Principal Java consultant at Ordina, passionate about the Spring ecosystem, microservices, REST, clean code and best practices in general. An avid open source enthusiast and Spring contributor. Helps fellow developers as Competence Center leader for architecture and best practices by giving workshops, talks and courses about the newest technologies.