Arquitetura de software e liderança técnica: decisões, observabilidade e migração incremental

Escopo da liderança técnica na arquitetura - Apresentação

Apresentando o curso e o instrutor

Olá! Pessoa estudante da Alura, é um prazer ter você aqui em mais um curso da carreira de Tech Lead (Líder Técnico).

Meu nome é Henrique Lamontanha e serei sua pessoa instrutora ao longo deste curso. Vou me autodescrever.

Audiodescrição: Henrique é um homem branco, de cabelo longo preso, barba média e veste uma camiseta preta.

Apresentando objetivos e responsabilidades de arquitetura

Neste curso, nós vamos explorar a questão da arquitetura no nível de equipe: como tomamos decisões técnicas, como desenhamos a arquitetura, qual é de fato o escopo de arquitetura pelo qual a pessoa Tech Lead (Líder Técnico) é responsável e o que permanece sob responsabilidade da pessoa arquiteta. Também veremos o papel da pessoa Tech Lead (Líder Técnico) na arquitetura local.

Para oferecer um panorama geral do que vem a seguir, nós vamos tratar de arquitetura local; do papel da pessoa Tech Lead (Líder Técnico) e do alcance que acabamos de mencionar; de como tomamos decisões técnicas; e de como conduzimos o alinhamento técnico.

A função de Tech Lead (Líder Técnico) carrega um viés de liderança — por isso o termo lead (liderança). Discutiremos como o time se sente confortável com mudanças, como comunicamos essas mudanças, como promovemos a participação do time nas decisões, como envolvemos outras pessoas que são pares ou que têm escopos mais amplos, como pessoas arquitetas e pessoas gestoras, e quais são os ritos por meio dos quais alcançamos esses alinhamentos.

Documentando decisões com ADRs

Também trataremos de documentação com ADRs (Registros de Decisões de Arquitetura).

Depois que esses rituais são realizados, como documentamos as decisões para futuras pessoas desenvolvedoras, ou mesmo para que nós e nossas pessoas colegas relembremos as escolhas feitas? Muitas vezes, antes de nos tornarmos Tech Lead (liderança técnica), já passamos por situações em que não se recordava que uma decisão havia sido tomada no passado — ou, pior, por que ela havia sido tomada.

Analisando observabilidade e evolução incremental

Observabilidade. Dado que temos serviços em produção, com pessoas clientes utilizando-os, como gerenciamos os trade-offs (compensações) e as decisões que vamos tomar? Como extraímos métricas, dados e fatos para decidir com segurança, explicando claramente: é por este motivo, por aquele e por outro?

E, por último, porém não menos importante, evolução incremental. Como realizamos uma migração segura, fazendo os serviços evoluírem para atender ao negócio com segurança? Neste tópico, vamos entender quando usar um Big Bang (migração de uma vez só) e quando usar evolução incremental, pois, em muitos casos, a evolução incremental será nossa melhor aliada.

Contextualizando com a BitBank e concluindo

Como fio condutor, utilizaremos a BitBank. Se já vimos a BitBank em outros cursos da Alura, aqui ela volta a aparecer. Será uma fintech (empresa de tecnologia financeira), um banco digital, e nossa equipe será a de pagamentos, que herdou um monólito financeiro e precisa evoluí-lo de forma incremental e com segurança.

Vamos direcionar a equipe para atravessar essas decisões, apoiar a pessoa Tech Lead (liderança técnica), documentar, observar e evoluir.

Nos vemos no próximo vídeo.

Escopo da liderança técnica na arquitetura - Diferenciando Tech Lead e pessoa arquiteta

Contextualizando o curso e os papéis técnicos

Contextualização do papel de Tech Lead e pessoa arquiteta

Olá, bem-vinda, bem-vindo a mais um vídeo da aula. Vamos contextualizar o papel de Tech Lead (liderança técnica) em contraste com o papel da pessoa arquiteta, entender o contexto que teremos neste curso e qual será nosso papel na tomada de decisões.

Como mencionamos no vídeo anterior, teremos o fio condutor do BitBank. Nós somos da Escola de Pagamentos do BitBank, atuamos como Tech Lead (liderança técnica) da Escola de Pagamentos, e nossa equipe recebeu o monólito financeiro legado, com código acumulado ao longo dos anos, muitas dependências e pressão constante por novas funcionalidades. Nosso desafio é evoluir esse monólito de forma segura, gerenciando os trade-offs (compensações), as pressões e as ambiguidades do mundo real — um cenário que provavelmente, mesmo antes de assumirmos uma liderança técnica, já vivenciamos.

Debatendo a demanda de pix em parcelas e a fronteira entre papéis

A Escola de Pagamentos recebe uma nova demanda: implementar Pix em parcelas. É provável que já tenhamos utilizado Pix em algum momento da vida. Diante disso, a equipe abre o debate: criamos um microserviço separado? É melhor colocar como módulo no monólito? Será melhor adicionar ao monólito, que já é uma dependência com muito código legado e difícil de evoluir? Ou adotamos uma arquitetura orientada a eventos, um novo enfoque?

Nesse momento, chega a pessoa arquiteta, entra na reunião e questiona por que essa discussão não está passando pela arquitetura. Em geral, o ambiente fica tenso: em home office (trabalho remoto), alguém desliga o microfone e a câmera; no presencial, muda a expressão. É comum já termos passado por algo semelhante. E fica a pergunta: quem toma essa decisão? Onde está a fronteira entre o papel de Tech Lead (liderança técnica) e o papel da pessoa arquiteta quando existe a separação dessas funções?

Equilibrando relações e autonomia decisória

Há um pensamento que queremos levar não apenas para este curso, mas para a carreira, pois costuma ajudar muito: boas relações constroem bons sistemas. Independentemente de estarmos lidando com sistemas e sermos pessoas técnicas, no final, trata-se de pessoas. Se mantivermos boas relações, facilitamos o caminho para construir bons sistemas.

Voltando ao nosso fio condutor: se a liderança técnica decide tudo sozinha, isso se torna um “go horse (seguir adiante sem planejamento)” arquitetônico. Tudo passa por essa liderança, que toma decisões sem dar visibilidade; equipes vizinhas não ficam sabendo; não há documentação e, às vezes, nem discussão interna no próprio time. Isso é prejudicial, pois aumenta o risco de quebrar contratos; pessoas que deveriam ser consultadas não são; e as decisões carecem de uma visão holística do produto e da organização.

Por outro lado, se a liderança técnica não pode decidir nada, para que ter uma liderança técnica? O papel se torna um gargalo burocrático; a equipe perde agilidade e autonomia; a cada pergunta feita para a liderança técnica, a resposta depende sempre da aprovação de alguém. Isso torna o papel inviável. Com isso, a pessoa arquiteta vira um gargalo permanente, porque a liderança técnica reencaminha todas as decisões para a arquitetura.

A lição é: sem uma fronteira clara entre papéis, temos um problema. Surgem retrabalho, desalinhamento e frustração de várias funções.

Diferenciando arquitetura de solução e arquitetura local

Vamos entender agora que tipos de arquitetura temos para separar esses papéis de forma efetiva. Há a arquitetura de solução, geralmente associada à função da pessoa arquiteta. É comum ouvirmos “subir isso para a arquitetura” ou “envolver a arquitetura nesta chamada”. A arquitetura de solução é acionada quando há algo mais global que precisa de uma visão holística, algo transversal entre as equipes de um produto ou entre produtos de uma corporação. Esse é o território da pessoa arquiteta.

A pessoa arquiteta:

• Define contratos entre serviços.
• Estabelece como os padrões devem ser seguidos (e não os detalhes, que geralmente ficam com as equipes).
• Define padrões de segurança da organização.
• Dá visibilidade às equipes, às lideranças técnicas — isto é, aos Tech Leads (lideranças técnicas) — e às pessoas gestoras sobre o que precisa ser priorizado, por que precisa ser priorizado e por que isso é importante.

A arquitetura local, tema deste curso, é território de quem exerce a função de Tech Lead (liderança técnica). Nesse contexto, essa pessoa domina e navega bem pelo domínio, compreende o desenho interno, os limites e como a equipe vai modelar os dados. É importante envolver a equipe na decisão de como modelar, e é desejável que esteja à frente dos refinamentos, com autonomia para assumir uma tarefa, uma história, do início ao fim, propondo soluções. Além disso, esse processo é uma via de mão dupla: a equipe aprende e nós também aprendemos com a equipe. Trazemos padrões, mostramos como fazer uma melhor organização interna e impulsionamos a equipe para que evolua continuamente e se torne mais sênior.

Aplicando decisões do tipo 1 e do tipo 2

Trazemos aqui um quadro conceitual bastante conhecido, que ajuda a separar com clareza o que é decisão da pessoa Tech Lead e o que é decisão da pessoa arquiteta. Jeff Bezos, que foi CEO (diretor executivo) da Amazon por muito tempo e é fundador da empresa, apresenta as decisões do Tipo 1 e do Tipo 2 — conhecidas como Type 1 (Tipo 1) e Type 2 (Tipo 2). O conceito é simples: decisões do Tipo 1 são portas de um único sentido, isto é, irreversíveis ou muito custosas de reverter; portanto, têm grande impacto. Por exemplo, alterar o broker (corretor) de mensageria responsável pela comunicação entre microserviços é uma decisão importante. Isso afeta o know-how (conhecimento prático) da equipe — se ela conseguirá trabalhar com o novo broker ou se precisará de curva de aprendizado — e também se outros times dominam essa tecnologia. É uma decisão que não está apenas no domínio da nossa equipe; é irreversível ou muito custosa de reverter.

Se for uma decisão com alto risco de gerar impacto financeiro ou de atrasar um roadmap (roteiro), estamos diante de uma decisão do Tipo 1. Outro exemplo é trocar o protocolo de comunicação entre microserviços, o que impacta nossa equipe e equipes vizinhas. Nesses casos, é prudente envolver a pessoa arquiteta, que deve participar da decisão; caso contrário, voltamos aos problemas já comentados.

Já as decisões do Tipo 2 são portas de duas vias: podemos entrar e voltar. São decisões reversíveis, ajustáveis no meio do caminho; se errarmos, não será custoso nem difícil reverter. Elas podem ser usadas para que a equipe experimente novas tecnologias e novas libs (bibliotecas) dentro do seu contexto. Assim, a equipe tem mais autonomia. Por exemplo, adotar uma lib (biblioteca) de retry (nova tentativa) dentro do próprio serviço não afeta outros times; não precisa passar pela pessoa arquiteta, sendo um uso inteligente do tempo de cada papel.

A chave aqui não é “quem decide”, e sim o custo de reverter a decisão, o impacto e o risco caso ela dê errado. Se der certo, perfeito — mesmo que a decisão não devesse ter passado por nós, funcionou e talvez nem atraia a atenção devida, embora o processo estivesse equivocado. Portanto, não devemos focar em quem decide, mas em qual é o custo se decidirmos e der errado. Haverá impacto financeiro para a empresa? Isso realmente deveria passar por nós? Esse raciocínio ajuda bastante. Pensemos sempre: é uma decisão do Tipo 1 ou do Tipo 2? Se for do Tipo 1, envolvemos mais pessoas, com um olhar holístico e transversal. Se for do Tipo 2, temos autonomia para envolver a equipe e discutir, entrando em conversas produtivas que rendem muitos aprendizados.

Conectando responsabilidades com o caso do pix em parcelas

Entendemos, até aqui, que a pessoa Tech Lead não é a pessoa arquiteta. Na maioria dos casos, é responsável por zelar pela equipe, pela arquitetura local e pelo seu contexto. Não é alguém que controla tudo. Garante coerência, padrões esperados pela organização, e sabe escalar e envolver outras pessoas quando são ultrapassadas fronteiras de domínio.

Retomando nosso fio condutor: como o PIX em parcelas se comunica com outros serviços? Essa é uma decisão do Tipo 1, pois envolve contato entre equipes. Precisamos nos alinhar com a pessoa arquiteta. Se o PIX em parcelas vai se comunicar com cinco microserviços, precisamos alinhar com as equipes, com as squads (equipes) responsáveis por esses serviços: estão preparadas? É algo novo? Já existe e é apenas evolutivo? Todos esses detalhes precisam estar bem alinhados — seja com as pessoas Tech Leads de outros times, seja com pessoas arquitetas, se houver na estrutura.

Já decisões do Tipo 2, como modelar o pagamento em parcelas internamente — por exemplo, se for apenas mais um módulo no monólito e a decisão for “como modelar isso internamente” —, não exigem envolver outras equipes para começarmos a construir e refinar. A equipe tem total autonomia e, na prática, deve resolver. É responsabilidade da equipe definir o desenho interno dos componentes e da pessoa Tech Lead orientar ao longo da jornada.

Na próxima aula, discutiremos como a equipe sabe o que é realmente de sua responsabilidade. Até logo.

Escopo da liderança técnica na arquitetura - Definindo ownership e bounded contexts

Apresentando a aula e objetivos

Olá, estudante, é um prazer ter você em outra aula. Você está aproveitando o curso até agora?

Nesta aula, vamos entender como o time sabe qual é sua responsabilidade e como você, como Tech Lead (liderança técnica), pode orientá-lo. Agora que compreendemos o que é arquitetura local e o que é arquitetura global, já podemos separar os temas, direcionar o que cabe à pessoa arquiteta, o que cabe a você e, consequentemente, o que cabe ao time. Vamos lá.

Contextualizando o monólito e dúvidas de responsabilidade

Seu time de pagamentos, do qual você é Tech Lead (liderança técnica), herdou o monólito. Porém, a codebase (base de código), por ser um monólito, tem vários módulos. Não há apenas itens de pagamentos: há notificações, autenticação, gerenciamento de sessão, relatórios financeiros, dashboard (painel). Já existe conteúdo transacional misturado com analítico. Há pagamentos e transações com Pix, e é aí que entra seu squad.

Como as pessoas desenvolvedoras costumam ter menos visibilidade que você, surgem dúvidas: quem é responsável por quê? Em que podemos mexer? E aquela classe compartilhada, o que fazer com ela? Esse cenário é complicado e frequentemente gera um efeito “terra de ninguém”.

Expondo efeitos da falta de ownership

Se existe um repositório único que atua como monólito e o time não tem clareza sobre o que pode tocar, o que deve tocar, o que é seu ou não, torna-se difícil promover mudanças. Sem ownership (senso de pertencimento e responsabilidade) — isto é, sem o sentimento de ser responsável por determinadas classes, por aquele código, por aquela funcionalidade —, passamos a sofrer um conjunto previsível de efeitos colaterais. Isso drena energia, reduz a velocidade do time, gera ruído na comunicação, aumenta a fricção com pessoas desenvolvedoras de outros squads e cria diversos problemas.

Os mais comuns, listamos quatro:

• Bugs sem responsável. Surge um bug em uma classe compartilhada. Como todos tocam nessa classe, não há dono claro. Investiga-se quem foi a última pessoa a alterar: “foi o time X”. “Mas não deveria acompanhar a funcionalidade que subiu?” Sem um ownership claro, não é possível atribuir 100% da culpa à pessoa desenvolvedora, pois a expectativa não foi alinhada. Em geral, em áreas limítrofes, ninguém assume responsabilidade por falhas; ninguém assume responsabilidade pelo que não percebe como seu, mesmo que seja.
• Código sem cuidado. Se algo é compartilhado, sem limites claros, tende a ser negligenciado no dia a dia — não por má-fé, mas porque a pessoa desenvolvedora não sente que o código é seu. Parece algo que todes deveriam observar, fica implícito. Isso é nocivo para a operação e não é responsabilidade do Tech Lead manter um ambiente assim. A probabilidade de termos falhas graves, riscos e impactos no produto é consideravelmente maior.
• Decisões sem registros. Como o serviço “é de todes”, no fim ninguém registra. Ou, se registra, o MySquad inicia, mas esse comportamento não se difunde; as documentações que o MySquad criou ficam obsoletas rapidamente. Não é apenas documentar: é como documentar, manter atualizado e incorporar isso ao fluxo de desenvolvimento. Isso vem com cultura, e a cultura precisa ser divulgada e difundida. Precisamos impregnar essa cultura nas pessoas desenvolvedoras, em nós e em nossos pares. Se ninguém documenta o que ficou implícito entre times, não há registro de decisões nem histórico; os times não sabem por que algo foi feito nem por que está sendo feito. Isso é muito importante.
• Medo de mexer. Vamos trazer um exemplo vivenciado no início de carreira: não havia muito receio de alterar código, mas escutávamos muito esse conselho. Em alguns momentos, paramos para refletir: “Cuidado, isso pode afetar o time X.” Porém, precisamos passar por aqui para chegar ao objetivo Y. Em muitos casos, a incerteza paralisa. É aquele código que todes têm medo de tocar, porque está lá há muito tempo, é legado, funciona, mas limita o avanço. Não podemos ficar estagnades porque um código é antigo. Precisamos agir com responsabilidade e calma, analisando o impacto. Se necessário, vamos envolver outras pessoas, pedir outras opiniões. E, se você, como Tech Lead (liderança técnica), perceber que alguém do time tem potencial e conhecimento técnico, mas não está conseguindo aplicar por medo de mexer e de quebrar, é uma boa oportunidade para acompanhar mais de perto.

Definindo bounded context e limites entre squads

O conceito de Bounded Context (contexto delimitado), muito presente em DDD (Domain-Driven Design, ou Design Orientado a Domínio), ajuda bastante a definir limites. Cada equipe deve ter um contexto bem delimitado para que possamos fortalecer o sentimento de pertencimento do time e orientar de forma objetiva. Isso ajuda inclusive no onboarding de novas pessoas desenvolvedoras: apresentar materiais, manter algum diagrama — não precisa seguir estritamente um padrão UML —, mas algo simples que permita mostrar, até “em um desenho na alvenaria” ou em uma folha, quais são os limites do seu squad. Nosso squad de pagamentos, por exemplo, é responsável por transações. Vamos contextualizando e direcionando as pessoas desenvolvedoras.

Ao definir esse perímetro — termos, modelos e regras do squad, o que faz sentido para ele —, o time passa a atuar com mais autonomia e consistência. Dentro do Bounded Context, a palavra “conta” tem um significado muito claro; fora dele, pode significar algo completamente diferente. O Bounded Context funciona como o mapa de ownership (senso de pertencimento e responsabilidade) do time. Ele direciona o que realmente deve ser percebido como responsabilidade do squad.

No exemplo do squad de pagamentos, do qual você é Tech Lead (liderança técnica), e do squad de notificações: pagamentos inclui transações, limites e aprovações. Ainda que tudo esteja dentro do monólito e seja compartilhado, mesmo que nosso time seja guardião, há códigos aos quais precisamos estar mais atentes, pelos quais devemos nos responsabilizar na manutenção, observação e acompanhamento de saúde. Já itens como notificações incluem templates (modelos). O time de pagamentos pode enviar uma notificação à pessoa usuária, mas deve seguir o template do time de notificações. Os canais são mantidos pelo time de notificações, algo mais genérico. Preferências da pessoa usuária — se deseja receber determinada notificação ou desativá-la — também ficam sob responsabilidade desse time.

Em um contexto bancário, por exemplo, pode chegar uma notificação judicial de que uma pessoa cliente não deseja receber determinada notificação, e será necessário tratar o caso de forma específica. Esses contextos inesperados vão ocorrer. É importante que o contexto esteja delimitado para sabermos rapidamente a quem direcionar quando chega uma decisão importante desse tipo, como uma resolução judicial, para agirmos com rapidez e assertividade, mitigando erros e bugs.

Alinhando times ao fluxo e conectando a métricas DORA

Outro conceito importantíssimo é o de Team Topologies (Topologias de Times), que nos ajuda a direcionar para stream-aligned teams (times alinhados ao fluxo de valor do negócio). Há uma frase famosa: You Build It, You Run It (quem constrói, opera). Isso significa que o time não apenas constrói, mas também opera; é responsável por fazer o software funcionar em produção. Não desenvolvemos apenas; somos responsáveis pela operação.

O time técnico não deve se sentir isolado (“somos o time técnico, vamos cuidar do código”). Precisamos nos envolver. Você, como Tech Lead (liderança técnica), deve incentivar o diálogo com PMs, POs e pessoas de negócio, para que o time entenda o produto, sinta-se parte da cadeia e corresponsável pela operação. O time deve se perceber como parte integral de tudo que constrói. Isso aguça a visão, antecipa problemas e traz ganhos para o conjunto e para você. Ao assumir a Tech Lead (liderança técnica), deixamos de ser contribuidores individuais: passamos a ser responsáveis por todas as entregas. Se houve uma entrega X de uma pessoa desenvolvedora, também somos responsáveis pelo sucesso e pelo fracasso dessa entrega.

Esse ownership (senso de pertencimento e responsabilidade) gera consequências diretas e mensuráveis. Há conceitos conhecidos como DORA Metrics (métricas DORA), relacionados a entrega, deploy (implantação), capacidade de resposta a incidentes. Quando investimos em times alinhados ao valor, como consequência — não como objetivo primário —, as DORA Metrics (métricas DORA) tendem a melhorar:

• Menor lead time (tempo de entrega), menos handoffs (passagens de trabalho), fluxo mais contínuo. Pessoas desenvolvedoras passam a sugerir melhorias para a pessoa usuária, pois estão alinhadas ao objetivo do negócio e sabem onde o time está posicionado na cadeia de valor.
• Menor MTTR (tempo médio de recuperação dos serviços). Quem construiu geralmente resolve incidentes mais rápido. Ao ver um erro, identifica a área provável: “esse erro que está aparecendo, já sabemos onde é; foi naquela parte onde algo passou.” A investigação se torna mais direcionada. Mesmo pedindo ajuda para acelerar a análise, chegamos mais rapidamente à causa raiz.
• Maior frequência de deploy (implantação). Um time fluido precisa de menos direcionamentos e se autogerencia mais. Como consequência, há maior cadência de deploy, código flui melhor, a pipeline (esteira de entrega) funciona bem e as tarefas avançam mais rapidamente.

Monitorando operação e reduzindo falhas

Como Tech Lead (liderança técnica), é importante monitorar isso. Acompanhe os serviços várias vezes ao dia, verifique se há erros nas pipelines, identifique se as pessoas desenvolvedoras precisam de algo. Não espere sempre que venham até você; seja proative. Pergunte se está tudo bem. Às vezes o código está bem, mas a pessoa desenvolvedora não está bem naquele dia. É importante equilibrar ambos os aspectos. Mostre-se disponível.

Por último, mas não menos importante, a métrica de Failure Rate (taxa de falhas). Com tarefas avançando mais rapidamente, pessoas desenvolvedoras mais confortáveis com a pipeline, times resolvendo incidentes e problemas com mais rapidez e acerto, e ownership claro, teremos menos falhas em produção. Isso pode ser convertido em algo tangível para pessoas gestoras: “Reduzimos a quantidade de falhas em produção ao fortalecer o senso de pertencimento do nosso time, aproximando-o da responsabilidade pelo que constrói.” Esse resultado é extremamente valioso.

Implementando o Tech Radar do time

Como sugestão prática para você, Tech Lead (liderança técnica), implemente o Tech Radar (radar tecnológico) do time. Em equipes de tecnologia e desenvolvimento, é comum que pessoas desenvolvedoras e a liderança técnica proponham soluções novas e alternativas para melhorar o que já existe. Como gerenciar isso sem microgerenciar, de forma simples? O Tech Radar (radar tecnológico) do time é um documento vivo que comunica escolhas e experimentos em andamento, para que possamos gerir tecnologias de modo explícito, colaborativo e com visibilidade para todes.

Você, como Tech Lead (liderança técnica), pode criar esse documento e compartilhá-lo, por exemplo, com a gestão, para acompanhamento e discussão conjunta. Isso é importante e saudável. Assim, não dependemos de memória ou de decisões implícitas no código — como alguém precisar abrir uma classe de mil ou duas mil linhas para entender algo. O Tech Radar acelera o entendimento, garante autonomia ao time sem gerar caos, reduzindo a carga cognitiva. Pessoas recém-chegadas saberão exatamente como serem orientadas no onboarding, o que usar e o que evitar, porque haverá um histórico de decisões (“o porquê”).

Ao estruturar o Tech Radar (radar tecnológico), recomendamos manter o mínimo viável. Pense nele como uma bússola com direções que representam quadrantes em um plano cartesiano: cada quadrante agrupa tipos de tecnologias (por exemplo, linguagens, ferramentas, plataformas, técnicas) e cada anel indica o nível de adoção (por exemplo, adotar, experimentar, avaliar, evitar). Essa abordagem visual e incremental é suficiente para começar com clareza e evoluir continuamente.

O que adotamos em produção e escolhemos como padrão, o que ainda estamos experimentando, o que já foi sugerido e está em teste, o que evitamos com base em lições aprendidas do passado — que geraram erros, incidentes, reduziram nossa capacidade de entrega ou tornaram a manutenção mais difícil — deve ser explicitado em uma seção de “evitar”. Já aprendemos com esses pontos, portanto, não vamos mais utilizá-los.

Podemos registrar tudo em um documento simples e flexível, com links para outras documentações mais detalhadas. Nele, podemos indicar materiais que desejamos que sejam utilizados e referências que facilitem o aprofundamento quando necessário. A ideia é não cair na armadilha da microgestão, mas também não ficar sem nenhum acompanhamento do que estamos experimentando de novo.

Exercitando a classificação de decisões locais e globais

Gostaríamos de propor um exercício rápido. Vamos enunciar algumas decisões; sugerimos pausar o vídeo para refletir: trata-se de uma decisão local ou global? Lembramos do tema de decisões Tipo 1 e Tipo 2 da aula anterior. Vamos exercitar com decisões relacionadas ao time de pagamentos da ByteBank. Depois, justificaremos o porquê.

• Decisão: biblioteca de testes da equipe (squad). Rufem os tambores: alcance local. Por quê? Porque não afeta outros times. A biblioteca de testes usada nos nossos serviços com a nossa equipe não impacta as demais.

• Próxima decisão: estratégia de cache (cache) interno. Rufem os tambores: alcance local. Por quê? É implementação interna do serviço. Salvo exceções em que o cache seja padronizado entre todas as equipes, é interessante que nós, como pessoas Tech Lead (lideranças técnicas), usemos bom senso e direcionemos o time a utilizar a ferramenta compartilhada pela organização. Em geral, porém, é algo interno do serviço. Por exemplo, podemos fazer cache de uma consulta executada uma vez ao dia diretamente na memória da aplicação se for algo pequeno: na primeira execução em uma nova máquina, consultamos, registramos o cache e pronto — não precisamos necessariamente de um Redis completo para isso.

• Próxima decisão: modelagem de dados de pagamentos. Decisão local. Por quê? Porque pertence ao Bounded Context (contexto delimitado) do time. Definimos como estruturar as classes, o que é melhor para manter e evoluir. Temos visão alinhada ao contexto em que trabalhamos. Em conversa com as pessoas PMs (pessoas gerentes de produto), POs (pessoas product owners) e pessoas de negócio, fica mais claro quando podemos otimizar e fechar mais o escopo, ou quando precisamos manter algo mais aberto para suportar evoluções futuras com facilidade.

• Próxima decisão: protocolo de comunicação entre serviços. Decisão global. Por quê? Ao nos comunicarmos com outros serviços, não envolve apenas nosso time (a menos que todos os serviços sejam do nosso próprio time). Vamos interagir com outras equipes, alinhar com outras pessoas Tech Lead e, possivelmente, com pessoas arquitetas, se esse papel existir na organização. Teremos contato cross-team (entre equipes); esse é o motivo para classificá-la como decisão global. Aqui, já entramos em decisões Tipo 1, mais custosas de reverter; se houver problemas operacionais, o impacto no roadmap (roteiro) não será interessante, e surgirão questionamentos que poderiam ter sido evitados. Diferentemente das três anteriores (decisões locais Tipo 2), nas quais o time tem autonomia para conduzir.

• Penúltima decisão: padrão de autenticação, OAuth ou OIDC. Decisão global. Por quê? Trata-se de segurança organizacional. Nós, como pessoas Tech Lead, não podemos ignorar segurança. Empresas sofrem tentativas de ataque todos os dias, o tempo todo. Algumas contam com profissionais de SOC (Centro de Operações de Segurança) para responder a incidentes, bloquear e rastrear rapidamente. Isso não nos exime da responsabilidade de orientar o time a escrever código seguro, conduzir revisões de código e direcionar para práticas mais seguras. Segurança é uma responsabilidade compartilhada por toda a cadeia.

• Última decisão: alias (apelidos) entre serviços. Decisão global. Por quê? Estamos tratando de acordos que envolvem não só o técnico, mas também negócio, gestão, clientes e contratos. Não é algo que possamos decidir sozinhos. Precisamos de alinhamento entre múltiplas equipes e papéis.

Preferindo guardrails a gates na governança técnica

Alguns conceitos importantes para o dia a dia: preferimos guardrails (balizas) a gates (portões).

• O que são gates? São “portões” de aprovação: alguém precisa autorizar qualquer decisão para seguirmos adiante. Isso, na maioria dos casos, não é interessante, pois cria gargalos e burocracia. Um exemplo comum são as GMUDs, nas quais precisamos de várias aprovações para implantar mudanças em produção. Três ou quatro pessoas precisam aprovar (gerência da área A, da área B, etc.), e um ajuste simples vira um gargalo. O arquiteto vira um constante bottleneck (gargalo). O time perde velocidade e senso de propriedade, pois se sente bloqueado e sem autonomia.

• E o que são guardrails? Não são “bala de prata”, e não estamos dizendo que gates não possam existir. Alguns serão necessários, especialmente quando o time é mais júnior: no início, gates ajudam a reduzir o risco de falhas em produção. Com mais maturidade e fluidez na pipeline (esteira), liberamos mais e transformamos gates em guardrails. A organização define limites claros para os produtos; quanto maior a empresa, mais frequentemente veremos guardrails do que gates.

Exemplo típico: um quality gate (barreira de qualidade) que exige, no mínimo, 85% de cobertura por testes unitários em microserviços. O time não decide se vai escrever testes unitários; decide como fazê-los. Seguimos a regra organizacional para dar coerência entre equipes, preservando autonomia com responsabilidade: qual biblioteca usar, que estratégia de organização de testes adotar, etc. A pessoa arquiteta atua como enabler (facilitadora), não como blocker (bloqueadora). Em caso de dúvidas, perguntamos, mas não precisamos de aprovação o tempo todo; assim, não vira um gate. Os times ficam mais rápidos sem perder coerência nem ownership (propriedade).

Exemplo de guardrail da ByteBank que poderíamos definir para a equipe de pagamentos: todo novo serviço deve expor métricas via OpenTelemetry. Instrumentar é obrigatório; a organização decidiu padronizar. Mas quem decide como instrumentar? O time. Definimos quais métricas e spans (intervalos) são relevantes para o domínio, pois conversamos com pares e com as pessoas de negócio e temos visão operacional. Quem está muito alto na organização pode tomar decisões equivocadas por falta dessa visão. Em resumo: autonomia dentro do time, com limites definidos. Guardrails funcionam porque tornam as regras explícitas e, em certa medida, inegociáveis, ao mesmo tempo que liberam o time para decidir com segurança — permitindo aprender com erros dentro de limites responsáveis e com riscos baixos.

Recapitulando a aula e contextualizando papéis de arquitetura

Encerrando a Aula 1, vamos recapitular o que vimos até agora. O papel da pessoa Tech Lead é o de guardiã da arquitetura local; não substituímos a pessoa arquiteta quando esse papel existe. Cuidamos do domínio do time, fazemos a interface, alinhamos expectativas, mantemos relações e comunicação, mas não de toda a arquitetura dos outros times. O framework de decisões Tipo 1 e Tipo 2 (modelo de Jeff Bezos) é simples e extremamente efetivo no dia a dia: se houver dúvida sobre o que escalar ou quando envolver mais gente em um contexto mais holístico, usamos esse modelo. O conceito de Bounded Context (contexto delimitado) e o Tech Radar (radar tecnológico) definem ownership (propriedade) claro para o time — fica explícito quem é dono de quê. Pode haver dúvidas no início da implementação, mas depois torna-se natural e vira trabalho de manutenção, especialmente com novas pessoas desenvolvedoras e movimentações internas. Local versus Global: entendemos o que é arquitetura local (soluções) e o que é governança global; mapeamos explicitamente as decisões para evitar ambiguidade de papéis (voltaremos a isso em seguida). Guardrails e não gates: não é proibido ter gates, mas devemos refletir se algo não poderia ser um guardrail, se vai bloquear a equipe e se realmente precisa ser um gate. Quando precisar, tudo bem; avaliamos quantos gates já existem e se não estão obsoletos, mantendo um limite saudável e natural. Preferimos sempre dar autonomia ao time. A união faz a força, e dividir para conquistar tende a ser a melhor estratégia.

Uma observação importante: pode não existir a pessoa arquiteta na organização. Nesses casos, arquitetura se torna uma disciplina, e normalmente fica sob responsabilidade de quem está em Tech Lead. É comum existirem comitês de arquitetura com várias pessoas Tech Lead (ou com papéis análogos) discutindo e decidindo sobre arquitetura. Não é raro o papel formal de arquiteta não existir — por custo, por falta de necessidade no momento, ou por haver pessoas técnicas muito sêniores que já atuaram assim e têm essas competências. Quando não existe, geralmente esse papel recai sobre a liderança técnica; assumimos diferentes papéis conforme a necessidade. O que discutimos aqui permanece válido: se algo for uma decisão Tipo 1, apenas mudam os atores envolvidos e os fóruns onde discutiremos; o peso das decisões segue o mesmo (Tipo 1 e Tipo 2).

Dito esse apêndice, eu agradeço por ter chegado até aqui. Espero que tenha ficado claro. Qualquer dúvida, você pode deixar nos fóruns da Alura; nós responderemos e resolveremos com a maior agilidade possível. Eu espero você na próxima aula, em que veremos como a equipe se alinha tecnicamente nas decisões locais, com alguns rituais que ajudam a manter o engagement (engajamento), a fluidez e a dinâmica, sem burocratizar demais. Até a próxima.

Sobre o curso Arquitetura de software e liderança técnica: decisões, observabilidade e migração incremental

O curso Arquitetura de software e liderança técnica: decisões, observabilidade e migração incremental possui 215 minutos de vídeos, em um total de 41 atividades. Gostou? Conheça nossos outros cursos de Liderança em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Escopo da liderança técnica na arquitetura
• Ritos de alinhamento técnico do time
• Documentação de decisões com ADRs
• Observabilidade e gestão de tradeoffs
• Migração incremental de sistemas legados