Tech Radar: por que times de engenharia precisam de um

Desenvolvimento, Open Source
• 3 fev 2022

Manter um projeto competitivo dentro do mercado de tecnologia é, sem dúvida, um dos grandes desafios dos times de engenharia. Isso porque é necessário estar sempre atualizando e revisando soluções, já que, da mesma forma que é ruim usar tecnologias legadas, também não é aconselhável utilizar tecnologias simplesmente por serem buzzwords. E é aqui que um Tech Radar se faz relevante.

Mas como monitorar e visualizar todas essas soluções? Uma forma de acompanhar essas pilhas, que são cruciais para organização, é fazendo com que sua empresa ou times tenham um Tech Radar.

Nesse artigo, falaremos o que é um Tech Radar, como usamos dentro do nosso time Open Source e por qual motivo sua empresa deveria ter um.

Artigo escrito por: Otávio Santana e Mariana Moreira.

Conhecendo o Tech Radar

De maneira geral, o Tech Radar é uma documentação técnica de engenharia que funciona como um portfólio para você visualizar as tecnologias e metodologias de uma instituição, monitorar as novas tendências, além de identificar quais ferramentas precisam ser removidas, seja por motivo da tecnologia ser legada, seja por deixar de ser estratégico para a empresa.

O Tech Radar mais famoso e pioneiro do mercado pertence a Thoughtworks e é muito comum que essa ferramenta seja adaptada e atualizada de acordo com a necessidade de cada organização. O maior diferencial desta solução é que ela é construída por meio de um processo de contribuição dentro do próprio time de engenharia.

O radar na prática

Ilustração de um Tech Radar, em que temos um círculo dividido em 4 quadrantes e vários pontos coloridos em cada quadrante, indicando diferentes tecnologias. — Fonte.

Os radares, por padrão, possuem quatro quadrantes com suas respectivas categorias:

Linguagens e frameworks;
Plataformas;
Técnicas;
Serviços.

Em cada um dos quadrantes, há quatro anéis nos quais você identifica o nível de importância e relevância da tecnologia e/ou metodologia para a instituição: Hold, Asses, Trial e Adopt. Quanto mais próximo do centro, mais importante essa ferramenta é.

Na prática, isso significa que durante a escolha de uma ferramenta, linguagem e/ou metodologia, por exemplo, sempre se dará prioridade àquela que o time já conhece e/ou já domina.

Em alguns casos, é importante verificar se existe algum estudo com relação a essa nova demanda. Caso dois times precisem conhecer uma ferramenta, toda a engenharia saberá que existe uma nova frente com esse objetivo. Afinal, tudo estará registrado no Tech Radar.

Atualmente, existem vários modelos que podem ser utilizados para criar um Tech Radar, por exemplo:

Um pouco sobre os projetos Open Source da Zup

Antes, um rápido contexto: atualmente, o grupo Open Source da Zup é dividido em quatro projetos:

Charles CD: uma ferramenta open source que realiza deploys de forma ágil, contínua e segura, permitindo que as equipes façam validações simultâneas de diferentes hipóteses com grupos específicos de usuários;
Ritchie CLI: uma ferramenta open source para criar, armazenar e compartilhar automações de forma segura. Também otimiza comandos repetitivos para você ter mais autonomia programando;
Beagle: um framework open source cross-platform pautado em Server-Driven UI, que permite às equipes fazerem alterações em aplicações nativas mobile ou web a partir apenas da alteração do código direto no back-end;
Horusec: uma ferramenta de código aberto que realiza análise de código estático e que potencializa a identificação de vulnerabilidades em seu projeto com apenas um comando.

Dentro desses quatro times, temos como foco a inovação a partir de projetos Open Source, de fato, utilizando dependências que sejam compatíveis com os projetos que, atualmente, utilizam o Apache V2.

Por que construir um Tech Radar para um time de engenharia?

Dentro do time Open Source na Zup, utilizamos o Tech Radar principalmente para a gestão de conhecimento e também para nos auxiliar a construir soluções com mais qualidade.

A gestão de conhecimento do Tech Radar tem alguns objetivos:

Gerir as informações que circulam entre diversos times: sabendo as ferramentas que cada time usa ou deseja utilizar, fica mais fácil de estabelecer uma comunicação efetiva entre os projetos e também evitar silos de conhecimento;
Motivação e treinamento: uma vez que as tecnologias que os times precisam aprender e/ou aprimorar estão mapeadas, é possível organizar grupos de estudos, palestras, workshops e pesquisas, inclusive cross-teams;
Evitar que o time perca o foco e siga o “efeito rebanho”: por mais que haja muito oportunidade de se conhecer novas ferramentas em eventos externos, é importante se atentar com as reais motivações por trás da pilha utilizada, pois certamente terão ferramentas que “escalam”, “performam”, etc. É preciso cautela para não transformar os projetos em um “laboratório em produção”;
Evitar que a pilha tecnológica se torne uma “salada de frutas”: bem semelhante ao caso anterior e, às vezes, oriundo dele, o grande ponto é evitar que existam diversas ferramentas que fazem a mesma coisa. Afinal, se dentro do grupo já existe uma solução que resolve um problema, qual é a motivação de utilizar uma nova com o mesmo propósito;
Qualidade no código: um time concentrado e com alta coesão na pilha de tecnologia facilita a gestão de conhecimento, resultando em boas práticas e fluência entre times, além de códigos melhor escritos e trabalhados;
Open Source: um dos pontos críticos de projetos Open Source, é que eles realmente precisam ser Open Source, ou seja, que as suas dependências tenham licenças compatíveis com os nossos projetos.

Dentro das opções de Tech Radar, optamos pela solução do Agile Partner e sua adaptação para o Hugo, realizada por Yoan Thirion. Temos como base dois motivos: o time já conhece e está familiarizado com Markdown e Hugo, além da licença ser do MIT.

Com base nele, criamos as nomenclaturas mais próxima do nosso cotidiano:

Tela inicial da tela do Tech Radar do portal open source da Zup. Com ela, é possível, realizar a pesquisa, observar as categorias, além de olhar o radar. — Fonte

Os nossos anéis

Estratégico: tudo que é considerado fundamental para os projetos. Os times têm conhecimento, segurança e fluência;
Essencial: tudo que já está em processo de adoção e conhecimento é vital para o sucesso da equipe. Por isso, os times precisam de capacitação e/ou experiência;
Potencial: tudo que possui aderência com a cultura, as devidas licenças e tem potencial para ser adotado em projetos atuais ou em futuros engajamentos. Para isso, é interessante realizar estudos e testes para validação da efetividade no respectivo cenário de aplicação;
Descontinuado: tudo que é atualmente utilizado, deve ser removido em algum momento. Os motivos para tal medida se dão por coesão da pilha tecnológica ou pela quebra de cultura e/ou licenças Open Source adotadas.

Os quadrantes ou categorias

Linguagens e frameworks: são as ferramentas que usamos de forma direta no desenvolvimento dos projetos;
Ferramentas: são softwares que utilizamos de forma direta para o desenvolvimento, sendo necessário realizar uma manutenção direta. Por exemplo, um banco de dados, um orquestrador de container, etc;
Serviços: semelhante ao anterior, são softwares que auxiliam no desenvolvimento, porém são disponibilizados sem necessidade de manutenção direta do time. No geral, eles se encaixam como um PaaS e/ou um SaaS;
Técnicas: são elementos de um processo de software, como design de experiência e/ou código, metodologias, além de formas de estrutura de software, como microsserviços.

A diferença entre softwares homologados e o Tech Radar

Se grandes empresas realizam processos semelhantes ao do Tech Radar, há bastante tempo, qual é a diferença entre esse novo modelo em relação aos softwares homologados? A resposta está na metodologia.

A visualização do Tech Radar é apenas o “pico do iceberg”, uma vez que sua criação é um processo colaborativo e em constante andamento com todo o time de engenharia.

Já softwares homologados costumam partir de um pequeno grupo de engenharia que, muitas vezes, não tem o contexto para a escolha das tecnologias por estarem fora dos times que irão utilizá-las.

O Tech Radar do time é open source e, portanto, passível de sugestão por todos os times, não apenas pelo time de arquitetura. Toda a equipe tem o poder de revisar, promover, depreciar e adicionar uma tecnologia a partir de uma contribuição no repositório, no caso, um PR (pull request).

As discussões são definidas de forma aberta e por meio de uma comunicação transparente e técnica. A grande vantagem desse formato é que tende a reduzir expressões comuns como “não vou adotar tal ferramenta, pois não quero” ou “eu já vi várias pessoas utilizando, então devemos utilizar também”.

Conheça nosso Tech Radar

Ilustração do Tech Radar dentro do time open source. Nele é possível entender a relação dos quadrantes e dos anéis. — Fonte.

Ele funciona como um portfólio de tecnologias que estão sendo utilizadas pelo nosso time. Para a equipe de Open Source da Zup, além de ser organizado levando em consideração as soluções Open Source, também é um processo transparente para as escolhas de pilha que serão utilizadas nas soluções.

Quer conhecer mais sobre Tech Radar? Então assista a essa live que fizemos sobre o tema: