Os CIOs em geral enfrentam um grande desafio: encontrar formas de manter seus sistemas atualizados com o mínimo de risco e custo para o negócio. Mas com a evolução cada vez mais frenética da tecnologia e com o ciclo de vida das novidades ficando cada vez menor, TI sofre com a falta de alternativas de baixo custo e risco para manter-se atualizada em relação às novas tendências. Este cenário fez com que TI procurasse meios de automatizar o processo de transformação de uma aplicação para poder se adequar às necessidades de negócio num prazo aceitável e de maneira natural. Se esta situação parece familiar a você, não se preocupe – você não está sozinho.
Quando falamos de aplicações legadas (não tecnologia legada), estamos normalmente lidando com código antigo, muitas vezes complexo, de missão crítica, mal documentado e com cada vez menos gente capacitada para mantê-lo. Uma aplicação ganha o status de “legada” não somente porque sua tecnologia é ultrapassada. É uma combinação de fatores. Java, por exemplo, é a nova plataforma para muitos projetos de transformação, ao mesmo tempo a plataforma antiga para outras (que implementaram as primeiras versões de Java).
A transformação se torna ainda mais complexa quando as tecnologias são completamente diferentes. Neste artigo, discutiremos alguns desafios na conversão de Cobol para Java. Este é um caminho bastante adotado em migrações de aplicações do ambiente mainframe para baixa plataforma. Este caminho leva aplicações escritas com programação procedural, para um novo mundo da programação orientada a objetos e a eventos. As ferramentas disponíveis para auxiliar nesta migração costumavam usar uma estratégia de conversão direta de Cobol para Java, gerando um código Java procedural, o famoso “jobol”. Mas as intervenções no código após a conversão eram tão grandes, que a tarefa de migração, no final das contas, ainda era complicada e arriscada.
As linguagens de programação evoluíram do assembler para a 4a geração, reduzindo cada vez mais o esforço de escrever código. Quanto mais alta a geração, mais poderosos eram os comandos. A mesma evolução pode ser observada em outra dimensão. Desde que o OMG começou a falar de MDA (Model Driven Architecture), algumas empresas incorporaram este modelo nos seus processos de desenvolvimento e mais tarde em ferramentas para acelerar o desenvolvimento de aplicações. MDA é usado agora em projetos de transformação, através de ferramentas que implementam seu processo para converter aplicações de uma linguagem para outra, em dois passos:
- Converte a aplicação atual em um modelo;
- Converte o modelo na linguagem escolhida para a plataforma destino.
E por que esse método será mais vantajoso do que a velha conversão direta de linguagem para linguagem? Com MDA, a transformação pode ser feita de maneira mais aderente à plataforma destino, ao invés de levar para a nova plataforma o modelo de programação da plataforma de origem. Em outra palavras, em uma conversão de Cobol para Java, o resultado é um código Java orientado a objeto, não um Java procedural. Este método representa uma excelente alternativa para acelerar o processo de transformação, ao mesmo tempo em que reduz o risco e o custo.
Mas tenha sempre em mente que ainda sim é um processo automatizado de conversão, e continua com pequenas desvantagens em comparação a uma migração manual. O código gerado muitas vezes carrega bibliotecas do fornecedor da ferramenta e em outros casos obrigado a manutenção do código a ser feita pela IDE do fornecedor (neste caso a aplicação poderia ser mantida alterando o modelo ou ou código fonte).
Alguns fatores que deve ser considerados antes de selecionar a ferramenta ideal de conversão:
- Procure por referências no mercado – boas ferramentas ganham boa reputação muito rápido;
- Fuja de qualquer tipo de dependência do fornecedor após a conversão – normalmente isso acontece com IDEs, frameworks e bibliotecas embutidas no código convertido;
- Peça uma prova de conceito antes de decidir- é sempre bom validar na prática o que o fornecedor diz que é capaz de entregar. Peça seus especialista para validar o resultado e identificar prós e contras. Avalie a qualidade do código gerado e o quanto de alterações o código convertido vai precisar para entrar em produção. Não existe 100% de conversão automática. Algumas adaptações ainda se fazem necessário;
- Não existe uma solução que atenda a tudo e a todos. Você talvez tenha que combinar ferramentas para acelerar a conversão e conversão manual;
- Tenha métricas atualizada da sua aplicação como complexidade, tamanho, manutenibilidade, importância para o negócio e frequência de atualização. Estas informações o ajudarão a definir a estratégia de migração. Se o parceiro selecionado ignorar estes dados, fuja dele!
Os resultados de uma conversão usando MDA são mais realmente mais aceitáveis, no ponto de vista de qualidade do código gerado. É um caminho interessante para projetos de transformação. Novas estratégias de conversão continuam a surgir no mercado e uma delas pode ser a mais adequada para suas aplicações legadas. Mas lembre-se: uma solução não serve para tudo. Esteja preparado para combinar ferramentas que aceleram a conversão com conversão manual de código de forma a maximizar as economias, mas mantendo o risco baixo e uma qualidade aceitável.
Até o próximo artigo!
[Crédito da Imagem: Desenvolvimento – ShutterStock]