O que realmente orienta decisões arquiteturais
Como critérios de sucesso e atributos de qualidade moldam a arquitetura de um sistema
No texto anterior, falamos que arquitetura de software não começa na tecnologia.
Ela começa nas decisões difíceis e nos sacrifícios que escolhemos fazer.
A pergunta natural que fica é:
Com base em quê essas decisões deveriam ser tomadas?
Arquitetura de software precisa de critério
Toda arquitetura, consciente ou não, otimiza alguma coisa.
Às vezes é desempenho.
Às vezes é velocidade de entrega.
Às vezes é segurança, confiabilidade ou facilidade de manutenção.
O problema é que, na maioria dos times, isso nunca é explicitado.
Decisões são tomadas, tecnologias são escolhidas, estruturas são criadas…
sem que fique claro qual critério estava guiando tudo aquilo.
Em muitos contextos, esses critérios aparecem como critérios de sucesso do sistema.
Ou seja: o que precisa ser verdade para que esse software seja considerado bem-sucedido ao longo do tempo.
Quando olhamos isso pela lente da arquitetura, estamos falando dos atributos de qualidade.
O que realmente sustenta o sucesso de um sistema
Em muitos contextos, os critérios de sucesso de um sistema aparecem com outro nome:
requisitos não funcionais.
Eles não descrevem o que o sistema faz, mas as condições que precisam ser atendidas para que ele seja considerado bem-sucedido ao longo do tempo.
Quando olhamos esses critérios pela lente da arquitetura, estamos falando dos atributos de qualidade.
Atributos de qualidade não são funcionalidades.
Eles descrevem como o sistema deve se comportar, não o que ele faz.
Estamos falando de coisas como:
- desempenho
- escalabilidade
- confiabilidade
- segurança
- manutenibilidade
- testabilidade
- observabilidade
Aqui, “qualidade” não se refere à área de QA ou testes, mas às características estruturais que sustentam o sucesso do sistema.
Esses atributos atravessam todo o software e influenciam praticamente todas as decisões arquiteturais.
Em outras palavras:
Atributos de qualidade são os critérios de sucesso vistos pela lente da arquitetura.
O ponto incômodo: critérios entram em conflito
Aqui está a parte que muita gente prefere ignorar.
Critérios competem entre si.
Alguns exemplos bem conhecidos:
- mais desempenho costuma aumentar a complexidade
- mais segurança pode piorar a usabilidade
- mais flexibilidade quase sempre cobra um custo cognitivo maior
- mais abstração raramente vem de graça
Não dá para maximizar tudo ao mesmo tempo.
Toda decisão arquitetural é, na prática, uma escolha de qual critério priorizar
e quais outros aceitar sacrificar.
É exatamente aqui que arquitetura deixa de ser opinião
e passa a ser decisão consciente.
O custo invisível de ignorar critérios
Ignorar critérios não significa que eles deixam de existir.
Significa apenas que o custo fica invisível.
A complexidade cresce silenciosamente. A manutenção fica mais cara. As decisões ficam cada vez mais difíceis.
Existe uma força natural nos times para focar apenas na parte funcional do software. Especialmente no início da carreira, somos treinados a entregar comportamento (e software rodando), não a refletir sobre critérios.
Mesmo times experientes caem nessa armadilha. O modo constante de “apagar incêndio” consome energia demais para explicitar critérios e atributos importantes.
No fim, a falta de critério não só compromete a arquitetura, como também drena o time.
Arquitetura como escolha de otimização
Uma pergunta simples, mas poderosa, que raramente é feita:
o que esse sistema está tentando otimizar?
Quando essa resposta não existe, ou muda a cada conversa, o que surge é uma arquitetura acidental.
Ela não foi construída para sustentar critérios claros.
Ela apenas aconteceu, decisão após decisão, pressão após pressão.
Arquitetura madura não tenta garantir tudo.
Ela escolhe conscientemente onde faz sentido investir energia.
Uma pergunta simples (e muito útil) para orientar decisões
Antes de discutir tecnologia, frameworks ou padrões, experimente perguntar:
Qual critério de sucesso é mais importante neste contexto?
Um sistema financeiro regulado não otimiza as mesmas prioridades que um produto em early stage.
Um sistema interno não tem os mesmos critérios de um produto de massa voltado ao consumidor final.
Da mesma forma, um software corporativo complexo, com responsabilidades críticas, integrações sensíveis e uso estratégico de IA, tende a priorizar critérios como confiabilidade, segurança, governança, auditabilidade, compliance e controle.
Já um produto pequeno, ainda em fase inicial (protótipo, PoC, MVP, etc.), muitas vezes construído em um contexto mais experimental ou até com vibe coding, costuma otimizar velocidade de aprendizado, custo baixo e rapidez de iteração, mesmo que isso signifique aceitar mais risco, menos robustez e decisões provisórias.
Contexto define critério.
Critério guia decisão.
Decisão define arquitetura.
Aqui vale lembrar também que:
Ferramentas mudam rápido. Frameworks vêm e vão.
O que sustenta uma boa arquitetura ao longo do tempo não é a stack ou a tecnologia,
mas a clareza dos critérios que orientam as decisões.
No próximo passo dessa reflexão, uma pergunta inevitável surge:
o que acontece quando esses critérios mudam com o tempo?
Mas isso fica para a próxima conversa.
Seguimos juntos, pelo código, pela arquitetura e além! ☕🚀
