INFO’s Technology Radar
Read more by Edgar Vonk
That’s why, in this blog post, we will explain why we felt the need to create our very own tech radar and how it has helped us. We will also talk about how we incorporate it in our way of working, and how we keep it up to date. We hope that this blog provides you with some valuable insights about how you can create and maintain your own tech radar, and to shine a light on the benefits it has.
INFO’s Technology radar at Github
What is a tech radar?
A tech radar is a company’s go-to tool for strategic technology management and informed decision-making about which technology direction to pursue, and to avoid. It’s a visualization of a company’s technology portfolio and maps out existing and emerging technologies.
Why did we create a tech radar?
To us, our Technology Radar is an important part of our overall technological vision. It helps us with making strategic, company-wide technological choices, and to align these choices with our overall corporate vision. Our Technology Radar also helps our agile client teams with making informed decisions about the tech stack they will incorporate in the solutions we design and build for our clients. Furthermore, it lends focus to our technological strategy, when we’re deciding which new technologies we really want to investigate, for example. Our tech radar helps us to continuously rethink and re-evaluate our technological choices, which sometimes leads to the termination of a certain technology in favor of another.
Another area where the tech radar helps us is communication. Both internally and externally. Internally, we use it to validate our technological choices for internal alignment. Externally, we hope it helps attract the talent that we are looking for. This is also one of the reasons that we have shared our overall preferred tech stack (which can be seen as part of the tech radar) on StackShare.
How do we use it?
Creating a tech radar is all well and good but it only becomes worthwhile when you actually use it. We try to use ours in a number of ways. We use it whenever we need to make important technological choices, like when we’re introducing a new technical solution to an existing client, or when we’re making a proposal for a new potential client. We also use our Technology Radar to validate or make strategic choices within the company. For example, when we’re defining internal research projects, migrating tools, or refining our services. Using the radar consistently makes us think about high-level technology choices very explicitly.
Of course it also occurs that we make a certain technological choice (e.g. in a client team) that does not comply with our tech radar. Deviations are no problem as long as there is a good reason for them and we make these decisions consciously. To help make our high-level technology decisions very explicit and to consider all relevant tradeoffs, we try to use Architectural Decision Records (ADRs) as much as possible. ADRs don’t only help with the process of making such choices but they also act as a backlog, in which you can always go back and check why a decision was made, who made it, and which trade-offs were considered.
What to put on your tech radar?
First of all, we only try to add high-level technological choices to our tech radar. More low-level tech choices, such as very specific frameworks or specific SaaS services are not something we typically add to our radar. If we would, the radar would quickly become very hard to maintain. Also, not having more than a few dozen technologies on the radar helps with maintaining focus and keeping an overview of what’s really important to the company. It also helps that we have zero ambition to have a 100% complete tech radar when it comes to our tech choices; some of our choices are so obvious to us that we do not even consider putting them on the radar. And while we are always eager to try out new technologies, we do try to be a little conservative with what we add to the radar, so that we don’t lose focus of what really deserves our attention.
We try to be extra careful when adding a certain technology to the ‘adopt’ ring on the radar, because if we do, this indicates that we think we can and should really start using this technology in our teams asap. We have a list of technology selection criteria (kind of like a checklist) that we typically use to determine whether a specific technology should be moved to the ‘adopt’ ring on the tech radar. These criteria include things like future proofness, fit for purpose, security, and regulatory compliance. To be perfectly honest, these criteria can be quite subjective at times, and they are certainly not always applicable, but they can still help.
Keeping your tech radar up to date
Every quarter or so we organize in-house workshop sessions where we gather feedback from our tech people on what they think should be added or removed from our current radar. Lively discussions are certainly encouraged in these sessions, since these sessions, together with the continuous alignment we do with our business strategy teams, form the basis for a new version of our tech radar . Our technological leadership team is responsible for maintaining the contents of the tech radar, organizing the workshop sessions, and compiling all the feedback.
Workshop session to collect feedback.
From a technical point of view we treat the contents of INFO’s Technology Radar as code and thus store it in a GitHub repository. We use ordinary Git pull requests to make and review changes to our radar but we save up and bundle these changes so that we can publish a new version of the radar each quarter. We owe many thanks to AOEPeople for making their tech radar solution publicly available for companies like us to use. We have only started using this solution quite recently (we previously managed our radar on our wiki), and this setup works really well for us. We would also like to thank the good people of ThoughtWorks who maintain their ThoughtWorks tech radar since it continues to be a huge inspiration for us
Worth the effort
We think having a tech radar and using it consistently really helps us with making better-informed technology choices and with aligning the technology vision within our company. The main benefit we see is that it makes technology choices very explicit, especially when used in combination with Architectural Decision Records. In our experience, the easy part is creating the initial tech radar – actually using it consistently and having a process in place to regularly update it is the hard part, and something we can still improve. That being said, we are convinced that – if done well – adding a tech radar to your business is definitely worth the effort.
Onze laatste blogs en artikelen ontvangen?
Schrijf je in voor onze nieuwsbrief!
Laat hieronder je naam en email achter