Modernização
COBOL, mainframe e IBM i: modernizar sem desligar o que funciona
Os sistemas centrais em COBOL ou RPG costumam ser os mais confiáveis da empresa e, ao mesmo tempo, os mais difíceis de mudar. Nem sempre convém reescrevê-los: primeiro medimos e depois decidimos o que se documenta, o que se abre por APIs e o que se migra.
O problema
O risco não é a tecnologia, é o conhecimento
As regras de negócio se acumulam há décadas em programas batch, copybooks e arquivos, e as pessoas que as conhecem estão se aposentando. Cada mudança exige um especialista cada vez mais difícil de encontrar, e o custo de operar o sistema não para de crescer.
Como fazemos
Do núcleo legado a decisões com dados
Inventário de programas e dados
Programas, copybooks, processos batch, arquivos e tabelas DB2 são inventariados e relacionados entre si.
Regras extraídas para especificação
O comportamento de cada processo fica escrito como especificação verificável, com testes que a comprovam.
APIs ao redor do núcleo
Quando reescrever ainda não compensa, o núcleo é aberto por APIs para que os canais novos o usem sem modificá-lo.
Migração gradual
O que de fato se migra sai módulo a módulo, com comutação reversível e comparação de resultados com o sistema central.
Trabalhamos com a IBM como parceiro tecnológico.
Cenário ilustrativo
Uma seguradora com seu núcleo de apólices em COBOL
Imagine um sistema de apólices em COBOL sobre mainframe, com processos batch noturnos e um portal web que precisa consultar dados on-line.
- O inventário identifica quais programas e arquivos participam da consulta e da emissão de apólices.
- As regras de cálculo desses programas são documentadas como especificação com testes.
- Publica-se uma API de consulta sobre o núcleo atual, sem modificá-lo, para que o portal a utilize.
- Com a especificação em mãos, decide-se módulo a módulo o que fica no mainframe e o que é migrado.
Cenário ilustrativo: Exemplo hipotético para explicar o método: não descreve um cliente nem um resultado medido.
O que fica com você
Um núcleo documentado e um plano com dados
Inventário, especificação de regras e um plano por ondas que separa o que convém manter do que convém migrar.
Perguntas frequentes
É preciso sair do mainframe?
Não necessariamente. Muitas vezes convém manter o núcleo e modernizar ao seu redor: documentação, APIs e interfaces novas. A decisão é tomada com o inventário medido.
Também se aplica a IBM i (AS/400) e RPG?
Sim, com o mesmo método: inventário de programas, arquivos e tabelas, especificação de regras e testes. A amostra medida comprova isso no seu sistema.
Vocês têm um caso próprio com COBOL?
Não temos um caso próprio publicado em COBOL; nosso caso documentado é uma migração a partir do GeneXus. Por isso propomos começar com uma amostra medida sobre o seu sistema.
Próximo passo
Comece por uma amostra medida: de 5 a 10 telas do seu sistema transformadas em especificação verificável, com testes e um inventário de diferenças.