O problema do conhecimento tácito

Nas primeiras fases de uma startup, é comum que as decisões sejam tomadas informalmente, em conversas rápidas entre fundadores, líderes de produto e desenvolvedores. As justificativas são óbvias para quem estava na sala, mas ninguém as registra. O código cresce, a equipe multiplica, pessoas entram e saem. Meses depois, alguém pergunta: “Por que usamos este framework de ORM?” e as respostas variam: “porque na época era o mais simples”, “porque o fulano gostava”, “porque era o único que funcionava com nosso banco”. Nenhuma delas é mais que um palpite.

Esse conhecimento tácito se torna um problema sério quando o negócio escala. Investidores exigem governança, auditores pedem rastreabilidade, novos engenheiros precisam entender o legado e decisões de ontem condicionam a inovação de amanhã. Sem documentação, a empresa fica refém do acaso. Decisões importantes se perdem em e-mails, chats ou na mente de quem já saiu. A falta de contexto gera retrabalho: novas equipes repetem experimentos, descartam soluções que já foram testadas e sofrem com códigos com história mal contada.

Michael Nygard, em Release It!, conta casos em que a falta de registro dos “porquês” levou empresas a implementar soluções redundantes, comprar softwares desnecessários e repetir falhas de segurança. Quando chegou a hora de auditar, ninguém sabia explicar por que determinada tecnologia havia sido escolhida, e a empresa gastou milhões para refazer algo que havia sido construído há anos.

O que são Architecture Decision Records (ADRs)?

ADR, ou Architecture Decision Record, é um documento curto e estruturado que registra uma decisão arquitetural. Criado pelo próprio Nygard, ele segue um formato simples: apresenta contexto, decisões, opções descartadas e consequências. O objetivo é que qualquer pessoa, ao ler um ADR, entenda a motivação e as implicações daquela escolha em poucos minutos. Um ADR típico contém:

• Título: descreve em uma frase o que foi decidido (por exemplo, “Escolha de banco de dados NoSQL para módulo X”);

• Contexto: explica a situação que levou à decisão, incluindo requisitos, restrições, e informações sobre o negócio, usuários e tecnologia;

• Decisão: descreve a solução escolhida, por que foi escolhida, e quem participou da decisão;

• Alternativas consideradas: mostra outras opções avaliadas, com argumentos a favor e contra;

• Consequências: lista efeitos imediatos e de longo prazo, positivos e negativos, e ações derivadas (por exemplo, “adotar NoSQL implica em replicar dados manualmente e monitorar consistência”);

• Data e status: registram quando a decisão foi tomada e se ainda está em vigor ou foi revisada.

Neal Ford e Mark Richards, em Software Architecture: The Hard Parts, reforçam que o “porquê” (racionalidade) é mais importante que o “como” (implementação). A implementação pode mudar, mas a lógica que levou à escolha permanece relevante. Um ADR bem escrito ensina novas gerações de desenvolvedores por que a empresa evita determinado framework ou por que optou por dividir o monólito apenas em certos domínios.

Benefícios de documentar os porquês

1. Alinhamento e transparência – Quando decisões são registradas com clareza, todos na organização compreendem as motivações. Isso reduz ruído e evita discussões repetitivas. Times de produto entendem por que determinadas features têm restrições, operações sabem onde estão as fragilidades e times de compliance podem verificar se a tecnologia atende às normas.

2. Aceleração do onboarding – Novos engenheiros e arquitetos não precisam se perguntar o motivo das escolhas; os ADRs fornecem contexto histórico. Isso acelera a capacidade produtiva de novos colaboradores e reduz a dependência de “gurus” que conhecem tudo de cabeça.

3. Base para revisões – Quando o contexto muda (crescimento de tráfego, mudança de estratégia, alteração legislativa), as decisões podem ser revisadas com base em suas justificativas originais. Se um ADR indica que a escolha de não usar replicação geográfica se devia ao baixo volume inicial, é mais fácil revisitar essa decisão quando a visão de expansão global se torna realidade.

4. Rastreabilidade e governança – Investidores e reguladores exigem que a empresa saiba explicar como protege dados, como administra transações e como decide mudanças críticas. ADRs fornecem material para auditorias e relatórios de conformidade. Eles mostram que as decisões não são arbitrárias, mas baseadas em critérios e aprovadas por responsáveis.

5. Prevenção de decisões ruins – Ao descrever alternativas descartadas, os ADRs revelam contrapartes que podem ser úteis no futuro. E ao expor consequências, alertam sobre limitações que poderiam passar despercebidas em discussões apressadas. O ato de escrever obriga os decisores a refletirem mais profundamente, o que por si só aumenta a qualidade da escolha.

Como incorporar ADRs à cultura da empresa

1. Definir padrões e templates – Crie um template de ADR simples, adaptado ao contexto da empresa, e disponibilize a todos. Explique que não se trata de relatórios longos, mas de registros rápidos e direcionados.

2. Registrar as decisões ao serem tomadas – Não adie a escrita. Documente logo após a decisão, enquanto a motivação está fresca.

3. Revisar periodicamente – Estabeleça momentos (trimestrais ou semestrais) para revisar ADRs e verificar se ainda fazem sentido. Marque ADRs como superseded (superado) quando uma decisão é alterada. Essa revisão ajuda a manter o conhecimento atualizado e evita duplicidade.

4. Facilitar acesso e comunicação – Armazene ADRs em repositórios acessíveis (como Git) ou wikis, e divulgue internamente. Faça workshops para apresentar decisões cruciais a todas as áreas. Garanta que líderes de produto e operações entendam o conteúdo.

5. Incentivar a participação de stakeholders – Um ADR fica mais rico quando inclui perspectivas de diferentes áreas. Ao registrar uma decisão sobre política de logs, convide profissionais de segurança e jurídico para oferecerem insumos. Isso garante que a decisão esteja alinhada à visão e considere limitações de todos os lados.

Exemplos práticos de ADRs

Imagine que uma empresa de e-commerce precise decidir como armazenar dados de sessão de usuários. Três opções surgem: banco relacional, Redis e cookies persistentes. O ADR mostraria:

• Contexto: alta frequência de acesso, necessidade de escalabilidade horizontal, latência baixa, dados de sessão com expiração curta.

• Decisão: uso de Redis por causa da latência e capacidade de escalar horizontalmente.

• Alternativas: banco relacional (acesso lento, mas boa consistência), cookies (sem custo de infraestrutura, mas risco de segurança e tamanho limitado).

• Consequências: necessidade de adicionar mecanismo de failover ao Redis para alta disponibilidade; custo de infraestrutura; monitoramento da expirabilidade.

Em outra situação, uma fintech decide adotar API aberta para integrar com parceiros. O ADR registraria que a decisão foi tomada para acelerar integrações e captar parceiros, apesar do aumento de superfície de ataque. Como consequência, a empresa decide investir em WAF (Web Application Firewall) e monitoramento de APIs. Depois de três anos, ao rever o ADR, a empresa pode decidir evoluir para um gateway de API mais robusto, pois o número de parceiros e requisições cresceu.

Como a IA pode apoiar na construção de ADRs

A escrita de ADRs exige clareza e disciplina, mas isso não significa que precise ser um processo pesado. Modelos de linguagem (LLMs) podem atuar como assistentes de raciocínio, ajudando times a transformar conversas e decisões dispersas em registros estruturados. Em vez de substituir o julgamento técnico, a IA pode organizar, sugerir e acelerar o processo de documentação, permitindo que as pessoas se concentrem no essencial: pensar bem.

Aqui estão três formas práticas de usá-la:

1. Transformar discussões em decisões documentadas

   Ao integrar um modelo de linguagem a canais de comunicação (como Slack, Jira ou Notion), é possível capturar automaticamente decisões que emergem em reuniões ou threads de chat. A IA identifica padrões de decisão — frases como “decidimos usar… porque…” — e propõe um rascunho de ADR, preenchendo seções de contexto, decisão e alternativas. O arquiteto ou tech lead revisa e valida o conteúdo, garantindo precisão e autoria.

2. Gerar e comparar alternativas técnicas

   Diante de um problema, LLMs podem ajudar a explorar opções, vantagens e riscos de diferentes abordagens. Por exemplo, ao avaliar entre Kafka e RabbitMQ, a IA pode listar critérios de escolha com base no contexto descrito (volume de mensagens, SLA, custo, maturidade da equipe). Isso estimula uma análise mais rica e reduz o viés do “gosto pessoal” na decisão. O resultado pode alimentar diretamente a seção “Alternativas consideradas” do ADR.

3. Analisar coerência e impacto das decisões ao longo do tempo

   Com um conjunto de ADRs versionados em um repositório, um modelo de linguagem pode revisar periodicamente os documentos e detectar inconsistências, decisões conflitantes ou oportunidades de revisão. Por exemplo, pode sinalizar que um ADR antigo definia um padrão de autenticação diferente do adotado em serviços recentes. Essa leitura transversal ajuda times a manter a arquitetura coerente e a governança viva.

Em suma, a IA amplia a capacidade de uma organização refletir sobre si mesma. Ela não substitui o raciocínio arquitetural — mas torna o processo de pensar, registrar e revisar decisões mais contínuo, acessível e inteligente. O que antes dependia apenas da memória e disciplina humana pode agora se transformar em um sistema de aprendizado organizacional, onde cada decisão alimenta a próxima com mais contexto e menos ruído.

Da visão à prática: os porquês que sustentam a estratégia

Quando líderes apresentam uma visão arrojada – expandir para novos mercados, lançar produtos disruptivos, multiplicar a base de usuários – a equipe de arquitetura fica responsável por traduzir essa visão em decisões concretas. Documentar os porquês dessas decisões fortalece a ponte entre ambição e execução. Ao revisitar os ADRs, líderes podem avaliar se a estratégia ainda se sustenta ou se precisam redirecionar investimentos.

No longo prazo, uma empresa que mantém registro de suas decisões constrói um diferencial competitivo: ela aprende com seu próprio histórico, evita armadilhas, acelera a inovação e demonstra maturidade. Essa empresa também cria uma cultura em que questionar, registrar e revisar se torna natural. E isso, por si só, melhora a qualidade das discussões e aproxima a prática da visão. O resultado são sistemas que evoluem com coerência, equipes que gastam menos tempo em debates vazios e lideranças que tomam decisões baseadas em conhecimento sólido.

Por que estruturar a avaliação?

Startups, por natureza, têm pressa. Elas testam, erram, acertam e pivotam. Esse dinamismo não combina com análises que consomem meses e geram relatórios de centenas de páginas. Por outro lado, improvisar constantemente gera dívida técnica, sistemas frágeis e uma bola de neve de refatorações. O assessment surge como um meio-termo: um instrumento ágil, mas criterioso, que transforma suposições sobre arquitetura em diagnósticos e planos de melhoria baseados em evidências.

Paulo Merson, especialista em engenharia de software, define um assessment como “uma análise sistemática para assegurar que a arquitetura atenda aos requisitos funcionais e não funcionais”. Isso inclui revisar arquitetura e documentação existentes, esclarecer requisitos de atributos de qualidade, registrar decisões e seus motivos, identificar riscos e aumentar a comunicação entre stakeholders. Em resumo, o assessment responde às perguntas: Nosso sistema suporta a visão de negócio? Onde estão os riscos? O que precisamos fazer para ajustar o caminho?

Passos fundamentais do assessment

1. Definição de escopo e metas – Antes de qualquer análise, é preciso alinhar as expectativas: o que será avaliado (um módulo específico, todo o sistema, uma nova iniciativa?), quais atributos de qualidade são prioritários (desempenho, segurança, escalabilidade, manutenibilidade?) e qual horizonte de tempo se deseja cobrir (suporte ao crescimento nos próximos 6 meses, 1 ano, 3 anos?). Sem esse alinhamento, o assessment se torna vago e termina em recomendações genéricas.

2. Coleta de dados – Uma vez definido o escopo, a equipe de assessment – formada por arquitetos, desenvolvedores experientes e representantes de produto e operações – reúne informações: diagramas, documentos de requisitos, logs de uso, incidentes reportados, métricas de latência e throughput, custos de nuvem, integrações externas e cronogramas de entregas. A ideia é ter um panorama realista, e não idealizado, do sistema.

3. Modelagem e análise – Nessa etapa, utiliza-se técnicas como a Árvore de Utilidades para organizar atributos de qualidade e cenários de avaliação. Por exemplo, a árvore pode conter “Performance” no topo, seguido por “Tempo de Resposta em Pico” e “Tempo de Processamento de Lote”. Para cada cenário, definem-se métricas esperadas. Usa-se também a Tabela de Trade-offs para mapear decisões que impactam positivamente e negativamente atributos de qualidade. Uma decisão de usar cache melhora performance, mas aumenta complexidade; usar criptografia forte aumenta segurança, mas impacta latência. A análise busca identificar onde estão os gargalos e quais escolhas foram feitas sem considerar consequências.

4. Identificação de riscos e priorização – Com base na modelagem, cria-se uma lista de riscos: falta de redundância, escalabilidade insuficiente, dependência excessiva de fornecedores, ausência de observabilidade. Em seguida, classifica-se cada risco por probabilidade e impacto, identificando aqueles que mais ameaçam a visão estratégica. Por exemplo, se a meta de crescimento é duplicar o número de transações em um ano, um gargalo em processamento de pagamentos é mais crítico do que problemas de interface de backoffice.

5. Propostas de ação – O assessment não se limita a apontar problemas; ele indica caminhos. Para cada risco prioritário, propõe-se soluções de curto, médio e longo prazo, considerando o orçamento e o tempo. Isso pode incluir migração de banco de dados, refatoração de módulos críticos, adoção de ferramentas de observabilidade, treinos de equipe ou criação de times dedicados a certos componentes. O objetivo é conectar cada ação a um objetivo de negócio, evitando recomendações que não gerem valor real.

6. Documentação e comunicação – Uma vez analisados e priorizados os riscos e propostas, é vital documentar o que foi descoberto e acordado. Isso envolve atualizar diagramas, escrever ADRs para decisões tomadas ou revisadas, gerar relatórios executivos concisos e compartilhar com todas as áreas envolvidas: diretoria, produto, engenharia, operações e suporte. A transparência evita confusões e garante que todos saibam por que certas mudanças ocorrerão.

7. Acompanhamento e revisão – Um assessment não é um evento isolado, mas parte de um ciclo de melhoria contínua. A empresa deve acompanhar a execução das ações propostas, medir os resultados e planejar revisões periódicas. Se a estratégia de negócio mudar, o assessment deve ser refeito com novo foco. Essa disciplina evita que sistemas envelheçam sem cuidado e reduz custos de refatoração futura.

Vantagens para a liderança

Um assessment estruturado oferece benefícios tangíveis para executivos:

• Visibilidade: revela a real capacidade do sistema de suportar metas de negócio, evitando surpresas desagradáveis.

• Tomada de decisão informada: apresenta opções e trade-offs, mostrando o custo e o impacto de cada escolha, permitindo que líderes decidam com base em dados.

• Priorização de investimentos: orienta onde investir tempo e recursos, evitando desperdícios em iniciativas de baixo impacto.

• Alinhamento: cria um discurso comum entre diferentes áreas da empresa, reduzindo ruído e conflitos.

• Governança e conformidade: ajuda a documentar decisões, atender auditorias e cumprir requisitos regulatórios.

Para startups financiadas, apresentar um assessment aos investidores demonstra maturidade e compromisso com sustentabilidade. Para empresas em crescimento orgânico, o assessment é um guia para não comprometer a experiência do cliente ao escalar.

Conectando avaliação e visão estratégica

O grande valor do assessment é alinhar arquitetura à estratégia. Ao definir metas de negócio e traduzir em atributos de qualidade, o processo deixa claro para a liderança qual é o preço da ambição. Por exemplo, se a visão é ser a plataforma mais rápida do mercado, o assessment mostrará o custo de investir em infraestruturas em memória e distribuição geográfica. Se a meta é expandir para mercados regulados, o assessment trará à tona a necessidade de reforçar compliance e segurança de dados.

Isso possibilita conversas maduras: O quanto estamos dispostos a investir para atingir a visão? Qual o risco de não agir? Quais partes do sistema não precisamos mudar agora?. Ao mostrar dados concretos e planos de ação, o assessment permite decisões responsáveis, reduzindo a chance de iniciativas que sacrificam o futuro por ganhos imediatos ou vice-versa.

Boas práticas para um assessment eficaz

• Envolver múltiplos stakeholders: Produto, operações, segurança e suporte têm visões complementares. O assessment precisa capturar todas.

• Adotar critérios claros de sucesso: Definir previamente como será medida a eficácia das ações recomendadas (redução de latência, eliminação de incidentes, diminuição de custos, etc.).

• Evitar perfeccionismo: Não buscar uma arquitetura ideal e estática. Foco em resolver os problemas mais críticos agora e preparar terreno para evoluções futuras.

• Registrar e revisitar decisões: Manter memória das escolhas. Futuras equipes precisam entender por que a empresa escolheu X em vez de Y.

• Promover transparência: Compartilhar resultados e planos. Nada afeta mais a confiança do que mudanças sem justificativas claras.

Aprendizados práticos

• Um assessment sem escopo claro vira auditoria improdutiva.

• Métricas concretas transformam debates subjetivos em decisões.

• Pequenas revisões frequentes valem mais que um diagnóstico tardio.

Da visão à prática: internalizando o assessment

O assessment arquitetural é uma ferramenta que conecta a visão estratégica à prática cotidiana. Ele torna explícitas as lacunas entre onde a empresa está e onde pretende chegar, traça um caminho concreto e permite monitorar o progresso. Para startups que desejam escalar sem perder agilidade, internalizar a cultura de assessment é fundamental: ele disciplina o crescimento, reduz riscos, otimiza investimentos e cria uma organização que aprende com seus sistemas.

Referências

• Paulo Merson — Architecture Assessment

• Elemar Júnior — Arquitetura de Software

• Michael Nygard — Release It!

• Neal Ford & Mark Richards — Software Architecture: The Hard Parts

• Gregor Hohpe — The Architect Elevator

O mito da arquitetura perfeita

É tentador buscar a “arquitetura ideal”: um conjunto de padrões e tecnologias que resolva todos os problemas de escalabilidade, segurança e agilidade de uma vez por todas. Livros, conferências e tutoriais oferecem receitas prontas, desde micro serviços até serverless. Contudo, na prática, poucas organizações conseguem usar uma receita “universal” sem customizações. O problema não é a ausência de boas práticas, mas a crença de que existe uma solução permanente independente do contexto.

Quando a empresa se pauta por esse mito, a equipe passa meses desenhando diagramas complexos, investindo em ferramentas caras e frameworks sofisticados, mas ignora as incertezas do negócio: quem são nossos usuários?, qual é a nossa proposta de valor?, que integrações realmente precisaremos? Pouco depois, quando se descobre que o público não responde como esperado ou que uma funcionalidade é menos usada, a arquitetura pronta se mostra inadequada. Ajustes rápidos se tornam dolorosos e, em vez de agregar valor, o sistema se torna um entrave.

Descoberta como ciclo contínuo

Tratar arquitetura como descoberta significa aceitar que o entendimento do problema evolui. A cada iteração, novas hipóteses de negócio se confirmam ou são refutadas; novas métricas mostram gargalos de desempenho; feedback de clientes revela necessidades não mapeadas. O arquiteto passa a ouvir o mercado tanto quanto o código: acompanha testes A/B, interage com times de produto e marketing, participa de reuniões de estratégia e discute prioridades com a liderança.

Esse ciclo de descoberta inclui algumas etapas:

1. Explorar a visão do negócio – Entender qual problema a empresa resolve, qual proposta de valor é inegociável e qual ambição de crescimento existe. A visão define o “norte” e permite que a arquitetura evolua para suportá-la.

2. Mapear incertezas – Listar o que ainda não se sabe: volume de transações, comportamento de usuários, regulamentações futuras, integrações externas. Isso evita que decisões críticas se apoiem em suposições.

3. Hipótese e prototipagem – Construir pequenos experimentos de arquitetura para testar ideias: simulações de carga, provas de conceito com tecnologias emergentes, APIs de teste para validação de integrações. Em vez de adotar uma abordagem big bang, prototipos revelam limitações sem comprometer toda a stack.

4. Medição e feedback – Medir latências, custos de operação, taxa de falhas. Coletar feedback de clientes e analisar logs de uso. Esses dados alimentam ajustes na arquitetura.

5. Refinar e reavaliar – Ajustar designs, abandonar escolhas que não se mostraram eficazes, escalar componentes que se provaram úteis. Documentar as descobertas e revisitá-las periodicamente.

Nesse ciclo, a arquitetura deixa de ser um fim em si e se torna um meio para validar hipóteses de negócio. Cada decisão é acompanhada de métricas. Por exemplo: se a visão exige atender clientes em diferentes fusos horários, a descoberta pode mostrar a necessidade de replicar serviços em múltiplas regiões – mas só se monitorarmos o comportamento real de usuários nos novos mercados.

Em minha experiência, times de produto e engenharia conseguem atender bem aos itens 3 ao 5. No entanto, alinhá-los ao negocio (item 1-2), fator crítico, necessitam de maiores esforços e sinergia entre os times.

Traduzindo mudanças de negócio em atributos técnicos

Uma das habilidades centrais de arquitetos descobridores é traduzir uma estratégia de negócio em atributos de qualidade. Se o negócio exige lançar um serviço de assinatura premium, isso implica requisitos de alta disponibilidade, sistemas de cobrança e proteção de dados sensíveis. Se a visão é expandir para o mercado europeu, a descoberta inclui mapear as exigências do GDPR, como anonimização e consentimento explícito, e ajustar a arquitetura para suportar obrigações legais.

Esse trabalho de tradução leva ao conceito de atributos de qualidade: desempenho, segurança, disponibilidade, manutenibilidade, escalabilidade, entre outros. Cada atributo está ligado a uma meta de negócio. Por exemplo, uma empresa que oferece um serviço de streaming precisa de latência baixa (experiência do cliente), alta disponibilidade (retenção de usuários) e compliance com direitos autorais (legal). Já uma fintech que processa pagamentos precisa de consistência (integridade financeira), rastreabilidade (auditoria) e resiliência (redução de risco). A arquitetura deve refletir essa escolha de prioridades.

Ao alinhar cada decisão a um atributo de qualidade ligado à visão, o arquiteto garante que recursos e esforços sejam direcionados ao que mais importa, evitando desperdício em características desnecessárias. Por exemplo, não adianta investir em complexidade de replicação geográfica se a legislação e a base de usuários não justificam. Da mesma forma, é desperdício desenhar uma solução que suporte 1 milhão de requisições por segundo quando a previsão de uso é 10 mil.

Exemplos de trade-offs reais

Descobrir implica reconhecer trade-offs. Para ilustrar, pense em um marketplace de alimentos artesanais. A visão é se tornar a principal vitrine para pequenos produtores, oferecendo experiência premium e logística rápida. Três desafios surgem:

• Segurança vs. Experiência: O marketplace precisa proteger dados de cartão, mas também requer um fluxo de compra sem fricção. Implementar autenticação em dois fatores em todas as compras aumenta segurança, mas reduz conversão. A descoberta consiste em medir impacto real na taxa de abandono e decidir onde aplicar autenticação, possivelmente com a ajuda de modelos de risco.

• Desempenho vs. Custo: Para oferecer busca rápida e recomendações em tempo real, talvez seja necessário adotar um banco de dados em memória. Porém, isso aumenta o custo de infraestrutura em 300%. A pergunta é: a receita gerada pela experiência premium paga essa conta? A descoberta envolve testes com subset de clientes e acompanhamento do ticket médio.

• Escalabilidade vs. Complexidade: Conforme o marketplace cresce, surge a tentação de migrar para microserviços. Isso promete escalabilidade, mas adiciona overhead em comunicação, orquestração e observabilidade. A decisão precisa considerar a capacidade do time e se a estrutura atual ainda atende as previsões de crescimento. A descoberta pode levar a soluções intermediárias, como modularizar o monólito ou adotar micro serviços somente em partes críticas.

Cada exemplo mostra que decisões técnicas devem ser tomadas à luz de dados e experimentos, não em “achismos”. E que a descoberta contínua traz à tona o custo real de cada caminho.

A importância da comunicação e documentação

Um ambiente de descoberta exige comunicação constante. O arquiteto precisa escutar o produto, traduzir conceitos técnicos para stakeholders não técnicos e documentar as hipóteses testadas e suas conclusões. Documentar (via ADRs, diagramas atualizados, relatórios de experimentos) evita que descobertas se percam quando as equipes mudam, e ajuda a alinhar todos à nova visão.

Ao documentar, é possível mostrar para a liderança quais foram os experimentos que levaram a uma arquitetura, qual o impacto estimado de uma melhoria e quais decisões podem ser revisitadas. Isso cria confiança entre quem define a estratégia e quem a implementa, reforçando que a arquitetura não é um campo de improvisos, mas de decisões justificadas que evoluem com o tempo.

Da visão à prática: descobrindo sempre

Adotar arquitetura como descoberta é admitir que não existe “sistema pronto”, apenas versões provisórias que refletem o que sabemos hoje. Isso traz flexibilidade: a empresa deixa de ficar presa a escolhas do passado e passa a ajustar sua base tecnológica conforme a visão e as condições mudam.

Lideranças que incorporam esse pensamento não buscam um único “arquiteto gênio” com respostas definitivas, mas constroem equipes que aprendem coletivamente. Elas apoiam experimentos controlados, aceitam descartar componentes que não funcionam e entendem que tempo investido em protótipos e medições economiza tempo de reescrita futura.

Na prática, alinhar visão à descoberta exige planejamento: reservar tempo para avaliações regulares, incluir arquitetos em discussões de negócio, medir resultados de decisões anteriores e manter uma cultura de transparência sobre o que se sabe e o que não se sabe. Com isso, a arquitetura deixa de ser uma barreira e se torna um catalisador para o sucesso — um guia que adapta a rota conforme novas paisagens se revelam.

Se a inovação é a visão de uma startup, a arquitetura é o conjunto de decisões que permite que essa visão se transforme em prática. Para que essa transformação ocorra, os arquitetos precisam se comportar como investigadores. Em vez de começar por "qual framework vamos usar?" ou "vamos nos dividir em microserviços?", o diálogo começa com perguntas que tensionam o contexto: Qual é o modelo de negócio que queremos sustentar? Quantas transações pretendemos processar nos próximos 12 meses? Que nível de risco regulatório podemos assumir? Esse tipo de questionamento expõe restrições, prioridades e o terreno onde as escolhas técnicas serão feitas.

Arquitetura como arte de perguntar não é apenas uma técnica de desenho, mas uma disciplina de alinhamento. Cada pergunta é um elo entre a visão estratégica e as decisões cotidianas que a transformarão em código. Perguntar "O que acontece se nosso volume de usuários triplicar do dia para a noite?" não é pessimismo; é colocar a visão de crescimento sob a luz da prática. Perguntar "Estamos preparados para abrir novos mercados que exigem conformidade com diferentes legislações?" é traduzir a ambição em requisitos de segurança e compliance. Perguntar "Quanto de latência nossos usuários toleram antes de abandonarem o carrinho?" é alinhar métricas de desempenho com resultados de negócio.

A dor de não perguntar

Quando o time de engenharia ignora ou subestima a importância dessas perguntas, a arquitetura se desenvolve como uma colcha de retalhos. Cada entrega responde a um pedido urgente de negócio, mas nenhuma decisão passa por uma análise holística. Em startups, onde velocidade é imperativo, essa abordagem parece natural – até o dia em que o faturamento é interrompido porque a base de dados não suporta o volume de pedidos, ou uma campanha de marketing provoca uma queda generalizada do sistema.

Um exemplo clássico: a decisão de adotar microserviços porque "todas as empresas modernas estão fazendo". Se ninguém pergunta "Quais são nossos requisitos de escalabilidade?" ou "Quantas equipes independentes temos para justificar esse overhead?", o resultado é uma arquitetura fragmentada demais para um time pequeno, gerando custos desproporcionais e retrabalho. Da mesma forma, a adoção de uma tecnologia proprietária sem perguntas sobre vendor lock-in pode prender a empresa a custos de licença, impossibilitando pivotar quando a estratégia mudar.

Em 2018, uma fintech brasileira quase perdeu a janela de mercado porque, ao lançar um novo serviço de crédito, não considerou a pergunta "Quantas simulações de empréstimo serão realizadas simultaneamente?" Estimativas tímidas levaram a uma arquitetura centralizada; na primeira campanha promocional, a plataforma caiu. O resultado foi uma crise de confiança e gastos extras para refatorar a arquitetura em plena corrida contra concorrentes. Tudo poderia ter sido evitado com perguntas mais agressivas no início.

Perguntas como ferramenta de visão

O livro The Mom Test, de Rob Fitzpatrick, mostra que fazer perguntas é uma arte que evita dados falsos. Ele aconselha a perguntar sobre fatos passados, não suposições futuras, e a buscar o que as pessoas fazem, não o que dizem que fariam. Em arquitetura, a aplicação é direta: perguntar "Como lidamos com picos de demanda atualmente?" é mais útil do que perguntar "Você acha que vamos crescer?"; perguntar "Quanto dinheiro o downtime custou no último incidente?" revela prioridades de negócio melhor do que "Vocês querem alta disponibilidade?"

Da mesma forma, Rian Dutra, em Enviesado, alerta para armadilhas cognitivas que contaminam nossas perguntas: medo de parecer incompetente, tendências a confirmar hipóteses prévias ou a imitar decisões de empresas de sucesso sem refletir sobre contexto. Evitar esses vieses exige coragem para perguntar com neutralidade: "O que realmente importa para o negócio nesta decisão?" e ouvir respostas que podem contrariar preferências pessoais ou modismos.

Quando CEOs e investidores demandam crescimento acelerado, é responsabilidade dos arquitetos traduzir esse imperativo em perguntas técnicas. O alinhamento "da visão à prática" acontece quando se pergunta "Se aumentarmos nossa base de usuários em 10 vezes, temos estrutura para suportar a nova carga sem degradação?", ou "Quanto nos custará em termos de infraestrutura e equipe atender a esse volume?". Perguntar assim garante que o entusiasmo do pitch deck se materialize em plataformas sustentáveis, evitando a frustração de prometer mais do que se pode entregar.

O papel do arquiteto como questionador

Arquitetos não são desenhistas de sistemas no vácuo; são mediadores entre a ambição do negócio e o pragmatismo da implementação. Um arquiteto eficiente entra em reuniões de estratégia munido de perguntas provocativas: "O que acontece se o mercado regulatório mudar?"; "Se a receita de um produto superar as previsões, como isso impacta nosso throughput?"; "Qual é a expectativa de experiência do usuário e como ela se traduz em latência e disponibilidade?" Essas perguntas abrem discussões sobre prioridades e fazem a liderança perceber que cada funcionalidade tem implicações em capacidade, segurança e custos.

Ao apresentar seus questionamentos, o arquiteto precisa dominar a arte de traduzir linguagem técnica em impacto de negócio. Se uma pergunta técnica surgir, como "Quanto tempo levaria para implementar replicação geográfica?", o arquiteto a deve traduzir em "Replicação geográfica reduzirá nosso downtime máximo de 1 hora para 15 minutos, atendendo às demandas de grandes clientes que pagam prêmios. Isso vale o investimento?". O poder da pergunta está em relacionar escolhas técnicas com métricas como churn, NPS e receita recorrente.

Perguntar exige enfrentar incomodidades. Em muitas organizações, existe a cultura do "faz rápido e corrige depois", e arquitetos que insistem em perguntar sobre custos ou riscos podem ser vistos como empecilhos. Aqui, a liderança deve reconhecer que boas perguntas são investimentos: economizam dinheiro ao evitar reescritas e incidentes, protegem a reputação ao antecipar falhas, e aceleram entregas ao reduzir o retrabalho. É preciso promover uma cultura em que perguntar não seja visto como crítica, mas como amor ao negócio.

Perguntas para tornar a visão prática

Para colocar a visão estratégica em prática, algumas perguntas precisam ser recorrentes em toda startup que busca escalar:

1. Qual é nosso modelo de monetização e como o sistema o suporta? – Perguntar isso direciona decisões de arquitetura para otimizar o que traz receita, seja ads, assinaturas ou transações.

2. Qual é a previsão de crescimento em usuários e transações? – Sem essa pergunta, é impossível definir escalabilidade necessária e custos de infraestrutura.

3. Quais são as expectativas de experiência do cliente? – Performance, disponibilidade e segurança devem ser alinhadas com o que o público valoriza; perguntar isso evita gastar em atributos que não geram retorno.

4. Quais regulamentações e políticas de compliance precisamos cumprir? – Responde a perguntas de arquitetura sobre criptografia, segregação de dados e logging.

5. Quais são os piores cenários possíveis? – Perguntar "como isso pode dar errado?" orienta planejamento de resiliência e falhas.

6. Qual é a tolerância ao risco do negócio? – Saber se a empresa prefere investir em qualidade ou aceitar riscos com menor custo operacional ajuda a priorizar.

Fazer dessas perguntas um ritual formal – em reuniões de kick-off, revisões de roadmap e retrospectivas de incidentes – cria um ambiente em que a visão se desdobra em critérios técnicos discutidos abertamente.

Da visão à prática: um trabalho contínuo

Ao final do dia, perguntas movem a arquitetura porque elas são pontes entre intenção e ação. Um CEO que visualiza sua empresa no topo de um mercado precisa de arquitetos que façam perguntas incômodas agora para evitar desastres depois. Um investidor quer retorno rápido, mas esse retorno só virá se o sistema aguentar o crescimento; cabe ao arquiteto perguntar se a infraestrutura suporta a visão. Um product manager visualiza uma funcionalidade inovadora, mas o arquiteto precisa perguntar se essa funcionalidade não compromete segurança ou custo.

A verdadeira prática de arquitetura, portanto, não é um evento pontual de design, mas um diálogo permanente entre visão e prática. Perguntar é uma postura estratégica. É a forma como se constrói confiança entre tecnologia e negócio. É a disciplina que evita que as decisões sejam tomadas com base em modismos. E, ao registrar e responder a essas perguntas de maneira estruturada, a empresa constrói uma memória organizacional que orienta cada nova iniciativa.

É assim que a arquitetura se transforma de passivo ignorado em ativo estratégico. Perguntar é o primeiro passo. Responder com dados é o segundo. Documentar e comunicar as implicações fecha o ciclo. E, ao repetir esse processo continuamente, startups aprendem a alinhar visão ambiciosa com execução sólida, traduzindo planos ousados em sistemas resilientes, eficientes e alinhados ao que realmente importa.

Tenho ajudado equipes a transformar perguntas em guias arquiteturais. Mas quero ouvir de vocês:

Vocês acham que seus times estão perguntando o suficiente — ou já partem direto para a solução?

Deixe um comentário

E é justamente nesse ponto que volto a Neal Ford e Mark Richards. No clássico Fundamentals of Software Architecture, eles defendem que arquitetura não é apenas diagrama ou estilo arquitetural, mas a combinação de quatro fatores: estrutura do sistema, características da arquitetura, decisões de arquitetura e princípios de design. Esses fatores já eram suficientes para enquadrar os dilemas de um arquiteto. A chegada da IA, no entanto, não os substitui: ela os expande, adicionando tensões inéditas.

A estrutura em mutação: das linhas pretas aos pipelines de IA

Ford e Richards definem estrutura como a organização física e conceitual do sistema — os estilos arquiteturais como camadas, microserviços ou microkernel. Na prática, sempre que desenhamos diagramas de caixas e setas, estamos lidando com estrutura. No início da carreira, eu via essa atividade como o coração da arquitetura: escolher se a aplicação seria monolítica ou distribuída, onde colocar o banco de dados, quais serviços poderiam se comunicar diretamente. A chegada da IA, porém, modificou o tabuleiro.

Modelos de IA exigem pipelines de dados para coleta, limpeza, versionamento e treinamento. Eles também demandam infraestruturas específicas (GPUs, TPUs, clusters distribuídos) e integração com serviços externos. Em outras palavras, são componentes que não se encaixam nas estruturas tradicionais. Arquiteturas modernas precisam comportar pipelines que treinam e fazem fine-tuning de modelos, sistemas de observabilidade para monitorar drift, e mecanismos de inferência servindo modelos em tempo real.

Essa imprevisibilidade tem impactos profundos. Códigos gerados por IA são probabilísticos e desafiam as suposições determinísticas de arquiteturas tradicionais, levando a testes instáveis e divergências de comportamento. Percebi isso quando um microserviço, alimentado por um LLM para normalizar dados bancários, gerou três versões diferentes do mesmo algoritmo durante o desenvolvimento. O problema não era o estilo arquitetural em si, mas a incorporação de uma nova “camada” probabilística dentro da estrutura. A solução que tem emergido é adotar uma camada intermediária de orquestração — um guardrail que direciona chamadas, controla contexto e filtra resultados. De repente, a estrutura não é apenas sobre caixas estáticas; é sobre fluxos de aprendizado, índices vetoriais e sidecars de raciocínio que protegem o restante do sistema.

Características expandidas: além dos “-ilities” clássicos

O segundo fator, as características da arquitetura, abrange atributos como disponibilidade, escalabilidade, desempenho e segurança. Esses “-ilities” funcionam como critérios de sucesso: definem o que precisa ser preservado, mesmo que a funcionalidade mude.

No contexto de IA, os atributos clássicos continuam válidos, mas novos entram em cena:

• Explicabilidade e ética: usuários e reguladores querem saber por que um modelo tomou certa decisão.

• Confiabilidade de inferência: lidar com alucinações e resultados inconsistentes exige estratégias de fallback, testes de robustez e monitoramento de acurácia.

• Privacidade e compliance: dados sensíveis usados em treinamento ou inferência precisam de cuidados adicionais.

• Custo operacional: modelos de linguagem de última geração são caros; arquiteturas precisam equilibrar latência e custo de GPUs ou chamadas a APIs.

Esses atributos influenciam a estrutura. Se a privacidade é essencial, talvez seja necessário treinar modelos localmente; se a confiabilidade é crítica, um mecanismo de validação humana (human in the loop) pode ser obrigatório. As novas características também criam trade-offs: priorizar explicabilidade pode reduzir desempenho; garantir privacidade pode limitar a qualidade do modelo. A arquitetura vira um exercício constante de negociação entre requisitos clássicos e emergentes.

Decisões de arquitetura em um mar de incertezas

Ford e Richards definem decisões de arquitetura como regras ou restrições que determinam como o sistema deve ser construído. Elas protegem a integridade da estrutura e das características, impondo limites claros.

A IA amplia e complica esse universo de decisões. Uma das primeiras perguntas tornou-se: treinar ou consumir modelos? Decidir entre um modelo próprio, que exige curadoria de dados e infraestrutura pesada, ou um serviço externo, que oferece menor controle e custos variáveis, é hoje uma decisão arquitetural. Outras questões incluem:

• On-device ou cloud? Modelos executados localmente têm menor latência e preservam privacidade, mas podem ser limitados em tamanho.

• Modelo geral ou especializado? Usar um LLM poderoso para tarefas genéricas ou um modelo pequeno e afinado para domínios específicos.

• Forma de integração: IA como módulo interno, como serviço externo ou como interface principal (chatbots, voz).

• Políticas de prompt e governança: definir padrões de engenharia de prompt, selecionar modelos apropriados e estabelecer pipelines de avaliação.

Decisões agora se tornam mais frequentes e efêmeras. Como os modelos evoluem rápido, regras que valem hoje podem se tornar obsoletas em meses. Por isso, muitas organizações adotam o conceito de fitness functions: métricas automatizadas que avaliam continuamente se as decisões ainda entregam os atributos desejados. Em vez de decidir uma única vez e documentar, o arquiteto cria guardrails e mecanismos de revisão constantes.

Princípios de design: da separação de responsabilidades ao responsible AI

O quarto fator, os princípios de design, fornece orientações para os desenvolvedores tomarem boas decisões sem que tudo seja imposto. Esses princípios funcionam como uma bússola: se uma decisão não for explícita, o desenvolvedor sabe qual caminho seguir.

Na era da IA, esses princípios precisam evoluir. Alguns exemplos:

• Responsible AI: adotar diretrizes éticas e sociais desde a concepção, evitando vieses e assegurando uso transparente de dados.

• Data-centric design: tratar dados como produto central, com pipelines e catálogos governados.

• Observabilidade de modelos: monitorar acurácia, deriva (model drift) e fairness.

• Simplicidade e modularidade: princípios clássicos como separação de responsabilidades tornam-se ainda mais valiosos para encapsular componentes imprevisíveis.

Esses princípios, assim como os tradicionais SOLID ou DRY, ajudam a manter a coerência quando novas integrações surgem. Em projetos recentes, percebi que instruir equipes a encapsular chamadas de IA em adaptadores e expor apenas contratos estáveis evitava propagação de mudanças. Outro princípio importante é não confiar cegamente em saídas de modelos; sempre que possível, adicionar validação humana ou lógica determinística.

Entre o fascínio e a prudência

Escrever este ensaio foi um exercício de reflexão sobre como os quatro fatores de Ford & Richards continuam fundamentais, mesmo quando somos seduzidos pela magia da IA. A arquitetura de software permanece ancorada na estrutura, nas características, nas decisões e nos princípios, mas cada um desses elementos ganhou novas camadas de significado. A IA não dissolveu os pilares; ela os esticou e, em alguns casos, os tensionou até quase romper.

A estrutura agora inclui fluxos de dados e pipelines de IA. As características expandiram-se com explicabilidade, ética e custo de inferência. As decisões tornaram-se mais voláteis e sujeitas a revisões constantes. Os princípios de design passaram a incorporar a noção de responsible AI e a centralidade de dados.

As bases que Ford & Richards propuseram, no entanto, oferecem uma estrutura mental sólida para navegar nessa nova era. Entender que cada decisão é um trade-off e que cada característica requer concessões torna mais fácil discutir, por exemplo, por que vale a pena sacrificar latência para ganhar mais privacidade.

Arquitetos não serão substituídos por um “ArchitectGPT”, mas por outros arquitetos que souberem usar IA com inteligência e responsabilidade. Para mim, isso significa abraçar a IA como companheira de trabalho, não como rival — e adaptar os quatro fatores da arquitetura a um mundo onde o software já não é apenas feito por humanos, mas em colaboração com máquinas inteligentes.

E você, como a IA tem influenciado as suas decisões arquiteturais? Quero ouvir suas opiniões nos comentários.

Deixe um comentário

Fizemos vários testes: cobrimos cenários esperados, aqueles que todo mundo imaginava que poderiam dar errado. Tudo parecia em ordem. Até que em produção surgiram combinações de valores que ninguém tinha previsto. Os resultados saíam incorretos, relatórios ficavam inconsistentes e a pressão foi imediata: correria para corrigir em produção, mais erros, atrasos acumulados e desgaste com os usuários.

O mais curioso é que os bugs não estavam escondidos em alguma lógica obscura. Eles apareciam justamente em edge cases que simplesmente não foram testados. Situações improváveis mas possíveis como acontece em software o improvável sempre dá um jeito de aparecer.

Foi nessa experiência que percebi: testar apenas casos exemplares nos dá uma falsa sensação de segurança. E foi assim que comecei a enxergar valor em outra abordagem – o property-based testing.

Assine agora

Property-Based Testing

Quando falamos em testar software é comum pensar em casos de uso específicos: “com este input, espero este output”. Essa abordagem funciona, mas às vezes nos dá uma sensação exagerada de segurança. Property-based testing propõe um olhar diferente: em vez de verificar exemplos isolados, vamos identificar regras gerais que o sistema sempre deve respeitar, independentemente dos dados de entrada.

Quais são as propriedades invariantes que sempre devem se manter verdadeiras, não importa o input

Por exemplo:

• “O saldo de uma conta nunca pode ser negativo.”

• “Um relatório consolidado não pode perder transações no processo.”

• “Se eu ordenar uma lista e depois inverter a ordem, devo conseguir recuperar os elementos originais.”

Essas propriedades não descrevem cenários, descrevem leis e é aqui que PBT mostra seu valor: ele gera automaticamente milhares de casos aleatórios para tentar quebrar essas leis. Se alguma falhar, descobrimos uma brecha antes que ela chegue em produção.

Essa mudança de foco ajuda a aumentar a confiança em sistemas complexos e, em experiências relatadas por empresas que adotaram PBT, como Amazon e Volvo, revelou benefícios significativos ao descobrir bugs fora do alcance dos testes tradicionais.

Descobrindo boas propriedades

Uma das dúvidas mais frequentes é: “como encontro essas propriedades?”. Não existe fórmula mágica, mas alguns padrões ajudam a guiar o processo, Comece entrevistando negócio, suporte e finanças. Busque frases que soam como lei:

• “Saldo de conta não pode ficar negativo.”

• “Não existe fatura paga duas vezes.”

• “Pedido não pode ser entregue antes de emitida a nota.”

• “Conversão de moedas deve conservar valor até a precisão acordada.”

Transforme cada frase em propriedade usando um padrão simples:

• Invariante: “Para todo X, Y… sempre vale Z.”

• Limite/monotonicidade: “Se A aumenta, B não pode diminuir.”

• Conservação: “Total antes == total depois (considerando taxas/ajustes).”

• Reversibilidade/round-trip: “encode(decode(x)) == x (dentro de tolerância).”

• Idempotência: “Aplicar a mesma operação N vezes == 1 vez.”

• Comutatividade/associatividade: “op(a,b) == op(b,a)” / “op(op(a,b),c) == op(a,op(b,c))”.

Dica: invariantes “chatas” são ouro. As falhas caras nascem quase sempre do óbvio esquecido.

Esses padrões não esgotam as possibilidades, mas fornecem um ponto de partida útil. Outra fonte rica são incidentes passados e contratos de negócio: falhas anteriores e SLAs costumam revelar invariantes implícitas (“saldo nunca negativo”, “transações não duplicadas”). Transformá-las em propriedades evita a repetição desses erros.

psc: futuramente farei um post exclusivo de como ser um caçador de problema xD

Refinando o que realmente importa

Uma vez identificada a propriedade, é hora de refiná-la. Testes baseados em propriedades pedem que você defina domínios de entrada (faixa de valores possíveis), estado inicial e observáveis (o que será medido para validar a propriedade).

No exemplo de testar a função max em uma lista, em vez de enumerar dezenas de casos, você pode dizer: “para qualquer lista, max(list) == last(sort(list))” e deixar o framework gerar dados aleatórios. Se o teste falhar, o mecanismo de shrinking reduz o contraexemplo para um caso mínimo, o que facilita ajustar a propriedade ou o código.

Sugestões práticas:

• Varie entradas realistas e maliciosas: valores comuns, extremos e inválidos.

• Considere correlações: respeite dependências internas, como data de entrega ≥ data de emissão.

• Defina tolerâncias: margens de erro aceitáveis em cálculos numéricos.

• Trate exceções como parte do teste: entradas inválidas devem gerar erros claros e sem efeitos colaterais.

Quando abrir ou fechar a caixa

O PBT pode funcionar como teste de caixa preta, em que você não olha para o código interno: apenas fornece entradas e observa as saídas. Essa abordagem tem a vantagem de exercitar o sistema de ponta a ponta, avaliando interface, servidor, banco de dados e integrações.

Mas há momentos em que abrir a “caixa” é útil, como para:

• Instrumentar contadores internos: medir valores escondidos (como número de retries ou erros) para garantir que não ultrapassem limites esperados.

• Verificar invariantes estruturais em estruturas de dados: checar se propriedades internas (como árvore balanceada ou índices únicos) continuam válidas após operações.

• Modelar sequências de estados em fluxos complexos: gerar passos aleatórios em processos (ex.: pedido > pagamento > estorno) e validar que cada transição respeita as regras.

Em muitos casos, combinar abordagens – caixa preta para APIs públicas e caixa branca para estruturas internas – oferece o melhor equilíbrio entre realismo e cobertura.

Pontos de atenção e limites

Apesar de poderoso, o PBT traz alguns desafios:

• Complexidade inicial: escrever boas propriedades e geradores demanda esforço.

• Sobrecarga de configuração: escolher ferramentas e definir propriedades leva tempo.

• Distribuição de dados: geradores mal calibrados podem deixar áreas cegas.

• Interpretação de falhas: entender contraexemplos pode exigir investigação cuidadosa.

• Flakiness: relógio, timezones e dependências externas podem gerar instabilidade.

• Integração com outras técnicas: PBT complementa, não substitui, testes unitários ou de integração.

Adesão no mundo real

Voltando ao caso do cálculo de rateio de categorias, o property-based testing poderia ter sido um grande aliado. O processo partia de um pedido de venda, com valores de frete, impostos e descontos, que depois eram distribuídos entre categorias específicas. A regra de ouro era simples:

a soma dos valores de competência e de caixa deveria ser exatamente igual à soma dos valores rateados.

Com testes tradicionais cobrimos alguns cenários previsíveis, mas com PBT poderíamos ter declarado essa propriedade como lei, deixando o framework gerar automaticamente milhares de combinações de pedidos: com ou sem frete, descontos negativos, impostos fora do padrão, rateios ausentes ou múltiplos por centro de custo (totais ou parciais).

A cada execução, a verificação seria sempre a mesma: a soma dos valores rateados deve bater com os totais do pedido. Se alguma entrada quebrasse essa regra, o teste encontraria o contraexemplo e ainda o reduziria ao caso mais simples para facilitar a investigação.

Em outras palavras, enquanto nós testávamos exemplos “óbvios”, o PBT teria explorado as possibilidades “escondidas” – justamente aquelas que acabaram estourando em produção.

Empresas que lidam com sistemas críticos têm usado PBT há anos em componentes de alta complexidade. Nessas situações, propriedades atuam também como documentação viva, ajudando novos desenvolvedores a compreender o que é essencial no sistema.

Arquitetura, domínio e estratégia

Em um nível mais profundo, propriedades não são apenas aspectos técnicos. Elas revelam o que é essencial no domínio de negócio.

Quando uma fintech afirma que “nenhuma transação pode ser contabilizada duas vezes”, está expressando uma regra inegociável de sobrevivência. Quando um ERP de logística define que “nenhuma entrega pode ser registrada com data anterior à emissão da nota fiscal”, está lidando com a base legal do negócio.

Essas invariantes não são detalhes de código: são decisões arquiteturais que sustentam a confiabilidade do produto. Ignorá-las – ou testá-las apenas com exemplos ocasionais – é abrir espaço para falhas estratégicas.

O property-based testing, nesse sentido, é mais do que uma técnica de QA. É uma forma de alinhar arquitetura de software e lógica essencial do negócio.

O ângulo da confiabilidade

Grandes falhas em sistemas críticos raramente nascem de cenários complexos. Quase sempre, são quebras de propriedades simples:

• um saldo que ficou negativo,

• uma duplicata que passou batido,

• um campo que aceitou valores inconsistentes.

Essas falhas custam caro não apenas em retrabalho, mas em perda de confiança. E confiança, em software corporativo, é capital estratégico.

Ao aplicar PBT, ampliamos o alcance da validação. Em vez de dezenas de casos escolhidos a dedo, temos milhares de combinações testadas de forma automática. Não se trata de eliminar todo risco, mas de aumentar a confiança estatística de que nossas invariantes estão protegidas.

Conclusão

Property-based testing nos convida a refletir: quais verdades devem permanecer imutáveis no nosso sistema?. Não se trata de abandonar os testes que já fazemos, mas de acrescentar uma lente diferente. Essa lente ajuda a expor e proteger as leis invisíveis que regem o negócio, aumentando a confiança no software.

Vale a pena começar pequeno: escolha uma propriedade simples, implemente, e veja o que os testes revelam. A experiência tende a ser reveladora e, com o tempo, gratificante.

Para continuar a conversa…

E você, já passou por situações em que um detalhe não testado acabou virando um problema em produção? Como imagina que o property-based testing poderia ajudar no seu contexto?

Deixe seu comentário abaixo – vou gostar de ouvir suas experiências e trocar ideias.

Poucas horas no mercado podem arruinar anos de trabalho. Em 1º de agosto de 2012, a Knight Capital — uma das maiores corretoras de alta frequência — colocou em produção um novo módulo de roteamento de ordens (SMARS).

O código substituía um algoritmo de teste antigo chamado Power Peg que havia sido desativado desde 2003. Entretanto, parte desse algoritmo de testes permaneceu no sistema e um engenheiro reutilizou a mesma flag que ativava o Power Peg para acionar o novo módulo. O programador implantou manualmente o código em oito servidores; por engano, um deles ficou com a versão antiga, sem testes e com o Power Peg oculto. Como não havia processo de validação ou automação para a implantação, ninguém percebeu o erro. Às 9h30, o servidor defeituoso começou a enviar milhares de ordens de compra e venda a cada segundo, sem considerar o número de ações já executadas.

Em 45 minutos a Knight executou mais de 4 milhões de operações e perdeu cerca de US$ 440 milhões. Investigadores notaram que o código morto não foi removido, a reutilização de flags confundiu a equipe e faltou automação de testes e implantação. A empresa também trabalhou com um prazo de apenas 30 dias para desenvolver, testar e implantar mudanças complexas em um sistema que movimentava bilhões de dólares por dia — um cronograma “impulsivo, ingênuo e imprudente”.

O problema: falta de alinhamento com objetivos estratégicos

Os fatos acima ilustram um problema recorrente: a qualidade do software não foi tratada como parte da estratégia do negócio. A Knight priorizou velocidade de entrega e custo, mas ignorou atributos de qualidade vitais para uma corretora — confiabilidade, segurança operacional e gerenciamento de risco. Não havia processos formais de validação, automação de implantação nem gestão de riscos. O resultado foi uma falha catastrófica que levou à perda de reputação e à venda da empresa dois anos depois.

A mesma falta de alinhamento aparece em outras tragédias da engenharia. A Boeing projetou o 737 Max para competir com o Airbus A320neo sem exigir treinamento adicional dos pilotos. Para economizar custos e acelerar a certificação, os engenheiros escolheram um único sensor de ângulo de ataque para alimentar o sistema de correção MCAS — omitindo redundância e criando um ponto único de falha. Pressões de cronograma e cultura corporativa focada em margens fizeram a empresa ocultar o sistema dos manuais de pilotagem e minimizarem riscos. Dois acidentes (Lion Air JT610 e Ethiopian Airlines ET302) e 346 mortes forçaram a paralisação global da frota. Na missão da Mars Climate Orbiter, a NASA perdeu uma sonda de US$ 125 milhões porque o software de navegação em solo usava unidades inglesas, enquanto os demais sistemas trabalhavam em unidades métricas; a discrepância passou despercebida porque as verificações e validações não confirmaram que o software atendia aos requisitos e porque as equipes não comunicaram suas preocupações.

Outro caso clássico presente como case nas universidades. A sequência de erros do Therac‑25 — acelerador de radioterapia que matou pelo menos cinco pessoas — mostra como a eliminação de intertravamentos de hardware e a falta de revisão de código e testes permitiram que software não testado controlasse doses letais.

Esses casos mostram que qualidade de software não é um atributo isolado; ela deve estar alinhada com os riscos, valores e estratégias do negócio.

Quando empresas se concentram apenas em prazos ou custos e desconsideram atributos como segurança, confiabilidade ou usabilidade, criam riscos sistêmicos que podem se materializar em acidentes, perdas financeiras ou até mortes.

Um relato pessoal: relatórios financeiros e o cabo de guerra entre usabilidade e segurança

Apesar de as tragédias acima terem impacto midiático, muitos conflitos relacionados à qualidade permanecem invisíveis dentro das organizações. Recentemente, vivenciei um caso que ilustra como a ausência de critérios explícitos para ordenar atributos de qualidade pode gerar tensões internas. Trabalhávamos em um módulo para disponibilizar relatórios financeiros a clientes via e‑mail. A solução inicial envolvia enviar um link público para acessar o relatório. Do lado de produto, a prioridade era usabilidade: o processo deveria ser simples, com poucos cliques e sem cadastros. Do lado de engenharia, havia preocupação com confidencialidade e proteção dos dados. Como não havia uma diretriz prévia sobre quais atributos de qualidade deveriam prevalecer, a discussão se transformou em um cabo de guerra com reuniões intermináveis e atrasos.

Essa disputa expôs riscos invisíveis que muitas vezes passam despercebidos. Relatórios financeiros contêm dados sensíveis que, se compartilhados por um link público e sem controle de acesso, podem ser interceptados por terceiros ou cair nas mãos erradas. Um simples erro de envio de e‑mail pode constituir um vazamento de dados.

No nosso caso, o bom senso acabou prevalecendo: optou‑se por exigir autenticação e links expirados, implementando controles de acesso para priorizar a segurança — uma decisão que deveria ter sido óbvia se houvesse um alinhamento prévio com os objetivos estratégicos da empresa (proteger dados sensíveis e preservar a confiança dos clientes). O conflito poderia ter sido evitado se a organização tivesse definido explicitamente que, em produtos financeiros, segurança e confidencialidade têm prioridade sobre conveniência, servindo como critério de desempate em decisões de design.

Esse episódio também revelou outras fragilidades comuns: funções críticas sem um simples perfil de acesso, ausência de mascaramento de valores e campos vulneráveis a XSS. Esses riscos não geraram manchetes, mas representam um risco invisível que pode levar a perdas financeiras, multas regulatórias e danos à reputação se não forem tratados.

Alinhar atributos de qualidade aos objetivos do negócio — e comunicar essa ordem a todo o time — evita disputas desgastantes e reduz a exposição a esses riscos.

Por que alinhar atributos de qualidade com a estratégia?

Um software existe para atender a necessidades de diversos stakeholders. O modelo ISO/IEC 25010 define:

Qualidade de software é o grau em que o sistema satisfaz as necessidades explícitas e implícitas dos stakeholders.

E propõe um modelo de nove atributos de qualidade (funcionalidade, desempenho, compatibilidade, usabilidade, confiabilidade, segurança, portabilidade, manutenibilidade e escalabilidade) subdivididas em subatributos. Esses atributos representam valores que podem apoiar objetivos estratégicos como satisfação do cliente, conformidade regulatória ou eficiência operacional.

Alinhar atributos de qualidade com a estratégia significa responder a questões como: quais atributos são críticos para gerar valor? Se a empresa opera serviços financeiros, confiabilidade e integridade de dados são fundamentais; se o negócio prioriza crescimento rápido de usuários, usabilidade e escalabilidade importam mais. Técnicas modernas de trade‑off, como as propostas por Neal Ford no livro Software Architecture: The Hard Parts, seguem essa premissa. Em vez de um processo extenso como o ATAM, os autores recomendam um processo simples de três etapas:

1. Identificar o que está entrelaçado, ou seja, quais requisitos e componentes entram em conflito;

2. Analisar como esses elementos estão acoplados e como cada decisão de arquitetura impacta múltiplos atributos;

3. Avaliar o impacto de mudanças discutindo explicitamente os trade‑offs com base nos objetivos de negócio.

Para orientar essa conversa, a Architecture Characteristics Worksheet sugere listar no máximo sete atributos arquiteturais. Atributos implícitos como segurança ou viabilidade podem tornar‑se prioritárias quando são críticas para o negócio.

Escolhendo os atributos certos (e por que limitar-se a três)

É tentador querer otimizar todos os atributos — ter software rápido, seguro, confiável, fácil de usar, portátil e barato. No entanto, isso é impossível na prática. Como observa um artigo do Stack Overflow, não existe “o melhor de todos os mundos”: há inevitáveis trade‑offs entre atributos de qualidade; aumentar a segurança pode reduzir a usabilidade, melhorar a performance pode dificultar manutenção. Por isso, uma parte essencial da análise de requisitos é entender quais atributos de qualidade são mais importantes para o negócio. Muitas listas incluem dezenas de atributos, mas poucos projetos precisam se preocupar com todos.

Se a sua empresa é uma start/scale-up, concentre‑se nos dois ou três atributos que melhor suportam a visão e as metas estratégicas da empresa — isso facilita a tomada de decisões e evita conflitos de design. Neal Ford e Mark Richards defendem de 5 a 7 atributos, acho que isso se aplica a grandes corporações ou grandes projetos, se esse for o seu caso, considere-os.

Na prática, o time identifica quais atributos arquiteturais são importantes para o sistema, p.ex.: desempenho, segurança, disponibilidade. Cada atributo recebe uma classificação de importância de acordo com o contexto do negócio. Para cada atributo, descreve-se o porquê ele é importante, em que cenários será testado/avaliado e qual o critério de sucesso. Por fim, registrar trade-offs, e utilizar a planilha como uma “bússola”: quando há dúvida sobre design, a escolha é guiada pelos atributos prioritários documentados.

Em novo post, falarei mais sobre Architecture Characteristics Worksheet.

Faz sentido escolher atributos diferentes por épico ou produto?

Em produtos amplos ou em portfólios de soluções, diferentes epics podem ter metas específicas: um módulo de pagamentos precisa priorizar segurança e conformidade, enquanto outro módulo voltado para marketing pode valorizar usabilidade e desempenho. Portanto, definir atributos de qualidade por épico ou produto pode fazer sentido, contanto que haja coerência com a estratégia global. A arquitetura deve assegurar que atributos críticos (por exemplo, segurança e confiabilidade) não sejam negligenciados em nenhum componente que possa impactar a empresa como um todo. Além disso, decisões sobre atributos locais devem ser comunicadas a toda a equipe para evitar incompatibilidades (como aconteceu no Mars Climate Orbiter, onde equipes isoladas não comunicaram suas preocupações e o erro de unidades passou despercebido).

Quando mudar os atributos prioritários?

Os atributos de qualidade são vivos e devem evoluir com a estratégia. Mudanças no mercado (como regulamentações de proteção de dados), novas metas de negócio (por exemplo, priorizar expansão internacional ou reduzir custos), estágio do produto (MVP vs. produto consolidado) ou indicadores de desempenho (alta taxa de churn por dificuldade de uso) podem exigir revisar as prioridades. Técnicas modernas de trade‑off recomendam ciclos de reavaliação: após identificar e priorizar os atributos de qualidade, a equipe deve revisá‑las periodicamente para revalidar os trade‑offs e ajustar as escolhas. Uma revisão semestral ou a cada grande release pode detectar a necessidade de incluir um novo atributo (como escalabilidade) ou rebaixar outro. A mudança deve ser tratada como decisão estratégica: avalie como ela impacta a arquitetura e se há recursos para atender às novas metas.

Contraste: o perigo de escolhas isoladas

Tomar decisões de qualidade isoladamente — seja por equipe, funcionalidade ou gestor — é perigoso. No 737 Max, a escolha de usar um único sensor e esconder o MCAS foi tomada sob pressão comercial sem considerar a segurança global; a falta de comunicação com reguladores e pilotos agravou o risco. Na NASA, a equipe de navegação não utilizou a documentação de interface para validar unidades e não comunicou suas preocupações a outras equipes; erros “escorregaram pelas rachaduras” e levaram à perda da sonda. O Therac‑25 concentrou responsabilidades de segurança no software sem intertravamentos de hardware e sem revisão independente; a crença de que o sistema não podia causar sobredosagem e a falta de canais de reporte impediam que os incidentes fossem investigados. Esses exemplos reforçam que qualidade precisa ser discutida transversalmente, com participação de todas as áreas, revisões independentes e validação de requisitos.

Conclusão

A qualidade de software não é um atributo técnico isolado, mas sim uma extensão da estratégia da empresa. A história da Knight Capital mostra que ignorar atributos essenciais à confiabilidade e à segurança operacional pode levar a perdas bilionárias e à ruína; os casos do 737 Max, da Mars Climate Orbiter e do Therac‑25 mostram que decisões de engenharia desconectadas dos objetivos de segurança e comunicação acabam em tragédia.

Para evitar esses erros, as organizações devem:

1. Identificar drivers de negócio e derivar atributos de qualidade que realmente suportem esses objetivos;

2. Priorizar um pequeno conjunto de atributos (tipicamente 2 ou 3) para orientar decisões e evitar trade‑offs conflitantes;

3. Definir cenários mensuráveis e revisá-los iterativamente com base em técnicas modernas de trade‑off (como as de Neal Ford), envolvendo todas as partes interessadas;

4. Comunicar e coordenar decisões de qualidade através de todas as equipes para evitar discrepâncias e erros como os que levaram à perda da Mars Climate Orbiter.

5. Revisar e ajustar prioridades quando a estratégia, o mercado ou os resultados exigirem;

Ao alinhar a qualidade do software aos objetivos estratégicos e tratar essa escolha como uma decisão de negócios, as empresas reduzem riscos, melhoram a satisfação do cliente e aumentam suas chances de sucesso sustentável.

Você já parou para pensar qual atributo de qualidade o seu time defende quando tudo entra em conflito? Velocidade, usabilidade, segurança… e quando ninguém define a ordem, o que acontece?

Deixe um comentário

Abaixo deixo um cheat sheet, um atalho para escolher e comunicar o Top 3 de atributos de qualidade alinhados à estratégia. Siga o fluxo Identificar → Definir → Comunicar → Revisar para tomar decisões com menos atrito e mais direção.

Referências

• Plan for tradeoffs: You can’t optimize all software quality attributes

• Case Study 4: The $440 Million Software Error at Knight Capital

• System Failure Case Studies (august 2009 vol. 3 issue 05)

• Architecture Tradeoff Analysis Method (ATAM)

• Software Architecture: The Hard Parts

• The Therac-25 accidents Case Study

• ISO/IEC 25010