Resolvendo Todos Os Problemas Do Windows E Outros Programas

Reconstruindo o Legado

Segundo algumas estimativas, o valor total dos aplicativos que residem em mainframes hoje ultrapassa US $ 1 trilhão. A maior parte desse código foi escrita nos últimos 40 anos em Cobol, com algum assembler, PL / 1 e 4GL incluídos na mistura. Infelizmente, esses programas não funcionam bem com os sistemas distribuídos de hoje, e a quantidade de código legado em empresas como a Sabre Holdings Corp. em Southlake, Texas, torna a reescrita uma grande tarefa. 'Estamos limitados por nosso software e sua falta de portabilidade', disse o vice-presidente do Sabre, Alan Walker, sobre os 40.000 programas ainda em execução no IBM Transaction Processing Facility (TPF), Agilent Modular Power System e outros sistemas de mainframe.

google manter dicas e truques
Alan Walker, vice-presidente da Sabre Holdings

Com a escassez de talentos em programação Cobol surgindo na próxima década e uma necessidade clara de maior agilidade de software e custos operacionais mais baixos, as organizações de TI começaram a fazer planos de transição para aplicativos de mainframe. O truque está em descobrir quais aplicativos modernizar, como fazer e onde devem residir.



Os aplicativos se enquadram em um dos três grupos com base na escala, diz Dale Vecchio, analista da Gartner Inc. Aplicativos com menos de 500 MIPS estão migrando para sistemas distribuídos. 'Esses caras querem ir embora', diz Vecchio. À medida que as organizações começam a descartar aplicativos menores, elas podem migrar para um aplicativo empacotado; portar o aplicativo para Unix, Linux ou Windows; ou, em alguns casos, reescrever os aplicativos para rodar em um ambiente .Net ou Java, diz ele.



Dale Vecchio, analista da Gartner Inc.
Na arena de 1.000 MIPS para cima, o mainframe ainda é a plataforma preferida. Aplicações entre 500 e 1.000 MIPS caem em uma área cinzenta, onde a melhor alternativa é menos clara. Uma estratégia cada vez mais comum para esses aplicativos é deixar o Cobol no lugar enquanto usa uma arquitetura orientada a serviços (SOA) para expor as principais interfaces que isolam os desenvolvedores do código.

'Se você expõe esses aplicativos como um serviço da Web, é irrelevante em que o aplicativo foi escrito', diz Ian Archbell, vice-presidente de gerenciamento de produto da fornecedora de ferramentas Micro Focus International PLC em Rockville, Maryland. 'SOA é apenas um conjunto de interfaces , uma abstração. '



'SOA pelo menos permite quebrar os laços de dependência', diz Ron Schmelzer, analista da ZapThink LLC em Waltham, Massachusetts.

Cobol não está indo embora, mas também não está avançando. Embora a base de código Cobol em mainframes seja projetada para aumentar de 3% a 5% ao ano, isso é principalmente um subproduto da manutenção, diz Gary Barnett, analista da Ovum Ltd. em Londres.

'Ninguém está mais aprendendo [Cobol] na escola, e novos aplicativos não estão mais sendo desenvolvidos no Cobol', diz Schmelzer. 'Cobol é como o latim.'



Fornecedores como a Micro Focus abandonaram a ideia de desenvolver a linguagem Cobol para o desenvolvimento de aplicativos distribuídos. “O Micro Focus não se trata de um compilador Cobol melhor”, diz Archbell. Em vez disso, sua abordagem é 'abraçar e estender', diz ele. 'Nós expomos coisas como transações CICS agregadas como JavaBeans, serviços da Web ou código .Net ou C #. Está embrulhando. ' Mas com tanto código legado, esse processo não acontecerá da noite para o dia. 'Pode levar 20 anos', diz Archbell.

O Sabre ainda tem mais de 10.000 MIPS de aplicativos em mainframes, e Walker planeja migrar tudo nos próximos anos. O aplicativo de busca de tarifas baseado em TPF da empresa, usado por Travel-ocity.com LP e agentes de viagens, foi reescrito para funcionar como um programa Linux de 64 bits em servidores Opteron de quatro vias.

O Sabre migrou os dados de back-end para 45 servidores executando M ySQL, cada um contendo dados totalmente replicados. O novo sistema é mais flexível e 'muito barato' em comparação com o mainframe, diz Walker. Ele questiona a sabedoria convencional de que todos os aplicativos de ponta precisam permanecer nos mainframes, observando que o aplicativo de pesquisa estava na casa dos milhares de MIPS. 'É bastante óbvio que você não precisa de mainframes para fazer transações em grande escala', diz ele, apontando para os sucessos do eBay Inc. e Amazon.com Inc.

Barnett aponta que muito poucos de seus clientes tiveram sucesso em reescrever completamente aplicativos de grande escala.

No caso do Sabre, é importante notar que o aplicativo exigia muito da CPU e da memória e que as pressões da concorrência teriam forçado uma reescrita de qualquer maneira. 'Resolvemos um problema maior', que era a necessidade de gerar centenas de resultados em vez dos 10 a 20 que o sistema TPF poderia fornecer por pesquisa, diz Walker.

Simplesmente reescrever milhões de linhas de código para fornecer os mesmos recursos não apenas não seria um resultado financeiro para o The Bank of New York Co., mas também exigiria uma vida inteira de trabalho, diz Edward Mulligan, vice-presidente executivo da divisão de serviços de tecnologia . Uma transição gradual para aplicativos empacotados pode ajudar essas empresas, diz Barnett da Ovum. 'Oitenta por cento dos principais processos de negócios nos bancos são iguais. Em 10 anos, fará pouco sentido ter seu próprio programa de poupança local exclusivo ', diz ele.

Mulligan tem migrado alguns aplicativos menores, liberando capacidade cara de mainframe. O grande motivo: custo. Quando o fornecedor de seu software de gerenciamento de problemas se recusou a alinhar o licenciamento com pacotes equivalentes na área do Windows, ele migrou para uma versão mais barata do Windows. Os custos operacionais totais para executar aplicativos no mainframe podem ser 'facilmente' 10 vezes maiores do que em uma arquitetura Unix ou Windows, diz Walker do Sabre.

Embora a IBM tenha começado a oferecer preços com base no uso de subcapacidade, poucos fornecedores terceirizados de software de mainframe seguiram o exemplo. “Os fornecedores que não adotam preços flexíveis estão acelerando o declínio em seus negócios”, diz Barnett.

No Sabre, Walker planeja continuar a migrar para fora do mainframe, que ele diz ser muito caro.

Atualização no local

Bob DiAngelo, vice-presidente e CIO do MIB Group Inc.
Bob DiAngelo, vice-presidente e CIO do MIB Group Inc., já está enfrentando esse desafio. Sua empresa depende de um aplicativo de E / S intensivo usado para detectar fraudes em seguros para mais de 500 seguradoras na América do Norte. DiAngelo diz que era impossível contratar alguém para dar suporte aos aplicativos de mainframe IBM do MIB Group, originalmente escritos em 1969 em assembler com um banco de dados VSAM de back-end. Então, alguns anos atrás, ele recebeu a aprovação para fazer a reengenharia do sistema. A equipe de TI está desenvolvendo o novo sistema em Java com base em uma arquitetura de três camadas usando WebSphere MQSeries e DB2. Mas o novo sistema, agora pela metade, não roda em hardware Unix ou Windows. Ele, junto com os sistemas ainda em produção e os ambientes de teste de garantia de qualidade e desenvolvimento, todos são executados em uma única partição lógica em um uniprocessador IBM zSeries 880 de 210 MIPS com um z / OS Application Assist Processor (zAAP) que lida com a carga de trabalho Java.

O novo código Java é executado em um zAAP. Manter os aplicativos fora do processador de mainframe impede que o licenciamento baseado em CPU para aplicativos de terceiros aumente enquanto aumenta a capacidade total do sistema para 366 MIPS. Mas DiAngelo não tem muitos softwares de terceiros com que se preocupar. Ele diz que os custos operacionais decrescentes do mainframe permitiram à empresa crescer de um sistema de 80 MIPS para a caixa de 210 MIPS mais o processador zAAP, enquanto os custos totais permaneceram 'relativamente estáveis'.

Walker não está convencido. 'Poderíamos executar código Java em um z9, mas isso o tornaria a CPU Java mais cara do mundo', diz ele.

Barnett concorda - parcialmente. “Se você tem Java ou cargas de trabalho que precisam de acesso de alta velocidade aos dados de mainframe, executá-los em uma partição de mainframe é uma escolha viável”, diz ele. 'Mas ... para cargas de trabalho genéricas do Linux ou Java, ainda não é uma plataforma de consolidação óbvia.'

A IBM espera que outros sigam o exemplo do MIB Group. “A IBM está empurrando uma caixa, várias arquiteturas”, diz Vecchio, do Gartner. Guru Rao, um colega da IBM e engenheiro-chefe do eServer, diz que consolidar uma arquitetura de três camadas no mainframe quando os dados residem lá faz sentido porque as comunicações entre o front e o back end não precisam passar por um TCP / IP propenso à latência rede. No mainframe, ele diz, 'você pode se comunicar com cada um desses espaços usando instruções em vez do tráfego TCP'.

DiAngelo reconhece que nem sempre reescrever aplicativos é prático. 'Fazer uma remoção e substituição é uma grande coisa', diz ele sobre o projeto de cinco anos. 'Há coisas que você não pode arcar com a reengenharia e provavelmente sempre ficarão no lugar onde foram desenvolvidas.'

A transição também requer mais potência para um aplicativo que consome até 300 I / Os por transação e até 130.000 transações por dia. 'Java requer mais potência de CPU do que assembler, [e] conforme você muda de VSAM proprietário para um sistema de banco de dados gerado, você perde eficiência. Com o WebSphere, MQSeries e DB2, você precisa acionar o dial, 'diz DiAngelo.

Outra questão é se essa estratégia será dimensionada para aplicativos além de algumas centenas de MIPS em tamanho, diz Vecchio. No alto, a TI deve migrar para SOA porque não há outras opções, diz ele. 'A esperança para os clientes de mainframe é que o WebSphere e o Java possam funcionar com a mesma qualidade de serviço que eles esperam do CICS, IMS e Cobol', diz ele.

Christian Anschuetz, CIO da Publicis Group SA
Publicis Group SA mudou totalmente de um mainframe MVS para um sistema aberto. A agência de publicidade implantou servidores blade de alta densidade Hewlett-Packard Co. e partições VMware Inc. para aumentar os níveis de utilização. Ele migrou o aplicativo principal - um sistema de relatório financeiro que incluía faturamento do cliente, ERP e relatórios que representavam 80% da carga de trabalho do mainframe - para o PeopleSoft. Outros aplicativos foram portados ou totalmente refeitos, diz o CIO Christian Anschuetz. “Foi um esforço hercúleo, com certeza”, diz ele sobre o projeto de quatro anos.

Sua principal motivação era o custo. O mainframe era 'extraordinariamente caro' e não ágil o suficiente para as necessidades da organização, diz Anschuetz, e 'os custos de licenciamento associados às ferramentas de desenvolvimento eram simplesmente astronômicos'. A Publicis reduziu seus custos operacionais em 10% ao ano.

Mesmo depois de considerar os custos de gerenciamento de um sistema distribuído e o custo dos servidores Intel necessários para substituir o mainframe, o custo total de propriedade ainda era 'drasticamente menor', diz Anschuetz.

Ele diz que tinha preocupações em sair do mainframe. 'Lembro-me de alguém me dizendo que não deveríamos nos livrar do mainframe, é cinco 9s, e você vai rodar esse lixo do Windows', diz Anschuetz. 'A realidade é que [nossos sistemas distribuídos] estão ativos o tempo todo, e nosso [tempo médio entre falhas] real é tremendo.'

Quando se trata de lidar com aplicativos legados, não há respostas gerais, diz Robert Rosen, presidente da Share, um grupo de usuários de mainframe IBM com sede em Chicago. “O problema é quando você tenta forçar uma solução”, diz ele. 'Pegar o melhor dos dois mundos, essa é a chave.'

Inibidores de crescimento Os gerentes de data center citaram os custos de software como o maior inibidor para aumentar o uso de mainframes.
Custos de hardware

1%

Custos de software IBM

quinze%

Custos de software de terceiros

47%

Base: 100 participantes da conferência do data center

Fonte: Pesquisa Gartner Inc. de 2005

Planos para aplicativos Cobol
Qual das opções a seguir melhor descreve a estratégia de sua empresa para seus aplicativos Cobol de mainframe?


Base: 158 tomadores de decisão de TI não governamentais
Fonte: Forrester Research Inc., pesquisa de novembro de 2005