O que muda quando a arquitetura começa pelo negócio

Começar pelo negócio não significa deixar a tecnologia em segundo plano. Significa dar a ela um propósito claro. Antes de escolher plataforma, padrão ou fornecedor, a equipe entende qual mudança precisa produzir, para quem e dentro de quais limites.

O problema de começar pela tecnologia

É comum uma iniciativa nascer com frases como “precisamos de microsserviços”, “vamos para a nuvem” ou “temos de usar inteligência artificial”. Essas ideias podem fazer sentido, mas ainda não descrevem um problema. São possíveis respostas apresentadas antes da pergunta.

Quando isso acontece, a arquitetura tende a otimizar o que é tecnicamente interessante, não necessariamente o que é importante. A equipe pode criar alta disponibilidade onde o negócio tolera algumas horas de parada, adicionar integrações em tempo real para um processo diário ou aumentar a complexidade sem gerar benefício percebido.

Cinco perguntas para abrir a conversa

Uma boa descoberta não precisa começar com um workshop de vários dias. Uma conversa objetiva já melhora muito a qualidade do desenho. Pergunte:

1. Qual resultado queremos mudar? Reduzir abandono, acelerar atendimento, diminuir custo, entrar em um novo mercado ou atender uma regra?
2. Quem percebe esse resultado? Cliente, operação, parceiro, área comercial ou auditoria?
3. Como saberemos que melhorou? Defina um indicador observável, mesmo que ainda seja uma estimativa.
4. Quais limites são reais? Prazo, orçamento, segurança, legislação, equipe disponível e sistemas que não podem ser alterados.
5. Quais riscos não podemos aceitar? Perda de dados, indisponibilidade, exposição de informação ou dependência excessiva de um fornecedor.

As respostas formam o contexto da arquitetura. Elas ajudam a separar requisitos importantes de preferências e tornam as escolhas mais fáceis de justificar.

Como traduzir objetivo em decisão

O caminho pode ser enxergado como uma sequência curta:

Essa sequência evita saltar diretamente do objetivo para o produto. Primeiro entendemos o que a organização precisa ser capaz de fazer. Depois definimos as qualidades necessárias e só então avaliamos alternativas técnicas.

Exemplo: melhorar o checkout

Imagine um comércio eletrônico que quer “modernizar o checkout”. O pedido ainda é amplo. Ao investigar, a equipe descobre que o resultado esperado é reduzir o abandono em celulares, hoje concentrado na etapa de pagamento.

O indicador escolhido é a taxa de conclusão. A principal restrição é manter o provedor atual durante seis meses. O risco mais sensível é cobrar duas vezes quando a conexão do cliente oscila.

Agora as decisões ganham direção. A solução precisa simplificar a jornada móvel, tratar repetição de requisições com segurança, observar falhas por etapa e permitir a troca futura do provedor. Talvez dividir todo o sistema em microsserviços não ajude nesse momento. Criar uma fronteira clara para pagamentos e melhorar a experiência pode gerar valor mais rápido e com menos risco.

Um roteiro de 45 minutos

• 10 minutos: descreva o problema e quem é afetado, sem falar de solução.
• 10 minutos: combine indicadores e o que seria uma melhora relevante.
• 10 minutos: liste restrições, riscos e decisões já tomadas.
• 10 minutos: desenhe capacidades e fluxos essenciais.
• 5 minutos: registre dúvidas, hipóteses e o próximo experimento.

O resultado não é a arquitetura final. É um ponto de partida compartilhado. A partir dele, o HLD, as provas de conceito e os ADRs passam a responder ao mesmo contexto.