Migração de sistemas legados é um assunto que pode render horas, dias, semanas ou meses em qualquer empresa, algo que considero normal, pois envolve uma quantidade enorme de variáveis e traz grandes desafios. Não precisamos ir muito longe para identificar sistemas legado e os desafios para mantê-lo nos dias de hoje.

Sistemas que cresceram muito rápido e em um curto espaço de tempo, menos de 1 ano por exemplo, pode não ser considerado legado, entretanto na maioria das vezes este crescimento rápido e não planejado não irá suportar o crescimento da empresa a médio e longo. Com isso, o assunto migração entra em cena novamente.

Meu objetivo nesta série de artigos é ir a fundo no tema, trazer um pouco da minha experiência, sugerir caminhos e alternativas para uma migração menos dolorosa, além de recomendar soluções que irão ajudá-los. Vale lembrar que não existe receita de bolo e vocês verão isso aqui, cada caso é um caso e ninguém melhor do que você para saber dos problemas nas soluções desenvolvidas por você ou sua empresa. Faça seus comentários ao final do artigo, eles irão agregar e ajudar outros a refletir sobre que caminho tomar na neste processo, além de me ajudar nos próximos artigos.

Se não é fácil e sabemos, então por onde começamos?

Todos tem de estar desarmados

A primeira coisa a se fazer neste processo é entrar desarmado, aberto a mudança, aceitar ideias, críticas e sugestões, expor o que você pensa e ouvir, ouvir, ouvir e ouvir muito. Todos aqueles envolvidos neste projeto, deverão estar conscientes disso e preparados para mudar seu comportamento, a pior coisa neste longo projeto é ter um grupo de pessoas remando contra, enquanto todos os outros estão remando para frente. Trabalho em equipe será fundamental, críticas, sugestões e debates calorosos existirão, mas todos tem que estar cientes de que é para o melhor do projeto.

Incorporar métodos ágeis como SCRUM já na fase inicial do projeto pode ser de grande ajuda, as práticas ágeis enfatizam muito a colaboração, trabalho equipe, interação entre as pessoas, etc. Isso pode começar a estabelecer um ponto de equilíbrio na equipe e reforçar de forma continua o trabalho em equipe.

Por que migrar?

Faça esta pergunta a si mesmo “Por que migrar?”, esqueça por um instante o famoso ditado “Time que está ganhando não se mexe”, ou seja, “sistema que está funcionando não se mexe”.

A grande maioria dos sistemas ERP desenvolvidos na década de 80 e início dos anos 90 adotaram a arquitetura Cliente/Servidor (Cliente/Server) e foram desenvolvidos para plataforma Desktop, ao longo do tempo isso foi mudando, a web se tornou uma plataforma mais atrativa e hoje vivemos no mundo dos dispositivos móveis. Naquela época muitas soluções baseadas em Web surgiram, mas o avanço da tecnologia foi tão rápido que essas antigas aplicações web não foram bem estruturadas, trazendo vários outros problemas. Enfim, integração entre plataformas e diversidade de meios de acesso tornou o modelo Cliente/Servidor obsoleto.

Considere como exemplo sistemas ERPs legado ou outros similares, reflita sobre o cenário mencionado no parágrafo anterior e traga para sua realidade, seus clientes hoje querem acesso as informações via web, via iPhone, iPad, Android e seus muitos celulares e tablets e assim por diante. A recente pesquisa que fiz aqui no blog mostrou que 75% dos entrevistados irão desenvolver aplicações para mobile e 45% irão migrar suas aplicações desktop para web em 2013. Como você faria essa migração hoje de forma rápida e escalável? Como você integraria apps com seu backend? Quanta regra de negócio seria reutilizada? Já se perguntou?

Seja Desktop ou Web, se seu sistema está baseado em Cliente/Servidor, a eficiência da sua empresa está comprometida pois você está o tempo todo fazendo remendos para atender as necessidades do mercado, isso eleva a dificuldade de manutenção do código, diminui a eficiência da sua equipe, aumenta o seu custo e o custo do seu cliente, ou seja, diminui sua competitividade no mercado.

Já deve fazer um tempo que seu cliente pede para que TODO o sistema seja Web, ele faz questão de dizer TODO O SISTEMA, ele não precisa de tudo e sim certos módulos importantes, como por exemplo relatórios, gráficos estatísticos em tempo real, acesso ao cadastro de clientes, etc. Mais uma vez arquitetura Cliente/Servidor se torna um problema, o seu cliente disse que os relatórios tem de estar acessíveis pela web e relatórios na web podem trazer uma carga enorme em todo o sistema. Como você atenderia a estas solicitações? Não precisa me dizer dos remendos, eu já imagino, replicar os dados para um servidor web, manter sincronizado, etc.. Isso é caro, não é escalável e se torna um remendo temporário que irá rasgar em pouco tempo.

Já se perguntou quanto custa manter seus sistemas Desktop? Depois de muitos anos sua aplicação virou um grande sistema, com dezenas de módulos, integrações, recursos, dependências, etc.. Para responder essa pergunta, você precisa se fazer as perguntas abaixo:

• Quantos problemas de instalação do sistema são registrados mensalmente?
• Quantos problemas de compatibilidade de Windows são registrados mensalmente?
• Quantos problemas de atualização do sistema são registrados mensalmente?
• Quantas visitas mensais os técnicos do suporte técnico fazem a clientes para resolver problemas que não são possíveis de resolver remotamente?
• Quanto representa essa grande estrutura de suporte técnico no seu custo final?
• Que crescimento você estima para o negócio se todo sistema estivesse na Web?
• Quais diferenciais a web traria para o seu negócio?
• Quanto tempo irá levar para você desenvolver uma aplicação Android com base na atual infra que sua empresa oferece?
• Etc…

Provavelmente você não tenha a resposta para todas, então é hora de começar a buscar e mensurar estes custos.

Aplicações desktop aumentam o custo final, principalmente por causa do alto-custo do suporte técnico, não estou dizendo para mandar embora metade da equipe de suporte técnico, muito pelo contrário, a equipe de suporte técnico tem um grande conhecimento do sistemas e pode ser reutilizado em outras funções, como desenvolvedores, testadores, analistas, etc…

Que tal oferecer sua solução como serviço (SaaS), o negócio do seu cliente não é TI, porque não ter  uma infra-estrutura na nuvem e oferecer sua solução? Cobrar por este serviço.

São inúmeros os pontos a se pensar, os pontos aqui mencionados são alguns entre os milhares e talvez não seja razão para você, o que é totalmente aceitável da minha parte, entretanto reflita sobre outros pontos que você acha importante e faça sua própria análise.

Vou ficando por aqui com esta primeira parte, enquanto isso reflita sobre as razões que o levaria a migrar sistemas legados ou mal estruturados.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Estou avaliando alguns frameworks para desenvolvimento web e até agora entre todos os que vi o Grails me chamou bastante atenção. Grails é um framework Open Source que funciona sobre JVM, utiliza o Groovy como linguagem dinâmica, foi inspirado no Ruby on Rails e outros frameworks.

O que mais me chamou a atenção foi a simplicidade com que podemos criar interfaces web com base no nosso modelo de dados, que por sua vez mapeia as classes e grava os dados, em outras palavras ORM.

Abaixo um vídeo introdutório do site do Grails, nele você pode ter uma idéia de como o framework funciona.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse