Decisões Arquiteturais: Como Tomar Boas Decisões com Informação Imperfeita

Neste artigo · 11 seções

1. A ilusão da decisão perfeita
2. Decisões arquiteturais são apostas, não certezas
3. Começa por uma pergunta bem formulada
4. Opções reais, não teatro de escolha
5. Explícito o que você não sabe
6. Reversibilidade e custo de troca
7. Prova de conceito não é brinquedo, é ferramenta de redução de incerteza
8. Formalizar a decisão ajuda mais do que parece
9. Organização também precisa decidir como decide
10. Conclusão: o valor do arquiteto está na decisão, não na onisciência
11. Insights & Takeaways

Vamos começar direto: se você está esperando “ter todos os dados” para tomar uma decisão de arquitetura, você não está fazendo arquitetura. Você está adiando.

Em sistemas grandes, com vários times, legado, política, fornecedor, nunca vai existir o cenário de informação perfeita. Sempre falta alguma coisa: custo real lá na frente, comportamento de carga, maturidade do time, apetite de risco da diretoria. Ainda assim, a decisão precisa ser tomada. E adiar também é uma decisão, geralmente ruim.

Gregor Hohpe insiste bastante nisso em “The Software Architect Elevator”: se você não está tomando decisões significativas, tornando-as explícitas e ajudando as pessoas a entendê-las, você não está fazendo arquitetura de verdade.

A pergunta então não é “como decidir quando souber tudo?” mas “como decidir bem sabendo que nunca vou saber tudo?”. É isso que vamos destrinchar.

A ilusão da decisão perfeita

A coisa é mais ou menos assim: alguém levanta um tema grande, tipo “vamos padronizar mensageria?” ou “vamos migrar esse monólito para serviços?”. A sala enche de “dependes”. As pessoas começam a levantar mais pesquisas, mais benchmarks, mais reuniões com fornecedores.

Nada contra estudar. O problema é quando a busca por informação perfeita vira desculpa elegante para não se comprometer. Enquanto isso, o time continua empilhando solução ad-hoc, cada squad resolve de um jeito, o acoplamento aumenta, a dívida cresce.

Arquitetura acontece de qualquer forma. A diferença é se você escolhe conscientemente ou deixa “o default” decidir. Como Hohpe pontua, sempre existe uma arquitetura, mesmo quando você “não teve tempo” de pensar em arquitetura.

Aceitar que você sempre vai decidir com lacunas de informação é o primeiro passo para sair da paralisia.

Decisões arquiteturais são apostas, não certezas

Uma forma bem didática de enxergar decisões de arquitetura é pensar nelas como apostas: você está apostando que, dado o que sabe hoje, aquela estrutura vai se pagar no tempo.

Algumas apostas são pequenas: escolher um lib de logging, o formato de um evento interno, um naming convention. Outras são grandes: tipo de particionamento de dados, dividir um domínio em dois bounded contexts errados, escolher um fornecedor que vai estar no coração da operação.

Não adianta fingir que arquitetura é exata. O que dá para fazer é:

• Tornar explícito qual é a aposta.
• Em que contexto ela faz sentido.
• E como você pretende reagir se a realidade não confirmar o plano.

Hohpe fala muito de arquitetura como “vender opções” para o negócio: você não promete que o futuro vai ser daquele jeito, você cria opções de caminho que mantêm a empresa flexível em vez de aprisionada.

Começa por uma pergunta bem formulada

Decisão ruim começa em pergunta ruim. Antes de discutir tecnologia ou desenho, você precisa cravar:

Que decisão exatamente estamos tomando?

“Arquitetar o sistema X” não é uma decisão. É um trabalho. “Esse sistema vai expor tudo via API síncrona ou vamos introduzir eventos assíncronos para integração com os outros domínios?” já é outra história.

Uma boa pergunta de decisão arquitetural tem algumas características:

• Foca em um trade-off específico.
• Tem impacto claro em mais de um time, sistema ou requisito de qualidade.
• Tem opções reais diferentes, não variações cosméticas da mesma coisa.

Se você não consegue escrever essa pergunta em uma frase clara, ainda não está no nível certo. Fica tudo abstrato, e aí cada um discute uma coisa.

Opções reais, não teatro de escolha

Outro erro comum em decisão sob incerteza é fingir que está avaliando alternativas, quando na prática já está tudo decidido emocionalmente. O famoso “vamos avaliar, mas a opção B é impraticável, a C ninguém quer, a D o fornecedor não suporta”.

Ser didático aqui é simples:

• Escreva 2 ou 3 opções que você realmente aceitaria implementar.
• Inclua conscientemente “não fazer nada agora” como uma delas, quando isso for de fato possível.
• Liste prós e contras de cada uma em critérios arquiteturais: acoplamento, latência, complexidade operacional, curva de aprendizado, dependência de fornecedor, impacto em times.

Quando você faz isso na frente do time, algo interessante acontece: fica claro que não existe opção sem custo. A conversa sai do “gosto mais dessa” para “topo esse custo para ganhar esse benefício?”.

É aqui que a informação imperfeita entra como dado de entrada, não como desculpa para fuga. Você assume que alguns prós e contras são hipóteses, marca isso e segue.

Explícito o que você não sabe

Arquitetos lidam o tempo todo com requisitos não ditos, dependências implícitas e suposições velhas que ninguém mais lembra de onde vieram.

Quando a informação é imperfeita, o pior que você pode fazer é varrer isso para debaixo do tapete. Melhor é jogar luz diretamente:

• O que estamos assumindo sobre volume de tráfego daqui a 2 anos?
• O que estamos assumindo sobre quantos times vão mexer nesse módulo?
• O que estamos assumindo sobre quanto o negócio aceita de downtime?

Você não precisa ter o número exato. Mas precisa escrever “estamos supondo que…”. Isso muda a postura da equipe. Se lá na frente a realidade vier diferente, você sabe que essa hipótese quebrou. E pode revisitar a decisão sem drama, porque ela nunca foi uma “verdade absoluta”, era uma escolha sob hipótese X.

Reversibilidade e custo de troca

Um truque extremamente útil na prática é classificar a decisão por duas dimensões:

1. Quão difícil é voltar atrás?
2. Quão espalhada é a consequência dessa decisão?

Escolher um banco de dados relacional para o sistema central, com schema compartilhado por 20 módulos, é uma decisão difícil de reverter e com raio de impacto alto. Escolher um formato de payload interno entre dois serviços, que você controla dos dois lados, é muito mais barato de mudar depois.

Isso muda como você decide com informação imperfeita:

• Se a decisão é reversível e local, você pode aceitar decidir com menos estudo e mais experimentação.
• Se a decisão é quase irreversível e global, você precisa gastar mais tempo refinando hipótese, falando com pessoas diferentes, às vezes fazendo prova de conceito mais séria.

Hohpe bate bastante na disciplina de decisão: não é sobre nunca errar, é sobre saber quais decisões são realmente pesadas e tratá-las com mais cuidado.

Prova de conceito não é brinquedo, é ferramenta de redução de incerteza

Informação imperfeita não se resolve só em reunião. Muitas vezes, o caminho mais honesto é admitir: “a gente não sabe se essa abordagem vai dar conta do recado, vamos rodar um experimento controlado”.

Prova de conceito, teste de carga, spike técnico. Tudo isso deixa de ser “curiosidade de dev” e vira peça do processo de decisão. A diferença quando você está sendo disciplinado é:

• Você entra no experimento com perguntas claras.
• Define o que quer medir.
• E decide antes quanto tempo e esforço vai gastar.

Ao final, você não sai com certeza absoluta, mas reduz a incerteza em áreas importantes. Isso já é o suficiente para tomar a decisão com muito mais confiança.

Formalizar a decisão ajuda mais do que parece

Arquitetura sob incerteza gera muito ruído de memória. Alguns meses depois, alguém pergunta: “mas por que mesmo a gente escolheu isso?”. E ninguém lembra. A decisão vira alvo fácil de crítica retroativa, sem contexto.

Hohpe sugere algo simples e poderoso: registrar decisões arquiteturais de forma leve, os famosos Architecture Decision Records. Coisa de uma página, com:

• Contexto.
• Problema.
• Opções consideradas.
• Decisão.
• Consequências.

Quando você registra assim, dois efeitos aparecem:

• Fica muito mais fácil revisar a decisão quando o contexto muda, sem culpar ninguém.
• Fica mais fácil para novos times entenderem como chegaram ali, em vez de supor que “foi porque alguém quis”.

Organização também precisa decidir como decide

Por fim, existe um aspecto organizacional: como a empresa decide quando não tem consenso e não tem dados completos.

Se cada decisão grande vira um ciclo infinito de comitês, apresentações e “vamos pensar mais um pouco”, a arquitetura vira refém de governança. Aí entra o papel do arquiteto como facilitador:

• Ajudar a timeboxar discussões.
• Propor critérios de “bom o bastante por agora”.
• Sugerir revisões futuras explícitas: “a gente decide isso hoje com esses dados, e em 9 meses revisita com dados de produção”.

Hohpe lembra que, em grandes organizações, parte do trabalho do arquiteto é justamente enfrentar essa inércia, sabendo que sistemas sociais resistem à mudança tanto quanto sistemas técnicos.

Decidir com informação imperfeita não é uma falha do processo, é a condição normal. Ter processo explícito para isso é sinal de maturidade, não de desleixo.

Conclusão: o valor do arquiteto está na decisão, não na onisciência

Arquitetos não são oráculos. Não existe “saber o futuro” o suficiente para acertar toda decisão sem risco. O que existe é disciplina:

• Formular bem a pergunta.
• Explorar opções reais.
• Tornar claros os critérios e as incertezas.
• Classificar reversibilidade.
• Usar experimentos a seu favor.
• Registrar a decisão de forma que possa ser revisitada.

Com isso, você sai do modo “decisão por feeling” e entra em um modo mais adulto: decisões assumidamente imperfeitas, mas conscientes, explicadas, rastreáveis e ajustáveis.

No dia a dia, esse é o verdadeiro trabalho de arquitetura: não é escolher ferramenta ou desenhar caixinha bonita, é tomar e sustentar boas decisões em ambientes onde nunca vai dar para saber tudo. Quem aprende a fazer isso com clareza vira referência, mesmo sem ter todas as respostas.

Insights & Takeaways

• Arquitetura sempre é feita com informação incompleta, o risco não está em decidir com lacunas, e sim em fingir que elas não existem e deixar o “default” decidir sozinho.
• Decisões arquiteturais são apostas com hipóteses, não verdades absolutas; explicitar hipóteses, opções e trade-offs já melhora muito a qualidade da decisão.
• Classificar decisões por reversibilidade e raio de impacto ajuda a calibrar o nível de análise e experimentação adequado para cada caso.
• Provas de conceito e registros de decisão (ADRs) não são burocracia, são ferramentas práticas para reduzir incerteza e preservar contexto para revisões futuras.
• Parte do papel do arquiteto é desenhar o próprio processo de decisão da organização, fugindo tanto da paralisia por análise quanto da decisão por impulso sem critério.