Skip to main content

Contexto de Negócio

Visão Geral​

A mesma arquitetura pode ser excelente numa empresa e desastrosa em outra, com o mesmo problema técnico. A diferença está no contexto de negócio: o que a empresa está tentando fazer, com quanto dinheiro, em quanto tempo, sob quais regras, com quantas pessoas.

Ignorar esse contexto produz arquiteturas tecnicamente defensáveis e organizacionalmente inviáveis — que são as que não sobrevivem.

O Problema​

Engenheiros são treinados a otimizar propriedades técnicas: latência, throughput, disponibilidade, elegância. Nenhuma dessas propriedades tem valor em si. Elas têm valor na medida em que sustentam algo que o negócio precisa.

O sintoma clássico: um time investe seis meses construindo uma plataforma capaz de absorver crescimento de cem vezes, para um produto que ainda não sabe se terá usuários. A engenharia é boa. A decisão é ruim — porque o risco dominante era de mercado, não de escala, e os seis meses foram gastos reduzindo o risco errado.

O oposto também acontece: um sistema que processa transações financeiras construído com a mesma tolerância a inconsistência de um feed social, porque ninguém perguntou o que acontece quando um valor fica errado.

Nos dois casos a falha é a mesma. A arquitetura respondeu a uma pergunta técnica sem ter estabelecido qual pergunta de negócio estava sendo respondida.

Conceitos Centrais​

O que compõe o contexto​

Cinco grupos de fatores restringem arquitetura antes de qualquer discussão técnica começar.

Modelo de negócio. Como a empresa ganha dinheiro determina o que uma falha custa. Indisponibilidade num marketplace transacional custa receita por minuto; numa ferramenta interna, custa produtividade. Os dois números diferem em ordens de grandeza e justificam investimentos diferentes.

Estágio. Uma empresa buscando encaixe de produto precisa de velocidade de mudança acima de tudo, porque vai jogar fora boa parte do que construir. Uma empresa em escala precisa de estabilidade, porque o custo de errar aumentou. A mesma decisão arquitetural — digamos, investir em abstração para trocar de provedor — é prudência numa e desperdício na outra.

Restrições regulatórias. Onde o dado pode residir, quanto tempo precisa ser retido, o que precisa ser auditável, quem pode ver o quê. Não são negociáveis, e frequentemente eliminam opções inteiras antes da primeira reunião técnica.

Economia. Orçamento, se é capital ou despesa operacional, e o horizonte em que o investimento precisa se pagar.

Organização. Quantas pessoas, com que competências, distribuídas como. Uma arquitetura que exige competência que a empresa não tem e não vai contratar é uma arquitetura que não vai existir. Este fator retorna com força no Nível 07, via lei de Conway.

As perguntas que extraem o contexto​

Stakeholders raramente oferecem esse contexto de forma organizada. Ele é extraído, e as perguntas que funcionam são concretas:

  • Como a empresa ganha dinheiro com este sistema?
  • O que acontece, em termos de negócio, se ele ficar fora por uma hora? E por um dia?
  • Quanto custa um dado errado? Alguém percebe? Quem paga?
  • Que regulação se aplica, e o que ela proíbe?
  • Isso precisa estar pronto quando, e o que acontece se atrasar dois meses?
  • Quantas pessoas vão manter isso daqui a um ano?

Perguntas vagas — "quais são os requisitos não-funcionais?" — produzem respostas vagas. Perguntas sobre consequência produzem números.

Contexto muda; arquitetura precisa acompanhar​

Contexto de negócio não é um levantamento que se faz uma vez. Empresas mudam de estágio, entram em mercados regulados, crescem ou encolhem times.

Uma arquitetura correta para o contexto de três anos atrás pode ser errada hoje sem que nada de técnico tenha mudado. Reconhecer isso é o assunto de evolução da arquitetura.

Modelo Mental​

Antes de qualquer decisão técnica, responda: qual risco esta decisão reduz, e esse risco é o maior que temos?

A pergunta funciona porque força a comparação. Quase toda decisão arquitetural reduz algum risco. O que distingue uma boa decisão é reduzir o risco dominante — e o risco dominante é uma propriedade do contexto de negócio, não do sistema.

Por Que Isso Importa​

Porque determina o que "bom" significa. Sem contexto, "boa arquitetura" vira preferência estética. Com contexto, vira adequação verificável: esta arquitetura sustenta o que a empresa precisa fazer, dentro do que ela consegue pagar e operar?

Porque é o que permite defender uma decisão. Um argumento técnico convence engenheiros. Um argumento que conecta a decisão técnica a uma consequência de negócio convence quem aprova orçamento — e é essa a conversa que determina se a arquitetura vai existir.

Porque evita reduzir o risco errado. É o desperdício mais comum e o mais invisível, porque o trabalho feito é de boa qualidade. Ninguém aponta erro num sistema bem construído; só se percebe, tarde, que ele resolveu um problema que não era o gargalo.

Erros Comuns​

Tratar contexto como assunto de produto. Arquitetura decidida sem contexto de negócio otimiza por default — normalmente para escala ou pureza técnica, que raramente são o risco dominante.

Aceitar "precisa ser rápido e confiável" como requisito. Não é requisito; é um desejo. Requisito é "95% das buscas abaixo de 300 ms" ou "no máximo 4 horas de indisponibilidade por ano". A conversão de desejo em número é trabalho arquitetural, e é onde o contexto entra.

Projetar para o crescimento prometido em vez do provável. Toda empresa espera crescer cem vezes. A pergunta útil não é qual o teto imaginado, e sim qual o crescimento nos próximos doze meses e quanto custa adiar a decisão de escala até lá.

Confundir o que o negócio pede com o que o negócio precisa. Stakeholders descrevem soluções — "precisamos de um dashboard em tempo real". O trabalho é recuar até o problema: que decisão será tomada com esse dado, e com que atraso ela ainda é útil? A resposta frequentemente elimina "tempo real" do requisito, e com ele metade da complexidade.

Presumir contexto em vez de perguntar. Especialmente sobre regulação e sobre custo de dado errado — dois assuntos em que a intuição de engenharia costuma estar errada por ordens de grandeza, nos dois sentidos.

Exemplo Real​

Uma empresa de logística pede um sistema de rastreamento de entregas em tempo real. O time esboça arquitetura orientada a eventos, WebSockets, atualização sub-segundo.

Três perguntas mudaram o projeto inteiro.

Quem consome essa informação? Operadores de central, que verificam o status quando um cliente liga. Não há tela aberta em observação contínua.

Com que frequência a posição de fato muda de forma relevante? A cada parada — em média, a cada dezoito minutos.

O que acontece se a informação estiver cinco minutos atrasada? Nada. O operador informa "saiu para entrega" ou "a caminho", e cinco minutos não alteram a resposta.

O sistema entregue faz consulta com cache de dois minutos. Custou uma fração do esboço original, tem uma fração da complexidade operacional, e atende integralmente a necessidade.

A parte que merece atenção: o esboço original não era tecnicamente errado. Ele respondia corretamente ao pedido — "tempo real" — que era a solução que o stakeholder tinha imaginado, não o problema que ele tinha.

Conceitos Relacionados​

Exercício Prático​

Escolha um sistema em que você trabalha e responda por escrito às seis perguntas da seção "As perguntas que extraem o contexto".

Marque quais você respondeu com fato verificável e quais com suposição.

As suposições são o material da próxima conversa com quem tem a resposta — e, na maioria dos times, elas são a maioria.

Perguntas de Entrevista​

  • Como você levanta requisitos com um stakeholder que só descreve soluções?
  • Dê um exemplo de decisão arquitetural que você mudou por causa de contexto de negócio.
  • Como o estágio de uma empresa muda o que é uma boa arquitetura?

Para Aprofundar​

  • Vernon, Vaughn. Implementing Domain-Driven Design. Addison-Wesley, 2013 — capítulos sobre alinhamento entre domínio e negócio.
  • Ford, Neal; Richards, Mark. Fundamentals of Software Architecture. O'Reilly, 2020 — capítulo sobre drivers arquiteturais.