fbpx

Sistema Legado | Decisão de negócio

Hoje decidi falar sobre algo que ninguém gosta, nossos sistemas legados.

Eles são antigos, mal escritos, com muitos problemas.

Poucas pessoas conhecem seu funcionamento, mas se pararmos para analisar são esses tiozinhos que pagam a conta.

Isso mesmo, enquanto nós buscamos a melhor arquitetura e uma forma de tornar nossos sistemas cada vez mais evoluídos, esses monolitos mal escritos estão processando e resolvendo os problemas do dia a dia. E sim, vez ou outra eles precisam de manutenção, param e ninguém entende o motivo, mas eles possuem uma riqueza de funções e regras de negócio adquiridos ao longo dos anos.

Ou seja, ninguém gosta deles, mas eles que nos sustentam.


Ok, então pelo que você está dizendo deveríamos mantê-los?

Bom, aí que mora o problema.

A maior parte do tempo tratamos de sistemas que estão à beira de um colapso.

A utilização de sistemas antigos traz uma variedade de problemas, e vou listar e explicar aqui algumas das que mais vejo no dia a dia.

1) Conhecimento

Pense você que aquele sistema antigo foi construído por pessoas que o dominavam, e conseguiam altera-lo e entende-lo com facilidade, mas essas pessoas mudam de empresa ou se aposentam, e os que ficam não conhecem no mesmo nível.

Vamos fazer um paralelo, imagine que estamos falando de carros. Com certeza o engenheiro que desenvolveu o Fusca, possuía conhecimento para alterar suas funções e adapta-lo com facilidade, pois ele viu e participou da concepção do projeto. Diferente do mecânico, que apesar de conhecer e adquirir muita experiência, dificilmente terá a mesma expertise.

Ou seja, quem constrói possui um conhecimento diferente de quem arruma.

2) Falando ainda de conhecimento

Imagine você que seu sistema antigo, tem tantos anos que sua linguagem já não é aprendida pelas novas gerações, ou seja, o mercado não está mais formando pessoas com capacidade técnica para atuar nesse sistema, o que traz outro grande problema.

Para conseguir contornar essa situação sem alterar o sistema você terá um enorme gasto com treinamento, e possivelmente você vai perder essa batalha, pois nenhum profissional de tecnologia quer trabalhar com sistemas antigos.

É do perfil do profissional de tecnologia se interessar por coisas novas, portanto possivelmente você vai gastar muito esforço para treinar pessoas que vão sair da sua equipe assim que possível.


3) Comunicação com o mundo externo

As tecnologias assim como as linguagens de programação evoluem, e nem sempre elas se conversam.

Vamos voltar no exemplo do Fusca, imagine que você quer colocar um kit multimidia no seu fusca, possivelmente você vai conseguir, é uma alteração mais simples e superficial.

Mas os carros que estão sendo preparados para o futuro são híbridos, e possivelmente preparar o seu fusca para ser hibrido seria a mesma coisa que comprar um novo carro já com essa função.

Ou seja, no sistema as coisas são parecidas, alterações superficiais ou periféricas costumam funcionar, mas quando falamos de novas tecnologias e tendências, possivelmente você vai sofrer.

natanpf
sistemalegado
tecnologia
TI
microsserviços
engenharia de software
arquitetura de software
4) Lentidão e falhas = perda de mercado

Bom, imagine você que em suas mãos está um sistema antigo, com profissionais que não o conhecem muito bem, que não tem domínio sobre a tecnologia em que ele foi desenvolvido.

São essas pessoas que vão precisar adapta-lo de forma rápida para atender as mudanças de mercado.

Qual a chance de isso dar certo?

Sistemas antigos normalmente possuem milhares de débitos técnicos e puxadinhos, soluções tomadas para atender a uma situação extrema ou necessidade urgente, e por esse motivo, alterar um sistema com quebra-galhos é algo extremamente complicado o que possivelmente vai matar a competitividade do seu negócio, você será lento, isso é um fato.

Fora a lentidão, lembre-se que o cenário acima aumenta em muito a chance de uma falha, e a piora da experiência de usuário.

Lento de mais para ganhar novos clientes, e ruim de mais para reter os que você já conquistou.

5) Instabilidade e insegurança

Bom, é fácil então concluir que com todos os pontos levantados acima o risco assumido em manter um sistema legado é extremamente alto. Você não possui controle e nem equipe de resposta para esse sistema e por esse motivo seu dia a dia tem a tendencia a ser algo assustador e crítico.


Conclusão

É comum encontrar engenheiros de sistemas querendo inovar e implementar melhorias e experimentações o tempo todo, mas eu penso de uma forma um pouco diferente, sou sim apaixonado por tecnologia, adoro aprender e experimentar, mas penso sempre que a tecnologia deve ser utilizada de maneira estratégica, para melhorar nosso dia a dia e propor soluções que atendam a alguma necessidade.

Tecnologia sem necessidade é apenas hobby, e deve ser tratada como tal, não podemos deixar nossa vontade de consumir e gerar tecnologia em algo que nos cega a real necessidade do momento.

E com essa linha de raciocínio, eu penso da seguinte forma.

Manter sistemas legados e antigos é muito arriscado, eles devem ser evoluídos, e se você possui um sistema muito antigo você deveria faze-lo agora, e não visando novos benefícios e possibilidades. Mas sim colocando na balança os problemas que esse sistema vai ou já está trazendo para a sua operação.

Por vezes entro em discussões sobre como os novos sistemas vão revolucionar, e sim eles devem revolucionar, mas mais do que isso, eles devem manter a operação.

É bom lembrar que se não mudarmos os sistemas antigos vamos entrar em colapso.

Outra opinião que tenho é sobre a forma de readequação desses sistemas.

Pensando em mão de obra e conhecimento, não é uma boa estratégia fazer todo o seu sistema com as tecnologias mais novas e emergentes, pelos mesmos motivos que você não possui mão de obra para cuidar de algo antigo, você também não tem para construir algo que ainda é experimental no mundo de tecnologia, ou algo que está tomando corpo agora.

Por esse motivo eu defendo uma reescrita do sistema utilizando fundamentos já estruturados e linguagens já robustas e amplamente conhecidas.

Você deve experimentar sim, mas não no sistema inteiro, você não pode colocar toda sua operação em risco para a experimentação, e por esse motivo eu entendo que a experimentação deve ser realizada em partes menos críticas e afastadas do core do seu negócio, e depois de provados ai sim replicados para o resto do sistema.

Por último, é importante lembrar que a evolução sistêmica bem feita, nunca acaba.

Hoje estamos entendendo que sistemas antigos começam a trazer problemas, mas não deveríamos chegar a esse ponto, o melhor dos mundos é ter uma evolução constante, com experimentação comprovação e ampliação sendo feitos a todo momento, e não de tempos em tempos.

natanpf
tecnologia
inovação
liderança

Deixe uma resposta

Powered by WordPress.com. por Anders Noren

Acima ↑

%d blogueiros gostam disto: