Quanto tempo vai durar seu software?

No momento histórico aonde muitas empresas apostam no fim de aplicações com arquiteturas cliente / servidor e anunciam que tudo que é novo deve ser construído em .NET ou Java, submetemos uma reflexão baseada em uma pesquisa e a posição do autor.

por Fabio Camara

No momento histórico aonde muitas empresas apostam no fim de aplicações com arquiteturas cliente / servidor e anunciam que tudo que é novo deve ser construído em .NET ou Java, submetemos uma reflexão baseada em uma pesquisa e a posição do autor.

O objetivo deste artigo é colaborar com informações que permitam você ratificar ou retificar as estratégias de migração de seus aplicativos próprios, possibilitando um novo direcionamento quando for o caso e, principalmente, agregando dados novos ao seu plano de negócio (business plan).

Vamos criar um cenário: Você é dono de uma software house e possui um produto comercializado em vários clientes construído em Delphi 6. Você possui uma equipe de manutenção corretiva e evolutiva que atende satisfatoriamente seus desafios.

Uma pergunta não sai mais de seu pensamento, preciso migrar minha solução para uma versão mais nova ou uma tecnologia mais nova. De forma mais incisiva, por que devemos migrar um aplicativo construído em Delphi 6 para Delphi 8 .NET ou C#.NET ou Java?

Na minha leitura, não existe uma resposta pronta e exata para esta questão. Cada situação possuíra uma grandeza de requisitos que serão determinantes a decisão do enorme investimento e esforço necessários a migração.

Sem avaliar ainda questões sobre tecnologias novas, o gráfico abaixo demonstra historicamente qual o tempo de vida de um software.

Fonte: Revista Programmers Paradise

Este gráfico, extraído da revista "Programmers Paradise", demonstra-nos que a maioria das migrações iniciam-se entre 5 e 6 anos de vida. Antes deste tempo, provavelmente existem relatos de problemas de negócios ou arquitetura indevida aos requisitos exigidos. Depois deste tempo, observasse o início dos "fantasmas comercias", como por exemplo os argumentos de que os clientes exigem que sua solução funcione na Web ou tenha recursos gráficos avançados.

Alguns agentes externos também podem apressar a necessidade de migrar sua atual solução, como foi por exemplo a corrida desenfreada pelos programadores Clipper em portar seus aplicativos para o Windows 95.

Hoje, observando este fato, comprovamos que as imposições comerciais estão fundamentadas em modismos e não em aspectos técnicos. Muitas soluções em Clipper não tinham (e não têm) o menor sentido de ser migrada para arquiteturas com visual "Windows Form", como por exemplo aplicativos de automação comercial tipo "frente de loja".

Entendendo todo o contexto ensinado nestes 15 anos de micro-informática, arrisco-me a afirmar que sempre foi o "modismo" criado pelos provedores de marketing que influenciaram as decisões de migração. Afinal, o que entende um usuário final sobre qual tecnologia deve ser construído o software que ele deseja adquirir? Que diferença isso faz se todos os requisitos de negócios são plenamente atendidos?

Independente do seu motivo particular para migrar, apenas desejo que seja uma sábia decisão, compatível com os desafios que terás que superar.

O primeiro grande desafio que enfretarás será com sua equipe de desenvolvimento. Ele é tão gigantesco que podemos dividir em algumas partes:

1- Escolha da nova tecnologia que será construída sua futura solução.

Se você já possui em sua equipe expertise em Visual Basic, muito certamente continuará na família Microsoft e o .NET será uma grata inovação, contudo isso também é super perigoso pois seu time de desenvolvimento desdenhará para os novos paradigmas e utilizará o Visual Basic.NET como se fosse o Visual Basic 6, ou, pior ainda, irá programar em ASP.NET como se faz em ASP.

Se você utiliza ferramentas de outros fornecedores, erroneamente pode ser conduzido a escolhas não baseadas em requisitos técnicos e sim baseadas em racismos infantis contra a Microsoft. Não penso em fazer você tomar a mesma decisão que eu, que optei pelo .NET nas comparações que fiz com outras tecnologias, contudo responsabilizo-me sobre minha condição de orientador.

Baseie sua decisão na seguinte hierarquia, respectivamente: Oportunidades comerciais, requisitos de negócios e requisitos técnicos.

2- Passagem de conhecimento sobre o passado ou sobre a nova tecnologia.

Um erro comum dos empresários é acreditarem que irão migrar sua solução existente com o time "existente". Pense racionalmente, se todos os seus desenvolvedores já possuem tarefas que os ocupam diariamente, o que eles deixarão de fazer para poderem se dedicar a está nova implementação?

Outro erro comum é investir em treinamentos para seu time atual mantendo-os com a manutenção do legado. Acertar em uma nova implementação requer maturidade, conhecimento de negócio e prática na tecnologia proposta. Os dois primeiros estão satisfeitos, porém como eles conseguirão uma autonomia técnica se não conseguem se dedicar "full time" a nova tecnologia?

Na minha leitura a resposta são times mistos, um balanceamento perfeito entre desenvolvedores que dominam o conhecimento dos requisitos de negócios com programadores que comprovadamente possuem maturidade e prática na nova ferramenta.

Uma prática fortemente recomendada é contratar uma terceira opinião e juntos, todos criarem direções técnicas como por exemplo assuntos sobre arquitetura e boas práticas para código fonte. Historicamente os resultados de estratégias similares, apesar de parecerem mais caras no início, economizam significativas horas durante o projeto.

3- O dilema da migração.

A palavra "migração" nos impõe determinadas compreensões indevidas, no meu entender. Em algum dicionário de informática esta palavra deve significar sair de uma linguagem "A" e ir para uma linguagem "B", assim como os animais migratórios que saem do ponto "A" para o ponto "B".

Pessoalmente, vejo este pensamento como "cancerígeno", pois atrapalha sensivelmente a criatividade evolutiva, nos aprisionando a restrições fundamentadas em sentimentos vis, como vaidade por exemplo. Em outras palavras requisitos de negócios não podem ser questionados para não ferir suscetibilidades dos seus autores.

É preciso ter coragem para assumir uma nova implementação, que deve ser no mínimo melhor e mais completa que a anterior. Vejo até como uma oportunidade melhor nos aspectos comerciais, pois podes conseguir parceiros "homologadores" e possuirá um novo produto.

Conclusivamente, trabalhar de forma saudável as comparações entre o passado e o futuro software e inteligentemente usar o melhor existente sendo livre para evolução.

Entendemos também que os mesmos temores que nos cercam, estão presentes em nossos clientes. Perguntas como - o que vai acontecer com as manutenções do aplicativo presente visto que todos os esforços estão voltados para a nova solução - assustarão nossos clientes, principalmente de empresas que não valorizam o quesito gerência de relacionamentos.

Hoje em dia, uma estratégia de sucesso dever obrigatoriamente conter os conceitos R.C.P. (Reliable, Connected e Painless). Sobre confiança, Reliable, o quesito atomicidade já é amplamente conhecido por implementadores de software. Connected também é lugar comum, ou como Stanilaw Ponte Preta gostava de dizer - óbvio ululante.

Painless significa numa tradução livre "sem sofrimento" e merece um pouco mais de destaque. São dois os pontos que fundamentam este conceito: Em primeiro lugar criar uma importação simples e transparente através de ferramenta de automação, e em segundo, que as novas interfaces sejam familiares e fáceis, liberando seus clientes de altos investimentos em capacitação.

Aproveitando o atalho sobre interfaces, uma das grandes vitórias do mundo Windows 95 sobre as soluções Clipper foram as questões visuais. Ergonomia e beleza são assuntos sérios que devem ser tratados por especialistas e facilitam enormemente a adoção da nova solução por seus usuários finais. Sempre lembrem-se desta lição de nossa história.

Mais assuntos podem ser escritos acerca deste polêmico tema, porém acredito que grandes construções devem ser viabilizadas andar por andar. Eis o primeiro andar e desejo-lhes muito sucesso em suas evoluções, não migrações.