Quando falamos de sistemas legados, pensamos em algo obsoleto, em fase terminal ou pronto para ser descontinuado. No entanto, esta ideia “simplista” nem sempre corresponde à realidade. Um sistema ou uma aplicação não deve ser descontinuada simplesmente pelo facto de surgir uma nova tecnologia, uma relativa melhoria na performance ou qualquer mudança aplicacional ou técnica na organização. Devem ser avaliadas todas as condicionantes (internas e externas) que viabilizem a decisão e os resultados estimados pela mudança devem ser realmente diferenciadores.
Vários fatores internos e externos podem despoletar esta “necessidade” de mudança:
- Sistemas que, apesar de estarem permanente atualizados, são superados por outros com uma arquitetura mais flexível – com custos operacionais menores e com um desempenho melhor adaptado à atual ou à futura estrutura da organização;
- Aplicações desalinhadas com a estratégia da organização devido à sua rigidez e/ou complexidade – aplicações frequentemente desatualizadas e por vezes até desnecessárias, que podem ser simplificadas por alguns dos novos sistemas refletindo-se numa diminuição de custos de manutenção e/ou provável aumento da vantagem competitiva da organização;
- A integração contínua dos sistemas existentes pode provocar o “isolamento” de um sistema, isto provoca uma perda contínua de desempenho ou até a indisponibilidade do sistema;
- Sistemas de continuidade obrigatória por motivos legais.
Em todos estes casos pode-se considerar que o sistema completou o ciclo produtivo e atingiu a sua fase final. Torna-se então necessário tomar uma decisão: migrar ou simplesmente modernizar?
Apesar da severidade destes argumentos, os “legacies” podem “reinventar-se” na era digital, por exemplo: as “novas” máquinas Mainframe aproveitam-se como servidores transacionais críticos e de alta segurança empresarial, integram sistemas operativos Open Source, adotam processadores e algoritmos de processamento analítico, aumentam a disponibilidade dos dados, diminuem a latência e podem até funcionar facilmente como clouds híbridas. Que decisão tomar então?
Antes de tomar uma decisão precipitada, deve-se avaliar os riscos e saber como mitigá-los. Podemos analisá-los a partir de várias perspetivas:
- Análise de impacto (são sistemas muito evoluídos pelo que qualquer alteração deve ser bem analisada);
- Análise técnica (sistemas fortemente interligados com arquiteturas complexas);
- Análise do negócio (reduzir a complexidade, desestruturação e falta de documentação do que foi feito ao longo do tempo);
- Análise de custos (atingir um equilíbrio entre o que foi feito e o que se pretende fazer).
Sistemas como os Mainframes, AS/400, Unix e alguns presumivelmente mais atuais dispõem de soluções no mercado que permitem a sua modernização e o prolongamento no tempo, para que as aplicações existentes sofram significativas melhorias no seu desempenho.
As soluções mais comuns que facilitam esta transição baseiam-se na integração em arquiteturas orientadas a serviços SOA (Service Oriented Architecture) mediante Web services, com a utilização de frameworks de desenvolvimento comuns a diferentes linguagens, a utilização de geradores e corretores automáticos de código ou com a utilização de soluções Open Source para diminuir os custos de licenciamento.
Na transição para um sistema mais evoluído, obviamente já menos legado, deve-se integrar as políticas de qualidade, normas e regras atualizadas da organização e garantir que o risco existente (mitigado) não transita para o futuro, caso contrário voltaremos ao ponto de partida, mas com custos acrescidos.
A evolução da tecnologia e das regras de negócio “empurram” as organizações a tomar decisões que devem ser cuidadosamente analisadas em relação aos riscos e custos inerentes à mudança. A tentação de migrar, apesar de ser facilitada tecnologicamente, deve ser bem estudada, especialmente no atual contexto económico.
