O Cobol ainda não morreu

Até alguns meses atrás, os sistemas de compensação e billing para as operações com opções de compra de ações da Bolsa de Valores de Nova York (Nyse) consistiam de cerca de 800 programas “discretos” Cobol rodando em um mainframe IBM. Hoje, todo o conjunto de aplicações migrou para um par de servidores Windows com quatro processadores, em cluster. Os programas recompilados permanecem em Cobol, mas não vão existir por muito mais tempo.

“Não é nossa meta continuar rodando as aplicações Cobol para sempre. Essa foi uma medida tática para tirar aplicações existentes do mainframe com o mínimo possível de interrupção”, conta Steven Hirsch, vice-presidente de suporte a tecnologia da Bolsa. Ele espera que nos próximos anos tudo seja reescrito para Java e C, plataformas-padrão de desenvolvimento da Nyse. Outros sistemas baseados em Cobol que movem a operação “também fazem parte de um esforço similar de mudança de plataforma”, observa.
A Bolsa não é a única organização que gostaria de abandonar Cobol. Dos 352 entrevistados em uma pesquisa realizada recentemente pelo COMPUTERWORLD-EUA com executivos de TI, 218, ou 62%, disseram que usam Cobol. Destes 218 entrevistados, 36% planejam migrar gradualmente e 25% migrariam, se não fosse o custo de reescrever todo o código.

Mas o que há de errado com Cobol? A tecnologia, que existe desde 1960, é extremamente sólida, destaca-se em processamento batch e é praticamente auto-documentada. As ferramentas para Cobol foram modernizadas e já suportam sistemas distribuídos. A Micro Focus International oferece até o Cobol.Net, um componente de sua solução Net Express que se encaixa perfeitamente no .Net Framework da Microsoft e se integra ao pacote de ferramentas de programação Visual Studio.

Problema de imagem
Mas Cobol também é uma linguagem de procedimentos em um mundo orientado a objetos. Embora seja uma linguagem adequada para operações batch, o mesmo não se pode dizer em relação ao desenvolvimento de aplicações interativas ou front ends baseados na Web. E ainda há um grande problema de imagem. Fora dos data centers recheados por mainframes, Cobol hoje é considerado por muitos programadores especializados em Java, Visual Basic e C# uma linguagem obsoleta e inferior, remanescente da idade das trevas.

A maioria dos novos programas Cobol é escrita apenas para estender ou suportar aplicações existentes no mainframe. A Papé Group, que atua no setor de bens de capital, desenvolve novas aplicações Cobol para seus sistemas back-end para adequar aquisições, segundo Shaun Swift, diretor de sistemas de informação.

Quando aplicações Cobol não são migradas para Windows, Unix ou sistemas distribuídos, elas permanecem assim porque reescrevê-las é oneroso e arriscado, não porque Cobol seja a melhor opção. “Ninguém quer Cobol, mas, realisticamente, ninguém consegue se livrar dele”, resumo Dale Vecchio, analista da Gartner.

Reescrever, em geral, também não faz muito sentido financeiramente. Mike Dooley, gerente de engenharia de software da Harland Financial Solutions, não tem planos de reescrever seus mil programas Cobol. “O que você vai ganhar em troca?” pergunta. Segundo Dooley, um projeto deste tipo levaria anos para ser concluído. “É preciso um bom argumento para isso.” Swift também planeja ficar como está. “Não vejo nenhuma vantagem em mudar.”

Além disso, Cobol praticamente não é usado para desenvolvimento de aplicações totalmente novas. “Não estamos fazendo nada, exceto suportar o que temos na linguagem. Qualquer novo desenvolvimento é feito em SharePoint ou WebFocus”, revela James Hinsey, líder administrativo da Parker Hannifin. “Nossos novos desenvolvimentos são inteiramente em Java”, faz coro Mike Zucker, diretor de desenvolvimento de aplicações da Universidade de Miami.

A verdade é que Cobol “está fora de moda”, de acordo com Zucker. Mas ele ainda usaria a linguagem se os componentes de uma nova aplicação exigissem processamento batch. A Parker Hannifin e a Universidade de Miami utilizam Cobol no mainframe para processamento back-end intensivamente e não têm planos imediatos de mudar.

“Fui à procura de alguém que estivesse fazendo desenvolvimentos novos básicos em Cobol e ainda continuo sem encontrar”, afirma Mark Crego, arquiteto-chefe da Accenture. “É uma lástima.” Crego define Cobol como uma “linguagem magnífica” para processamento de registros em larga escala. Mas hoje, fora do mundo do mainframe, a linguagem co-inventada pela lendária contra-almirante Grace Murray Hopper simplesmente não é respeitada.

Os riscos de reescrever
Para melhor ou para pior, o destino de Cobol está indissoluvelmente ligado ao do mainframe. E ambos ainda deverão existir por muito tempo. Migrar programas Cobol do mainframe pode proporcionar mais velocidade e economia de custo em algumas situações. Os gastos das operações com opções de compra de ações da Bolsa de Valores de Nova York, por exemplo, passaram de 2,5 milhões de dólares anuais em um mainframe hospedado para 200 mil dólares em um sistema distribuído interno que é de 10 a 20 vezes mais rápido nas aplicações em tempo real.

Entretanto, as organizações talvez queiram pensar cuidadosamente antes de reescrever estas aplicações para outra linguagem. Cobol é mais fácil de ler e gerenciar do que C# ou Java, diz Crego, que chama Visual Basic, C e C# de “write-only code”. E reescrever alguns programas Cobol pode exigir quatro ou cinco vezes mais linhas de programa em Java ou C#, explica Vecchio, do Gartner. Ele descreve tais projetos como “um pesadelo de manutenção anunciado”.

Reescrever Cobol também traz outros riscos. As aplicações, que costumam dominar o processamento back-end, incorporam anos de conhecimento acumulado em processos e regras de negócio criados por programadores que já deixaram a empresa. “É aí que moram os riscos. Você está mudando não só a base de código, mas também a base de conhecimento”, aponta Hirsch, da Nyse. Algumas empresas começaram a reescrever projetos e descobriram que não têm o código-fonte ou, pelo menos, não a versão atual.

Mas ninguém é obrigado a reescrever. “Sempre existirão sistemas capazes de executar código compilado IBM 360”, acredita Crego, da Accenture. Cobol pode ser modernizado e os usuários podem ser separados do back end por links para aplicações baseadas na Web. É o que a Papé Group está fazendo. Embora 95% de seus sistemas back-end permaneçam em Cobol, aplicações front-end estão passando para tecnologias Web.

Lógica do negócio
Na opinião de Dooley, da Harland Financial Solutions, recompilar para Cobol.Net facilita integrar aplicações back-office com programas front-end escritos em linguagens .Net. “Se colocamos em Cobol.Net, a aplicação Visual Basic .Net  pode chamar as mesmas rotinas sem ter de saltar obstáculos.”
A Attorneys’ Title Insurance Fund está reescrevendo em C# quase 2 mil programas Cobol back-end para mainframe, processo que deverá levar de três a cinco anos para ser finalizado, prevê o analista sênior Kirk Gagnon.

A empresa está terceirizando a manutenção de sistemas para liberar a equipe de suporte a mainframe da tarefa de treinamento em ferramentas e produtos .Net, incluindo software Visual Studio, BizTalk e MSMQ-MQSeries Bridge. “Estamos otimizando tudo em um conjunto de software comum.” Porém, mesmo com programadores de mainframe qualificados no leme, o projeto é um grande salto. “Nunca fizemos nada tão grandioso antes”, reconhece Gagnon.

Migrar do mainframe e reescrever o código ao mesmo tempo pode ser uma “receita para o desastre”, afirma Vecchio. O desejo de deixar Cobol para trás costuma ser movido por um dentre três fatores: redução do custo total de propriedade, necessidade de lidar com o notório déficit de talentos na tecnologia ou a crença errônea de que a única maneira de conseguir agilidade no negócio é abandonar Cobol de vez.

Na Nyse, Hirsch está dando um passo de cada vez: primeiro migrando do mainframe e portando os programas Cobol com o mínimo possível de modificações. A partir daí, os programas serão reavaliados, não apenas reescritos. “Você precisa repensar a maneira de executar uma função e não se limitar a querer saber como agir da mesma maneira em uma plataforma nova.”

“Por que alguém desenvolveria uma aplicação a partir do zero se existem tantas maneiras de fornecer elementos dela?” pergunta o analista do Gartner, Vecchio. Alguns programas talvez não sejam necessários, enquanto outros podem ser substituídos por aplicações empacotadas. Ferramentas de gestão de processos e mecanismos de regras podem ser usados para substituir outros.

Talvez, só talvez, alguns programas, como os utilizados em processamento batch, devam ser recompilados e modernizados em Cobol. “Existem ambientes onde o melhor é pensar com foco em procedimentos”, conclui Vecchio. Só porque seu front end é orientado a objetos não significa que o back end precisa ser também, corrobora Crego. “E não há razão para Cobol não se encaixar neste espaço.”
O Cobol morreu ou está perto de morrer? “De maneira nenhuma”, afirma Vecchio, mas deverá prosseguir em seu declínio lento e longo. Antes centro das iniciativas de computação, a linguagem deixou de ser o foco da inovação no negócio. “Novos pacotes e programas não estão sendo desenvolvidos. Talentos estão em queda. Tudo isso junto trabalha contra sua ressurreição.”

As organizações devem fazer planos de migrar de Cobol algum dia, mas a possibilidade de fazê-lo não deve ser a mola propulsora de nenhuma decisão. “Concentre-se no que é melhor para sua organização, e não na tecnologia mais ‘quente’ do momento, que nem sempre está aonde você quer chegar”, ensina Swift. Enfim, as necessidades dos processos de negócio, não a escolha da linguagem de programação, devem ditar a hora certa de mudar.