Tech Radar: What It Is and Why Tech Teams Need to Have One

Learn how Tech Radar can improve your team's experience, as well as avoid headaches in your organization's architecture.

Otavio Santana

CORE ·

Mar. 13, 22 · Analysis

Like (5)

Save

8.6K Views

Keeping a project competitive within the technology market is, without a doubt, one of the most significant challenges for engineering teams. It is because it is necessary to update and revise solutions constantly: since, in the same way, it is terrible to use legacy technologies, it is also not advisable to use technologies simply because they are buzzwords.

But how to monitor and visualize all these solutions? One way to keep track of these stacks, which are crucial for an organization, is to make your company or teams have a Tech Radar.

This article will talk about what it is, how we use it within our Open Source team, and why your company should have one.

Getting to Know Tech Radar

In general, Tech Radar is technical engineering documentation that works as a portfolio for you to visualize an institution's technologies and methodologies, monitor new trends, and identify which tools need to be removed, either because the technology is legacy. Or because it is no longer strategic for the company.

The most famous and pioneering Tech Radar on the market belongs to Thoughtworks. It is widespread for this tool to be adapted and updated according to the needs of each organization. The biggest differentiator of this solution is that it is built through a contribution process within the engineering team itself.

Radars, by default, have four quadrants with their respective categories:

Languages and frameworks.
Platforms.
Techniques.
Services.

In each quadrant, there are four rings in which you identify the level of importance and relevance of the technology and methodology for the institution: Hold, Assess, Trial, and Adopt. The closer to the center, the more critical this tool is.

In practice, this means that when choosing a tool, language, and methodology, for example, priority will always be given to what the team already knows and/or has mastered.

In some cases, it is essential to check any study regarding this new demand. If two teams need to know a tool, all engineering will learn a new front with this objective. After all, everything registers on Tech Radar.

There are several samples of Tech Radar:

Why Build a Tech Radar for an Engineering Team?

First, a quick context: currently, the Open Source group at Zup has four projects:

On these four teams, we focus on innovation from Open Source projects using dependencies compatible with projects that currently use Apache-2.0.

Within the Open Source team at Zup, we use Tech Radar mainly for knowledge management and also to help us build better quality solutions.

Tech Radar's knowledge management has a few goals:

Manage the information that circulates between different teams: knowing the tools that each group uses or wants to use, it is easier to establish effective communication between projects and avoid knowledge silos.
Motivation and training: once the technologies that teams need to learn and/or improve are mapped, it is possible to organize study groups, lectures, workshops, and research, including cross-teams.
Prevent the team from losing focus and following the "herd effect": as much as there is a lot of opportunities to discover new tools in external events, it is essential to pay attention to the real motivations behind the stack used, as they will undoubtedly have tools that "scale", "perform", etc. Care must be taken not to transform projects into a "laboratory in production".
Prevent the technology stack from becoming a "fruit salad": very similar to the previous case and, sometimes, coming from it; the main point is to avoid having several tools that do the same thing.
Code quality: a focused team with high cohesion in the technology stack facilitates knowledge management, resulting in good practices and fluency between groups, in addition to better written and worked code.
Open Source: one of the critical points of Open Source projects is that they need to be Open Source, that is, that their dependencies have licenses compatible with our projects.

We opted for the Agile Partner solution and its adaptation to Hugo within the Tech Radar options, carried out by Yoan Thirion. We are using it for two reasons: the team already knows and is familiar with Markdown and Hugo, and the license is from MIT.

Based on it, we created the nomenclatures closer to our daily lives:

Our Rings

Strategic: Technologies within the Strategic Ring are fundamental to the projects. The teams that tested have knowledge, confidence, and fluency.
Essential: The technologies in this ring have been tested but are not fully mature. The teams that use it need training and/or experience to ensure the project's success.
Potential: Potential Technologies have chances to be adopted in current or future projects. It is necessary to carry out studies and tests.
Deprecated: If a technology is in that ring, avoid it. We've already tested it, our experience was bad and we don't want you to waste your time.

The Quadrants or Categories

Languages and frameworks: are the tools that we use directly in the development of projects.
Tools: we use software directly for development, requiring direct maintenance. For example, a database, a container orchestrator, etc.
Services: similar to the previous one, they are software that helps in the development; however, they are made available without direct team maintenance. Overall, they fit in as a PaaS and/or SaaS.
Techniques: are elements of a software process, such as experience design and/or code, methodologies, and ways of structuring the software as microservices.

References

agile Open source IT

Opinions expressed by DZone contributors are their own.

Comments

Related

Trending