Times de tecnologia tomam decisões sobre ferramentas e frameworks o tempo todo — muitas vezes de forma reativa, isolada e sem critérios claros. O resultado é a proliferação silenciosa de tecnologias que ninguém mais sustenta, a adoção de modismos sem avaliação real e a dificuldade crescente de onboarding. O TechRadar existe para resolver exatamente esse problema.
Este guia mostra como criar e manter um TechRadar na sua empresa do zero — do processo de avaliação até as ferramentas para publicar e compartilhar com o time.
O que é um TechRadar?
O TechRadar é um framework criado pela ThoughtWorks para catalogar e comunicar o posicionamento de uma organização em relação a tecnologias, técnicas e ferramentas. A ideia central é simples: toda tecnologia tem uma recomendação, e essa recomendação é revisada periodicamente com critérios explícitos.
O radar original da ThoughtWorks é publicado duas vezes por ano e é uma das referências mais consultadas pelo mercado tech. Mas a real força do TechRadar está em adaptá-lo para o contexto da sua empresa — com as suas linguagens, seus produtos, seu perfil de risco e suas restrições reais.
Por que não basta seguir o radar da ThoughtWorks?
O radar da ThoughtWorks reflete o contexto de uma consultoria com clientes em dezenas de setores e países. Uma fintech com stack Python e dados, uma software house especializada em .NET ou um SaaS B2B com microserviços em Go têm contextos completamente diferentes. O radar genérico informa; o radar interno guia decisões.
A estrutura do TechRadar
O radar é um diagrama circular dividido em dois eixos:
Os quatro quadrantes
| Quadrante | O que cobre |
|---|---|
| Técnicas | Práticas de engenharia: TDD, trunk-based development, feature flags, DDD |
| Ferramentas | Software de suporte ao desenvolvimento: IDEs, CLIs, plataformas de observabilidade |
| Plataformas | Infraestrutura e cloud: Kubernetes, GCP, AWS, bancos de dados gerenciados |
| Linguagens & Frameworks | Linguagens de programação, frameworks web, ORMs, bibliotecas |
Você pode (e deve) adaptar os quadrantes para a realidade da sua empresa. Se o seu core é dados, faz sentido ter um quadrante específico para ferramentas de dados. Se você tem muitos produtos internos, um quadrante de “Produtos DevEx” pode ser útil.
Os quatro rings
Os rings definem o nível de adoção recomendado para cada item:
Adopt (Adote): Tecnologia madura, com comprovação no contexto da empresa. É a escolha padrão para novos projetos. Qualquer desvio precisa de justificativa explícita. Exemplos: a linguagem principal do time, o orquestrador de containers, o sistema de observabilidade.
Trial (Experimente): Tecnologia promissora que já passou por avaliação inicial e está em uso em projetos específicos. Times podem adotá-la com consciência dos riscos — e devem compartilhar aprendizados. O objetivo é decidir se ela avança para Adopt ou recua.
Assess (Avalie): Tecnologias que valem atenção mas ainda não foram testadas em produção na empresa. Não são bloqueadas, mas não são recomendadas para projetos críticos. Um spike ou PoC é o próximo passo natural.
Hold (Pause): Tecnologias que o time decidiu não investir mais. Pode ser uma linguagem legada, uma ferramenta substituída ou algo que avaliamos e descartamos. Itens em Hold ainda podem existir em sistemas antigos, mas não devem ser adotados em novos projetos.
O ring mais importante é o Hold — ele comunica explicitamente onde o time não deve gastar energia, evitando que projetos novos nasçam com tecnologias que ninguém vai sustentar.
O processo de construção
1. Defina o escopo e os participantes
Um TechRadar não é documento de uma pessoa ou de um arquiteto isolado. As melhores implementações envolvem uma Tech Council ou grupo representativo dos times de engenharia — tech leads, arquitetos, engenheiros seniors de diferentes squads.
O grupo precisa ser pequeno o suficiente para tomar decisões (5 a 10 pessoas) e representativo o suficiente para que as decisões sejam legitimadas pelo resto do time.
2. Faça o inventário tecnológico
Antes de posicionar qualquer item no radar, você precisa saber o que existe. Faça um levantamento por categoria:
- Quais linguagens estão em uso ativo hoje?
- Quais frameworks sustentam os produtos em produção?
- Quais ferramentas de CI/CD, observabilidade e segurança o time usa?
- Quais plataformas de cloud e bancos de dados estão ativas?
- Quais práticas de engenharia o time adota (ou deveria adotar)?
Não filtre nada nessa etapa. O objetivo é visibilidade total.
3. Avalie cada item com critérios explícitos
A avaliação precisa de critérios claros para evitar debates de preferência pessoal. Use uma matriz como esta:
| Critério | Perguntas-chave |
|---|---|
| Maturidade | Está em produção conosco? Há versão estável upstream? |
| Adoção pelo time | Quantos devs têm proficiência? O onboarding é simples? |
| Suporte e comunidade | Há mantenimento ativo? Issues são respondidas? |
| Custo total | Licença, operação, treinamento, migração futura |
| Alinhamento com estratégia | Suporta a direção técnica dos próximos 2-3 anos? |
| Risco | Vendor lock-in? Dependência de uma pessoa só? |
Cada item recebe uma pontuação ou classificação qualitativa nesses critérios. O ring final é uma decisão coletiva do grupo, não a média das notas.
4. Posicione e documente
Para cada item posicionado no radar, registre:
- Ring atual e justificativa
- Ring anterior (se houve mudança)
- Data da última revisão
- Contexto de uso na empresa
- Próximos passos esperados
A justificativa é o elemento mais valioso. “Migramos de RabbitMQ para Pub/Sub (Google) porque o custo operacional de manter um cluster próprio era desproporcional para o volume atual” é infinitamente mais útil do que apenas “Hold: RabbitMQ”.
5. Defina a cadência de revisão
O radar não pode ser documento estático. O recomendado é revisão semestral, com um ciclo de atualização entre as revisões para capturar mudanças críticas (uma tecnologia entra em EOL, uma nova ferramenta ganha tração em múltiplos times, uma dependência crítica é descontinuada).
Estrutura sugerida para a revisão semestral:
- Semana 1: Coleta de propostas de mudança de qualquer engenheiro da empresa (via formulário, issues, ou sessão assíncrona)
- Semana 2: Tech Council revisa as propostas, pesquisa, testa se necessário
- Semana 3: Sessão de decisão com o grupo — cada item é discutido e posicionado
- Semana 4: Publicação da nova versão com changelog e comunicação para o time
Ferramentas para publicar o seu radar
Thoughtworks Build Your Own Radar
A própria ThoughtWorks disponibiliza um gerador gratuito em radar.thoughtworks.com/byor. Você alimenta com uma planilha Google Sheets ou CSV e ele gera o visual interativo do radar. É a opção mais rápida para começar.
Formato da planilha:
name,ring,quadrant,isNew,description
Kubernetes,adopt,Platforms,FALSE,"Orquestrador padrão para todos os serviços em produção."
Go,trial,Languages & Frameworks,TRUE,"Adotando para serviços com requisito de baixa latência."
GraphQL,assess,Techniques,FALSE,"PoC em andamento no squad de Marketplace."
Angular.js,hold,Languages & Frameworks,FALSE,"Legado. Novos projetos usam React."Backstage Tech Radar Plugin
Se você já usa o Backstage como portal de desenvolvedor, o plugin @backstage/plugin-tech-radar integra o radar diretamente na sua instância. A vantagem é centralizar num lugar que o time já acessa. Os dados podem vir de um JSON estático ou de uma API interna.
Radar personalizado com Astro ou Next.js
Para empresas que querem controle total sobre design e integração com outros sistemas internos, construir uma página própria é uma opção viável. O radar é essencialmente um SVG com coordenadas polares — bibliotecas como d3.js ou mesmo SVG puro cobrem a visualização.
O dado fica num JSON versionado no Git, o que dá histórico nativo e pull requests para mudanças — uma vantagem real para rastreabilidade.
Notion, Confluence ou documento simples
Para times menores ou que estão começando, uma tabela em Notion ou Confluence já entrega 80% do valor. O visual radar é opcional — o que importa é a decisão documentada e acessível. Comece simples e evolua para uma ferramenta mais elaborada conforme a necessidade aparecer.
Erros comuns ao implantar um TechRadar
Radar como documento de arquiteto, não do time
Quando o radar é construído por uma pessoa ou um grupo pequeno sem input dos times, ele perde legitimidade. Engenheiros ignoram recomendações que não entendem ou não confiam. Inclua o processo, não apenas o resultado.
Atualização anual (ou nunca)
Um radar de dois anos atrás é pior que nenhum radar — ele dá uma falsa sensação de governança enquanto a realidade dos sistemas divergiu. Defina responsabilidade clara pela manutenção antes de publicar a primeira versão.
Hold sem plano de migração
Dizer que uma tecnologia está em Hold sem um plano realista de migração cria frustração. Times que mantêm sistemas legados precisam de um horizonte claro. “Angular.js está em Hold; migração para React planejada para H2 2026, squad X responsável” é muito mais útil.
Radar com granularidade errada
“JavaScript” em Adopt é inútil — qual runtime? Qual bundler? Qual versão alvo? Por outro lado, “eslint-plugin-unicorn versão 55.0.3” é detalhe demais para um radar estratégico. Calibre a granularidade para decisões de projeto, não para gestão de dependências.
Sem comunicação das mudanças
Cada revisão do radar é uma oportunidade de engajamento com o time. Apresente as mudanças em All Hands técnico, escreva um changelog claro e explique o raciocínio por trás de cada movimento. Um blog post interno a cada revisão funciona muito bem para isso.
Exemplo: TechRadar de uma software house .NET
Para ilustrar como fica na prática, veja um radar simplificado de uma empresa com stack principal em .NET e cloud na GCP:
Adopt:
- Linguagens & Frameworks: C# (.NET 10), TypeScript, React
- Plataformas: GKE (Google Kubernetes Engine), Cloud SQL (PostgreSQL), Cloud Pub/Sub
- Ferramentas: GitHub Actions, Datadog, Terraform
- Técnicas: Trunk-based development, Health Checks com probes, Feature flags
Trial:
- Linguagens & Frameworks: Go (para serviços de alta performance)
- Plataformas: AlloyDB (avaliando para substituir Cloud SQL em casos específicos)
- Ferramentas: Backstage (portal de desenvolvedor interno em implantação)
- Técnicas: Platform Engineering, Internal Developer Portals
Assess:
- Linguagens & Frameworks: Rust (interesse do time, sem projeto piloto definido)
- Plataformas: Vertex AI (avaliando para workloads de ML)
- Ferramentas: OpenTelemetry Collector como alternativa ao SDK proprietário do Datadog
- Técnicas: eBPF para observabilidade de rede
Hold:
- Linguagens & Frameworks: .NET Framework 4.x (migração em andamento), Angular.js
- Plataformas: VMs (Cloud Compute Engine) para novos workloads
- Ferramentas: Jenkins (substituído pelo GitHub Actions), RabbitMQ
- Técnicas: Monorepo com scripts shell (adotando Nx)
Como medir se o TechRadar está funcionando
O radar é um meio, não um fim. Indicadores de que ele está gerando valor real:
- Tempo de decisão de stack para novos projetos cai — há uma resposta padrão, não um debate
- Diversidade tecnológica se estabiliza — sem crescimento descontrolado do número de linguagens e ferramentas em uso
- Onboarding mais rápido — novos engenheiros encontram um mapa claro do que aprender e do que está em uso
- Propostas estruturadas — quando alguém quer introduzir uma nova tecnologia, o processo de avaliação é conhecido e seguido
- Pull requests para o radar — o time se sente dono do documento e propõe mudanças ativamente
Conclusão
O TechRadar não é burocracia — é o mecanismo pelo qual times de engenharia tomam decisões técnicas de forma explícita, coletiva e rastreável. A alternativa é deixar as decisões acontecerem de forma implícita, individual e sem registro. Qualquer empresa com mais de 5 engenheiros já tem um radar informal na cabeça de algumas pessoas; a questão é se esse conhecimento está acessível para todos ou concentrado em quem lembra da conversa de corredor de dois anos atrás.
Comece simples: uma planilha, o gerador da ThoughtWorks e uma sessão de 3 horas com os tech leads. O importante é dar o primeiro passo.
Quer ajuda para estruturar o processo de governança tecnológica da sua empresa? Na DevPlus, apoiamos times de engenharia na definição de arquitetura, boas práticas e estratégia técnica de longo prazo. Fale com a gente.