terça-feira, 31 de janeiro de 2012

Elefantes custam a morrer...


Sistemas velhos, feitos em plataformas ultrapassadas, "pululam" nas empresas, gerando custos e problemas para todos. Alguns defendem que estes aplicativos já se pagaram, e que agora só geram lucro, outros advogam que a sua tecnologia é sólida, gerando vantagens para os Clientes. Porém, a realidade mostra outra coisa...




O que acontece com os elefantes?

Há uma lenda que diz que um elefante, quando fica velho demais, se afasta da manada para morrer, evitando prejudicar os outros. Isto não é verdade. Os elefantes são nômades e vivem mudando de local para buscar alimento. Quando um elefante não consegue mais acompanhar a manada, é deixado para trás, e, consequentemente, acaba morrendo.

É o que deveria acontecer com os sistemas: quando ficam velhos, devem morrer com dignidade!

Mas não é o que acontece... Um sistema velho é muitas vezes mantido vivo a custa de aparelhos, gastando tempo e recursos preciosos para adiar o inevitável: o descarte! Logo, como elefantes, absorvem grande quantidade de insumos, incomodam e causam problemas para todos.


Longevidade de sistemas aplicativos

Sistemas aplicativos com mais de 5 anos com certeza geram mais custos do que benefícios para as empresas.

Porém existem diversos argumentos utilizados para justificar a sua longevidade:

  • O sistema ainda é útil e o investimento já foi pago;
  • Nós dominamos a tecnologia;
  • Não queremos investir porque o sistema será substituído em breve;
Este último motivo é bem popular! Toda empresa tem uma porcaria de sistema, que todos odeiam, e que será substituído por um novo projeto "fodástico". Só que o projeto "fodástico" nunca sai do papel...



MEL DELS: ele tem o setup!

Outro dia, estava conversando com um conhecido meu que ainda tem o "setup" do Visual Basic 3! Ele copiou para DVD para não perder! Eu perguntei qual o motivo, se seria por saudosismo, ou algo do gênero, e sabe qual foi a resposta? Ele disse que usava para instalar novas estações para o cliente dele, ou seja, ELE AINDA USA O VB 3 PARA DESENVOLVER NOVOS SISTEMAS!!!!!

Mas, não é só ele, pois tem muitos, mas MUITOS desenvolvedores que ainda criam e mantém sistemas em CLIPPER! É isso mesmo que você leu: EM CLIPPER, C@4@1ho!

Que m34d@ de cliente é esse que aceita um sistema feito em VB 3 ou Clipper? Só pode ser um idiota, que adora jogar dinheiro pela janela...


Quando os carros tinham carburador...

Ah, fala sério, cara! É isso mesmo? Então tá. Vamos voltar a 1994, época em que carro a álcool e a gasolina eram veículos distintos, e que ainda existia uma coisa chamada "afogador" no painel. Eu tinha um Mille Eletronic, branco, novinho, Lindo, só que, antes de sair com o carro, tinha que puxar o afogador e manter o carro "esquentando" por algum tempo, para evitar que "engasgasse" por estar frio.

Bons tempos, não? A vida era fácil... Programávamos em COBOL, VB 3 e até mesmo em Clipper. Os caros não tinham direção hidráulica e nem ar condicionado... Que beleza!

ACORDA, k@4@1ho! Os caras que defendem essas velharias andam de carro novo, flex, com ar condicionado e SEM AFOGADOR! Tudo pago com o dinheiro que ganham dos clientes otários, que "comem em suas mãos"!

Para mim, só existem dois motivos para a existência de sistemas paquidérmicos:

  • A empresa é uma m34d@ e sua gerência também;
  • Alguém tem interesse nisso.


E sistema tem prazo de validade?

Tem sim! Um sistema está fora da vida útil quando deixa de ser rentável, ou seja, para mantê-lo funcionando, gastamos mais do que seus benefícios. Mas isto é difícil de medir... O retorno de um sistema de informação deve ser medido por vários fatores, entre eles:

  • Economia de escala: ganhos em produtividade proporcionados pelo uso do sistema;
  • Retorno dos clientes: aumento de satisfação através de um serviço melhor, proporcionado pelo sistema;
  • Eficiência de custos: desperdícios e desvios evitados através do uso do sistema;
Querer medir o retorno de um sistema da mesma forma que um investimento financeiro é difícil, pois você tem que botar números em fatores subjetivos, como os que eu acabei de citar. Existem algumas metodologias para isto, como o CoBIT (http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx), que propõem alinhar a TI à estratégia da empresa, controlando todos os investimentos em TI (sistemas, equipamento etc) como um portifólio de investimentos.

De qualquer forma, é preciso planejar antecipadamente a vida útil dos seus sistemas aplicativos, afinal de contas, eles são a "alma" de qualquer empresa moderna. 

Certa vez um aluno me perguntou: "Ao implantar um sistema, quando devemos pensar em fazer um novo?" E eu respondi: "no dia seguinte!" 

Um projeto de software moderno, se for feito com todas as técnicas e boas práticas, deve demorar em média 4 meses. Se demorar mais que isso, corre o risco de ficar desatualizado ao implantar. Quando eu comecei a trabalhar na área, nos idos de 1976, dizia-se que a vida útil de um sistema de informação era de 5 anos. 

Claro! Não havia Internet, o mercado era todo dominando por uma só plataforma (Mainframes IBM), e praticamente só havia uma única linguagem de programação: COBOL. Então, a vida útil acabava quando um sistema havia sido muito "mexido", logo, o código-fonte ficava muito difícil de manter.

Porém, a evolução tecnológica logo adicionou mais fatores aos critérios de obsolescência dos sistemas, como: conectividade, distribuição, ubiquidade e mobilidade.

Claro que vale! Em uma empresa que não vou citar o nome, me pediram para  "ajudar converter um sistema Java para rodar no eclipse"... Coisa inocente, não? Quando fui ver, era uma po44@ dum sistema feito com Servlets em Java EE 1.2, que rodava na mesma versão do WSAD que Noé usava em sua arca! Fala sério! Como um gerente admite manter um sistema tanto tempo sem pensar em atualização? 

O resultado? O sistema inteiro teria que ser re-escrito e adaptado para uma versão mais recente do Java e do Java EE. E o que aconteceu? Varreram para baixo do tapete e ficou assim mesmo.

Aliás, essas coisas vivem acontecendo comigo... Certa vez, em outra empresa, me mandaram para os EUA para dar manutenção numa m34d@ dum sistema feito em Small Talk. ALÔ, ATENÇÃO: S-M-A-L-L-T-A-L-K! Só o idiota aqui sabia mexer com aquela porcaria de linguagem, que jamais deveria ter existido. Porém, havia um sistema lá no Cliente (nos EUA) e a empresa precisava fazer uma alteração... Buscaram um cara no Brasil e pagaram passagem, salário e estadia (foram vários meses), para fazer uma manutenção!

O pior é que eu propus fazer uma versão em C++ ou em Java, e disse que trabalharia de graça para isto, só que o Cliente não aceitou. ELE NÃO ACEITOU, K@4@lho!

Pelo que você está dizendo, um sistema fica desatualizado antes de ser implantado. Então, qual é a solução?

A solução é seguir as boas práticas da engenharia de software e dos grandes gurus, como Martin Fowler: 
  • Modularizar bem o seu projeto;
  • Criar módulos de baixo acoplamento e alta coesão;
  • Produzir código-fonte auto documentado;
  • Refatorar sempre que possível;
  • Separar núcleo e empacotamento;
  • Planejar a obsolescência;
Eu sei que você concorda com as quatro primeiras, mas e com as duas últimas? O que significariam?

Separar núcleo e empacotamento

Todo módulo (seja ele classe ou componente) tem um núcleo, ou seja, uma função que realmente implementa o negócio. O resto, não importa! Você pode pegar essa função e "empacotar" como: Web Service, ou EJB, ou ainda como um componente CORBA (Argh!) O importante é que a função seja independente do "empacotamento", que é a forma como a funcionalidade está sendo exposta.

Muita gente boa cria Web Service monolítico, com o código-fonte "entranhando" com o código de apresentação. Isto diminui a vida útil do sistema, além de torná-lo menos flexível.

Planejar a obsolescência

Crie um "roadmap"! Se você está desenvolvendo em Java, já sabe o que vem por aí, ou seja, quais as novas versões e tecnologias que ainda estão "no forno". Procure conhecer e se atualizar, fazendo provas de conceito e estudos de compatibilidade. Planeje novas iterações do projeto para que seja adaptado às novas versões, crie agendas de longo prazo e convença seu cliente (ou seu gerente) da necessidade de seguir estas agendas. 

Por exemplo, você está desenvolvendo um sistema em Java EE 6, com JSF 2.0. Logo, já sabe que vem aí o Java EE 7, com maior ênfase em virtualização e suporte à criação de nuvens (Platform as a Service) e JSF 2.2, logo, deveria conhecer estas tecnologias e, se for possível, evitar utilizar recursos que vão "morrer" nas novas versões.

Se você separar direitinho o núcleo do empacotamento, e modularizar seu projeto, pensará em datas de "vencimento" para os diversos componentes, indicando qual o "roadmap" para cada camada: apresentação, regras de negócio, persistência etc.

Moral da história

Manter sistemas velhos, feitos em tecnologias obsoletas, é um gerador de custos para qualquer empresa. Segundo a ZDNet (http://www.zdnet.com/blog/service-oriented/study-us-government-spends-36-billion-a-year-maintaining-legacy-systems/6505) o Governo Americano gasta 36 bilhões de dólares anualmente para manter sistemas legados. Por que? Bem:
  1. Os fornecedores não dão mais suporte às plataformas antigas;
  2. O número cada vez mais restrito de desenvolvedores que conhecem as linguagens antigas;
  3. O código-fonte vai se deteriorando com o tempo (brittleness).
Se você, como bom programador, ouvir alguém falar "meu sistema em COBOL roda até hoje", já sabe que seu interlocutor é negligente e a empresa, displicente, com seus ativos de TI.