Durante muito tempo, foi confortável tratar arquitetura como uma disciplina principalmente técnica. A conversa girava em torno de componentes, bancos de dados, filas, protocolos, escalabilidade e deployment. Tudo isso continua importante. O problema é que esse repertório, sozinho, já não explica bem por que alguns sistemas continuam evoluindo com fluidez enquanto outros, mesmo “funcionando”, se tornam cada vez mais caros de mudar. Nos últimos anos, discussões de platform engineering, Team Topologies e arquitetura moderna têm apontado na mesma direção: boa arquitetura não é apenas a que organiza software; é também a que organiza o trabalho necessário para evoluir esse software. Recentemente li um artigo que me fez refletir muito sobre o que gostaria de parafrasear e adicionar minha opinião.
O ponto que eu quero defender neste artigo é simples: hoje já não faz sentido avaliar arquitetura apenas por critérios como performance, disponibilidade ou elegância técnica. Uma arquitetura também precisa ser julgada pelo efeito que produz no fluxo do time. Se ela aumenta handoffs, concentração de conhecimento, necessidade de coordenação e quantidade de contexto que as pessoas precisam carregar para fazer mudanças comuns, então ela está falhando arquiteturalmente — mesmo que o sistema esteja estável em produção. A ideia aqui é mostrar como enxergar esse tipo de falha, por que ela aparece e que decisões ajudam a reduzi-la.
O problema não é só complexidade. É onde ela vai morar
Toda arquitetura distribui complexidade. A pergunta nunca foi se um sistema será complexo ou não. A pergunta real é onde essa complexidade vai morar.
Em sistemas e plataformas bem desenhados, uma parte relevante dela é absorvida por contratos claros, boas abstrações, automação, caminhos pavimentados e defaults seguros. Em sistemas mal desenhados, ela é empurrada para a cabeça das pessoas. O software continua funcionando, mas cada mudança relevante passa a depender de memória tribal, entendimento implícito e especialistas recorrentes. O Team Topologies trata isso de forma bem direta ao afirmar que carga cognitiva é central para permitir fluxo rápido de mudança: quando a capacidade cognitiva do time é excedida, aparecem mais context switching, menos domínio real do problema e perda de ownership sobre o espaço que aquele time deveria controlar.
Foi por isso que eu passei a olhar para carga cognitiva como um critério arquitetural. Não porque ela seja “mais humana” ou “mais subjetiva”, mas porque ela se tornou uma restrição operacional real. Quando a arquitetura exige que uma pessoa saiba coisas demais ao mesmo tempo para fazer uma mudança comum com segurança, o sistema passou a cobrar contexto demais.
Um serviço simples pode revelar uma arquitetura ruim
Eu gosto de usar um exemplo bem prático.
Imagine duas organizações em que uma squad precisa colocar um novo serviço em produção.
Na primeira, isso exige que o time entenda pipeline, observabilidade, segredos, política de runtime, naming, alertas, IaC, permissões e mais um punhado de convenções espalhadas. Nada disso é impossível, mas quase tudo depende de descobrir “como se faz aqui”. O código do serviço não é difícil; difícil é montar o contexto necessário para ele existir com segurança no ambiente real.
Na segunda organização, boa parte dessa complexidade repetitiva foi encapsulada na plataforma. O serviço nasce com observabilidade mínima, pipeline previsível, padrões de segurança, naming coerente e integração com catálogo já resolvidos. O time ainda precisa tomar decisões importantes, mas não precisa redecidir infraestrutura básica toda vez.
As duas empresas podem dizer que têm autonomia. Só que, na prática, só uma delas tomou a decisão arquitetural de reduzir a carga cognitiva da mudança comum.
Esse contraste aparece com força nos materiais recentes de platform engineering. O State of Platform Engineering Vol. 4 descreve que muitos fluxos que deveriam ser simples ainda disparam processos longos e multietapas entre vários grupos, o que leva a slow delivery, qualidade inconsistente e dificuldade de escalar engenharia com previsibilidade. No lado oposto, a visão de “platform as a product” e “golden paths” existe justamente para reduzir esse custo mental recorrente e permitir autonomia real.
Autonomia performática é diferente de autonomia real
Esse é um ponto que eu vejo aparecer muito na gestão.
No organograma, muita empresa diz que os times são donos “de ponta a ponta”. Mas, na prática, existe uma diferença enorme entre um time que consegue avançar sozinho porque o sistema foi desenhado para isso e um time que “é responsável por tudo”, mas precisa entender dez camadas de complexidade para fazer uma mudança simples.
Eu costumo chamar o primeiro caso de autonomia real e o segundo de autonomia performática.
Autonomia real aparece quando o time consegue operar dentro de um espaço com boundaries legíveis, contratos razoavelmente estáveis e plataforma suficientemente útil para que a maior parte das decisões repetitivas já venha resolvida.
Autonomia performática aparece quando o time continua dependente de especialistas, alinhamentos paralelos e lembranças históricas, mas a organização insiste em chamar isso de ownership. Nessa situação, o discurso de autonomia está apenas mascarando transferência de complexidade para as pessoas.
Esse diagnóstico não é só intuitivo. A literatura recente de Team Topologies e platform engineering vem reforçando que plataformas existem justamente para reduzir a carga cognitiva necessária para times stream-aligned avançarem com fluidez. Quando isso não acontece, os sintomas aparecem rápido: excesso de context switching, atrasos por bloqueios, queda de eficiência e aumento da dependência de especialistas.
Arquitetura distribuída pode continuar cognitivamente monolítica
Outro erro comum é confundir separação técnica com separação cognitiva.
Eu já vi sistemas muito bem decompostos no diagrama, com serviços separados, ownership distribuído e contratos aparentemente bem definidos. Ainda assim, qualquer mudança relevante exigia entendimento profundo de três ou quatro domínios ao mesmo tempo. O serviço estava separado no repositório, mas não na cabeça de quem precisava mudá-lo.
Esse é o tipo de problema que não aparece quando a discussão sobre arquitetura fica restrita a “monólito versus microsserviços”. A pergunta mais útil, para mim, é outra: essa fronteira realmente reduziu o contexto simultâneo necessário para uma mudança local? Ou apenas espalhou o sistema sem reduzir a dependência mental entre partes?
Esse tema conversa bastante com o que eu já escrevi em Design Modular: O Alicerce das Arquiteturas Evolutivas. Modularidade real não é só dividir o sistema em peças menores. É dividir o sistema de um jeito que reduza o contexto necessário para trabalhar bem em cada peça. Quando isso não acontece, a arquitetura pode até parecer modular no desenho, mas continua monolítica na prática da mudança.
O reflexo na gestão aparece cedo
Uma das razões de eu considerar esse tema tão importante é que os sintomas aparecem muito antes de qualquer “grande falha técnica”.
Eles aparecem quando refinamentos começam a ficar longos demais porque qualquer item simples puxa uma teia de dependências invisíveis. Aparecem quando reviews ficam concentrados sempre nas mesmas pessoas. Aparecem quando o onboarding leva meses não porque o domínio é difícil, mas porque o time precisa aprender uma geografia inteira de exceções e caminhos especiais. Aparecem quando a daily deixa de ser sincronização e vira reconstrução coletiva de contexto.
Nesses momentos, a tentação é concluir que o time está mal organizado ou que faltou documentação. Às vezes falta mesmo. Mas, com frequência, esses sintomas são apenas a superfície de uma arquitetura que exige contexto demais para operações comuns.
Eu passei a prestar mais atenção a sinais como:
- quantas pessoas o time sente que precisa consultar para fazer uma mudança pequena;
- quanto do review é gasto entendendo impacto, e não discutindo implementação;
- quanto do onboarding é consumido por rituais locais e não por domínio;
- e quantas áreas do sistema parecem “proibidas” para quem não é especialista.
Esses sinais costumam me dizer mais sobre a qualidade arquitetural do que muitos diagramas bonitos.
Plataforma ajuda — mas também pode piorar o problema
Eu gosto de usar plataforma como exemplo porque ela mostra muito bem os dois lados dessa história.
Uma boa plataforma reduz carga cognitiva quando absorve complexidade repetitiva sem esconder o que é essencial. Ela oferece um caminho padrão para as tarefas comuns, cria guardrails, diminui improviso e permite que os times concentrem energia no que realmente diferencia o produto.
Mas uma plataforma mal desenhada pode fazer exatamente o contrário. Em vez de reduzir complexidade, ela acrescenta mais uma camada opaca que o time precisa entender para conseguir operar o sistema principal. Nesse caso, a promessa de simplificação vira apenas deslocamento de complexidade.
Esse ponto aparece de forma bem forte nas discussões recentes sobre adoção de plataformas internas. Uma conclusão recorrente é que plataformas falham muito mais por problemas de adoção, clareza e alinhamento com o fluxo dos times do que por deficiência puramente técnica. Ou seja: a plataforma não é sociotécnica só porque “envolve pessoas”; ela é sociotécnica porque o valor dela depende diretamente do encaixe entre arquitetura, produto interno e comportamento organizacional.
IA torna isso mais urgente, não menos
Eu não colocaria IA no centro do artigo, mas também não dá para ignorar o efeito que ela tem aqui.
Se ferramentas de IA reduzem o custo de produzir código, documentação, testes e explorações iniciais, o gargalo se desloca ainda mais para entendimento, revisão, integração e operação. Em outras palavras, desloca-se exatamente para as partes do sistema em que a carga cognitiva importa mais.
Isso significa que IA não reduz a importância desse debate; ela aumenta. Quanto mais fácil fica gerar mudança, mais importante se torna uma arquitetura que limite a quantidade de contexto necessária para validar e absorver essa mudança com segurança.
É por isso que eu vejo tanta conexão entre a conversa atual sobre AI-native platform engineering e a necessidade de reduzir carga cognitiva. O ecossistema está começando a perceber que não basta jogar IA por cima do fluxo existente. Se a arquitetura e a plataforma continuarem empurrando contexto demais para os times, a velocidade adicional de geração só vai amplificar o caos.
O que eu procuro quando penso arquitetura por esse ângulo
Hoje, quando eu olho para uma arquitetura, eu tento fazer uma pergunta muito simples:
o que esse time precisa saber ao mesmo tempo para fazer uma mudança comum com segurança?
Se a resposta é longa demais, geralmente já existe um problema.
Também tento separar o que é complexidade essencial do domínio do que é complexidade acidental do ecossistema. A primeira eu dificilmente elimino; preciso apenas organizá-la melhor. A segunda eu deveria tentar absorver com plataforma, automação, padrões e contracts mais bem definidos.
No fim, eu acabei ficando menos interessado em arquiteturas que apenas parecem sofisticadas e mais interessado em arquiteturas que preservam fluxo. Aquelas em que uma mudança comum não exige arqueologia técnica. Aquelas em que ownership é legível. Aquelas em que a plataforma realmente funciona como compressão de contexto e não como outra camada de mistério. Aquelas em que a coordenação necessária faz sentido para o domínio, e não para compensar escolhas mal encapsuladas.
Fechando a ideia
No fundo, o que mudou é que já não dá para separar honestamente arquitetura de software de arquitetura do trabalho. Um sistema pode estar correto no desenho e ainda assim ser ruim de operar, ruim de entender e ruim de mudar. Quando isso acontece, o problema não está apenas no processo nem apenas nas pessoas. Está na arquitetura.
Reduzir carga cognitiva, limitar dependências desnecessárias e desenhar plataformas e boundaries que preservem fluxo deixaram de ser efeitos colaterais de uma boa arquitetura. Eles se tornaram parte direta do critério de qualidade.
E, para mim, esse é um dos sinais mais claros de que a arquitetura ficou sociotécnica de vez.
