Um cliente não chega com uma arquitetura. Ele chega com um problema: uma operação que não escala, informações espalhadas, processos manuais, riscos difíceis de controlar ou uma oportunidade que precisa ser validada.

Antes de escolher tecnologias, precisamos compreender o que o sistema deverá sustentar. Quantas pessoas irão utilizá-lo? Que tipo de dado será tratado? O que acontece quando uma integração falha? Quanto tempo a equipe terá para operar e evoluir a solução? Quais decisões podem ser revistas depois e quais criariam um compromisso difícil de desfazer?

Essas perguntas importam porque arquitetura não é uma coleção de ferramentas. Ela é o conjunto de decisões que determina como o software será construído, operado e modificado ao longo do tempo.

Na Triarch Tech, não tratamos essas decisões como preferências técnicas. Trabalhamos com contexto, hipóteses, alternativas, evidências e critérios de revisão. É assim que aplicamos princípios da Engenharia de Software Baseada em Evidências ao projeto de arquitetura.

O problema vem antes da solução

Pedidos como "precisamos de microsserviços", "queremos usar inteligência artificial" ou "o sistema precisa estar na nuvem" podem expressar uma necessidade real. Ainda assim, eles não explicam sozinhos qual arquitetura será adequada.

Uma solução precisa responder ao contexto em que será usada. Isso inclui objetivos de negócio, pessoas envolvidas, dados tratados, integrações, orçamento, prazo, capacidade operacional e consequências de uma falha. Também precisamos tornar atributos de qualidade discutíveis e verificáveis. "O sistema deve ser rápido" é uma intenção. Um tempo de resposta esperado, em um cenário e volume definidos, oferece um critério que pode orientar projeto e teste.

Arquitetura começa quando ligamos essas condições às consequências técnicas. Uma escolha pode melhorar isolamento e escalabilidade, mas aumentar custo operacional e dificuldade de diagnóstico. Outra pode acelerar a primeira entrega, mas limitar mudanças futuras. Não existe benefício arquitetural sem contexto e quase sempre existe um compromisso associado.

Separamos fatos, hipóteses e preferências

No início de um projeto, parte do que sabemos são fatos e parte são suposições. O primeiro exercício de rigor é não confundir os dois.

Podemos saber que o produto precisará integrar três fontes de dados. Ainda não sabemos se essas fontes responderão com a disponibilidade, consistência e velocidade necessárias. A compatibilidade pode ser uma hipótese. A capacidade de processar determinado volume pode ser outra. Cada hipótese pede uma forma de investigação proporcional ao seu impacto.

Silva e colaboradores (2025) avaliaram o ArchHypo, uma técnica que torna incertezas arquiteturais explícitas e associa a elas planos técnicos para reduzir desconhecimento ou impacto. No projeto de missão crítica estudado, a técnica ajudou a organizar o trabalho arquitetural em iterações e a adiar compromissos de maneira consciente. A equipe também identificou curva de aprendizado e ajustes de processo como barreiras.

O estudo acompanha um projeto e não permite afirmar que a técnica produzirá o mesmo efeito em qualquer organização. A prática que adotamos é mais contida: quando uma decisão relevante depende de algo ainda não demonstrado, registramos a hipótese e definimos o que poderia confirmá-la, refutá-la ou reduzir seu risco.

Evidência precisa chegar a tempo da decisão

Engenharia de Software Baseada em Evidências não significa procurar um artigo que escolha uma tecnologia por nós. Significa integrar a melhor evidência disponível com experiência profissional, valores das pessoas envolvidas e circunstâncias do projeto.

Pfleeger e Kitchenham (2025) revisitam diretrizes da engenharia de software empírica e observam que mudanças na forma de produzir software, incluindo sistemas baseados em IA, exigem novas perguntas e critérios. A contribuição é uma reflexão metodológica, não uma comparação experimental entre arquiteturas. Ela reforça um princípio importante: evidência precisa acompanhar a natureza do sistema e do risco analisado.

Também não é realista realizar uma revisão sistemática completa para cada decisão de projeto. Pizard e colaboradores (2025), em um estudo que combinou revisão e replicação com uma equipe ágil, observaram que revisões rápidas foram percebidas como fontes confiáveis e que algumas recomendações foram utilizadas meses depois. Ao mesmo tempo, recomendações acadêmicas amplas precisaram ser traduzidas em opções concretas de mudança.

Esse resultado vem de um contexto limitado, mas oferece uma orientação prática: a profundidade da pesquisa deve acompanhar o impacto, a incerteza e a dificuldade de reverter a decisão. Documentação primária e um teste pequeno podem bastar para uma escolha local. Uma decisão estrutural, cara e duradoura pede investigação mais cuidadosa.

Comparamos alternativas antes de defender uma preferência

Experiência é necessária, mas não nos torna imunes a vieses. Familiaridade pode parecer adequação. A primeira alternativa lembrada pode se tornar uma âncora. Confiança no plano pode esconder custos de operação ou cenários de falha.

Borowa, Almeida e Wiese (2025) realizaram um experimento com 16 estudantes e 20 profissionais. Uma intervenção que ensinava a listar múltiplas soluções, discutir desvantagens e explicitar riscos melhorou a argumentação e reduziu ocorrências de ancoragem e viés de otimismo. O estudo avaliou uma amostra pequena e efeitos imediatos; não demonstra que a intervenção garante melhores sistemas no longo prazo.

Não tratamos o resultado como receita. Transformamos a recomendação em disciplina de decisão:

  • consideramos mais de uma alternativa plausível;
  • registramos benefícios, desvantagens e riscos;
  • procuramos evidências que contrariem a opção preferida;
  • distinguimos uma limitação certa de um risco que pode ou não ocorrer;
  • explicamos por que uma alternativa adequada em outro contexto pode não servir aqui.

O objetivo não é produzir uma matriz extensa para qualquer detalhe. É evitar que uma decisão de alto impacto seja apenas uma preferência apresentada com linguagem técnica.

Uma prova de conceito deve terminar em evidência

Quando a evidência externa não responde ao contexto específico, podemos produzir evidência local. Benchmarks, protótipos técnicos, testes de integração e provas de conceito ajudam a investigar comportamento antes de assumir um compromisso maior.

Uma proposta apresentada na ICSE 2026 por Petrillo e Antognolli trata PoCs como experimentos curtos, orientados a risco e explicitamente ligados a uma decisão arquitetural. O trabalho é recente e propositivo. Ele não oferece evidência ampla de que o framework melhora resultados em diferentes organizações.

Ainda assim, a distinção é útil. Uma PoC não deve existir apenas para mostrar que uma tecnologia funciona. Ela precisa registrar:

  1. a hipótese investigada;
  2. o cenário e o ambiente do teste;
  3. as métricas e o critério de sucesso;
  4. o resultado e suas limitações;
  5. a consequência para a decisão.

O código experimental pode ser descartado. O aprendizado não deve desaparecer com ele.

Rastreabilidade é mais do que um registro aprovado

Depois de comparar alternativas e avaliar evidências, registramos a decisão perto do trabalho. Um Architecture Decision Record, ou ADR, pode preservar contexto, motivadores, alternativas, evidências, consequências e condições de revisão.

Preencher um ADR, porém, não comprova que houve deliberação. Santana e colaboradores (2026) analisaram 921 repositórios de código aberto e 5.800 ADRs. Aproximadamente 63% dos registros já foram criados como aceitos, sem preservar o caminho de discussão que o artefato deveria apoiar. As correlações observadas entre características dos ADRs e métricas de qualidade ou produtividade foram, em sua maioria, pequenas.

O recorte em projetos de código aberto impede transportar os resultados diretamente para qualquer empresa. Ele também alerta contra uma afirmação tentadora: não há base nesse estudo para dizer que usar ADRs, por si só, melhora a qualidade do software.

Para nós, o valor está na rastreabilidade. Um bom registro permite responder:

  • qual problema exigiu a decisão;
  • quais evidências estavam disponíveis;
  • quais alternativas foram consideradas;
  • que riscos foram aceitos;
  • qual nível de confiança tínhamos;
  • que sinal deverá provocar uma revisão.

Como aplicamos essa disciplina

Nosso processo não transforma cada projeto em uma pesquisa acadêmica. Ele incorpora práticas empíricas ao trabalho de arquitetura na intensidade exigida pela decisão.

1. Definimos o que está em jogo

Traduzimos objetivos, restrições e atributos de qualidade em critérios observáveis. Também identificamos quem será afetado e quais consequências não podem ser ignoradas.

2. Tornamos a incerteza visível

Separamos fatos, premissas e hipóteses. Priorizamos o que combina maior impacto com menor conhecimento disponível.

3. Buscamos evidência proporcional ao risco

Consultamos estudos, revisões, documentação primária e experiências relevantes. Avaliamos se o contexto das fontes se aproxima do problema em análise e registramos seus limites.

4. Comparamos caminhos possíveis

Analisamos alternativas, desvantagens, riscos, custo de operação e reversibilidade. Uma tecnologia conhecida não recebe preferência automática.

5. Testamos o desconhecido mais crítico

Quando necessário, executamos um experimento pequeno com hipótese, métrica e critério de decisão definidos antes do resultado.

6. Decidimos, registramos e revisamos

Preservamos o raciocínio e definimos sinais de revisão. Mudanças de volume, custo, equipe, regulação ou comportamento do sistema podem invalidar premissas que antes eram razoáveis.

Rigor não é ausência de incerteza

Arquitetura baseada em evidências não significa encontrar uma resposta definitiva antes de começar. Também não significa aplicar um paper como manual ou esconder julgamento profissional atrás de métricas.

Rigor científico, em nosso processo, significa tornar hipóteses, evidências, limites e critérios de revisão explícitos.

Isso não elimina a incerteza. Torna possível aprender com ela, justificar escolhas e mudar de direção sem apagar a história que levou até ali.

Para o cliente, o resultado é mais importante do que uma lista de tecnologias: uma solução coerente com o problema atual, consciente de seus compromissos e preparada para ser revista quando a realidade mudar.

Referências

  1. Pfleeger, S. L.; Kitchenham, B. Evidence-Based Software Engineering Guidelines Revisited. IEEE Transactions on Software Engineering, v. 51, n. 3, 2025, p. 814-819. DOI: 10.1109/TSE.2025.3526730.
  2. Pizard, S.; Lezama, J.; García, R.; Vallespir, D.; Kitchenham, B. Using Rapid Reviews to Support Software Engineering Practice: A Systematic Review and a Replication Study. Empirical Software Engineering, v. 30, n. 1, artigo 10, 2025. DOI: 10.1007/s10664-024-10545-6.
  3. Silva, K.; Melegati, J.; Silveira, F. F.; Wang, X.; Ferreira, M.; Guerra, E. ArchHypo: Managing Software Architecture Uncertainty Using Hypotheses Engineering. IEEE Transactions on Software Engineering, v. 51, n. 2, 2025, p. 430-448. DOI: 10.1109/TSE.2024.3520477.
  4. Borowa, K.; Almeida, R. R.; Wiese, M. Debiasing Architectural Decision-Making: An Experiment With Students and Practitioners. 22nd IEEE International Conference on Software Architecture, 2025, p. 210-220. DOI: 10.1109/ICSA65012.2025.00029.
  5. Petrillo, F.; Antognolli, B. Proofs of Concept as First-Class Architectural Decision Instruments. 48th IEEE/ACM International Conference on Software Engineering, Software Architecture Birds-of-a-Feather Session, 2026. Programa da ICSE 2026.
  6. Santana, E. G. et al. Architecture Decision Records: Adoption, Impact, and Developer Engagement in Open-Source Software. 23rd IEEE International Conference on Software Architecture, 2026, p. 335-345. DOI: 10.1109/ICSA66085.2026.00040.