Seu time de tecnologia tem liberdade para escolher ferramentas e linguagens. Isso é ótimo para inovação. Mas o que acontece quando cinco times escolhem cinco bancos de dados diferentes? Quando uns usam Python, outros Go, outros Node.js? Quando cada projeto traz uma nova biblioteca de logging, um novo framework HTTP, um novo jeito de fazer deploy?
A inovação sem governança vira caos. E o caos vira dívida técnica, dificuldade de rotacionar times, onboarding lento e custos operacionais altos.
O Tech Radar é uma ferramenta simples e poderosa para resolver esse dilema. Inspirado no famoso ThoughtWorks Technology Radar, ele ajuda sua empresa a documentar, comunicar e evoluir sua estratégia tecnológica de forma transparente – dando diretrizes claras sem sufocar a inovação.
Neste post, vamos mostrar como criar e manter um Tech Radar na sua empresa, quais categorias usar, como envolver o time e como transformá-lo em uma ferramenta viva de decisão técnica.
O que é um Tech Radar?
Um Tech Radar é uma matriz bidimensional que classifica tecnologias (linguagens, frameworks, ferramentas, plataformas, práticas) de acordo com dois eixos:
- Quadrante (categoria) – a natureza da tecnologia (ex: linguagens, frameworks, infraestrutura, ferramentas)
- Anel (status) – o quão recomendada é a tecnologia (ex: adotar, experimentar, avaliar, evitar)
Exemplo visual simplificado
Os quatro anéis (recomendação)
| Anel | Significado | Ação típica |
|---|---|---|
| Adotar (Adopt) | Tecnologia recomendada para uso geral | Use em produção. Times devem ter expertise. |
| Experimentar (Trial) | Tecnologia promissora, mas com riscos conhecidos | Use em projetos de baixo risco, avalie em produção, compartilhe resultados. |
| Avaliar (Assess) | Tecnologia emergente, vale a pena conhecer | Faça POCs, estude, não use em produção ainda. |
| Evitar (Hold) | Tecnologia com problemas conhecidos ou obsoleta | Não use novos projetos. Planeje migração se já existe. |
Os quadrantes (categorias)
A ThoughtWorks usa quatro quadrantes, mas você pode adaptar:
| Quadrante | O que inclui | Exemplos |
|---|---|---|
| Linguagens e Frameworks | Linguagens de programação, frameworks web/backend | Go, Python, React, Spring Boot |
| Plataformas e Infraestrutura | Cloud, bancos, filas, orquestração | Kubernetes, AWS Lambda, PostgreSQL, Kafka |
| Ferramentas | CI/CD, observabilidade, IDEs | GitHub Actions, Prometheus, VS Code |
| Técnicas e Padrões | Práticas de desenvolvimento, arquitetura | TDD, Event Sourcing, Feature Flags |
Por que sua empresa precisa de um Tech Radar
Problema 1: Caos de escolhas
Cada time escolhe sua própria stack. Dez microsserviços usam cinco linguagens diferentes, três bancos, quatro jeitos de fazer deploy.
Tech Radar resolve: define o que é padrão, o que é permitido com justificativa, o que é proibido.
Problema 2: Onboarding lento
Novo desenvolvedor passa semanas aprendendo as ferramentas e padrões “não escritos” da empresa.
Tech Radar resolve: a estratégia tecnológica está documentada e acessível. Novo membro sabe o que aprender primeiro.
Problema 3: Decisões repetidas
Cada time, ao escolher uma biblioteca de logging, passa pelo mesmo debate.
Tech Radar resolve: a decisão já está tomada e documentada. Time só desvia se houver justificativa forte.
Problema 4: Inovação sem governança
Times experimentam tecnologias novas sem compartilhar aprendizados. O conhecimento fica preso.
Tech Radar resolve: o radar é atualizado coletivamente. Experimentações são visíveis e os resultados, compartilhados.
Como criar seu Tech Radar
Passo 1: Defina o time de curadoria (Tech Radar Committee)
O radar precisa de donos. Monte um comitê com:
- Arquitetos de software
- Tech leads de diferentes áreas
- Representantes de produto (opcional)
- Representante de segurança (opcional)
Papéis:
- Revisar propostas de mudança no radar
- Conduzir reuniões de atualização (ex: trimestrais)
- Comunicar mudanças ao time
Passo 2: Escolha o formato e a ferramenta
| Ferramenta | Tipo | Prós | Contras |
|---|---|---|---|
| ThoughtWorks Radar (open source) | Visual | Simples, gratuito, exporta PNG/SVG | Apenas visual, sem backend |
| Build Your Own Radar (BYOR) | Código | Configurável via JSON/YAML | Requer desenvolvedor |
| Backstage (Plugin Tech Radar) | Plataforma | Integrado ao catálogo de serviços | Requer Backstage |
| Planilha + diagrama manual | Manual | Fácil de começar | Difícil manter versões |
Recomendação: comece com uma planilha + diagrama manual (Draw.io ou Miro). Se o radar provar valor, migre para uma ferramenta como Backstage.
Passo 3: Popule a versão inicial
Não comece do zero. O primeiro radar deve refletir a realidade atual da empresa.
Perguntas para levantar:
- O que usamos hoje em produção?
- O que já decidimos que NÃO vamos usar?
- O que estamos experimentando agora?
- O que gostaríamos de avaliar no futuro?
Classificação inicial (exemplo):
| Tecnologia | Quadrante | Anel | Justificativa |
|---|---|---|---|
| Go | Linguagens | Adotar | Padrão para microsserviços de alta performance |
| Python | Linguagens | Avaliar | Usar apenas para Data Science e scripts |
| Node.js | Linguagens | Evitar | Migrar para Go em novos projetos |
| Kubernetes | Infraestrutura | Adotar | Padrão para orquestração |
| MongoDB | Bancos | Evitar | Preferir PostgreSQL, exceto casos específicos |
| Temporal | Workflows | Experimentar | Avaliando para fluxos de orquestração |
Passo 4: Comunique e eduque
Um radar que ninguém conhece é inútil.
- Publique em local acessível (wiki, GitHub, Backstage)
- Apresente em reunião geral de engenharia
- Incorpore nas práticas de onboarding
- Use como referência em pull requests que introduzem novas tecnologias
Como manter o Tech Radar vivo
Ciclo de atualização típico (trimestral)
Mês 1: Coleta
- Times sugerem mudanças (via issue, formulário)
- Compartilham aprendizados sobre tecnologias em Trial/Assess
Mês 2: Curadoria
- Comitê revisa sugestões
- Discute evidências e justificativas
- Decide novas classificações
Mês 3: Publicação
- Radar atualizado
- Anúncio para a empresa
- Atualização de documentação
Gatilhos para mudanças não programadas
- Lançamento de versão major de tecnologia relevante (ex: nova versão de framework)
- Incidente de segurança ou performance relacionado a tecnologia específica
- Depreciação anunciada por fornecedor
Exemplo de entrada no Tech Radar (documentação de apoio)
Cada tecnologia no radar deve ter uma entrada documentada.
# Go (Linguagem / Adotar)
**Quadrante:** Linguagens e Frameworks
**Anel:** Adotar
**Última revisão:** 2026-06-01
**Curador:** time-plataforma
### Justificativa
Go é a linguagem padrão para todos os novos microsserviços e APIs de alta performance. Oferece excelente concorrência (goroutines), baixa latência, binários estáticos e curva de aprendizado acessível para times com experiência em Python/Node.
### Quando usar
- Microsserviços de API
- Workers de processamento assíncrono
- Ferramentas CLI e operações de infraestrutura
### Quando NÃO usar
- Data Science / Analytics (prefira Python)
- Protótipos muito rápidos com baixa exigência de performance
- Sistemas que exigem reflexão extensiva (Go tem limitações)
### Experiência na empresa
Adotado em 2024. Hoje 40+ microsserviços em produção. Redução média de 60% no custo de computação comparado ao Node.js anterior.
### Recursos de aprendizado
- Curso interno "Go para times Python"
- Documentação: link
- Exemplos: template-service-go (repo)
### Decisões relacionadas
- Node.js foi movido para EVITAR para novos projetos
- Python mantido em ADOTAR para Data ScienceArmadilhas comuns ao implementar um Tech Radar
| Armadilha | Consequência | Correção |
|---|---|---|
| Radar muito restritivo | Times ignoram, inovação morre | Deixe espaço para Trial e Assess |
| Radar só no papel | Ninguém consulta, decisões continuam ad hoc | Comunique regularmente, integre ao onboarding |
| Sem justificativas documentadas | Parece “ditadura tecnológica” | Cada entrada tem porquê e contexto |
| Atualização muito lenta (anual) | Radar fica defasado, perde utilidade | Ciclo trimestral ou semestral |
| Sem representação de múltiplos times | Radar reflete só a visão de um time | Inclua tech leads de diferentes áreas |
Como o Tech Radar se relaciona com outros artefatos
| Artefato | Relação com Tech Radar |
|---|---|
| Architecture Decision Records (ADRs) | Radar é visão estratégica; ADRs são decisões táticas documentadas |
| Onboarding Guide | Radar informa o que aprender primeiro |
| Pull Request templates | Incluir checklist: “a nova tecnologia está no radar?” |
| Tech debt backlog | Tecnologias em “Evitar” podem gerar itens de migração |
Caso real: empresa de fintech adota Tech Radar
Uma fintech de médio porte (80 engenheiros, 50 microsserviços) sofria com proliferação de tecnologias. Identificaram:
- 5 linguagens diferentes em produção
- 3 bancos de dados relacionais
- 2 soluções de mensageria
- 4 frameworks HTTP diferentes
Implementação Jacobus:
- Criado comitê com 6 arquitetos e tech leads.
- Primeiro radar definiu: Adotar (Go, PostgreSQL, Kubernetes, Kafka), Trial (Temporal), Assess (Rust para componentes críticos), Evitar (Node.js para novos serviços).
- Radar publicado no Backstage + wiki.
- Ciclo de atualização trimestral.
Resultados após 9 meses:
- Novos serviços: 100% em Go (antes mix de Python/Node/Go)
- Onboarding de novos devs: de 4 semanas para 2 semanas
- Incidentes relacionados a “jeito diferente de fazer”: redução de 45%
- Times ainda têm liberdade para experimentar (Trial/Assess), mas com governança
Conclusão
Tech Radar não é sobre controle – é sobre clareza. Ele documenta o que sua empresa já aprendeu, o que recomenda e o que evita. Dá aos times liberdade dentro de limites conhecidos e acelera a tomada de decisão.
Na Jacobus Software, usamos Tech Radar internamente e ajudamos clientes a implementar o seu. Se sua empresa sente a dor da proliferação tecnológica sem governança, o radar é a ferramenta certa.
Comece pequeno: uma planilha, um comitê pequeno, uma primeira versão refletindo o que você já usa. O resto vem com o tempo – e com as atualizações.
📡 Quer implementar um Tech Radar na sua empresa?
Nossos especialistas ajudam a definir quadrantes, anéis, processo de governança e documentação – adaptados à sua realidade.