 |
| Bellacosa Mainframe evoluindo em IMS 4 vias para crescer mais |
☕💣🚀 PADAWAN, O IMS NÃO PRECISA SER SUBSTITUÍDO. ELE PRECISA SER LIBERTADO!
As 4 Estradas da Transformação Digital no IMS: APIs, Java, SQL e DevOps na Visão da IBM
Quando alguém fala em transformação digital, normalmente surgem palavras como Cloud, Kubernetes, APIs, Microservices, DevOps, Inteligência Artificial e OpenShift.
Logo depois aparece alguém apontando para o mainframe e dizendo:
"Precisamos substituir tudo isso porque é legado."
E é exatamente nesse momento que começam alguns dos projetos mais caros, demorados e arriscados da história da TI corporativa.
O material da IBM "The 4 Paths to Digital Transformation in IMS", apresentado por Haley Fung, mostra uma visão radicalmente diferente. Em vez de substituir o IMS, a estratégia proposta é transformá-lo em um participante ativo do ecossistema digital moderno.
A mensagem principal do documento é simples:
O problema não é o IMS.
O problema é quando o IMS fica isolado.
Durante décadas, o IMS foi responsável por processar algumas das cargas mais críticas do planeta. Bancos, seguradoras, governos, operadoras de telecomunicações e empresas aéreas construíram seus negócios sobre ele.
E agora?
Agora a IBM mostra quatro caminhos principais para trazer o IMS para a era digital:
APIs
Java
Open Database (SQL/JDBC)
DevOps e Cloud
Vamos mergulhar profundamente em cada um deles.
O GRANDE MITO: MODERNIZAR NÃO É REESCREVER
Uma das maiores mentiras da indústria é:
Modernizar = Reescrever.
Não.
A IBM deixa claro que o objetivo é preservar o ativo mais valioso:
Dados
Regras de negócio
Processos transacionais
Disponibilidade
Segurança
Tudo isso já existe dentro do IMS.
A pergunta correta não é:
Como substituir o IMS?
Mas sim:
Como conectar o IMS ao mundo moderno?
Essa diferença de mentalidade pode representar milhões de dólares economizados.
A PRIMEIRA ESTRADA: API-ENABLE EVERYTHING
Transformando transações IMS em APIs REST
Durante décadas, acessar uma transação IMS exigia:
3270
MQ
Sockets proprietários
Middleware especializado
Para um desenvolvedor React, Angular ou Mobile isso parece arqueologia.
A solução apresentada pela IBM é simples:
Transformar ativos IMS em APIs REST.
z/OS Connect Enterprise Edition
O protagonista dessa transformação é:
IBM z/OS Connect EE
Ele permite expor:
Transações IMS TM
Dados IMS DB
Aplicações COBOL
Serviços z/OS
como APIs REST modernas.
O cenário tradicional
Imagine um banco.
Aplicação Mobile
↓
Middleware
↓
Gateway Proprietário
↓
MQ
↓
IMS
Múltiplas camadas.
Complexidade.
Custos.
O cenário moderno
Aplicação Mobile
↓
REST API
↓
z/OS Connect
↓
IMS
Muito mais simples.
Muito mais rápido.
Muito mais alinhado ao mercado.
O FIM DA DEPENDÊNCIA DE ESPECIALISTAS MAINFRAME
Uma observação extremamente interessante da IBM:
Não é necessário conhecimento profundo de mainframe para consumir APIs IMS.
Isso muda completamente a equação.
Um desenvolvedor Node.js pode consumir uma API IMS da mesma forma que consome:
Salesforce
SAP
Oracle Cloud
AWS
Sem saber o que é um PCB.
Sem saber o que é um GU.
Sem saber o que é um PSB.
IMS DE CENTRO DE CUSTO PARA CENTRO DE RECEITA
Essa é uma frase poderosa do material:
Converter IMS de Cost Center para Revenue Center.
Historicamente o IMS era visto como:
Com APIs ele passa a gerar novos negócios.
Exemplo:
Uma seguradora possui regras de cotação em IMS.
Em vez de reescrever tudo:
O IMS continua executando a regra.
O mercado passa a consumi-la.
CASOS REAIS DE SUCESSO
O documento apresenta diversos exemplos.
Um deles reduziu um processo de abertura de contas de:
3 dias
para
menos de 1 segundo.
Resultado:
Tudo sem substituir o IMS.
A SEGUNDA ESTRADA: JAVA NO IMS
Agora chegamos ao tema mais polêmico.
Quando alguém fala:
Java no Mainframe
sempre surge alguém dizendo:
Isso não faz sentido.
Mas a IBM vem investindo nisso há mais de 15 anos.
POR QUE JAVA?
Porque existe um problema real.
Encontrar:
COBOL Developers
IMS Specialists
DL/I Experts
está cada vez mais difícil.
Enquanto isso existem milhões de desenvolvedores Java no mundo.
A IBM percebeu isso há muito tempo.
NÃO É COBOL VS JAVA
Esse é outro erro comum.
O documento não propõe eliminar COBOL.
Ele propõe:
COBOL + Java
Trabalhando juntos.
ESTRATÉGIA 1: EXTENDER APLICAÇÕES EXISTENTES
Imagine um programa COBOL IMS.
Você possui uma rotina extremamente pesada:
validação
criptografia
cálculo complexo
A IBM sugere mover partes específicas para Java.
Benefícios:
ESTRATÉGIA 2: NOVAS APLICAÇÕES EM JAVA
Outra abordagem:
Criar novas aplicações IMS diretamente em Java.
O banco continua sendo IMS.
As transações continuam sendo IMS.
Mas a lógica é Java.
O SEGREDO CHAMADO zIIP
Aqui está uma das partes mais interessantes.
Java pode utilizar melhor os processadores especializados zIIP.
Para muitos ambientes isso significa:
menor consumo de MIPS
redução de custos
melhor escalabilidade
O MITO DA PERFORMANCE
Existe outro preconceito:
Java é lento.
A IBM apresenta benchmark demonstrando mais de:
25.000 transações por segundo
em workload Java sobre IMS.
Isso desmonta completamente a narrativa de que Java no Z seria apenas experimental.
O MODELO HÍBRIDO MAIS INTELIGENTE
O que muitos clientes estão fazendo?
COBOL continua cuidando do núcleo.
Java assume:
APIs
integrações
componentes modernos
novas funcionalidades
Resultado:
Baixo risco.
Alta velocidade.
A TERCEIRA ESTRADA: OPEN DATABASE
Agora chegamos ao assunto que faz muitos DBAs arregalarem os olhos.
IMS e SQL.
Sim.
IMS e SQL.
O FIM DO "IMS É FECHADO"
Durante muitos anos ouvimos:
IMS é fechado.
A IBM respondeu criando a estratégia Open Database.
JDBC DIRETO NO IMS
O modelo apresentado permite:
Aplicação Java
↓
JDBC
↓
IMS
Sem extrações complexas.
Sem replicações desnecessárias.
Sem ETLs gigantescos.
POR QUE ISSO É REVOLUCIONÁRIO?
Porque tradicionalmente o fluxo era:
IMS
↓
ETL
↓
Data Warehouse
↓
Analytics
Horas depois.
Às vezes dias depois.
Novo modelo
IMS
↓
SQL
↓
Analytics
Quase em tempo real.
IMS COMO FONTE DE IA E ANALYTICS
O material mostra integração com:
Tudo consumindo dados IMS.
Isso é enorme.
Porque o dado mais valioso da empresa geralmente está no IMS.
IMS CATALOG: A JOIA ESCONDIDA
Outro componente importante é o IMS Catalog.
Historicamente:
DBD
PSB
ACB
eram artefatos compreendidos por poucos especialistas.
O Catalog transforma isso em metadados mais acessíveis.
Resultado:
melhor governança
descoberta de dados
integração simplificada
DDL NO IMS
Uma das maiores mudanças modernas.
Desde o IMS 14:
CREATE DATABASE
CREATE TABLE
ALTER DATABASE
passaram a fazer parte do ecossistema IMS.
Para quem passou décadas vivendo apenas de:
isso representa uma mudança cultural gigantesca.
O QUE ISSO SIGNIFICA PARA O DBA?
Significa que o DBA IMS moderno precisa conhecer:
Hierarquia
SQL
Metadata
APIs
Analytics
O perfil profissional está mudando.
A QUARTA ESTRADA: DEVOPS E CLOUD
Agora chegamos à transformação mais profunda.
O FIM DO DESENVOLVIMENTO MAINFRAME ISOLADO
Antigamente:
Desenvolvimento Distribuído
↓
Pipeline Moderno
e
Mainframe
↓
Mudanças manuais
Dois mundos separados.
A VISÃO DA IBM
Integrar o IMS ao pipeline corporativo.
Mesmas ferramentas.
Mesma metodologia.
Mesmo fluxo.
GIT NO MAINFRAME
O documento mostra integração com:
Git
Jenkins
Maven
Nexus
Artifactory
e outros componentes DevOps.
Hoje isso já é realidade em muitos ambientes.
WAZI
Uma das iniciativas mais interessantes mostradas no material.
IBM Wazi oferece:
VS Code
Eclipse
Red Hat CodeReady
OpenShift
para desenvolvimento z/OS.
O impacto cultural
O novo desenvolvedor pode trabalhar em:
VS Code
e desenvolver para IMS.
Algo impensável vinte anos atrás.
ANSIBLE NO IMS
Essa talvez seja a parte que mais chama atenção de Sysprogs.
A IBM apresenta coleções específicas Ansible para:
z/OS
IMS
automação operacional
IMS COMO INFRAESTRUTURA PROGRAMÁVEL
Imagine executar:
geração de DBD
geração de PSB
geração de ACB
comandos IMS
automaticamente.
O documento mostra exatamente isso através dos módulos:
ims_dbd_gen
ims_psb_gen
ims_acb_gen
ims_command
Para um Sysprog isso é quase ficção científica comparado ao modelo tradicional.
ZOWE: O NOVO ROSTO DO MAINFRAME
Outro destaque é o Zowe.
Ele fornece:
para administrar IMS.
Exemplos:
iniciar regiões
parar regiões
consultar transações
automatizar deploys
Tudo através de scripts modernos.
O IMS ESTÁ VIRANDO CLOUD?
Na prática...
Sim.
Ou pelo menos absorvendo conceitos cloud.
z/OS CLOUD BROKER
O documento mostra o z/OS Cloud Broker integrado ao OpenShift.
Isso permite provisionar serviços como:
de forma semelhante ao mundo cloud.
O QUE ISSO SIGNIFICA PARA O FUTURO DO IMS?
A conclusão mais importante do material é que a IBM não vê o IMS como tecnologia do passado.
Ela vê o IMS como:
Plataforma transacional
Fonte de dados
Plataforma API
Plataforma DevOps
Plataforma híbrida
A GRANDE LIÇÃO PARA O PADAWAN MAINFRAME
Se você é:
Desenvolvedor COBOL
DBA IMS
Sysprog
Arquiteto
Gestor
precisa entender uma coisa.
A guerra não é:
COBOL vs Java
Mainframe vs Cloud
IMS vs Microservices
A verdadeira batalha é:
Sistema Isolado vs Sistema Conectado.
O documento da IBM demonstra que o IMS moderno pode participar de:
✅ APIs REST
✅ OpenAPI
✅ Swagger
✅ Java
✅ JDBC
✅ SQL
✅ Analytics
✅ Machine Learning
✅ Git
✅ Jenkins
✅ OpenShift
✅ Ansible
✅ Zowe
✅ DevOps
✅ Hybrid Cloud
sem abandonar décadas de investimento corporativo.
E talvez essa seja a maior lição de todas:
O futuro não pertence aos sistemas novos.
Pertence aos sistemas que conseguem evoluir.
E poucos sistemas na história da computação provaram tantas vezes sua capacidade de evolução quanto o IMS. ☕💣🚀
Fonte analisada: The 4 Paths to Digital Transformation in IMS, Haley Fung, IBM IMS.
