DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Lead a Successful Agile Transformation With the VICTORY Framework
  • Navigating Software Leadership in a Dynamic Era
  • What’s the Future of Device Management? 5 Predictions For What Lies Ahead
  • Key Takeaways: Adrian Cockcroft's talk on Netflix, CD, and Microservices

Trending

  • The 4 R’s of Pipeline Reliability: Designing Data Systems That Last
  • The Modern Data Stack Is Overrated — Here’s What Works
  • Rethinking Recruitment: A Journey Through Hiring Practices
  • Segmentation Violation and How Rust Helps Overcome It
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Tech Radar: What It Is and Why Tech Teams Need to Have One

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.

By 
Otavio Santana user avatar
Otavio Santana
DZone Core CORE ·
Mar. 13, 22 · Analysis
Likes (5)
Comment
Save
Tweet
Share
11.7K Views

Join the DZone community and get the full member experience.

Join For Free

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.Tech Radar Example

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

  1. Languages and frameworks.
  2. Platforms.
  3. Techniques.
  4. 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:

  • Zalando Tech Radar
  • Thoughtworks
  • Delivery Hero Tech Radar
  • Agile Partner

Why Build a Tech Radar for an Engineering Team?

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

  • Charles
  • Ritchie
  • Beagle
  • Horusec

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:

Tech Radar Creation Categories

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

  • ClearScore Tech Radar 2021
  • Technology Radar: Your Go-to Platform for Technology Management
  • Cisco Technology Radar
  • Tech at SumUp. It’s on our radar.
  • Thoughtworks
  • https://opensource.zup.com.br/radar/radar/
  • Build your own radar: a conversation about technology
  • Zalando Tech Radar - Scaling Contributions to Technology Selection
agile Open source IT

Opinions expressed by DZone contributors are their own.

Related

  • Lead a Successful Agile Transformation With the VICTORY Framework
  • Navigating Software Leadership in a Dynamic Era
  • What’s the Future of Device Management? 5 Predictions For What Lies Ahead
  • Key Takeaways: Adrian Cockcroft's talk on Netflix, CD, and Microservices

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!