Negócios
O Cobol ainda não morreu
Por COMPUTERWORLD
Compartilhe:
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.
Visões estreitas
Cada um vê o mundo com um prisma diferente e compara-se linguagem com produto. Uma linguagem é um elemento abstrato que pode ser implementada através de um produto. Cada pessoa que usa um produto baseado em COBOL parece que não se dá conta que a linguagem COBOL não é apenas aquilo que ele está usando e, ao se deparar com uma nova necessidade, logo acha que precisa trocar de linguagem. Não avalia se aquela implementação COBOL não prevê a situação ou o sujeito sequer pesquisou no manual ou help como resolver a questão.
Não existe nada que não possa ser feito com um computador que não possa ser escrito com a linguagem COBOL. Quem deixa o preconceito de lado, pára e pensa economiza muito tempo e dinheiro.
Fazendo uma atualização tecnológica no patrimônio em COBOL pode se ter com muito mais rapidez e segurança os resultados desejados, seja em batch, orientação a objetos, interface gráfica, banco de dados ou migração de mainframes para baixa plataforma.
Só não vê quem não quer para poder vender outra opção de solução.
Carlos Roberto - 29 Nov 2006, 13h11
COBOL eterno: SOA e o legado
Instituições financeiras, órgãos governamentais e empresas que fazem uso de computadores há muito tempo têm nas aplicações COBOL a espinha dorsal de seus negócios. Esse legado, que demandou recursos financeiros e tempo para ser construído, não pode ser substituído por uma questão de modismo ou preferência pessoal de um grupo de novos programadores. Vale lembrar o fenômeno do downsizing, que aconteceu em meados da década de 80, o fenômeno Clipper do começo da década de 90, e as ondas que vieram logo depois.
Essa tendência das empresas em resistir o quanto podem a migrações - e que as experiências passadas mostraram não compensar em vários casos - têm trazido à tona uma nova maneira de enxergar a tecnologia da informação: orientá-la a serviços. Programas COBOL estão sendo mantidos e/ou escritos tendo como meta prover serviços aos usuários, e fornecer estes serviços através de métodos heterogêneos de acesso, como CICS, celular, Web e outros.
A arquitetura SOA pretende dar ainda mais vida aos nossos velhos programas COBOL, integrando-os às novas tendências e necessidades dos usuários, através daquilo que é o melhor dos mundos: preservação dos investimentos já efetuados nos sistemas legados, mas permitindo que estes sejam estendidos por plataformas mais modernas de acesso.
Tulio - 29 Nov 2006, 09h11
Cobol Morreu ? - Papel dos Mainframes
Senhores, o que é preciso saber é que a linguagem Cobol continua muito boa para processar quantidades massivas de dados. É excelente auto-documentadora e muito efetiva.
Posto isso permitam-me corrigir um erro aqui: mainframes NÃO serão substituidos por ambientes distribuidos quando quantidades massivas de dados precisem ser processadas porque sua configuração de HW permite que canais processem com enorme rapidez grande quantidade de informações; aplicações tipicas I/O-bound.
Servidores (ex: Unixes) multi-processados são excelentes para aplicações CPU-bounded onde há muito processamento e relativamente pouco output.
Assim, cada um tem seu nicho específico de utilização... Aplicações back-office que atualizem cadastros enormes (tipico de financeiras/bancos/telefonia etc...) precisam de mainframes. Aplicações tipo CAD, front-office, graphics rodam melhor em processadores rápidos mas de relativamente baixo throughput...
Abraço
Marcio - 28 Nov 2006, 17h11
Conheça os 100 melhores CIOs do país
60 melhores empresas de TI e Telecom para trabalhar
A elite do RH de TI e Telecom no Brasil
Computerworld e Instituto GPTW apresentam as Melhores Empresas de TI e Telecom para Trabalhar 2009.
Veja o Especial
