Arquitetura de software não começa na tecnologia. Começa nos sacrifícios.
Arquitetura de software não começa na escolha da tecnologia. Começa nas decisões difíceis que ninguém gosta de assumir.
Em um cenário onde ferramentas mudam cada vez mais rápido, o diferencial continua sendo a qualidade das decisões, muitas delas difíceis e que ninguém gosta de assumir.
Quando alguém fala em arquitetura de software, a conversa quase sempre vai para o mesmo lugar:
“Qual stack vocês usam?”
“Qual framework?”
“É monólito ou microsserviços?”
“Qual banco? Qual cloud?
Agora mais recentemente: “Qual LLM…?”
Essas perguntas até são válidas em determinados contextos porém, muitas vezes, não são as mais importantes ou já começam tarde demais.
Arquitetura não é sobre escolher tecnologias.
É sobre decidir o que você está disposto a sacrificar.
Em um momento em que novas ferramentas, inclusive baseadas em IA, prometem acelerar tudo, essa distinção ficou ainda mais importante.
O problema que quase todo time vive
Na prática, decisões arquiteturais raramente acontecem em um cenário ideal.
Elas acontecem:
- com prazo apertado
- com sistema legado
- com pessoas entrando e saindo do time
- com o negócio mudando de direção
- com a evolução tecnológica batendo à porta, frameworks, IA, LLMs, novidades, etc.
E, mesmo assim, ainda existe a crença de que arquitetura é algo estático.
Define-se uma vez, documenta-se… e pronto.
Esse é um equívoco mais comum do que parece, cometido por muitos engenheiros e até por arquitetos com certa bagagem.
A tecnologia vem avançando tão rápido que muitas vezes as pessoas não percebem que a arquitetura também precisa evoluir. Cria-se a ideia de que ela é algo meramente estrutural, que uma vez definida deve ser seguida à risca, quase como algo imutável.
Essa ideia cobra um preço alto ao longo do tempo.
Arquitetura tem fundamentos, mas é viva
Um ponto central discutido no livro Fundamentos de Arquitetura de Software: uma abordagem de engenharia é que, apesar de existirem princípios sólidos, a arquitetura tem natureza dinâmica.
Ela muda porque:
- tecnologias mudam
- requisitos mudam
- o entendimento do problema amadurece
- o próprio time evolui
Arquitetura não é um estado final.
É um processo contínuo de decisões sob pressão e mudança.
Toda decisão cobra um preço
Toda escolha arquitetural otimiza algo e impacta outra coisa. Estamos falando das concessões ou, se preferir, dos trade-offs.
Alguns exemplos bem reais:
- mais flexibilidade leva a mais complexidade
- mais velocidade de entrega reduz o controle (gestão, qualidade, etc.)
- mais abstração aumenta o custo cognitivo
- mais autonomia exige mais esforço de coordenação
Não existe decisão correta no vácuo.
Existe decisão coerente com o contexto atual, sabendo o preço que será pago depois.
Em um tom mais reflexivo, essa é a vida… Tudo tem seu preço. Na arquitetura de software não seria diferente.
O erro que quase todo time comete
O problema raramente é a tecnologia escolhida.
O problema é fingir que não existe sacrifício.
Arquiteturas que tentam ser:
- escaláveis antes de precisar e preparadas para um futuro hipotético
- flexíveis para todos os cenários possíveis (como se fosse possível antecipar tudo)
costumam gerar sistemas caros, rígidos e difíceis de evoluir.
Casos como esses surgem por fatores como hype tecnológico, overengineering, falta de experiência ou desalinhamento com o contexto real, seja por interesses divergentes ou por desconhecimento.
No fim das contas, a arquitetura acaba virando peso e não alavanca.
Uma regra simples para ajudar
Guarde essa heurística:
Se você não consegue explicar claramente o que está sacrificando, provavelmente ainda não tomou uma decisão arquitetural de verdade.
Escolher tecnologia é relativamente fácil.
Escolher o que abrir mão exige maturidade.
Arquitetura não é sobre prever o futuro.
É sobre responder bem à mudança.
E quanto mais cedo entendemos isso, mais conscientes nos tornamos como profissionais, não só como desenvolvedores ou arquitetos, mas como pessoas que influenciam decisões reais.
Em um cenário onde ferramentas mudam rapidamente, o que sustenta uma boa arquitetura não é a tecnologia em si, mas a qualidade das decisões por trás dela.
Esse é um tema com muitas camadas e desdobramentos.
Pretendo explorá-lo aos poucos por aqui, com situações reais e decisões do dia a dia.
Se esse tipo de reflexão faz sentido para você, assinar a newsletter é a melhor forma de acompanhar esse conteúdo.
E me conta:
Você já precisou tomar uma decisão arquitetural importante?
Qual foi o maior sacrifício arquitetural que você ou seu time já precisaram fazer?
Seu comentário ajuda a continuar a conversa. Se este texto te fez pensar, não deixa de me acompanhar aqui e assinar a minha newsletter.
Seguimos juntos pelo código e além! ☕🚀
