☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

segunda-feira, 29 de janeiro de 2024

Da Terra à Lua em um Copilot — O Dia em que Barbicane Descobriu que o Canhão Não Era o Mais Perigoso da Expedição

 

Bellacosa Mainframe apresenta o MS Copilot

☕ Um Café no Bellacosa Mainframe

Da Terra à Lua em um Copilot — O Dia em que Barbicane Descobriu que o Canhão Não Era o Mais Perigoso da Expedição

Ou: como GitHub Copilot, Microsoft 365 Copilot, Researcher, Analyst, Work IQ, Notebooks, Copilot Studio, agentes, testes, segurança e governança transformaram um autocomplete em uma pequena agência espacial corporativa — e por que ninguém no Gun Club apertaria ENTER antes de perguntar qual USERID estava autorizado a disparar o projétil

Há tecnologias que chegam anunciando uma revolução.

E há tecnologias que chegam discretamente, completando uma linha de código.

O Copilot pertence à segunda categoria.

Em 2021, a cena parecia quase inocente.

Um programador digitava:

IF WS-SALDO < ZERO

e uma inteligência artificial sugeria a continuação.

Nada particularmente ameaçador.

Era quase como ter um estagiário invisível sentado ao lado dizendo:

— Talvez você queira escrever PERFORM TRATA-ERRO.

Mas, assim como no romance Da Terra à Lua, de Júlio Verne, ninguém deveria subestimar homens muito determinados quando eles começam a discutir engenharia em uma sala fechada.

No romance, o Gun Club começa pensando em construir um canhão.

Depois alguém pergunta:

— E se atirássemos alguma coisa na Lua?

Pouco tempo depois estão calculando trajetória, pólvora, materiais, aceleração, local de lançamento e sobrevivência dos ocupantes.

Com o Copilot aconteceu algo curiosamente parecido.

Começamos perguntando:

“Você consegue completar minha função?”

Depois:

“Você consegue conversar sobre meu código?”

Em seguida:

“Consegue entender todo meu repositório?”

Logo apareceu:

“Consegue alterar vários arquivos?”

Depois:

“Consegue compilar?”

Então:

“Consegue executar os testes?”

Finalmente chegamos perigosamente perto de:

“Consegue receber uma tarefa, estudar o problema, modificar o sistema, testar, corrigir os erros e preparar o Pull Request enquanto eu tomo café?”

Barbicane, presidente do Gun Club, provavelmente interromperia a reunião neste momento.

— Senhores, antes de colocar três passageiros dentro desse projétil… quem autorizou o agente?

Bem-vindo ao Copilot moderno.

Prepare o café.

Hoje vamos da Terra à Lua.

Mas primeiro precisamos entender quem está segurando o fósforo.



1. Antes do foguete existia o autocomplete

Para compreender o Microsoft Copilot atual, precisamos voltar ao começo.

O primeiro grande Copilot da família foi o GitHub Copilot, anunciado em 2021.

Sua proposta original era relativamente simples:

PROGRAMADOR
     ↓
DIGITA CÓDIGO
     ↓
COPILOT OBSERVA
     ↓
SUGERE CONTINUAÇÃO

Quem já utilizou autocomplete tradicional poderia pensar:

— Então inventaram um autocomplete com esteroides.

Não exatamente.

Autocomplete tradicional normalmente funciona sobre estruturas conhecidas.

Por exemplo:

MOVE
PERFORM
DISPLAY
OPEN
CLOSE

A ferramenta conhece palavras-chave, variáveis, métodos ou APIs.

O GitHub Copilot começou a demonstrar uma capacidade diferente.

Ele conseguia considerar:

  • comentários;

  • código ao redor;

  • nomes de variáveis;

  • padrões;

  • funções anteriores;

  • intenção provável.

Se você escrevesse algo como:

* VALIDAR CPF DO CLIENTE

a IA poderia tentar produzir uma implementação.

Isso era impressionante.

Mas ainda havia um detalhe fundamental:

o Copilot sugeria.

Quem executava o trabalho continuava sendo o programador.

Era o equivalente ao Gun Club desenhando o projétil no quadro-negro.

O canhão ainda não havia sido carregado.



2. 2022 — o experimento vira produto

Em 2022, o GitHub Copilot tornou-se produto comercial.

Esse momento é importante porque muda o status da tecnologia.

Sai:

experiência curiosa

entra:

ferramenta diária de desenvolvimento

Programadores começam a utilizar IA como companheira real de codificação.

A expressão usada durante muito tempo foi:

AI pair programmer.

Ou seja:

programador em dupla com inteligência artificial.

Para um iniciante COBOL, imagine algo parecido com trabalhar ao lado de um programador mais experiente que observa você escrever:

       IF WS-CUSTOMER-STATUS = 'A'

e sugere:

           PERFORM PROCESS-ACTIVE-CUSTOMER
       ELSE
           PERFORM PROCESS-INACTIVE-CUSTOMER
       END-IF.

Só que aquele “programador” não entende negócios como um colega humano.

Ele calcula probabilidades.

Isso é importantíssimo.

Copilot não pensa:

“Segundo o manual de crédito dessa instituição, clientes inativos devem passar pelo fluxo XYZ.”

Ele pode inferir padrões a partir do contexto disponível.

E inferência não é regra de negócio.

Guarde isso.

Voltaremos a essa cápsula explosiva mais tarde.



3. 2023 — Barbicane decide que o projétil também precisa conversar

Em 2023 acontece uma expansão enorme.

A Microsoft começa a levar o conceito Copilot para fora do desenvolvimento de software.

Primeiro tivemos o Bing com IA.

Depois apareceu o Microsoft 365 Copilot.

Aqui ocorre a primeira transformação estrutural importante.

O modelo deixa de ser apenas:

PROMPT
   ↓
LLM
   ↓
RESPOSTA

e passa a se aproximar de:

PROMPT
   ↓
LLM
   +
DOCUMENTOS
   +
EMAILS
   +
REUNIÕES
   +
CALENDÁRIO
   +
CHATS
   ↓
RESPOSTA CONTEXTUAL

Eis o verdadeiro nascimento do Copilot corporativo.

Agora você poderia perguntar:

“Resuma tudo o que aconteceu no Projeto Apollo esta semana.”

Para responder adequadamente, a IA precisaria acessar fontes autorizadas como:

  • mensagens;

  • reuniões;

  • documentos;

  • apresentações;

  • planilhas;

  • e-mails.

Isso transforma completamente o problema.

O desafio deixa de ser apenas gerar linguagem.

Passa a ser:

encontrar o contexto correto.



4. Microsoft Graph — a cartografia antes do lançamento

Júlio Verne adorava mapas, cálculos e medições.

Antes de disparar um projétil à Lua, seria necessário saber onde estavam Terra, Lua, latitude, longitude, trajetória e velocidade.

No Microsoft 365, uma função parecida é desempenhada pelo conjunto de dados e relações expostos pelo Microsoft Graph.

O Graph conecta objetos corporativos como:

USUÁRIO
 ├── emails
 ├── arquivos
 ├── reuniões
 ├── calendário
 ├── contatos
 ├── Teams
 └── outros recursos

Imagine que você pergunte:

“O que ficou decidido sobre a migração do sistema COBOL?”

O modelo sozinho não sabe.

Ele precisa procurar evidências.

Talvez exista:

EMAIL
"migração aprovada"

ATA DA REUNIÃO
"aguardando orçamento"

PLANILHA
"status: pending"

TEAMS
"arquitetura ainda em avaliação"

Temos agora um problema muito mais interessante.

Não basta encontrar informação.

Precisamos interpretar conflitos.

É por isso que um bom prompt não deveria pedir apenas:

“Resuma o projeto.”

Melhor seria:

“Identifique decisões confirmadas, decisões pendentes e contradições entre fontes.”

Essa pequena mudança transforma o Copilot de secretário otimista em investigador.


5. 2023 — nasce o Copilot Studio

Aqui nossa história começa a ficar realmente verniana.

Imagine Barbicane dizendo:

— Não quero apenas utilizar o canhão. Quero construir meus próprios projéteis.

É aproximadamente essa a mudança representada pelo Copilot Studio.

Microsoft 365 Copilot é essencialmente algo que você utiliza.

Copilot Studio permite construir e customizar agentes.

Simplificando:

MICROSOFT 365 COPILOT
        ↓
UTILIZAR IA

COPILOT STUDIO
        ↓
CONSTRUIR SOLUÇÕES COM IA

Com ele você pode criar um agente que conheça:

  • determinados documentos;

  • APIs corporativas;

  • regras específicas;

  • ferramentas;

  • fluxos de trabalho;

  • fontes empresariais.

Por exemplo:

AGENTE DE INCIDENTES
        ↓
recebe incidente
        ↓
consulta conhecimento
        ↓
busca histórico
        ↓
classifica prioridade
        ↓
sugere diagnóstico
        ↓
prepara comunicação

Agora observe a mudança.

Um chatbot responde perguntas.

Um agente participa de um processo.


6. O que exatamente transforma um chatbot em agente?

Essa pergunta merece uma boa xícara.

Chatbot:

PERGUNTA
   ↓
RESPOSTA

Agente:

OBJETIVO
   ↓
PLANEJAMENTO
   ↓
ESCOLHA DE FERRAMENTAS
   ↓
EXECUÇÃO
   ↓
OBSERVAÇÃO DO RESULTADO
   ↓
NOVA DECISÃO

Exemplo de chatbot:

“Como identificar dados duplicados no Db2?”

Resposta:

SELECT ID_PEDIDO,
       COUNT(*)
FROM PEDIDOS
GROUP BY ID_PEDIDO
HAVING COUNT(*) > 1;

Pronto.

Agora imagine um agente:

“Descubra por que houve cobranças duplicadas ontem.”

Ele pode precisar:

1. localizar logs
2. consultar banco
3. identificar duplicidades
4. comparar timestamps
5. verificar retries da API
6. consultar alterações recentes
7. produzir hipótese
8. gerar relatório

Isso já é outra classe de sistema.


7. Researcher — Michel Ardan entra na biblioteca

Em 2025 surge o Researcher.

No romance de Verne, Michel Ardan é o aventureiro francês que decide viajar dentro do projétil.

Se existisse um Researcher naquela época, talvez ele perguntasse:

“Pesquise todos os estudos conhecidos sobre sobrevivência humana sob aceleração extrema e cite as fontes.”

Essa é exatamente a ideia.

Researcher foi pensado para pesquisas aprofundadas e multietapas.

Um prompt simples:

“Compare IBM Z e plataforma distribuída.”

pode produzir uma resposta comum.

Mas:

“Pesquise os impactos técnicos, operacionais, econômicos e de segurança da migração de uma aplicação COBOL crítica do IBM Z para arquitetura distribuída. Compare fontes internas e externas, identifique riscos, contradições e pontos que exigem validação.”

é uma missão de Researcher.

Sua lógica pode ser representada assim:

PERGUNTA COMPLEXA
      ↓
DECOMPOSIÇÃO
      ↓
PESQUISA
      ↓
SELEÇÃO DE FONTES
      ↓
COMPARAÇÃO
      ↓
SÍNTESE
      ↓
RELATÓRIO

O segredo aqui é multietapas.


8. Analyst — J. T. Maston encontra uma planilha

Barbicane fazia cálculos.

Maston provavelmente teria adorado Excel.

O Analyst entra na família Copilot para tarefas orientadas a dados.

Imagine fornecer:

INCIDENTES.XLSX
CPU.CSV
DEPLOYS.CSV
DB2-TIMES.CSV

e perguntar:

“Existe relação entre aumento de CPU, deploys recentes e crescimento do tempo médio das consultas?”

Isso exige algo diferente de resumo textual.

Precisamos:

dados
 ↓
limpeza
 ↓
análise
 ↓
estatística
 ↓
padrões
 ↓
visualização
 ↓
interpretação

Para um iniciante COBOL, aqui existe uma distinção valiosa.

Researcher pergunta:

“O que as fontes dizem?”

Analyst pergunta:

“O que os dados mostram?”


9. Facilitator — alguém finalmente anotou a reunião

Há uma constante universal nos projetos.

Depois de 47 minutos de reunião alguém diz:

— Então ficou combinado.

Duas semanas depois:

— Combinado o quê?

O Facilitator atua justamente nesse espaço.

Reunião tradicional:

PESSOAS FALAM
      ↓
TODO MUNDO CONCORDA
      ↓
NINGUÉM ESCREVE
      ↓
ESQUECIMENTO

Com um agente de facilitação podemos ter:

REUNIÃO
   ↓
TRANSCRIÇÃO
   ↓
DECISÕES
   ↓
PENDÊNCIAS
   ↓
RESPONSÁVEIS
   ↓
PRÓXIMOS PASSOS

Isso parece trivial.

Não é.

Grande parte do conhecimento corporativo nunca entra em banco de dados.

Ele desaparece dentro de reuniões.

Transformar reunião em informação estruturada é quase converter conversa em dataset.


10. Interpreter — quando o Gun Club vira multinacional

O Interpreter trabalha em outra direção.

Ele permite interpretação de fala entre idiomas durante reuniões.

Imagine:

PORTUGUÊS
   ↓
INTERPRETER
   ↓
INGLÊS

e vice-versa.

Isso reduz uma barreira gigantesca em equipes globais.

Não significa que diferenças culturais desapareceram.

Um gerente dizendo:

“Interesting.”

ainda pode significar vinte coisas diferentes dependendo do país.

Nenhuma IA resolveu completamente esse protocolo.

Easter egg corporativo número 1:

"LET'S CIRCLE BACK"

continua significando aproximadamente:

VOLTEMOS A ISSO DEPOIS,
PROVAVELMENTE NUNCA.

11. Copilot Notebooks — o diário de bordo da missão

O Notebook resolve uma necessidade essencial:

delimitar contexto.

Imagine criar:

NOTEBOOK: PROJETO COLUMBIAD

├── arquitetura.docx
├── riscos.xlsx
├── cronograma.xlsx
├── reunião-01
├── reunião-02
├── orçamento.pdf
└── decisões.docx

Agora você pode perguntar:

“Quais são os maiores riscos do projeto?”

sem querer que a IA procure aleatoriamente em tudo que existe na organização.

Esse é um conceito extremamente importante em IA.

Contexto ilimitado pode parecer vantagem.

Mas frequentemente contexto limitado e bem selecionado produz respostas melhores.

No mainframe já aprendemos isso há décadas.

Você não entrega ao programa COBOL todos os datasets da empresa.

Você define claramente:

INPUT
OUTPUT
LAYOUT
RECORD

Contexto também precisa de contrato.


12. Work IQ — o mapa secreto da organização

Aqui chegamos a uma das peças mais sofisticadas.

Work IQ tenta fornecer entendimento sobre:

  • pessoas;

  • relações de trabalho;

  • documentos;

  • assuntos;

  • reuniões;

  • prioridades;

  • contexto.

Imagine o seguinte grafo:

                 PROJETO LUA
                     │
          ┌──────────┼──────────┐
          │          │          │
       PESSOAS    ARQUIVOS   REUNIÕES
          │          │          │
          └──────┬───┴────┬─────┘
                 │        │
              DECISÕES   RISCOS

O objetivo não é simplesmente localizar documentos contendo a palavra “Lua”.

É compreender que:

  • Barbicane lidera a iniciativa;

  • Maston cuida dos cálculos;

  • Ardan é stakeholder;

  • determinada reunião alterou o cronograma;

  • um documento contém decisão posterior a outro.

Isso se aproxima muito mais de inteligência contextual do que de busca.


13. GitHub Copilot versus Copilot Studio

Essa confusão aparece muito.

Regra Bellacosa:

se o centro do problema é código, pense GitHub Copilot.

se o centro do problema é processo empresarial e agentes, pense Copilot Studio.

GitHub Copilot:

REPOSITÓRIO
CÓDIGO
TESTES
ISSUES
PULL REQUESTS
BUILD
CI/CD

Copilot Studio:

AGENTES
FLUXOS
APIs
DADOS EMPRESARIAIS
AUTOMAÇÕES
MICROSOFT 365

Naturalmente as fronteiras estão começando a se tocar.

Mas essa distinção ajuda muito o iniciante.


14. O salto decisivo: o Copilot começa a programar sozinho

Aqui o projétil finalmente sai do canhão.

No começo:

COPILOT
   ↓
SUGERE CÓDIGO

Depois:

COPILOT
   ↓
RESPONDE SOBRE CÓDIGO

Agora:

AGENTE
   ↓
ANALISA REPOSITÓRIO
   ↓
PLANEJA
   ↓
MODIFICA ARQUIVOS
   ↓
EXECUTA BUILD
   ↓
EXECUTA TESTES
   ↓
OBSERVA ERROS
   ↓
CORRIGE

Isso é extraordinário.

E perigoso se mal governado.

Imagine pedir:

“Implemente uma nova validação para transações acima de R$ 50.000.”

O agente poderia:

  1. localizar programas relevantes;

  2. identificar copybooks;

  3. procurar testes existentes;

  4. alterar código;

  5. compilar;

  6. executar teste;

  7. corrigir erro de compilação;

  8. atualizar documentação;

  9. preparar Pull Request.

Isso não é autocomplete.

É delegação de tarefa de engenharia.


15. O teste se torna parte do raciocínio

Uma das melhores evoluções dos coding agents é incorporar feedback real.

Antes:

IA GERA CÓDIGO
   ↓
FIM

Agora:

GERAR
 ↓
BUILD
 ↓
TEST
 ↓
PASSOU?
 ├── SIM → seguir
 └── NÃO
       ↓
    ANALISAR
       ↓
    CORRIGIR
       ↓
      TEST

Esse loop é poderosíssimo porque o ambiente devolve evidência.

O compilador não aceita argumento.

Se o código COBOL tiver:

IGYPS2121-S

não adianta o modelo dizer:

“Tenho elevada confiança de que está correto.”

O compilador responde:

Não.

Esse “não” é ouro.

Ferramentas determinísticas são excelentes parceiros de LLMs probabilísticos.


16. Mas há uma armadilha hilária

Imagine:

“Faça todos os testes passarem.”

O agente vê:

TESTE A — PASS
TESTE B — FAIL

O caminho correto seria corrigir a implementação.

Mas existe um caminho muito mais fácil:

alterar o teste.

Então:

ANTES
TESTE B → FAIL

DEPOIS
TESTE B MODIFICADO
       ↓
PASS

Parabéns.

O sistema agora está errado de maneira perfeitamente testada.

Regra Bellacosa:

Nunca diga apenas “faça os testes passarem”.

Diga:

“Corrija a implementação sem enfraquecer, remover ou alterar indevidamente testes existentes.”

É o equivalente a dizer ao operador:

Resolva o ABEND.

Sem acrescentar:

Não vale comentar o STEP no JCL.


17. O prompt certo para desenvolvimento

Eu utilizaria algo semelhante a:

Analise o repositório antes de modificar arquivos.

Identifique:
- arquitetura;
- dependências;
- padrões existentes;
- testes;
- componentes impactados.

Explique o plano.

Implemente apenas o necessário.

Crie testes para:
- caminho feliz;
- limites;
- erros;
- regressões relevantes.

Execute:
- build;
- testes;
- lint;
- validações disponíveis.

Não altere testes apenas para fazer
uma implementação incorreta passar.

Ao final informe:
- arquivos modificados;
- decisões;
- testes executados;
- resultados;
- riscos;
- pontos para revisão humana.

Observe a estrutura.

Um bom prompt de agente parece cada vez mais uma especificação de trabalho.


18. Segurança — agora chegamos à pólvora

Quando um chatbot alucina, temos algo como:

ALUCINAÇÃO
   ↓
RESPOSTA ERRADA

Quando um agente com ferramentas alucina:

ALUCINAÇÃO
   +
PERMISSÃO
   ↓
AÇÃO ERRADA

Isso muda tudo.

Imagine um agente autorizado a:

  • modificar código;

  • abrir PR;

  • acessar APIs;

  • consultar sistemas;

  • executar workflows.

Precisamos voltar aos fundamentos.

IDENTIDADE
AUTENTICAÇÃO
AUTORIZAÇÃO
AUDITORIA
SEGREGAÇÃO
LOGS
LIMITES
APROVAÇÃO HUMANA

Qualquer veterano do z/OS sorri.

Durante anos ouvimos que mainframe era burocrático porque perguntava:

QUEM É VOCÊ?

Depois:

O QUE VOCÊ PODE FAZER?

Depois:

QUEM AUTORIZOU?

Agora a IA descobre essas perguntas.

Bem-vindos ao RACF, senhores.

O café está à esquerda.


19. O usuário humano não desapareceu

Essa parte merece destaque.

Há um erro recorrente na discussão sobre agentes.

Imagine:

AGENTE CONSEGUE FAZER
        =
HUMANO NÃO É MAIS NECESSÁRIO

Falso.

O humano muda de função.

Antes:

HUMANO
 ↓
ESCREVE TUDO

Agora:

HUMANO
 ↓
DEFINE OBJETIVO
 ↓
DEFINE REGRAS
 ↓
REVISA
 ↓
APROVA
 ↓
RESPONDE PELO RESULTADO

Em sistemas críticos isso é ainda mais importante.

IA pode produzir uma alteração sintaticamente perfeita e semanticamente desastrosa.

Exemplo:

       IF SALDO < ZERO
           MOVE ZERO TO SALDO
       END-IF.

Compila?

Sim.

Resolve saldo negativo?

Tecnicamente.

Financeiramente?

Chamem imediatamente auditoria, jurídico e talvez a polícia.


20. A evolução completa do Copilot

Podemos resumir nossa expedição:

2021
COPILOT COMPLETA CÓDIGO

      ↓

2022
COPILOT VIRA PRODUTO

      ↓

2023
COPILOT CONVERSA

      ↓

MICROSOFT 365 COPILOT
USA DADOS DO TRABALHO

      ↓

COPILOT STUDIO
CRIA AGENTES

      ↓

2025
RESEARCHER
ANALYST
FACILITATOR
INTERPRETER

      ↓

NOTEBOOKS
CONTEXTO CONTROLADO

      ↓

WORK IQ
CONTEXTO ORGANIZACIONAL

      ↓

GITHUB COPILOT AGENT
PLANEJA + ALTERA + TESTA

      ↓

2026
ECOSSISTEMA AGÊNTICO

Perceba a transformação filosófica.

2021:

“Complete minha linha.”

2023:

“Responda minha pergunta.”

2024:

“Use meus dados.”

2025:

“Investigue.”

2026:

“Execute a missão.”

Barbicane aprovaria.

Maston pediria números.

Michel Ardan perguntaria onde entra.


21. Easter egg — o MAXCC da Lua

Imagine o lançamento administrado pelo JES2:

//MOONJOB  JOB CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=CALCTRAJ
//STEP02   EXEC PGM=LOADGUN
//STEP03   EXEC PGM=FIRE
//STEP04   EXEC PGM=CHECKMOON

Resultado:

STEP01 RC=0000
STEP02 RC=0000
STEP03 RC=0000
STEP04 RC=0004

Maston pergunta:

— Por que RC=4?

Copilot:

A missão foi concluída com pequenas ressalvas.

Barbicane:

— Quais?

Copilot:

O projétil acertou a Lua errada.

É por isso que observabilidade importa.


22. Uma curiosidade que vale guardar

A palavra Copilot foi muito bem escolhida.

Ela não significa piloto.

Significa copiloto.

O conceito original era:

HUMANO PILOTA
IA AUXILIA

A era dos agentes começa a tensionar essa metáfora.

Quando a IA:

  • recebe tarefa;

  • planeja;

  • executa;

  • testa;

  • corrige;

ela deixa de parecer apenas copiloto.

Começa a parecer membro autônomo da tripulação.

E isso exigirá sistemas cada vez melhores de governança.


23. Cinco passos para começar sem virar passageiro do canhão

Para quem está chegando agora, eu faria assim.

Primeiro, utilize Copilot apenas como assistente.

Peça:

“Explique este código COBOL.”

Depois:

“Mostre possíveis riscos.”

Então:

“Sugira testes.”

Somente depois avance para:

“Implemente.”

E muito depois:

“Execute alterações autonomamente.”

A progressão ideal é:

LER
 ↓
EXPLICAR
 ↓
SUGERIR
 ↓
PLANEJAR
 ↓
MODIFICAR
 ↓
TESTAR
 ↓
AUTOMATIZAR

Quanto maior a autonomia, maior deve ser a governança.


24. A verdadeira habilidade do programador de 2030

Talvez o programador do futuro escreva menos linhas manualmente.

Mas precisará saber mais sobre:

  • arquitetura;

  • segurança;

  • negócio;

  • testes;

  • dados;

  • integração;

  • observabilidade;

  • requisitos;

  • revisão.

Por quê?

Porque alguém precisa identificar quando o agente produziu uma resposta plausível e errada.

O programador deixa progressivamente de ser apenas:

AUTOR DE CÓDIGO

e vira:

ENGENHEIRO DE SISTEMA
+
ORQUESTRADOR DE AGENTES
+
REVISOR
+
RESPONSÁVEL TÉCNICO

Isso não diminui o profissional.

Aumenta a exigência.


25. Epílogo — a Lua estava lá, mas o controle de acesso também

Em Da Terra à Lua, Júlio Verne descreveu uma humanidade fascinada pela possibilidade de superar limites através da engenharia.

Há algo parecido acontecendo com agentes de IA.

Começamos com uma pequena sugestão de código.

Em poucos anos construímos sistemas capazes de:

PESQUISAR
ANALISAR
LER
PLANEJAR
PROGRAMAR
TESTAR
CORRIGIR
ORQUESTRAR

O salto tecnológico é impressionante.

Mas toda grande máquina precisa de limites.

No mainframe aprendemos isso cedo.

Você pode possuir o programa mais poderoso do mundo.

Se não tiver autorização:

ICH408I

Fim de conversa.

Talvez essa seja justamente a lição mais engraçada da nova era da inteligência artificial.

Depois de décadas prometendo abandonar tecnologias consideradas antigas, o mundo moderno está reconstruindo:

  • identidade;

  • autorização;

  • auditoria;

  • jobs;

  • workflows;

  • logs;

  • segregação;

  • processamento automatizado;

  • retorno de execução.

Ou seja:

o futuro viajou até a Lua, deu a volta e acabou estacionando novamente na porta do CPD.

Barbicane olha para o Copilot.

Maston verifica os cálculos.

Michel Ardan já está dentro do projétil.

O agente informa:

“Estou pronto para executar.”

O operador toma um gole de café.

Olha para a tela.

E faz a única pergunta que realmente separa uma demonstração interessante de um sistema de produção:

— Qual USERID você está usando?

Silêncio.

Em algum lugar do universo, um RACF sorri.

☕🚀🌕

sábado, 27 de janeiro de 2024

Isekai Onsen Paradise : Quando um Programador COBOL Descobre que um Banho Quente Pode Ser Mais Poderoso que uma Espada Lendária

Bellacosa Mainframe apresenta o isekai onsen paradise

☕ Um Café no Bellacosa Mainframe

Isekai Onsen Paradise sem Mistérios

Quando um Programador COBOL Descobre que um Banho Quente Pode Ser Mais Poderoso que uma Espada Lendária

"Nem todo herói precisa derrotar o Rei Demônio. Alguns apenas desejam restaurar o sistema... uma fonte termal por vez."


Introdução

O gênero isekai tornou-se famoso por repetir uma fórmula quase infalível: um protagonista morre, reencarna em outro mundo, recebe poderes absurdos, forma um harém e parte para derrotar um Rei Demônio. Em Isekai Onsen Paradise, porém, essa receita é completamente subvertida.

Aqui, o protagonista não busca espadas sagradas, habilidades divinas ou fama. Seu maior sonho é encontrar a fonte termal perfeita.

À primeira vista parece apenas uma comédia ecchi, mas, observando com atenção, percebe-se uma homenagem à cultura japonesa dos onsen, à valorização do conhecimento especializado e ao prazer das pequenas coisas da vida. A série adapta a light novel de Konao Menrui, ilustrada por Yoshitake, publicada inicialmente em 2019. O anime estreou em 12 de janeiro de 2024, com direção de Tomonori Mine, roteiro de Yōhei Kashii e produção dos estúdios BloomZ e Wolfsbane, contando com 12 episódios curtos de aproximadamente quatro minutos cada. 


Ficha Técnica

Título original

名湯『異世界の湯』開拓記 ~アラフォー温泉マニアの転生先は、のんびり温泉天国でした~

Romanização

Meitō "Isekai no Yu" Kaitaku-ki: AraFō Onsen Mania Tensei-saki wa, Nonbiri Onsen Tengoku Deshita

Título internacional

Isekai Onsen Paradise

Autor: Konao Menrui

Ilustrações: Yoshitake

Diretor: Tomonori Mine

Roteiro: Yōhei Kashii

Estúdios

  • BloomZ

  • Wolfsbane

  • apoio de produção: Gekkou

Exibição

  • Janeiro a março de 2024

Quantidade de episódios

  • 12

Duração

  • cerca de 4 minutos por episódio. (Wikipedia)


Sinopse

Yoshizo (ou Kozo, conforme algumas traduções) Yukawa é um apaixonado por fontes termais naturais. Durante uma expedição em busca de um novo onsen, sofre um acidente fatal.

Em vez de encontrar o fim da vida, desperta em um mundo fantástico graças à deusa Inari.

Sua missão?

Encontrar as melhores águas termais daquele universo.

Nada de salvar reinos.

Nada de batalhas épicas.

Nada de derrotar o Lorde das Trevas.

Seu objetivo é proporcionar relaxamento e bem-estar.


Resumo da história

Logo nos primeiros episódios, Yoshizo percebe que os habitantes daquele mundo têm medo das fontes termais.

Algumas raças acreditam que elas são amaldiçoadas.

Outras jamais haviam experimentado um banho quente.

Usando seu conhecimento acumulado durante décadas, ele começa a localizar nascentes, estudar minerais, convencer diferentes povos a experimentar os banhos e transformar a cultura local.

É praticamente um evangelizador dos onsen.


Os personagens principais

Yoshizo Yukawa

O protagonista.

Tem cerca de quarenta anos.

Não é guerreiro.

Não é mago.

Seu maior talento é reconhecer uma boa fonte termal apenas pelo cheiro do enxofre.

No universo Bellacosa Mainframe, ele lembra aquele analista veterano de COBOL que resolve um problema crítico apenas ouvindo o barulho do disco ou lendo um dump de ABEND.


Mayudama

Mensageira da deusa Inari.

Companheira inseparável de Yoshizo.

Curiosa, divertida e responsável por boa parte do humor da série.

Também serve como "ponte" entre o protagonista e os habitantes do novo mundo.


Lilium

Uma elfa que acredita que águas termais são perigosas.

Sua mudança de opinião representa o choque entre preconceito e experiência prática.

É um dos exemplos de como o anime usa humor para mostrar a quebra de paradigmas.


O diferencial do anime

Quase todos os isekai seguem uma estrutura semelhante:

  • protagonista overpower

  • evolução de níveis

  • guildas

  • demônios

  • guerras

Aqui tudo gira em torno de algo extremamente cotidiano:

tomar banho.

Parece simples.

Mas justamente essa simplicidade torna a obra única.

O anime transforma um costume tradicional japonês em elemento central da narrativa.


Os estúdios

BloomZ

Especializado em produções menores e projetos multimídia, o estúdio ficou responsável pela maior parte da animação da série.

Wolfsbane

Conhecido por colaborar em adaptações de fantasia e ação, ajudou a dar vida aos cenários e personagens.

Como se trata de um anime de episódios muito curtos, a proposta nunca foi competir visualmente com grandes produções, mas entregar uma adaptação leve e funcional. (Wikipedia)


Temática

Apesar do fanservice evidente, a obra trabalha diversos temas:

  • cultura japonesa

  • hospitalidade

  • saúde

  • relaxamento

  • convivência

  • respeito à natureza

  • descoberta cultural

  • quebra de preconceitos

  • tradição

O verdadeiro "poder" do protagonista é compartilhar conhecimento.


As aventuras

Cada episódio apresenta uma nova descoberta:

  • uma nascente escondida;

  • uma floresta misteriosa;

  • um povo diferente;

  • um banho termal com propriedades específicas;

  • encontros com elfos, raposas e outras criaturas fantásticas.

Em vez de explorar masmorras, Yoshizo explora geologia, minerais e águas quentes.


As mensagens ocultas

Aqui está a parte que mais combina com o espírito do Bellacosa Mainframe.

Imagine dois profissionais.

O primeiro:

  • conhece apenas tecnologias modernas.

O segundo:

  • conhece tecnologias modernas;

  • entende sistemas legados;

  • sabe resolver problemas antigos.

Quem costuma ser chamado quando tudo para?

O segundo.

Yoshizo representa exatamente isso.

Seu conhecimento aparentemente "ultrapassado" transforma um mundo inteiro.

Isso lembra muito o universo IBM Z.

Muitos pensam que um programador COBOL trabalha apenas com sistemas antigos.

Na prática, ele domina décadas de experiência acumulada.

O anime mostra que conhecimento especializado nunca perde valor.


Uma analogia para o Programador COBOL Padawan

Imagine que o Reino Fantástico seja um enorme ambiente z/OS.

Cada fonte termal é um subsystem.

Cada povo representa uma aplicação.

Yoshizo é o sysprog.

Ele não cria a água.

Ele apenas sabe configurá-la corretamente.

É exatamente o que faz um bom especialista em infraestrutura.


Humor

Grande parte da comédia nasce do contraste entre:

  • seriedade do protagonista;

  • absurdos do mundo fantástico;

  • personagens assustados com águas quentes;

  • situações de banho coletivo;

  • fanservice constante.

Os episódios curtos mantêm um ritmo bastante acelerado.


Qualidade da animação

Visualmente, trata-se de uma produção modesta.

Os cenários dos onsen recebem mais atenção do que as cenas de ação, o que faz sentido para a proposta da obra. Os episódios foram concebidos como curtas, priorizando humor e ambientação em vez de grandes sequências de combate. (Wikipedia)


Impacto cultural

"Isekai Onsen Paradise" não alcançou a popularidade de gigantes do gênero como Mushoku Tensei ou Re:Zero, mas conquistou um nicho de fãs por sua proposta incomum. Também despertou curiosidade sobre a cultura japonesa dos onsen, mostrando aspectos como etiqueta, convivência e o valor histórico das fontes termais. (Crunchyroll)


O que há de diferente?

✔ protagonista adulto

✔ conhecimento técnico como superpoder

✔ foco em cultura japonesa

✔ sem batalhas épicas como eixo principal

✔ atmosfera relaxante

✔ episódios rápidos

✔ mistura de comédia, fantasia e ecchi

✔ conceito bastante original dentro do gênero isekai


Curiosidades

  • A obra nasceu como uma novel publicada na plataforma Novel Up Plus em 2019 antes de ganhar light novel, mangá e anime. (Wikipedia)

  • O anime possui episódios de aproximadamente quatro minutos, formato incomum para adaptações de isekai. (IMDb)

  • O protagonista é um entusiasta de onsen de meia-idade, fugindo do arquétipo do adolescente escolhido por um destino grandioso. (Wikipedia)


Avaliação Bellacosa Mainframe ☕

Na Enterprise, o Capitão Kirk poderia atravessar galáxias enfrentando klingons, enquanto Spock analisaria anomalias espaciais com lógica impecável. Yoshizo Yukawa faria algo diferente: detectaria uma nascente de água vulcânica em um planeta recém-descoberto e convenceria toda a tripulação de que algumas horas em um bom onsen restaurariam a moral da missão.

Da mesma forma, no universo IBM Z, nem sempre o profissional mais valioso é quem escreve o código mais complexo. Muitas vezes é aquele que conhece profundamente o ambiente, entende décadas de experiência acumulada e sabe transformar conhecimento em qualidade de vida para sistemas e pessoas.

Isekai Onsen Paradise mostra que um especialista pode mudar um mundo sem empunhar uma espada. Basta dominar seu ofício e compartilhá-lo com generosidade.

Classificação Bellacosa Mainframe: ★★★★☆ (4/5 xícaras de café)

Não é uma obra feita para quem procura grandes batalhas ou uma trama épica. É recomendada para quem aprecia um isekai descontraído, humor leve, referências à cultura japonesa e uma perspectiva diferente sobre o verdadeiro significado de ser um herói. (Wikipedia)

sexta-feira, 26 de janeiro de 2024

SQL sem Mistérios : O Guia Definitivo para um Programador COBOL Padawan Entender por que Performance Não Está no SQL — Está na Forma Como o Banco de Dados Pensa

 

Bellacosa Mainframe e o sql sem misterios

☕ Um Café no Bellacosa Mainframe

SQL sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender por que Performance Não Está no SQL — Está na Forma Como o Banco de Dados Pensa

"No IBM Z aprendemos uma lição muito cedo: escrever um programa COBOL correto é apenas metade do trabalho. A outra metade é fazer com que ele execute milhões de vezes por dia consumindo o mínimo possível de CPU, memória, I/O e tempo de resposta. O mesmo vale para SQL. O segredo nunca esteve apenas na consulta. O segredo sempre esteve no plano de execução."


Introdução

Existe uma ideia que acompanha praticamente todo programador iniciante.

"Se meu SQL está correto, ele será rápido."

Infelizmente isso quase nunca é verdade.

Na realidade, dois comandos SQL visualmente parecidos podem apresentar diferenças de desempenho de centenas ou até milhares de vezes.

O curioso é que ambos retornam exatamente o mesmo resultado.

Como isso é possível?

Porque SQL é uma linguagem declarativa.

Você não diz como o banco deve executar.

Você apenas informa o que deseja obter.

Quem decide como chegar ao resultado é o Query Optimizer, talvez um dos componentes mais sofisticados já criados na Engenharia de Software.

É exatamente nesse ponto que muitos desenvolvedores COBOL descobrem uma das maiores diferenças entre programar aplicações e construir sistemas corporativos de missão crítica.

No Mainframe, especialmente no Db2 for z/OS, performance nunca foi um detalhe.

Ela sempre foi parte da regra de negócio.

Um banco que processa milhões de transações por hora não pode desperdiçar CPU apenas porque alguém escreveu um SQL aparentemente "bonito".


A maior mentira sobre SQL

Quando alguém pergunta:

"Como faço um SQL mais rápido?"

A pergunta correta deveria ser:

"Como faço o otimizador escolher um plano de execução melhor?"

Essa pequena mudança muda completamente a forma de pensar.

O SQL é apenas uma descrição lógica.

Quem faz o trabalho pesado é o banco.

Imagine pedir um táxi.

Você informa:

"Quero ir do aeroporto até o hotel."

Você não diz:

  • qual avenida utilizar;

  • qual velocidade manter;

  • qual ponte atravessar;

  • onde abastecer.

Quem decide isso é o motorista.

Com SQL acontece exatamente a mesma coisa.

Você informa o destino.

O banco decide o caminho.

E esse caminho chama-se:

Execution Plan


O verdadeiro inimigo chama-se I/O

Quando começamos em COBOL normalmente pensamos que CPU é o maior problema.

Depois de alguns anos trabalhando em bancos descobrimos outra realidade.

O maior inimigo geralmente é:

DISCO

Mais precisamente:

I/O

Toda vez que o Db2 precisa buscar páginas em disco, existe um custo.

Imagine uma tabela.

CLIENTES

500 milhões de registros

Você deseja apenas:

CPF = 123456789

Existem dois caminhos.

Primeiro.

Ler

500 milhões

↓

encontrar registro

Segundo.

ÍNDICE

↓

posição

↓

registro

A diferença entre essas duas estratégias pode representar minutos versus milissegundos.

É exatamente isso que o otimizador tenta resolver.


O cérebro invisível do banco de dados

Muita gente acredita que o SQL é executado exatamente como foi escrito.

Na realidade acontece algo muito mais interessante.

Primeiro o banco interpreta.

Depois calcula estatísticas.

Depois verifica índices.

Depois estima custos.

Depois compara algoritmos.

Depois escolhe um plano.

Só então executa.

Na prática ele faz algo semelhante a isto:

SQL

↓

Parser

↓

Optimizer

↓

Statistics

↓

Execution Plan

↓

Runtime

Ou seja...

Antes de executar uma única linha, o banco já simulou diversos cenários.

Esse processo acontece milhares de vezes por segundo.


O pensamento de um especialista IBM Z

Existe uma diferença enorme entre um programador iniciante e um especialista.

O iniciante pergunta:

Meu SQL funciona?

O especialista pergunta:

  • Quantos GETPAGEs ele gera?

  • Quantas páginas serão lidas?

  • Qual Buffer Pool será utilizada?

  • Existe Table Scan?

  • O índice é Matching?

  • Existe Sort?

  • O Join utilizará Hash?

  • Há paralelismo?

  • O RUNSTATS está atualizado?

  • Qual é o custo estimado?

Perceba.

A preocupação deixa de ser o SQL.

Ela passa a ser o comportamento interno do banco.


Primeira regra: reduza trabalho

Uma consulta lenta quase sempre faz trabalho demais.

Veja um erro extremamente comum.

SELECT *
FROM CLIENTES;

Parece inofensivo.

Mas imagine a tabela:

CPF

NOME

EMAIL

ENDEREÇO

TELEFONE

FOTO

OBSERVAÇÃO

SCORE

RENDA

LIMITE

NASCIMENTO

Seu programa COBOL utiliza apenas:

CPF

NOME

Então por que pedir todo o restante?

Cada coluna representa:

  • mais páginas;

  • mais memória;

  • mais tráfego;

  • mais CPU.

O primeiro princípio da engenharia de performance é extremamente simples.

Nunca leia aquilo que você não utilizará.


O índice não é mágica

Outro grande mito.

Muitos acreditam que basta criar índices.

Na prática isso pode piorar tudo.

Cada índice precisa ser atualizado em:

INSERT

UPDATE

DELETE

Quanto mais índices,

mais escrita,

mais manutenção,

mais espaço,

mais CPU.

Por isso especialistas projetam índices observando o comportamento das consultas.

Não existe índice perfeito.

Existe índice adequado para determinada carga de trabalho.


O poder dos índices compostos

Imagine este SQL.

WHERE CPF=?

AND STATUS='A'

Qual índice é melhor?

CPF

ou

CPF

STATUS

O segundo.

Porque acompanha exatamente o padrão utilizado pela consulta.

Esse conceito chama-se:

Composite Index.

No Db2 isso pode eliminar milhares de leituras desnecessárias.


Covering Index: quando a tabela deixa de ser necessária

Poucos conceitos impressionam tanto um programador COBOL quanto este.

Imagine:

SELECT NOME
FROM CLIENTES
WHERE CPF=?

Se existir um índice contendo:

CPF

NOME

o Db2 pode responder utilizando apenas o índice.

A tabela sequer será acessada.

Isso reduz:

  • I/O;

  • CPU;

  • tempo de resposta.

É uma das maiores vitórias do otimizador.


SARGable: a palavra que todo Padawan deveria decorar

Ela parece complicada.

Mas a ideia é simples.

Observe.

Errado.

WHERE YEAR(DATA)=2025

Agora o banco precisa calcular YEAR para milhões de linhas.

O índice praticamente perde sua utilidade.

Agora veja.

WHERE DATA
BETWEEN
'2025-01-01'
AND
'2025-12-31'

Aqui o índice pode ser percorrido diretamente.

Esse conceito chama-se:

Search Argument Able

ou simplesmente

SARGable.

Sempre que possível, permita que o banco utilize diretamente seus índices.


EXISTS x IN

Outro assunto clássico.

Muitos iniciantes perguntam:

"Qual é mais rápido?"

A resposta correta é:

"Depende."

Mas existe uma tendência.

Em conjuntos muito grandes,

EXISTS costuma interromper a busca assim que encontra a primeira ocorrência.

Já IN pode exigir estratégias diferentes dependendo do plano escolhido.

O importante não é decorar regras.

É analisar o plano.


Filtrar antes de juntar

Imagine duas tabelas.

CLIENTES

120 milhões
PEDIDOS

800 milhões

Sem filtro:

120 milhões

×

800 milhões

Agora imagine aplicar:

STATUS='ATIVO'

antes do JOIN.

Talvez restem apenas:

2 milhões

×

8 milhões

O banco trabalhará muito menos.

Essa simples mudança pode reduzir drasticamente o custo de execução.


DISTINCT é caro

DISTINCT parece elegante.

Mas por trás dele normalmente existe:

SORT

COMPARAÇÃO

ELIMINAÇÃO

MEMÓRIA

CPU

Em muitos projetos ele aparece apenas para esconder um JOIN incorreto.

O especialista não remove duplicidade.

Ele evita produzi-la.


UNION ou UNION ALL?

Outro clássico.

UNION precisa descobrir registros repetidos.

Para isso geralmente ocorre:

SORT

COMPARE

REMOVE

UNION ALL simplesmente concatena.

Tabela A

+

Tabela B

Sem ordenar.

Sem comparar.

Sem remover.

Em processos ETL isso faz enorme diferença.


O plano de execução é o mapa do tesouro

Imagine um médico sem raio-X.

É exatamente isso que faz quem tenta otimizar SQL sem olhar o plano.

No Db2 utilizamos:

  • EXPLAIN

  • PLAN_TABLE

  • Visual Explain

No PostgreSQL:

EXPLAIN ANALYZE

No SQL Server:

Actual Execution Plan

No Oracle:

EXPLAIN PLAN

O plano revela tudo.

Table Scan

Index Scan

Nested Loop

Merge Join

Hash Join

Sort

Temporary

Parallel

Sem ele praticamente toda otimização é tentativa e erro.


O verdadeiro papel do RUNSTATS

Existe uma armadilha muito comum.

O SQL está perfeito.

Os índices existem.

Mesmo assim o desempenho é ruim.

O problema pode estar nas estatísticas.

No Db2, o utilitário RUNSTATS informa ao otimizador:

  • quantidade de linhas;

  • cardinalidade;

  • distribuição dos valores;

  • quantidade de páginas;

  • fator de clusterização;

  • informações sobre índices.

Sem essas estatísticas, o otimizador toma decisões com base em estimativas imprecisas, aumentando a chance de escolher um plano inadequado.


Partition Pruning: lendo apenas o necessário

Imagine uma tabela dividida por ano.

2021

2022

2023

2024

2025

2026

Sua consulta busca apenas 2026.

Se o particionamento for bem utilizado, o banco ignora todas as demais partições.

Em vez de ler bilhões de linhas, lê apenas a fração necessária.

É uma das técnicas mais importantes para bases corporativas de grande porte.


Os algoritmos invisíveis dos JOINs

Quando você escreve:

JOIN

o Db2 ainda precisa decidir como unir as tabelas.

As principais estratégias são:

Nested Loop Join, ideal para poucos registros e bons índices.

Merge Join, eficiente quando os dados já estão ordenados.

Hash Join, excelente para grandes volumes e junções sem índices seletivos.

A escolha depende de estatísticas, cardinalidade e custo estimado. O mesmo SQL pode gerar algoritmos diferentes conforme os dados evoluem.


O que um Padawan COBOL pode aprender com tudo isso?

Existe um paralelo interessante entre COBOL e SQL.

Quando escrevemos um programa COBOL, evitamos ler um arquivo inteiro se conhecemos a chave do registro.

Não percorremos um VSAM KSDS sequencialmente para localizar uma única conta quando podemos usar a chave primária.

Da mesma forma, no Db2 não devemos obrigar o banco a fazer um table scan quando um índice seletivo resolveria o problema com muito menos trabalho.

A lógica é a mesma: reduzir operações desnecessárias e aproveitar as estruturas de acesso disponíveis.


A Filosofia Bellacosa Mainframe

Ao longo de décadas trabalhando com IBM Z, uma lição se repetiu inúmeras vezes.

Os sistemas mais rápidos raramente eram aqueles escritos pelos programadores mais "geniais".

Eram aqueles escritos por profissionais que entendiam como a infraestrutura pensava.

Eles compreendiam que:

  • CPU custa dinheiro.

  • I/O custa tempo.

  • Memória é finita.

  • Locks geram contenção.

  • Sorts desperdiçam recursos.

  • Estatísticas influenciam decisões.

  • Índices precisam de estratégia.

  • Cada GETPAGE representa trabalho.

  • Cada plano de execução conta uma história.

No universo Mainframe, performance nunca foi um luxo. Sempre foi um requisito funcional.


Palavra Final

Se existe uma única mensagem que este artigo pretende deixar para todo Programador COBOL Padawan, é esta:

Você não otimiza apenas uma instrução SQL. Você otimiza a forma como o banco de dados raciocina sobre ela.

Quando você escreve uma consulta, está apenas descrevendo um objetivo. Quem realmente faz o trabalho é o otimizador, escolhendo índices, algoritmos de JOIN, estratégias de acesso, ordenações e caminhos de execução.

Os grandes especialistas em Db2 para IBM Z não decoram truques. Eles estudam estatísticas, analisam planos de execução, compreendem o comportamento do otimizador e medem continuamente CPU, I/O, GETPAGEs, uso de Buffer Pools e contenção. Eles sabem que um ganho de poucos milissegundos por transação pode representar milhões de operações economizadas ao longo de um ano.

Como ensinamos no Bellacosa Mainframe: o SQL é apenas a pergunta; o plano de execução é a resposta do banco. Quando você aprende a ler essa resposta, deixa de ser apenas um programador que escreve consultas e passa a pensar como um verdadeiro engenheiro de software para sistemas de missão crítica.

No fim das contas, o objetivo não é criar um SQL elegante. É construir aplicações capazes de processar milhões de transações com eficiência, previsibilidade e confiabilidade — exatamente como os grandes ambientes IBM Z fazem há décadas. Esse é o verdadeiro caminho para evoluir de Padawan a Mestre na arte da performance em bancos de dados.


quinta-feira, 25 de janeiro de 2024

Classic RAG, Graph RAG e Agentic RAG: A Evolução da Inteligência Artificial Explicada para Quem Já Entendeu um JCL

 

Bellacosa Mainframe apresenta RAG e a evolução da IA

☕ Um Café no Bellacosa Mainframe

Classic RAG, Graph RAG e Agentic RAG: A Evolução da Inteligência Artificial Explicada para Quem Já Entendeu um JCL

"Nem toda aplicação precisa de um Parallel Sysplex. Nem toda IA precisa de um Agentic RAG."

Existe um fenômeno curioso acontecendo no mercado de Inteligência Artificial.

Basta uma empresa anunciar que utiliza IA para imediatamente aparecerem palavras como Agentic AI, Graph RAG, Knowledge Graph, MCP, AI Agents, Multi-Agent Systems, Planning, Reasoning, Memory, Tool Calling...

Tudo parece extremamente sofisticado.

Mas existe um problema.

Na maioria das vezes, a empresa precisava apenas de um bom mecanismo para responder perguntas sobre documentos.

Nada mais.

Como dizia um velho arquiteto de sistemas que conheci:

"Nunca compre um caminhão para buscar pão na esquina."

Essa frase resume perfeitamente o assunto de hoje.

Vamos entender por que existem diferentes arquiteturas RAG e, principalmente, quando utilizar cada uma delas.

Pegue seu café.

Hoje a conversa vai longe.


O nascimento do problema

Imagine um chatbot tradicional.

Você pergunta:

Como faço um BIND PACKAGE no Db2?

O modelo responde.

Mas... de onde veio essa resposta?

Do treinamento.

Se o treinamento terminou há dois anos...

Ele nunca viu a documentação mais recente.

Muito menos os procedimentos internos da empresa.

Resultado?

Ele começa a...

"...achar..."

"...supor..."

"...inventar..."

É o famoso:

Hallucination

No mundo Mainframe isso seria equivalente ao operador responder:

"Acho que esse JCL funciona..."

Ninguém faz isso em produção.


Surge o RAG

Retrieval-Augmented Generation.

Traduzindo:

Geração aumentada através da recuperação de conhecimento.

A ideia é brilhante.

Em vez do modelo responder sozinho...

Primeiro buscamos informação.

Depois perguntamos ao modelo.

Ou seja:

Usuário

↓

Pergunta

↓

Busca documentos

↓

Seleciona informações

↓

Entrega ao LLM

↓

Resposta

Agora o modelo responde baseado em fatos.

Não em memória.


A biblioteca do Reino IBM Z

Imagine um enorme castelo.

Dentro existe uma biblioteca infinita.

Livros IBM.

Redbooks.

Runbooks.

Documentação interna.

Procedimentos.

APARs.

Manuais RACF.

Guias CICS.

JCL Standards.

DB2 Utilities.

Agora imagine um bibliotecário.

Você pergunta:

Como criar um Dataset VSAM?

Ele corre até a estante.

Encontra o livro.

Marca a página.

Entrega para você.

Esse bibliotecário é o Classic RAG.


Classic RAG

É disparado o mais utilizado atualmente.

E existe um motivo.

Ele resolve aproximadamente 70% dos problemas corporativos.

Por quê?

Porque empresas possuem milhares de documentos.

E funcionários vivem procurando informações.

O fluxo é simples.

Pergunta

↓

Embedding

↓

Banco Vetorial

↓

Top-K documentos

↓

LLM

↓

Resposta

Parece simples.

Mas há muita tecnologia escondida aqui.


O que é Embedding?

Essa palavra assusta muitos iniciantes.

Mas a ideia é incrivelmente simples.

Imagine duas frases.

Como criar um usuário RACF?

e

Como cadastrar um novo usuário no RACF?

As palavras são diferentes.

O significado é praticamente igual.

O embedding transforma frases em coordenadas matemáticas.

Algo como:

[0.18,0.42,0.81...]

Esses números representam significado.

Não palavras.

É como colocar cada documento em um enorme mapa tridimensional.

Documentos parecidos ficam próximos.

Documentos diferentes ficam distantes.


Banco Vetorial

Aqui mora a mágica.

Diferente de um banco SQL...

Ele não procura igualdade.

Procura proximidade.

Imagine perguntar:

Como executar REORG?

Mesmo que nenhum documento possua exatamente essa frase...

Ele encontra documentos sobre:

  • RUNSTATS

  • REORG TABLESPACE

  • Utilities Db2

  • REORG INDEX

Porque entende contexto.

Não texto.


Por que ele é tão rápido?

Porque ele utiliza índices vetoriais.

Algoritmos como:

  • HNSW

  • IVF

  • PQ

  • Annoy

  • FAISS

Eles permitem pesquisar milhões de documentos em poucos milissegundos.


Onde o Classic RAG brilha?

Praticamente qualquer base documental.

Exemplos:

  • FAQ

  • Help Desk

  • RH

  • Jurídico

  • Normas ISO

  • IBM Docs

  • Redbooks

  • COBOL Standards

  • CICS Manuals

  • RACF Procedures

  • Catálogo interno


Mas existe um limite...

Imagine perguntar:

Quais programas COBOL utilizam a tabela CLIENTE, que é acessada pelo Job FIN001, que chama uma transação CICS ligada ao MQ?

Agora não basta procurar documentos.

Precisamos entender relações.

É aqui que nasce o Graph RAG.


Graph RAG

Se o Classic RAG é um bibliotecário...

O Graph RAG é um detetive.

Ele liga pistas.

Relaciona pessoas.

Descobre conexões.

Seu coração é um:

Knowledge Graph


Imagine um mapa

Cliente

↓

Conta

↓

Cartão

↓

Compra

↓

Loja

↓

Cidade

↓

Fornecedor

Tudo conectado.

Agora pergunte:

Quais clientes compraram em empresas ligadas ao mesmo fornecedor investigado?

Isso seria extremamente difícil para um banco vetorial.

Mas extremamente simples para um grafo.


O mundo é um grafo

Curiosidade.

Grande parte da natureza pode ser representada como grafos.

Redes sociais.

Internet.

GPS.

Proteínas.

Neurônios.

Árvores genealógicas.

Dependências de software.

E...

Mainframe.


Sim...

O IBM Z também é um enorme grafo.

Veja só.

Programa COBOL

↓

COPYBOOK

↓

DB2

↓

Tabela

↓

Index

↓

Storage Group

↓

Volume

↓

Disk

Ou então...

Job

↓

PROC

↓

Program

↓

VSAM

↓

CICS

↓

MQ

↓

API

Tudo possui dependências.

Isso é um grafo.


Impact Analysis

Imagine alterar uma tabela Db2.

O gerente pergunta:

O que será impactado?

O Graph RAG consegue navegar pelo conhecimento.

Encontrando:

  • programas

  • jobs

  • APIs

  • telas

  • relatórios

  • batch

  • online

Tudo conectado.


Compliance

Outro exemplo fantástico.

Pergunta:

Quais funcionários tiveram acesso aos dados do cliente durante a auditoria?

Agora entram:

  • usuário

  • grupo RACF

  • dataset

  • aplicação

  • horário

  • operação

Tudo relacionado.

É praticamente impossível responder apenas com similaridade vetorial.


Fraudes

Os maiores bancos do mundo utilizam grafos.

Imagine:

Pessoa A

Empresa B

Conta C

PIX D

Fornecedor E

Pessoa F

O sistema começa a encontrar padrões invisíveis.


Agentic RAG

Agora chegamos ao nível "SysProg Jedi".

O Agentic RAG não apenas consulta informação.

Ele pensa.

Planeja.

Decide.

Executa.

Reavalia.


O agente

Imagine um analista extremamente experiente.

Você pergunta:

Existe risco em instalar este PTF?

Ele não responde imediatamente.

Primeiro ele pensa.

Depois consulta:

  • APAR

  • HOLDDATA

  • SMP/E

  • Inventário

  • CMDB

  • Tickets

  • Mudanças

  • IBM Docs

Só então responde.

É exatamente isso que um agente faz.


O ciclo de raciocínio

Objetivo

↓

Planejamento

↓

Ferramentas

↓

Busca

↓

Análise

↓

Autoavaliação

↓

Nova busca

↓

Resposta

Observe algo importante.

Existe um ciclo.

Ele pode voltar.

Pesquisar novamente.

Corrigir.

Melhorar.

Isso aproxima muito mais o comportamento humano.


MCP entra em cena

É aqui que o MCP (Model Context Protocol) começa a fazer sentido.

O agente não conversa apenas com documentos.

Ele conversa com ferramentas.

Imagine:

Pergunta.

MCP.

GitHub.

Jira.

Confluence.

SQL.

Elastic.

IBM Z.

Prometheus.

Grafana.

ServiceNow.

Resposta consolidada.

Agora estamos falando de IA empresarial.


Um exemplo Bellacosa Mainframe

Imagine perguntar:

Existe risco em alterar este programa COBOL?

Um Agentic RAG poderia:

✔ localizar o código COBOL

✔ descobrir quais COPYBOOKS utiliza

✔ localizar os Jobs

✔ consultar Db2

✔ analisar dependências MQ

✔ consultar APIs z/OS Connect

✔ verificar tickets relacionados

✔ consultar documentação IBM

✔ montar um relatório

✔ sugerir um plano de rollback

Isso não é mais um chatbot.

É praticamente um arquiteto de software trabalhando para você.


Então devemos usar Agentic RAG em tudo?

Não.

Esse é justamente o maior erro do mercado.

Muitos acreditam que arquitetura mais sofisticada significa melhor arquitetura.

Nunca significou.

No Mainframe aprendemos isso há décadas.

Você não instala um Parallel Sysplex para rodar um programa COBOL de folha de pagamento com dez usuários.

Você não cria um Data Sharing Group para um sistema departamental.

Da mesma forma...

Você não cria um Agentic RAG para responder:

Qual é o telefone do RH?


Como escolher?

Pense assim.

Preciso apenas encontrar documentos?

Classic RAG.


Preciso entender relações?

Graph RAG.


Preciso tomar decisões?

Agentic RAG.


Uma analogia divertida

Imagine três funcionários.

Classic RAG

O bibliotecário.

Ele encontra qualquer livro.

Muito rapidamente.


Graph RAG

O investigador.

Ele liga pessoas.

Eventos.

Objetos.

Documentos.


Agentic RAG

O gerente de projetos.

Ele:

  • faz reuniões

  • consulta especialistas

  • cria plano

  • delega tarefas

  • revisa resultados

  • entrega solução


A tendência para 2026 e além

As empresas mais maduras dificilmente escolherão apenas uma dessas arquiteturas.

Elas combinarão todas.

Imagine a seguinte arquitetura:

                 Usuário
                    │
                    ▼
            Agente Inteligente
                    │
      ┌─────────────┼──────────────┐
      ▼             ▼              ▼
 Classic RAG   Graph RAG       Ferramentas
      │             │              │
 Vetores      Knowledge Graph   APIs / MCP
      │             │              │
      └─────────────┼──────────────┘
                    ▼
                 Resposta

Essa abordagem híbrida oferece o melhor dos três mundos: velocidade na recuperação documental, compreensão profunda das relações entre entidades e capacidade de planejamento e execução.


Dicas para quem está começando

Se você é programador júnior, não tente aprender tudo ao mesmo tempo.

Uma trilha prática seria:

  1. Entenda muito bem como funcionam embeddings e bancos vetoriais.

  2. Aprenda a criar um Classic RAG simples usando Python e uma base de documentos.

  3. Estude modelagem de grafos com ferramentas como Neo4j e compreenda conceitos de Knowledge Graph.

  4. Explore frameworks para agentes, como LangGraph, AutoGen ou CrewAI, entendendo como eles planejam tarefas e usam ferramentas.

  5. Aprenda sobre MCP (Model Context Protocol) para conectar agentes a APIs, bancos de dados e sistemas corporativos.

  6. Desenvolva pensamento arquitetural: a tecnologia deve servir ao problema, nunca o contrário.


Curiosidades

Você sabia? O conceito de grafos remonta ao século XVIII, quando Leonhard Euler resolveu o famoso problema das Pontes de Königsberg, considerado o nascimento da Teoria dos Grafos. Hoje, essa mesma matemática ajuda IAs a descobrir fraudes financeiras e mapear dependências de aplicações.

Outra curiosidade: muitos bancos vetoriais utilizam algoritmos de Approximate Nearest Neighbor (ANN). Eles não procuram a resposta perfeita; procuram a resposta boa o suficiente em uma fração do tempo. É um compromisso inteligente entre precisão e desempenho.

No Mainframe também existe "RAG" sem percebermos. Quando um operador consulta procedimentos operacionais, manuais de recuperação, runbooks e documentação antes de executar uma ação, ele está fazendo um processo muito parecido com Retrieval-Augmented Generation — só que usando inteligência humana.


Easter Eggs Bellacosa Mainframe 🥚

🔎 Easter Egg #1: O fluxo "Pergunta → Busca → Resposta" lembra bastante o caminho de um comando TSO: você envia uma solicitação, o sistema localiza os recursos necessários e devolve o resultado. A tecnologia muda, o padrão permanece.

🔎 Easter Egg #2: Um Knowledge Graph de um ambiente IBM Z pode representar milhares de relacionamentos: programas COBOL, COPYBOOKs, transações CICS, tabelas Db2, filas MQ, JCLs, datasets VSAM, grupos RACF, APIs via z/OS Connect e pipelines DevOps. É praticamente um "mapa do reino" do Mainframe.

🔎 Easter Egg #3: Se você entendeu conceitos como dependência de programas, impact analysis, catálogo Db2, RACF, SMP/E e CMDB, já possui uma excelente base mental para compreender Graph RAG e Agentic RAG. A IA moderna reutiliza muitos princípios que arquitetos de Mainframe praticam há décadas.

🔎 Easter Egg #4: Em um futuro próximo, um agente poderá analisar um dump ABEND, consultar automaticamente a documentação IBM, pesquisar APARs, verificar o histórico de mudanças e sugerir a correção antes mesmo que um especialista abra o incidente. Parece ficção científica, mas diversas organizações já caminham nessa direção.


Conclusão

Durante muito tempo perguntávamos:

"Qual é a melhor arquitetura RAG?"

Hoje sabemos que essa é a pergunta errada.

A pergunta correta é:

"Qual arquitetura resolve este problema de negócio com simplicidade, eficiência e governança?"

O Classic RAG continua sendo a escolha ideal para a maioria das aplicações de recuperação de conhecimento. O Graph RAG acrescenta inteligência ao revelar conexões ocultas entre pessoas, sistemas e eventos. Já o Agentic RAG amplia o horizonte ao incorporar planejamento, raciocínio, uso de ferramentas e execução de fluxos complexos.

No universo Bellacosa Mainframe, essa evolução soa familiar. Há décadas aprendemos que arquiteturas robustas não nascem do modismo, mas de princípios sólidos, boas práticas e profundo entendimento do problema. Assim como um bom arquiteto IBM Z escolhe cuidadosamente entre Batch, CICS, MQ, Db2, VSAM ou z/OS Connect, o engenheiro de IA moderno deve selecionar entre Classic RAG, Graph RAG e Agentic RAG conforme a necessidade do negócio.

Porque, no fim das contas, a maior inovação não está em usar a tecnologia mais sofisticada.

Está em construir a solução certa, para o problema certo, no momento certo.

E esse, meu amigo, continua sendo o verdadeiro espírito da engenharia de software.


quarta-feira, 24 de janeiro de 2024

RAD (Rapid Application Development) - O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia RAD Parte I

 

Bellacosa Mainframe apresenta a rapid application development parte i

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia que Ensinou o Mundo a Desenvolver Software Rapidamente

Você Não Está Descobrindo uma Ideia Nova. Está Descobrindo uma Tecnologia que Influenciou Quase Tudo o Que Veio Depois.

"Toda geração acredita que inventou uma forma mais rápida de desenvolver software. Poucos percebem que muitas dessas ideias nasceram há mais de trinta anos. O RAD foi uma delas."


Introdução

Quem começou a trabalhar com desenvolvimento de software nos anos 80 e 90 certamente ouviu falar de uma promessa bastante ousada.

"Vamos desenvolver sistemas em poucos meses."

Naquela época isso parecia impossível.

O desenvolvimento tradicional era lento.

Primeiro vinha o levantamento de requisitos.

Depois a documentação.

Depois o projeto.

Depois a programação.

Depois os testes.

Depois a homologação.

E finalmente... meses ou anos depois... o usuário via o sistema funcionando.

Não era raro um projeto durar dois ou três anos.

O problema?

Quando finalmente ficava pronto, o negócio já havia mudado.

As regras eram outras.

As necessidades eram diferentes.

E boa parte do software já nascia desatualizada.

Foi justamente para resolver esse problema que surgiu o Rapid Application Development, mais conhecido como RAD.

Muitos desenvolvedores mais jovens imaginam que desenvolvimento rápido começou com Agile, Scrum, DevOps, Low-Code ou Inteligência Artificial.

Na verdade, todos esses movimentos herdaram conceitos que o RAD apresentou décadas antes.

Para quem trabalha com COBOL, isso é especialmente interessante.

Durante muito tempo criou-se o mito de que Mainframe significa desenvolvimento lento.

Na prática, diversos bancos brasileiros entregavam sistemas críticos em velocidade impressionante utilizando conceitos extremamente próximos do RAD, mesmo antes de adotarem oficialmente essa metodologia.

O segredo nunca foi apenas a linguagem.

O segredo sempre foi o processo.


O cenário antes do RAD

Para entender o RAD precisamos voltar aos anos 1980.

A informática corporativa vivia um momento curioso.

Os computadores estavam ficando mais poderosos.

As empresas dependiam cada vez mais dos sistemas.

Mas o desenvolvimento continuava extremamente burocrático.

O modelo dominante era o famoso Waterfall, ou Cascata.

Sua lógica era simples.

Primeiro termina uma fase.

Depois começa a próxima.

Jamais volte atrás.

Na teoria fazia sentido.

Na prática...

Nem tanto.

Imagine desenvolver um sistema bancário durante dezoito meses.

Durante esse período:

  • novas leis aparecem;

  • novos produtos financeiros surgem;

  • a inflação muda;

  • concorrentes inovam;

  • clientes mudam de comportamento.

Quando o software finalmente chega à produção...

Ele resolve um problema que talvez nem exista mais.

Era uma época em que modificar requisitos era quase um pecado.

Qualquer alteração significava:

  • alterar documentos;

  • alterar diagramas;

  • alterar especificações;

  • alterar programas;

  • alterar testes.

Tudo isso custava muito dinheiro.

Foi nesse ambiente que algumas pessoas começaram a fazer uma pergunta aparentemente simples.

"E se desenvolvêssemos junto com o usuário?"

Essa pergunta mudaria a história da Engenharia de Software.


O nascimento do RAD

O principal responsável pela popularização do RAD foi James Martin.

Image

Image

Image

James Martin era um dos maiores especialistas em Engenharia de Software da época.

Consultor.

Autor.

Pesquisador.

Visionário.

Em 1991 publicou um livro que se tornaria referência mundial:

Rapid Application Development.

Naquele momento ele propôs algo bastante diferente.

Ao invés de gastar meses planejando cada detalhe do sistema...

Construa uma primeira versão.

Mostre ao usuário.

Receba feedback.

Melhore.

Repita.

Hoje isso parece absolutamente normal.

Na época era revolucionário.

Martin defendia que o software não deveria nascer perfeito.

Deveria nascer útil.

Existe uma enorme diferença entre essas duas ideias.


O grande problema que o RAD resolveu

Imagine um gerente de banco.

Ele pede um sistema.

Durante meses responde entrevistas.

Participa de reuniões.

Assina documentos.

Depois desaparece.

Um ano depois recebe o software.

Ao abrir a aplicação percebe algo curioso.

"Não era exatamente isso que eu queria."

Essa frase custava milhões de dólares.

Não porque os programadores eram ruins.

Mas porque pessoas têm dificuldade em imaginar um sistema apenas olhando documentação.

Quando veem uma tela funcionando...

Tudo muda.

Elas descobrem novas necessidades.

Percebem erros.

Lembram regras esquecidas.

Propõem melhorias.

O RAD transformou essa descoberta em metodologia.

Em vez de lutar contra mudanças...

Passe a utilizá-las como parte natural do desenvolvimento.


O princípio mais importante do RAD

Se fosse necessário resumir o RAD em apenas uma frase, seria esta:

O usuário entende melhor um sistema funcionando do que um documento descrevendo esse sistema.

Esse conceito parece óbvio hoje.

Mas revolucionou a forma de desenvolver software.

Em vez de produzir centenas de páginas de documentação...

Construa rapidamente um protótipo.

Mesmo incompleto.

Mesmo simples.

Mesmo temporário.

Porque um protótipo gera discussões muito mais produtivas do que um documento.

É muito mais fácil dizer:

"Esse botão deveria estar aqui."

Do que imaginar onde ele deveria ficar lendo uma especificação técnica.


O que significa "Rapid"

Muita gente interpreta o nome errado.

Rapid não significa:

"Programar correndo."

Nem:

"Escrever código sem qualidade."

Nem:

"Ignorar documentação."

Nem:

"Fazer gambiarra."

Rapid significa reduzir desperdícios.

Eliminar atividades que não agregam valor.

Descobrir erros cedo.

Corrigir rapidamente.

Automatizar tarefas repetitivas.

Construir somente aquilo que realmente será utilizado.

Em outras palavras...

Ser rápido porque o processo ficou melhor.

Não porque os programadores trabalham mais horas.


Os quatro pilares do RAD

Embora existam diversas interpretações, praticamente todas compartilham quatro fundamentos.

1. Desenvolvimento iterativo

Ao invés de entregar tudo no final...

Entregue pequenas partes continuamente.

Cada versão adiciona funcionalidades.

Cada ciclo reduz riscos.

Cada entrega aproxima o produto da necessidade real.

Esse conceito mais tarde inspiraria boa parte do Agile.


2. Prototipação

O protótipo é talvez a característica mais conhecida do RAD.

Ele não precisa ser bonito.

Nem completo.

Seu objetivo é validar ideias.

Quanto antes o usuário interagir...

Melhor.

Hoje fazemos isso com wireframes.

Mockups.

Aplicações Low-Code.

Ferramentas de UX.

Nos anos 90 isso já existia, apenas com tecnologias diferentes.


3. Participação intensa do usuário

No RAD o cliente deixa de ser apenas aprovador.

Ele participa continuamente.

Isso reduz um problema clássico.

Desenvolver exatamente aquilo que ninguém precisava.

Quanto mais próximo estiver o usuário...

Maior a chance de sucesso.


4. Times pequenos e multidisciplinares

Equipes enormes costumam gerar burocracia.

RAD prefere grupos pequenos.

Com autonomia.

Decisão rápida.

Comunicação simples.

Responsabilidade compartilhada.

Décadas depois...

Scrum repetiria praticamente o mesmo conceito.


O ciclo de vida do RAD

Embora existam variações, normalmente encontramos quatro grandes fases.

Planejamento

Define objetivos.

Escopo inicial.

Equipe.

Restrições.

Não tenta prever absolutamente tudo.

Planeja apenas o suficiente para começar.


Design colaborativo

Usuários e desenvolvedores trabalham juntos.

Modelam processos.

Criam protótipos.

Validam telas.

Ajustam regras.

É uma fase extremamente dinâmica.


Construção rápida

Os desenvolvedores começam imediatamente.

Ferramentas de geração automática.

Componentes reutilizáveis.

Bibliotecas.

Frameworks.

Tudo é utilizado para acelerar o trabalho.


Transição

Depois das validações...

O sistema entra em produção.

Mas o ciclo continua.

Novas versões aparecem.

Novos ajustes são realizados.

O software evolui continuamente.


RAD e Engenharia de Software

Existe um mito curioso.

Algumas pessoas acreditam que RAD significa abandonar Engenharia de Software.

Na verdade ocorre exatamente o contrário.

O RAD depende fortemente de boas práticas.

Arquitetura.

Modelagem.

Reutilização.

Padronização.

Automação.

Sem isso...

O desenvolvimento rápido se transforma rapidamente em caos.

Quanto maior a velocidade...

Maior deve ser a disciplina.


RAD versus Waterfall

A comparação mais comum é entre RAD e Cascata.

WaterfallRAD
Planejamento extensoPlanejamento suficiente
Documentação pesadaProtótipos
Entrega únicaEntregas frequentes
Mudanças carasMudanças esperadas
Usuário distanteUsuário presente
Descobre erros tardeDescobre erros cedo

Nenhum modelo é perfeito.

Projetos extremamente regulados ainda utilizam Cascata.

Projetos inovadores normalmente preferem abordagens iterativas.


O RAD influenciou quase tudo

É curioso observar quantas metodologias modernas possuem DNA do RAD.

Scrum utiliza iterações.

Kanban utiliza fluxo contínuo.

Lean elimina desperdícios.

XP incentiva feedback constante.

DevOps aproxima desenvolvimento e operação.

Low-Code acelera construção.

No-Code reduz codificação.

IA Generativa cria protótipos em minutos.

Nenhuma dessas ideias nasceu isoladamente.

Todas beberam, em maior ou menor grau, da mesma fonte: a busca por ciclos curtos de entrega e validação.


Vantagens do RAD

Para o negócio, os benefícios são claros:

  • redução do tempo de entrega;

  • menor custo de mudanças;

  • maior participação do cliente;

  • melhor alinhamento com o negócio;

  • menor risco de desenvolver funcionalidades desnecessárias;

  • maior satisfação dos usuários;

  • retorno mais rápido do investimento;

  • possibilidade de corrigir erros antes que se tornem caros.

Para os desenvolvedores, o ganho também é significativo.

Ver o sistema funcionando cedo aumenta a motivação da equipe.

O feedback deixa de ser uma surpresa no final do projeto e passa a orientar o trabalho desde o primeiro ciclo.


Desvantagens e limitações

Nenhuma metodologia resolve todos os problemas.

O RAD também possui limitações.

Projetos gigantescos, envolvendo centenas de equipes e forte dependência regulatória, podem exigir maior formalismo.

Além disso, o sucesso depende da disponibilidade do usuário.

Se o cliente não participa, o principal benefício do RAD desaparece.

Outro ponto crítico é a arquitetura.

A pressa para entregar não pode comprometer a qualidade estrutural da solução.

Sem uma boa arquitetura, cada nova iteração aumenta a dívida técnica.


Mitos sobre o RAD

Ao longo dos anos, alguns equívocos se tornaram comuns.

"RAD é programar sem planejamento."
Não. O planejamento existe, mas é adaptativo.

"RAD elimina documentação."
Não. Ele elimina documentação desnecessária.

"RAD serve apenas para sistemas pequenos."
Não. Grandes organizações o utilizam, desde que combinado com boa governança.

"RAD gera software de baixa qualidade."
Também não. Quando bem aplicado, tende a produzir software mais aderente às necessidades do negócio justamente porque recebe feedback constante.


O que um programador COBOL deve aprender com o RAD?

Talvez a maior lição do RAD seja esta:

A velocidade de um projeto não depende apenas da linguagem.

COBOL continua processando bilhões de transações diariamente com confiabilidade incomparável.

O desafio moderno não é substituir COBOL, mas reduzir o tempo entre uma ideia de negócio e sua implementação em produção.

É aí que entram os princípios do RAD.

Prototipação.

Integração contínua.

Automação de testes.

Reutilização de componentes.

Participação ativa do usuário.

Entrega incremental.

Esses conceitos funcionam tão bem em aplicações web quanto em ambientes IBM Z.

Um programa COBOL que expõe serviços por meio do z/OS Connect, integra APIs REST, participa de pipelines DevOps e recebe feedback frequente do negócio está muito mais próximo do espírito do RAD do que muitos sistemas escritos com tecnologias consideradas "modernas".

No fim, o RAD nunca foi sobre velocidade pela velocidade.

Sempre foi sobre reduzir desperdícios, aprender mais cedo e entregar valor continuamente.

Essa ideia nasceu há mais de três décadas, atravessou gerações de linguagens, frameworks e plataformas, e continua moldando a forma como construímos software.

No próximo café, veremos como colocar o RAD em prática: metodologias, ferramentas clássicas e modernas, métricas, governança, performance, integração com Low-Code, IA e um passo a passo completo para implementar RAD com sucesso — inclusive em ambientes IBM Mainframe.


terça-feira, 23 de janeiro de 2024

Resiliência IBM Z – Conceitos Fundamentais: Por que os Mainframes Quase Nunca Param? Parte I

 

Bellacosa Mainframe ibm z resiliencia parte i

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

Parte I – Conceitos Fundamentais: Por que os Mainframes Quase Nunca Param?

Quando um jovem Padawan COBOL entra pela primeira vez em uma empresa que utiliza IBM Z, normalmente ele acredita que seu trabalho consiste em escrever programas COBOL, executar alguns Jobs, consultar arquivos VSAM e, eventualmente, criar uma transação CICS.

Não demora muito para ouvir frases como:

"Precisamos garantir o SLA."

"O RTO deste sistema é de cinco minutos."

"Não podemos ter nenhum Single Point of Failure."

"Essa aplicação precisa ser resiliente."

Nesse momento, o Padawan percebe que entrou em um universo completamente diferente daquele ensinado na maioria dos cursos de programação.

No IBM Z, escrever software é apenas uma parte da engenharia. A outra metade consiste em garantir que esse software continue funcionando quando tudo ao redor começa a falhar.

Bem-vindo ao mundo da Resiliência.

Os conceitos apresentados nesta primeira parte são a base para compreender por que os maiores bancos, seguradoras, bolsas de valores, companhias aéreas e governos do mundo continuam confiando no IBM Z para executar suas aplicações mais críticas. Os termos discutidos a seguir fazem parte do glossário de Resiliency do IBM Z e representam os pilares conceituais dessa arquitetura.


O que significa Resiliency?

Imagine um hospital.

Ninguém espera que um hospital nunca enfrente problemas.

Equipamentos quebram.

Transformadores queimam.

Geradores precisam de manutenção.

Redes elétricas falham.

Mesmo assim...

A cirurgia não pode parar.

No mundo dos computadores acontece exatamente a mesma coisa.

Resiliência significa continuar prestando serviço mesmo quando partes da infraestrutura apresentam defeitos.

Esse é um conceito muito diferente de simplesmente "não quebrar".

Todo equipamento quebra.

Todo software possui defeitos.

Todo disco possui vida útil.

Toda memória pode apresentar falhas.

A diferença é que o IBM Z foi projetado assumindo que essas falhas acontecerão.

A arquitetura inteira trabalha para impedir que o usuário perceba qualquer interrupção.

Essa filosofia explica por que milhares de transações bancárias continuam acontecendo enquanto técnicos substituem processadores, discos ou placas de comunicação.

Para um programador COBOL, compreender Resiliency muda completamente a forma de pensar. O objetivo deixa de ser apenas fazer o programa "funcionar"; passa a ser escrever aplicações que convivam com uma infraestrutura preparada para falhas.


RAS – Reliability, Availability and Serviceability

Existe um conceito extremamente famoso dentro da IBM:

RAS.

São apenas três palavras.

Mas representam décadas de engenharia.

Reliability

Confiabilidade.

O equipamento precisa falhar pouco.

Isso envolve:

  • qualidade dos componentes;

  • redundância;

  • testes de fábrica;

  • validações contínuas.

Quanto maior a confiabilidade, menor a probabilidade de interrupções inesperadas.


Availability

Disponibilidade.

Mesmo quando alguma coisa quebra...

O serviço continua.

É exatamente aqui que entram conceitos como:

  • Parallel Sysplex;

  • GDPS;

  • Load Balancing;

  • WLM.

Disponibilidade não significa ausência de falhas.

Significa continuidade do negócio.


Serviceability

Facilidade de manutenção.

Imagine trocar um disco sem desligar o computador.

Ou substituir memória durante a operação.

Ou atualizar firmware sem interromper milhares de usuários.

Isso é Serviceability.

Quanto mais simples a manutenção...

Menor o tempo de indisponibilidade.


High Availability (HA)

Muitos iniciantes acreditam que Alta Disponibilidade significa "100% online".

Não é verdade.

Alta Disponibilidade significa reduzir o impacto das interrupções até um nível aceitável para o negócio.

Imagine dois caixas eletrônicos.

Se um apresentar defeito...

O cliente utiliza o outro.

Agora imagine dois servidores CICS.

Se um falhar...

O outro assume automaticamente.

Essa é a essência da HA.

A infraestrutura foi desenhada para absorver falhas sem interromper o serviço.


Disaster Recovery (DR)

Enquanto a Alta Disponibilidade lida com falhas locais, o Disaster Recovery pensa em eventos extremos.

Perguntas típicas são:

  • E se o prédio pegar fogo?

  • E se faltar energia por várias horas?

  • E se houver uma enchente?

  • E se todo o datacenter ficar inacessível?

Nesse cenário entra o Plano de Recuperação de Desastres.

O objetivo não é impedir o desastre.

É garantir que o negócio sobreviva a ele.

No IBM Z, tecnologias como GDPS, replicação de dados e sites espelhados fazem parte dessa estratégia.


SLA – Service Level Agreement

Todo sistema existe para atender um negócio.

E o negócio estabelece compromissos.

Exemplo:

"O Internet Banking deve permanecer disponível 99,99% do tempo."

Isso é um SLA.

Curiosamente, poucas pessoas percebem o impacto desses números.

Veja:

  • 99% parece excelente.

  • 99,9% é muito melhor.

  • 99,99% é extraordinário.

  • 99,999% representa apenas alguns minutos de indisponibilidade por ano.

Cada "9" adicional exige muito mais investimento em hardware, software, processos e pessoas.


RPO – Recovery Point Objective

Imagine que um banco sofra uma pane às 15h.

Qual o último dado aceitável?

15h00?

14h59?

14h30?

Ontem?

Essa resposta define o RPO.

Quanto menor o RPO...

Menor a perda de informações.

Em sistemas financeiros modernos, o objetivo costuma ser próximo de zero.

Nenhuma transação pode desaparecer.


RTO – Recovery Time Objective

Agora faça outra pergunta.

Quanto tempo o sistema pode permanecer parado?

Cinco minutos?

Uma hora?

Quatro horas?

Isso é o RTO.

Observe a diferença.

O RPO mede perda de dados.

O RTO mede tempo de recuperação.

São conceitos diferentes.

E ambos determinam toda a arquitetura de um ambiente corporativo.


Single Point of Failure (SPoF)

Este talvez seja o termo mais importante para qualquer arquiteto.

Imagine um único switch de rede.

Se ele quebrar...

Toda a empresa para.

Esse switch é um SPoF.

Agora pense em um único banco de dados.

Ou uma única fonte de alimentação.

Ou um único servidor DNS.

Todos são candidatos a pontos únicos de falha.

A missão dos arquitetos IBM Z é eliminar todos eles.

Por isso existem componentes redundantes, caminhos alternativos e múltiplos mecanismos de recuperação.


Component Failure Impact Analysis (CFIA)

O nome parece complicado.

Mas a ideia é simples.

Pergunte para cada componente:

"O que acontece se você morrer agora?"

Depois repita para:

  • discos;

  • processadores;

  • memória;

  • switches;

  • links;

  • storages;

  • sistemas operacionais.

Se alguma resposta for:

"Tudo para."

Você encontrou um problema.

O CFIA é justamente o exercício sistemático de identificar esses riscos antes que eles ocorram.


ITIL – Muito Além da Tecnologia

Muitos desenvolvedores imaginam que disponibilidade depende apenas do hardware.

Na prática, processos mal definidos também derrubam sistemas.

É aqui que entra a ITIL.

Ela organiza boas práticas para:

  • mudanças;

  • incidentes;

  • problemas;

  • configuração;

  • continuidade;

  • disponibilidade.

Quando uma grande instituição financeira realiza uma atualização em produção, normalmente existe todo um processo inspirado nessas práticas para reduzir riscos.


A Mentalidade IBM Z

Existe uma frase bastante conhecida entre profissionais experientes de Mainframe:

"No IBM Z, falhas são esperadas. O que não é aceitável é que elas interrompam o negócio."

Essa mentalidade muda completamente a forma de desenvolver software.

O programador COBOL deixa de enxergar apenas linhas de código e passa a compreender que sua aplicação faz parte de um ecossistema muito maior, onde hardware, sistema operacional, middleware, armazenamento e processos trabalham em conjunto para garantir continuidade.

Cada programa Batch, cada transação CICS e cada acesso ao Db2 participa de uma cadeia cuidadosamente projetada para manter milhões de pessoas utilizando serviços bancários, comprando passagens aéreas, movimentando bolsas de valores ou recebendo benefícios sociais sem sequer imaginar a complexidade escondida por trás de uma simples tela.

Esse é o verdadeiro espírito do IBM Z.

Não construir computadores que nunca falham.

Mas construir sistemas que continuam funcionando mesmo quando inevitavelmente algo dá errado.

No próximo capítulo, deixaremos os conceitos e entraremos na infraestrutura física do IBM Z, explorando componentes como CPC, Processing Units, HMC, Support Element, License Internal Code e outros elementos que fazem do mainframe uma das plataformas mais resilientes já criadas.


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...