The ITP Tech Radar reflects our current view on software engineering technologies. It includes the technology choices we’ve made as a company and motivates why we’ve made them. Beyond that it shows what technologies are “on our radar”, and why we’re considering adopting them. Our Tech Radar is heavily inspired by the pioneering work of ThoughtWorks, and the adaptation of Zalando.
The rings of the Tech Radar correspond to the different stages in our Technology Lifecycle - the internal process we use to decide on technology. That process looks like this:
On our Tech Radar, the technologies that we chose to adopt are visualised at the core, and the technologies that we chose to put in hold are visualised at the edge. In between, the asses and trial stages are visualised as distinct rings. If a technology is promoted to a next stage, it will move closer to the core. Reversely, if it’s demoted, it will move further away from the core. Mapping the Technology Lifecycle process on our Tech Radar looks like this:
But what is the meaning of every stage in our Technology Lifecycle? What do we need to decide on promoting or demoting a technology? Let’s take a closer look at our process.
Before a technology can be added to our Tech Radar, it needs to meet 2 requirements:
It must be promising and relevant to our business. In other words: there should be a reason why we would want to invest time and resources.
It must be ‘important enough’ to track on our radar. We don’t have a hard definition for this, but we do have some guiding questions that help out. Generally, if one or more of the following questions should be answered with ‘yes’, a technology should be tracked on our Tech Radar:
Does it require significant expertise?
Is it relevant for discovery purposes?
Would it require a significant investment to replace the technology in a product?
Once both requirements are met, the technology will start its life in the Assess stage.
During the Assess stage, our goal is to get a better understanding of the technology and its potential. This includes creating small proof of concepts to build a better understanding of the technology, but we’ll also assess other aspects of the technology:
Who is maintaining the product? Are they trustworthy? How confident are we that the product will be well-maintained?
How does the community surrounding the technology evolve?
If it is a service, we’ll perform a thorough vendor assessment to ensure the vendor complies with our ISMS and relevant legislation.
Which of our current technologies could be replaced by this technology (if any)? And what are the technology’s prime competitors? Are they worth considering as well?
If we’re still convinced of a technology after this assessment, it will progress to the Trial stage. If not, we’ll put the technology in the Hold stage.
During the Trial stage, we want to test out the technology in an actual product, to check whether it lives up to its expectations. This is the most risky phase of a technology, so we’ll take a couple of precautions to limit the associated risks:
We’re limiting the trial to a single product and a single team. A technology can’t be used outside of that scope while it’s in the Trial stage.
We must have a ‘plan B’ in case the technology does not live up to expectations, and reverting to that plan should take days/weeks, not months.
After the trial, we’ll either decide to adopt the technology or decide to put it in the Hold stage. It is important to understand that a successful trial doesn’t guarantee adoption: it’s perfectly possible that a technology worked well during the trial, but wasn’t significantly better than one of our already adopted technologies. In such a case, it might not be worth the investment to adopt the technology. In our context, adopting a technology equals a commitment to support that technology for at least a couple of years - possibly more. So we’ll always carefully consider that decision.
During the Adopt stage, our goal is to actively build and grow our expertise in that technology, and promote its usage throughout our product teams. These are the technologies that we’re using day-to-day, and that receive the biggest focus in our knowledge sharing, research and learning activities.
A technology will typically remain in the Adopt stage until there is a better alternative. There’s also a chance that a technology might simply become irrelevant or obsolete, or is abandoned by its maintainer. In all of those cases, the technology will be moved to the Hold stage.
If a technology ends up in the Hold stage, it effectively means we no longer intend to invest in the technology, as we don’t think it’s the optimal choice for our company. It also means the technology should no longer be introduced in products that aren’t using it yet. In most cases, we’ll have a better alternative for that technology, which is linked on the radar as well.
It’s extremely important to capture why a technology was put in the Hold stage. After all, change is the only certainty in our industry, and that means we might need to reconsider past decisions. Recording the reason allows us to revisit it at a later point in time.
Finally, putting a technology on hold might also mean planning to deprecate it. After all, a technology could have been in the Adopt stage for a prolonged period, and we might have many products that are using it. This is actually quite a common scenario, and it’s one of the hardest things to get right. Some technologies can be replaced quite quickly, but others require a multi-year plan to deprecate them, during which we’ll still need to support it and thus maintain our expertise. There is no one-size-fits-all solution here, but it is important to have a plan - without it, you risk being stuck with the technology for a lot longer.
Internally, we use the Tech Radar to support innovation, facilitate decision making and enable expertise discoverability. It is a living tool, supported by our knowledge culture.
Externally, we publish a copy of our Tech Radar each quarter, containing much of the same information. By doing so, we hope to provide some guidance, trigger your interest or even spark a debate. After all, choices that are right for our context, aren’t necessarily right in every context - and choices we’ve made in the past, aren’t necessarily the right choices today.
We’re publishing a new, public version of our Tech Radar in the first month of every quarter (January, April, July, October). Although the internal version is updated more frequently, decreasing the number of public releases allows us to put more emphasis on the changes we’ve made in-between. We’ll typically discuss those changes in a blog post, but they are also visible on the Tech Radar itself, through the icon that is used for a specific technology:
▲ Promoted technologies: these technologies were promoted to a ring closer to the radar’s core, compared to the last publication.
▼ Downgraded technologies: these technologies were demoted to a ring further away from the radar’s core, compared to the last publication.