Modernizar software crítico sem perder o controle operacional

Todo programa de modernização começa com a mesma frase, e a frase costuma ser verdadeira: o sistema atual não se sustenta mais. O que quase nunca é examinado é a frase seguinte, que vem implícita e sem discussão — portanto, vamos substituí-lo.

A substituição troca um sistema que ninguém entende por inteiro, mas cujo comportamento é conhecido por anos de observação, por um sistema que alguém entende por inteiro no papel e cujo comportamento ninguém nunca viu. Do ponto de vista de quem opera, isso é perda de informação, não ganho. O risco da modernização não está na escolha de tecnologia: está no intervalo em que a empresa deixa de saber com precisão o que o próprio negócio faz.

O sistema antigo é a especificação

A documentação descreve o sistema pretendido. O que roda carrega anos de exceções: o cliente que tem uma regra diferente por um motivo que ninguém lembra, a rotina de correção que alguém executa no fechamento do mês, o campo que significa uma coisa antes de certa data e outra depois, o comportamento em erro do qual três sistemas vizinhos dependem sem nunca terem dito isso a ninguém. Nada disso está nos requisitos. Tudo isso está em produção, e é isso que os usuários chamam de sistema.

A consequência prática é que o primeiro trabalho de modernização não é escrever código novo: é ler comportamento. E a leitura precisa ser feita de fora — entradas, saídas, efeitos —, porque é a única descrição que obriga. Onde o sistema antigo está errado e o negócio já depende do erro, replicar o erro é uma decisão legítima. O que não pode é ser uma decisão tomada por acidente, por alguém que não sabia estar tomando decisão nenhuma.

Estrangular em vez de substituir

A alternativa conhecida é estrangular: colocar uma costura na frente do sistema antigo, mover uma fatia por vez para trás dela e deixar o resto onde está. A propriedade que importa nessa abordagem não é a velocidade, porque ela é mais lenta. É que em nenhum momento existe um sistema fora de operação: o conjunto está sempre vivo, e o que muda a cada passo é pequeno o bastante para caber na cabeça de quem vai operá-lo naquela noite.

A escolha das fatias é o trabalho de engenharia dessa fase, e o critério raramente é o que parece. Fatiar pelo organograma produz fronteiras que não correspondem a nada no estado e que se desfazem na primeira reorganização. Fatiar pela propriedade do dado produz fronteiras que sobrevivem. A primeira fatia precisa ser representativa em volume e em comportamento, mas limitada em consequência: a mais fácil não ensina nada, e a mais crítica cobra o aprendizado no pior lugar possível.

Uma migração só é incremental se cada passo puder ser desfeito sozinho. Caso contrário, é uma substituição entregue em parcelas.

Há duas armadilhas previsíveis nesse formato. A costura tende a virar permanente, o que é perfeitamente aceitável desde que tenha sido desenhada como fronteira e não como andaime provisório — andaime provisório permanente é a origem de metade da dívida técnica que se atribui a pressa. E o estado duplicado, o período em que os dois sistemas guardam a mesma informação, é a parte mais difícil de todas. A regra que evita o desastre é simples de dizer e cara de manter: para cada pedaço de estado, exatamente um lado é dono da escrita em cada momento, e o outro lê dele. Escrever dos dois lados e reconciliar depois é o método mais confiável de produzir dois sistemas errados.

Paridade tem de ser observável

Dizer que o novo faz a mesma coisa não é uma afirmação verificável por inspeção. Paridade é medição: rodar os dois lados, comparar e ter decidido antes o que conta como diferença. Quatro coisas precisam estar acordadas antes da primeira comparação, e todas as quatro custam pouco antes e viram discussão infinita depois:

• —O que é comparado: o efeito observável, não a estrutura interna. Duas implementações corretas divergem em forma, e comparar forma produz ruído sem fim.
• —O que conta como diferença aceitável — arredondamento, ordenação, carimbo de tempo —, escrito antes e não no dia em que a diferença aparece.
• —Quem adjudica: alguém com autoridade para declarar que o novo está certo e o antigo estava errado. Sem esse papel, cada divergência vira um debate técnico que ninguém encerra.
• —Por quanto tempo: um ciclo completo do negócio, porque o que mais diverge são os processos que rodam uma vez por mês ou uma vez por ano, e que ninguém lembrou de listar.

A descoberta desconfortável de toda operação em paralelo é sempre a mesma: boa parte das diferenças revela defeitos do sistema antigo, e alguém, em algum lugar, já depende de cada um deles. Cada diferença deixa de ser um problema técnico e vira uma decisão de negócio com dono e prazo. Tomar essas decisões antes do corte é praticamente todo o valor de rodar em paralelo. Tomá-las depois tem outro nome, e o nome é incidente.

Reversibilidade a cada passo

Um plano de retorno que está escrito no documento e nunca foi executado não é um plano de retorno. É uma intenção com aparência de controle, e ela costuma ser descoberta como intenção no único momento em que isso importa. Reversibilidade se testa quando é barata — no primeiro passo, com pouco em jogo —, porque é o único momento em que testá-la não é, por si só, um evento operacional.

E ela tem prazo de validade. A partir do instante em que o sistema novo escreve estado que o antigo não sabe ler, voltar deixa de ser gratuito e passa a ser uma migração no sentido inverso, feita sob pressão e sem preparo. Esse ponto existe em toda travessia e não pode ser eliminado. A diferença entre equipes não é evitá-lo: é conhecê-lo com antecedência, dizê-lo em voz alta e tratar a data como o que ela é — o momento em que o projeto muda de natureza e passa a exigir outro tipo de atenção.

O ponto em que voltar deixa de ser possível existe em toda migração. A diferença entre as equipes é saber a data dele.

Modernização bem-feita é longa e sem drama, e a cada semana a organização continua conseguindo responder às mesmas quatro perguntas: o que está rodando agora, quem responde por isso, o que muda esta noite e o que acontece se desligarmos. São perguntas operacionais, não arquiteturais, e é por elas que se mede se o controle foi preservado. A versão com drama é a que troca, num fim de semana, um sistema conhecido por um desconhecido mais novo — e um sistema desconhecido é o mesmo sistema com menos informação, que é exatamente o contrário do que a modernização deveria comprar.