Arquitetura é uma decisão operacional

Decisões de arquitetura são discutidas quase sempre num vocabulário técnico: escalabilidade, desacoplamento, padrão, adequação da ferramenta. As consequências, porém, chegam num vocabulário completamente diferente — um telefonema às três da manhã, uma alteração pequena que precisa de três equipes para acontecer, um botão de desligar que não existe.

Uma arquitetura é uma previsão sobre o comportamento futuro de uma organização sob pressão. Ela determina o que pode ser mudado por uma pessoa, o que exige acordo, o que pode ser desligado sem desligar o resto e quem precisa estar acordado para que a operação continue. Lida assim, ela deixa de ser uma escolha estética entre estilos e passa a ser uma decisão operacional com três leituras: acoplamento, fronteira de falha e custo de mudança.

Acoplamento é a lista de coisas que precisam ser verdadeiras

A definição operacional de acoplamento é direta: para que um pedido seja atendido, quantas coisas precisam ser verdadeiras ao mesmo tempo. Cada dependência síncrona acrescentada a um caminho é mais uma entidade cujo dia ruim vira o seu dia ruim. A disponibilidade se compõe para baixo, e ninguém percebe porque cada dependência, olhada isoladamente, parece confiável. O sistema não fica frágil por uma decisão; fica frágil por vinte decisões defensáveis tomadas em reuniões diferentes.

Existe um segundo acoplamento, e ele é o mais caro: dois componentes estão acoplados quando não se consegue mudar um sem o acordo do outro. Esse acoplamento não aparece no diagrama; aparece na agenda, na forma de quantas pessoas precisam estar na mesma sala para que uma alteração de meia hora chegue à produção. O banco de dados compartilhado é o caso clássico — como não há interface, cada consumidor tem um pressuposto próprio sobre o formato, e o conjunto desses pressupostos é um contrato que ninguém escreveu e que ninguém consegue listar inteiro.

Fronteira de falha é onde se consegue parar

Uma fronteira de falha não é onde o diagrama desenha uma caixa. É onde alguém consegue parar uma coisa sem parar todas. O teste é simples e quase nunca é feito: escolha uma funcionalidade e pergunte o que custa desligá-la agora. Se a resposta é uma implantação, a fronteira não está ali. Se a resposta é que ninguém sabe, ela não existe. Recursos compartilhados — filas de conexão, capacidade de processamento, cotas com terceiros — são o lugar onde as fronteiras desenhadas costumam desaparecer na prática, porque um consumidor lento consome a capacidade de todos os outros sem nunca ter atravessado nenhuma linha do desenho.

Uma fronteira só é real quando alguém consegue desligar um dos lados de madrugada sem precisar reunir três equipes.

O corolário é sobre degradação. Sistemas têm mais de dois estados, e decidir qual funcionalidade cai primeiro — e construir a chave que a derruba — é trabalho de arquitetura, não de operação. Quando isso não é decidido no desenho, a degradação acontece do mesmo jeito: é escolhida às três da manhã, por quem tiver acesso, com a pior informação disponível e sem tempo para consultar ninguém. A diferença entre uma degradação projetada e uma improvisada não é a existência da queda. É quem escolheu o que cai.

Custo de mudança é a propriedade que envelhece

Toda arquitetura é barata para as mudanças que antecipou e cara para todas as outras. A pergunta útil, portanto, não é se ela é flexível, e sim em que direção. Nenhuma resposta é errada em abstrato; o erro é não ter escolhido a direção conscientemente e descobrir dois anos depois que o eixo de mudança do negócio é justamente o único que a estrutura torna caro. Quatro perguntas transformam uma proposta de arquitetura em algo que a operação consegue avaliar:

• —Quando isto falhar às três da manhã, quem é acordado, e essa pessoa tem autoridade para agir sozinha?
• —Qual é a menor mudança possível aqui dentro, e quantas equipes precisam concordar com ela?
• —O que dá para desligar sem desligar o resto, e em quanto tempo?
• —Se esta escolha estiver errada, quanto custa desfazê-la daqui a dois anos, e quem paga essa conta?

As quatro têm resposta, e a resposta deveria ficar escrita ao lado da decisão, porque é ela que envelhece mal e é ela que ninguém consegue reconstruir depois. Vale registrar também o que não foi decidido por razão operacional: estruturas costumam ser escolhidas por familiaridade, por um plano de contratação, por um texto lido na semana anterior. São entradas legítimas, desde que nomeadas como tais. O modo de falhar mais comum é distribuir um sistema para obter independência entre equipes que não têm implantações independentes — o resultado é uma falha de rede a mais e uma autonomia a menos.

Quem devia estar na sala

Quem vai operar o sistema quase nunca participa da decisão que define como ele será operado. O custo operacional da escolha é descoberto um ano depois, por outras pessoas, em circunstâncias em que já não há o que decidir — só o que aguentar. A correção é barata e impopular: a revisão de arquitetura que importa inclui quem vai estar de plantão, e o resultado dela inclui, em linguagem comum, a consequência de plantão de cada opção. Não é um documento a mais. É a tradução que faltava entre a decisão e a conta.

Toda decisão de arquitetura escreve uma escala de plantão. A maioria é escrita por quem não vai estar nela.

Nada disso defende um estilo específico. Sistemas concentrados e sistemas distribuídos sobrevivem, e ambos falham; a diferença entre os que envelhecem bem e os que não envelhecem raramente está no estilo escolhido. Está em se o acoplamento, as fronteiras e o custo de mudança foram escolhidos ou herdados. Arquitetura é uma decisão operacional porque a conta é paga na operação — em noites, em coordenação e no que se consegue mudar enquanto alguma coisa está pegando fogo. Decidi-la apenas com vocabulário técnico não a torna mais rigorosa. Apenas garante que ela seja decidida sem as pessoas que vão pagar.