Arquitetura Quantitativa

O objetivo é maximizar o desempenho e a escalabilidade do sistema, reduzindo gargalos técnicos e financeiros, usando dados reais de métricas operacionais e de negócio.

Decisões técnicas de alto impacto devem ser baseadas em evidências. Isso significa que os sistemas precisam estar instrumentados com telemetria adequada, oferecendo dados confiáveis para análise contínua.

Obtendo insights do seu repositório de código

Um repositório de código é como uma linha do tempo viva da sua arquitetura. Ele revela não apenas mudanças e autores, mas também sinais de instabilidade, dívida técnica e pontos críticos arquiteturais.

Mesmo uma análise básica do Git pode revelar:

• Artefatos com o maior número de mudanças nos últimos 3 meses
• Desenvolvedores com mais commits
• Desenvolvedores com maior número de linhas alteradas
• Arquivos com baixa propriedade de código (muitos autores diferentes)

Mudanças vs Commits

• Commit – cada checkpoint explícito salvo no repositório (git commit -m)
• Mudanças – o número de linhas adicionadas ou removidas em cada arquivo (diff)

Esses dados ajudam a identificar pontos críticos de manutenção e detectar áreas com instabilidade ou baixa propriedade compartilhada. Artefatos com altas taxas de mudança requerem mais atenção. Estatisticamente, eles têm maior probabilidade de sofrer com instabilidade ou separação inadequada de responsabilidades, o que pode prejudicar a confiabilidade do sistema em produção.

Como lidar com essas áreas críticas

• Priorize esses fluxos para melhor cobertura de testes automatizados (idealmente acima de 80%)
• Considere refatorações incrementais guiadas por métricas (refatorações controladas)
• Os principais committers geralmente são aqueles com mais conhecimento do domínio

Pontos críticos podem representar alto valor de negócio (se estiverem em evolução ativa) ou problemas arquiteturais como acoplamento excessivo ou baixa coesão.

Para validar suas suposições, você pode:

• Vincular PRs a ferramentas de rastreamento (Jira, Azure DevOps, etc.)
• Verificar tipos de entrega (bug, feature, refatoração)
• Analisar cobertura de testes versus frequência de mudanças

Detectando Acoplamento (Change Coupling)

Arquivos frequentemente alterados juntos no mesmo commit ou PR:

• Mostram sinais de Change Coupling
• Podem esconder dependências implícitas
• Indicam oportunidades de modularização e melhor coesão

Cuidado com múltiplas equipes no mesmo repositório

Se múltiplas equipes estão editando os mesmos arquivos:

• Investigue o motivo
• Pode indicar bounded contexts ausentes, levando a responsabilidades sobrepostas
• Isso aumenta o risco de conflitos e bugs em produção

Se os arquivos estão fortemente acoplados e difíceis de testar:

• Revise a arquitetura
• Planeje uma refatoração controlada

Métricas precisam de contexto: Quantitativo + Qualitativo

Métricas quantitativas são úteis, mas devem ser lidas junto com sinais qualitativos como:

• Code reviews
• Feedback de desenvolvedores
• Conhecimento do domínio

Números sozinhos não contam a história completa.

Exemplo: um artefato com muitas mudanças pode estar evoluindo (bom) ou sendo constantemente corrigido (ruim).

MTTR vs MTBF

• MTTR (Mean Time to Repair)

Tempo médio para recuperação após uma falha.

MTTR = Tempo total de inatividade / Número de falhas

• MTBF (Mean Time Between Failures)

Tempo médio que o sistema roda antes de falhar.

Exemplo: 1.000 horas de uptime e 3 falhas → MTBF = 1000 / 3 = 333,3 horas

Em sistemas modernos com releases frequentes, o MTBF se torna menos útil devido à mudança contínua.

MTBF vs Continuous Deployment

Se as equipes focarem demais no MTBF, elas podem fazer deploy com menos frequência para evitar falhas. Isso leva a:

• Releases maiores com mais risco
• Análise de causa raiz mais difícil
• Rollbacks mais arriscados e complexos

Como adotar continuous deployment

• Automação forte de testes para caminhos críticos (não necessariamente 100%)
• Pipelines CI/CD estáveis e estratégias de rollback confiáveis

O objetivo são releases frequentes e de baixo risco.

Continuous deployment ajuda as equipes a entregar valor mais rápido. É um desafio, mas possível com maturidade em testes e automação.

Disclaimer

Esses indicadores nunca devem ser usados para medir o desempenho de desenvolvedores.

Eles são ferramentas para identificar riscos arquiteturais e oportunidades de melhoria.

Como trazer essa visibilidade para stakeholders de negócio

Um dos maiores desafios arquiteturais é traduzir melhorias técnicas em impacto de negócio.

Táticas:

• Traduza métricas técnicas em valor:
  • "CFR menor" → "Menos bugs em produção"
  • "Lead Time menor" → "Entrega mais rápida de ideias de negócio"
• Use dashboards visuais:
  • Google Sheets, Grafana — atualizados semanalmente ou mensalmente
• Construa uma rotina de comunicação:
  • Adicione uma seção de "impacto técnico" em sprint reviews ou reuniões de produto

Arquitetura Quantitativa em ação – 5 passos práticos

1. Instrumente serviços com métricas de negócio e operacionais
2. Use scripts Git para identificar pontos críticos de mudança
3. Correlacione mudanças com tipos de entrega (bug, feature)
4. Detecte acoplamento temporal
5. Priorize testes/refatorações com base em risco e impacto

Este post reflete lições e ideias da minha jornada de mentoria com Elemar Junior. Estou compartilhando notas, aprendizados e insights práticos sobre Arquitetura Quantitativa, focando no uso de dados reais para apoiar decisões arquiteturais.

Se este conteúdo foi útil, compartilhe com sua equipe. Se quiser discutir mais, sinta-se à vontade para conectar no LinkedIn