Quando mexer no sistema se torna um risco para a empresa

“Se está funcionando, não mexa.” Mas e se ninguém souber as consequências?

Em sistemas que estão em operação há muitos anos, essa frase pode parecer prudente. Afinal, uma mudança desnecessária também pode introduzir problemas.

O problema começa quando a empresa não evita mudanças por prudência, mas porque já não sabe com segurança quais serão as consequências de fazê-las.

Ninguém conhece completamente determinadas partes do sistema. A documentação é insuficiente ou está desatualizada. Algumas regras existem apenas no código. Integrações foram criadas ao longo dos anos e suas dependências não estão claras. Antes de qualquer alteração, é preciso consultar uma das poucas pessoas que ainda sabem como aquilo funciona.

Nesse momento, o problema não é simplesmente ter um sistema antigo.

É não ter segurança para modificá-lo.

Os sinais da paralisia

Os sinais costumam aparecer aos poucos.

• Uma mudança aparentemente simples exige uma análise muito maior do que o esperado
• Uma atualização é adiada porque ninguém sabe exatamente o que pode ser afetado
• Determinadas partes do sistema passam a ser evitadas
• Correções são feitas por meio de contornos porque alterar a origem do problema parece arriscado demais

Com o tempo, a organização aprende a conviver com essas limitações.

O sistema continua funcionando e isso pode criar uma sensação de segurança.

Mas existe uma diferença importante entre um sistema que é estável e um sistema que ninguém se sente seguro para alterar.

Não mexer também tem risco

Quando existe muita incerteza, é natural concluir que alterar o sistema representa risco.

O problema é assumir que não alterá-lo representa segurança.

Enquanto o sistema permanece como está, pessoas mudam de função ou deixam a empresa. Conhecimento informal desaparece. Componentes envelhecem. Dependências deixam de receber suporte. Novas necessidades surgem e precisam ser acomodadas em uma estrutura cada vez menos compreendida.

O risco não desaparece.

Ele apenas se acumula silenciosamente.

E quanto mais tempo essa situação permanece, mais difícil pode se tornar realizar uma mudança quando ela finalmente for inevitável.

Quando a arquitetura depende da memória de alguém

Ter profissionais que conhecem profundamente determinados sistemas é valioso.

Depender deles para que o sistema possa ser alterado é outra coisa.

• “Precisamos falar com aquela pessoa antes.”
• “Não altere essa tabela sem consultar o responsável.”
• “Existe um processo que usa esse campo, mas não sabemos exatamente onde.”

Frases assim podem indicar que uma parte importante do conhecimento necessário para operar e evoluir o sistema não está registrada de forma adequada.

Ela existe na experiência de algumas pessoas.

Isso transforma conhecimento técnico em dependência operacional. E, quanto mais crítico for o sistema, maior é o risco dessa concentração.

Antes de modernizar, é preciso reduzir a incerteza

Quando ninguém conhece completamente um sistema, substituí-lo inteiro pode ser tão arriscado quanto continuar evitando mudanças.

Por isso, modernização não precisa começar por uma reescrita ou uma grande migração.

Pode começar pela recuperação do conhecimento.

• Quais são as dependências do sistema?
• Quais integrações existem?
• Onde estão as regras críticas de negócio?
• O que acontece quando determinada funcionalidade é alterada?
• Quais partes possuem testes suficientes para permitir mudanças com segurança?
• Onde o conhecimento está concentrado?

Hoje, inclusive, ferramentas de inteligência artificial podem ajudar nesse trabalho, analisando grandes bases de código, identificando relações entre componentes, apoiando a reconstrução de documentação e auxiliando na criação de testes.

Mas tecnologia não elimina a necessidade de compreender e validar o comportamento real do sistema.

O objetivo inicial é outro: reduzir a incerteza até que a empresa volte a ter condições de decidir o que pode — e o que deve — ser alterado.