The Adventures of COYO: The Tech Radar
Have a look at the complete radar here
What is a Tech Radar and why do we need one?
According to ThoughtWorks, whom we used as inspiration and tools to create our own radar, a Tech Radar, and quote, “is a document that sets out the changes that we think are currently interesting in software development”. More personally, for us the Tech Radar is a way to provide an overview of the tech stack we use daily to develop our product and an alignment on how it should look like in the future.
Working in an agile environment with increasingly independent teams, we felt the need to have a way to align them, keep everyone informed of which technologies we use and want to keep investing in the future — and since we were at it, inform the outside world of our tech stack. Those were the main reasons behind creating our own Tech Radar, but many other use cases can be applied to it and may be discovered in the future.
How does the Radar came to life?
In every adventure, not only the goal, but also the journey and sharing the experience is the interesting part. There was a calling from an entity not so high above, our direct manager, to have some of the problems mentioned in the paragraph above solved. The topic was than brought to one of our Chapter meetings, in this case in the awesome Front-end chapter, and two developers reluctantly raised their hands and volunteered as tributes to make this request a reality, not knowing what they might encounter.
As Lao Tzu once said, “A journey of a thousand miles begins with a single step”, and for those two volunteers the single first step was research. What is a Tech Radar? How do other companies do it? Does any of our colleagues have an idea or opinions about it? Could other departments benefit from it? Luckily, in a fast visit to the worlds biggest library, the internet, we were able to find “ancient” transcripts from Porsche and Zalando, other adventurers who described their journey into the Tech Radar realm. Reading about their experiences, helped our two COYO adventurers to start. But before start packing, it was important for us to understand what were the expectations and necessities of this request from different teams and departments. Once that information was gathered, we were ready.
A common mention was the work of ThoughtWorks and how they create and provide others the tools to create Radars. But it’s not only about putting all the data into a machine and see the result at the other end. There’s a whole process behind it. First realization was what quadrants and rings are supposed to represent and how are they defined. Wanting to make this journey also our own, we decided to define those terms ourselves.
Starting with Quadrants:
- Languages and Frameworks: this is pretty self-explanatory. Every blip that is a programming language or framework we use;
- Platform: stack we build software on top of like mobile technologies (e.g. Android), virtual platforms or generic platforms like hybrid clouds;
- Techniques: elements of software development process and ways of structuring software. For us that also includes personal skill development and education techniques like Free Coding Day for example;
- Tools: 3rd party software products we integrate, like databases, software development tools, such as version controlling systems and other tools that helps in our daily work.
Following with Rings:
- Adopt: technologies currently, successfully used in production with broad adoption across all teams and can and should preferably be chosen for new projects;
- Trial: technologies that already bring a huge positive impact and serious usage and experiments have been made with them, but are not broadly used by many teams or only a few developers have used it. Those technologies can be chosen for new projects, if the risk is manageable;
- Assess: promising technologies used to solve small challenges or specific use cases that are worth to invest some research and prototyping efforts. Usually this are newly introduced technologies and only used by few. Should only be chosen for new projects after a proper risk assessment or only for experimental projects;
- Hold: technologies that we want to drop or are getting replaced by others. Technologies that were once assessed but did not make it to should also progress to Hold. This technologies should not be used in new projects but only maintained on existing ones. Their current adoption in existing projects should be regularly revisited and there should be strategies to get rid of them.
Once quadrants and rings were defined, we could start gather the information we had and start placing the different technologies blips in the respective quadrants and rings. What we soon realized was that we needed support from members from different teams to get information about the technologies and processes they have defined for their teams. And so, step by step we gathered a group of interested people that will be responsible to keep this radar updated. At the same time it allowed us to learn a lot about the different tech stacks of the other teams and by involving more people, help to spread the knowledge.
Was that the end of the journey? Not quite…
What’s next and what have we learned?
Like mentioned in the last sentence, creating and managing a radar is an ongoing process and the next step is exactly to create a process to keep the radar up to date. So every 3–6 months, the two main adventurers will get together and visit the different realms of our department and meet with the representatives of each team to understand what has changed in their stack and together update the radar. The Chapters should also be highly involved in discussing and planning how the radar mutates with time and drive initiatives to further get rid of technologies we don’t want to invest in. That was already happening before the Tech Radar was a reality but now we have a better way to display them as a vision to the future.
Our first trip ended up diverging a bit from the ThoughtWorks approach. While they suggest that a Tech Radar should provide a vision to the future, how tech is evolving and which technologies are trending, our approach was more into having a kind of documentation and alignment on which tech to chose for a new project and which to abandon. With this in mind, the first version of COYO Tech Radar, provides a big picture of everything we are using daily. In the future we would like that the radar also reflects a “star map” that will guide adventurers in(to) their COYO journey and get closer to the ThoughtWorks approach.
Don’t lose track of the next adventure, because we won’t stop here! Thank you for reading.
