Translate

terça-feira, 30 de junho de 2026

Agentic Data Intelligence no IBM watsonx.data intelligence: Quando a Inteligência Artificial Descobre que Dados Sem Contexto São Apenas Bits Perdidos

 

Bellacosa Mainframe introduz o agentic data intelligence no ibm watsonx

☕ Um Café no Bellacosa Mainframe

Agentic Data Intelligence no IBM watsonx.data intelligence: Quando a Inteligência Artificial Descobre que Dados Sem Contexto São Apenas Bits Perdidos

Como um Programador COBOL Padawan Pode Entender a Próxima Grande Revolução da Inteligência Artificial Corporativa

Durante muito tempo, ouvimos que a Inteligência Artificial iria substituir programadores.

Depois disseram que bastava conectar um LLM (Large Language Model) ao banco de dados da empresa e todos os problemas estariam resolvidos.

Hoje sabemos que nenhuma dessas ideias estava completamente correta.

O verdadeiro desafio nunca foi fazer a IA "ler" dados.

O desafio sempre foi fazer a IA entender o significado daqueles dados.

Essa diferença parece pequena.

Na prática, ela separa uma IA que apenas gera respostas bonitas de uma IA capaz de trabalhar como um verdadeiro analista de negócios.

É exatamente esse o objetivo do novo Agentic Data Intelligence, incorporado ao IBM watsonx.data intelligence.

Para quem trabalha com IBM Z, COBOL, CICS, DB2, VSAM ou IMS, esse assunto é muito mais importante do que parece. Na realidade, ele conversa diretamente com um problema que todo programador experiente já enfrentou: como descobrir o impacto de uma mudança em um sistema gigantesco criado ao longo de décadas?

Pegue sua caneca de café.

Hoje vamos conversar sobre uma das tecnologias que provavelmente fará parte do futuro do desenvolvimento em Mainframe.


O maior problema da IA nunca foi inteligência

Imagine que amanhã você seja contratado por um grande banco.

No primeiro dia, entregam seu usuário RACF.

Você recebe acesso ao:

  • TSO/ISPF

  • SDSF

  • DB2

  • CICS

  • JCL

  • dezenas de bibliotecas PDS

  • milhares de programas COBOL

Você consegue abrir qualquer programa.

Consegue consultar tabelas.

Consegue executar jobs.

Mas consegue entender o sistema?

Claro que não.

Você não sabe:

  • qual tabela é oficial;

  • qual copybook está obsoleto;

  • qual campo representa uma regra de negócio;

  • quem é o responsável por determinado cadastro;

  • quais programas utilizam aquele arquivo VSAM;

  • quais APIs dependem daquele campo.

Agora imagine uma Inteligência Artificial.

Ela sofre exatamente do mesmo problema.

Ela consegue acessar dados.

Mas não conhece a empresa.


Dados não são conhecimento

Essa talvez seja a primeira grande lição deste artigo.

Existe uma enorme diferença entre:

Dados

e

Conhecimento Corporativo.

Por exemplo:

CLIENTE.STATUS = "A"

Para você isso significa o quê?

Nada.

Agora imagine que o glossário da empresa define:

"A = Cliente Ativo"

Já faz sentido.

Mas e se outra empresa definir:

"A = Cliente Aposentado"

Ou ainda:

"A = Cliente de Alto Valor"

Percebe?

O dado é exatamente igual.

O significado muda completamente.

É isso que chamamos de contexto.


O que é o IBM watsonx.data intelligence?

Pense nele como um enorme cérebro corporativo.

Ele não guarda apenas tabelas.

Ele guarda conhecimento sobre essas tabelas.

Ele sabe:

  • quem criou;

  • quem mantém;

  • quem utiliza;

  • quais sistemas dependem;

  • de onde vieram os dados;

  • quais regras foram aplicadas;

  • qual o nível de qualidade;

  • quais políticas de segurança existem.

Em outras palavras...

Ele transforma metadados em conhecimento utilizável.


Fazendo uma analogia com o Mainframe

Todo ambiente z/OS possui diversos "cérebros invisíveis".

Por exemplo:

  • ICF Catalog

  • RACF

  • SYS1.PARMLIB

  • PROCLIB

  • SMS

  • JES2

Nenhum deles processa transações bancárias.

Mesmo assim...

sem eles o banco simplesmente para.

O watsonx.data intelligence exerce um papel semelhante.

Ele não substitui o DB2.

Nem o VSAM.

Nem o IMS.

Ele explica para a IA como interpretar tudo isso.


Como funciona o Agentic Data Intelligence?

Vamos imaginar um fluxo simples.

Um usuário pergunta:

"Quais clientes Premium tiveram queda no faturamento este mês?"

Uma IA tradicional faria algo parecido com isto:

Pergunta

↓

Procura tabelas

↓

Executa SQL

↓

Entrega resposta

Parece bom.

Mas há vários riscos.

Ela pode consultar:

  • tabela errada;

  • coluna desatualizada;

  • dados duplicados;

  • informações sem governança.

Agora veja o novo fluxo.

Pergunta

↓

Consulta o catálogo corporativo

↓

Verifica definições de negócio

↓

Consulta Data Lineage

↓

Verifica políticas

↓

Avalia qualidade

↓

Gera resposta

É um processo muito mais inteligente.


O que significa "Trusted Context"?

Esse é provavelmente o conceito mais importante do watsonx.data intelligence.

Traduzindo livremente:

Contexto Confiável.

A IA deixa de confiar apenas nos dados.

Ela passa a confiar também nas regras que explicam aqueles dados.

Isso muda completamente a qualidade das respostas.


O papel do Business Glossary

Imagine um banco.

A palavra "Saldo" pode significar:

Saldo Contábil

Saldo Disponível

Saldo Projetado

Saldo Bloqueado

Saldo Médio

Todos são "Saldo".

Mas representam conceitos diferentes.

O Business Glossary resolve exatamente esse problema.

Ele funciona como um dicionário oficial da empresa.

Quando a IA encontra um termo, ela consulta o glossário antes de responder.

É como perguntar ao analista de negócios:

"Quando vocês dizem saldo, qual saldo exatamente?"


Data Lineage: seguindo o caminho dos dados

Agora imagine um campo chamado:

LIMITE_DISPONIVEL

De onde ele veio?

A IA consegue descobrir algo como:

PIX

↓

Movimentações

↓

Conta Corrente

↓

Motor Financeiro

↓

Tabela DB2

↓

Dashboard

Ela enxerga toda a cadeia de transformação.

Isso é chamado de Lineage.


Pensando como um Programador COBOL

Imagine alterar um copybook.

01 CLIENTE.
   05 LIMITE        PIC S9(9)V99 COMP-3.

Antes de alterar esse campo, você gostaria de saber:

  • Quantos programas usam esse copybook?

  • Quais transações CICS dependem dele?

  • Existe algum Job Batch?

  • Alguma API REST utiliza esse campo?

  • Existe integração com sistemas externos?

Hoje isso normalmente exige:

SDSF.

Pesquisa no Endevor.

Ferramentas de Impact Analysis.

Consulta a analistas.

Reuniões.

Com Agentic Data Intelligence, boa parte dessa investigação pode ser automatizada.


O poder do Data Quality

Imagine perguntar:

"Qual o faturamento do último trimestre?"

Uma IA comum responde.

Uma IA inteligente responde:

"O conjunto de dados possui 97,8% de qualidade, porém existem registros duplicados na origem."

Essa pequena diferença aumenta enormemente a confiança na resposta.


Governança não é burocracia

Muitos iniciantes acham que Governança serve apenas para gerar documentação.

Na verdade...

Governança protege a empresa.

Por exemplo:

CPF.

A IA sabe que:

  • deve mascarar;

  • exige autorização;

  • está protegido pela LGPD;

  • possui classificação confidencial.

Ela aprende regras.

Não apenas dados.


Ownership: quem é o dono da informação?

Imagine encontrar uma tabela chamada:

CLIENT_MASTER

Quem responde por ela?

Financeiro?

CRM?

Marketing?

TI?

A IA consulta o catálogo.

Descobre o proprietário.

E informa.

Isso reduz muito o tempo gasto procurando especialistas.


O que é o MCP?

MCP significa:

Model Context Protocol.

Você pode imaginar o MCP como um "idioma universal" entre agentes de IA e sistemas corporativos.

Assim como:

ODBC

JDBC

ODBC permitiu acessar bancos de dados diferentes.

O MCP pretende permitir que qualquer IA consulte conhecimento corporativo da mesma maneira.

Isso significa integração com:

  • IBM Bob

  • Claude

  • GitHub Copilot

  • watsonx Orchestrate

  • aplicações internas


Agent Skills: ensinando experiência para a IA

Aqui está uma das partes mais interessantes.

Imagine ensinar um estagiário.

Você não diz apenas:

"Cadastre um novo Data Product."

Você entrega um procedimento.

Receber dados

↓

Classificar

↓

Enriquecer metadados

↓

Aplicar LGPD

↓

Publicar

↓

Validar

Esse fluxo recebe o nome de Agent Skill.

São habilidades reutilizáveis.

É como um PROC em JCL.

Você encapsula conhecimento.

Depois reutiliza quantas vezes quiser.


Um exemplo para quem conhece JCL

Veja este comando:

//STEP01 EXEC PROC=BACKUP

Você não precisa lembrar:

  • IDCAMS

  • SORT

  • DELETE

  • DEFINE

  • REPRO

Tudo já está preparado.

Agent Skills funcionam exatamente assim.


Um exemplo de uso no mundo real

Imagine um auditor perguntando:

"De onde veio o valor mostrado neste Dashboard?"

A IA pode responder:

Dashboard

↓

Data Product

↓

Tabela Curada

↓

Pipeline ETL

↓

DB2

↓

Programa COBOL

↓

Arquivo VSAM

↓

Sistema de Origem

Tudo automaticamente.

Sem abrir dez ferramentas diferentes.


Outro exemplo para o Padawan

Você altera um Copybook.

Antes do Deploy, pergunta:

"Qual será o impacto?"

O agente responde:

  • 218 programas COBOL afetados;

  • 12 aplicações Java;

  • 31 APIs REST;

  • 4 sistemas parceiros;

  • 6 dashboards;

  • 2 modelos de IA.

Isso é muito mais poderoso do que uma simples pesquisa textual.


Como isso muda a vida do Programador COBOL?

Muito.

Hoje gastamos boa parte do tempo tentando descobrir:

"Quem usa isso?"

No futuro a pergunta será:

"IA, mostre todo o impacto desta alteração."

A IA não apenas responderá.

Ela mostrará:

  • dependências;

  • riscos;

  • qualidade;

  • governança;

  • responsáveis.


Como começar a estudar?

Se você é um COBOL Padawan, siga esta ordem.

Etapa 1 — Domine o Mainframe

Antes de IA, conheça bem:

  • JCL

  • TSO

  • SDSF

  • VSAM

  • DB2

  • CICS

  • IMS

Sem isso, você não entenderá de onde vêm os dados.


Etapa 2 — Aprenda Modelagem de Dados

Estude:

  • Chaves primárias

  • Chaves estrangeiras

  • Normalização

  • Data Warehouse

  • Data Lake

  • Data Products


Etapa 3 — Aprenda Governança

Entenda conceitos como:

  • Metadata

  • Business Glossary

  • Data Steward

  • Lineage

  • Data Quality

  • Data Catalog

  • Ownership

Esses termos aparecerão cada vez mais no mercado.


Etapa 4 — Estude IA Corporativa

Depois avance para:

  • LLM

  • RAG (Retrieval-Augmented Generation)

  • Agentes de IA

  • MCP (Model Context Protocol)

  • IBM watsonx

  • IBM Bob

  • watsonx Orchestrate

Você perceberá que IA corporativa é muito diferente de simplesmente conversar com um chatbot.


Dicas práticas para evoluir

✔ Aprenda SQL profundamente. A IA depende de dados bem estruturados.

✔ Leia documentação de arquitetura dos sistemas onde trabalha. O contexto de negócio é tão importante quanto o código.

✔ Familiarize-se com ferramentas de análise de impacto, catálogos de dados e governança. Muitas das capacidades do Agentic Data Intelligence automatizam tarefas que hoje são feitas manualmente.

✔ Estude conceitos de segurança, LGPD e classificação de dados. Um bom profissional de Mainframe entende que proteger a informação é tão importante quanto processá-la.

✔ Experimente copilotos e agentes de IA, mas sempre valide as respostas. A confiança em IA corporativa nasce da combinação entre automação e governança.


Curiosidades

  • A maior parte do conhecimento de uma empresa não está no código COBOL, mas nas regras de negócio documentadas — ou, muitas vezes, apenas na cabeça dos especialistas.

  • Grandes bancos mantêm aplicações com mais de 40 anos de evolução contínua. Compreender suas dependências é um desafio monumental.

  • O conceito de lineage existe há anos em ferramentas de integração de dados, mas agora passa a fazer parte das respostas produzidas por agentes de IA.

  • O Model Context Protocol (MCP) está se consolidando como um padrão importante para conectar modelos de IA a ferramentas e fontes de conhecimento corporativo.

  • O futuro da IA empresarial dependerá menos de modelos gigantes e mais da capacidade de utilizar dados confiáveis, governados e contextualizados.


Conclusão: o futuro pertence a quem entende contexto

Durante décadas, o diferencial de um excelente programador COBOL nunca foi decorar comandos do compilador ou conhecer todas as instruções da linguagem. O que realmente fazia diferença era compreender profundamente as regras de negócio, as dependências entre sistemas e a história por trás de cada aplicação.

O Agentic Data Intelligence leva essa mesma filosofia para a Inteligência Artificial.

Em vez de responder apenas com base em dados brutos, os agentes passam a consultar glossários de negócio, políticas de governança, linhagem dos dados, métricas de qualidade e informações sobre responsabilidade dos ativos. Em outras palavras, eles começam a agir como faria um analista experiente que conhece o ambiente da empresa.

Para o COBOL Padawan, isso representa uma oportunidade extraordinária. Dominar apenas a linguagem COBOL continuará sendo importante, mas já não será suficiente. O profissional que se destacar será aquele capaz de unir programação, arquitetura de dados, governança, inteligência artificial e conhecimento do negócio.

Assim como o Mainframe evoluiu de cartões perfurados para APIs REST, microsserviços e integração com nuvem, a próxima evolução será impulsionada por agentes inteligentes capazes de compreender o contexto completo da organização.

E talvez essa seja a maior lição deste café no Bellacosa Mainframe:

O código continua sendo essencial, mas o verdadeiro poder está em compreender o significado dos dados. Quem dominar esse conhecimento ajudará a construir a próxima geração de sistemas inteligentes sobre a plataforma mais confiável do mundo: o IBM Z.

 

segunda-feira, 29 de junho de 2026

IBM Bob + Docling for watsonx: Quando a Inteligência Artificial Aprende a Trabalhar Como um Analista Mainframe

 

Bellacosa Mainframe criando automacao de documentos com o ibm bob

☕ Um Café no Bellacosa Mainframe

IBM Bob + Docling for watsonx: Quando a Inteligência Artificial Aprende a Trabalhar Como um Analista Mainframe

Da Especificação ao Código, dos Documentos ao Conhecimento — O Futuro da Engenharia de Software Também Está Chegando ao COBOL

"Um bom programador escreve código. Um excelente programador entende o problema antes de escrever a primeira linha. O IBM Bob faz exatamente isso."


Introdução

Durante décadas, nós, profissionais de Mainframe, aprendemos uma verdade que continua absolutamente válida.

Codificar nunca foi a parte mais difícil de um projeto.

O verdadeiro desafio sempre esteve em entender o problema.

Quem trabalhou em bancos, seguradoras, empresas aéreas ou grandes indústrias conhece essa realidade.

Antes de abrir o ISPF e digitar o primeiro:

IDENTIFICATION DIVISION.

havia semanas — às vezes meses — dedicados a:

  • levantamento de requisitos;

  • entrevistas com usuários;

  • documentação funcional;

  • especificação técnica;

  • desenho de fluxo;

  • modelagem de arquivos;

  • validação com analistas;

  • revisão de arquitetura.

Somente depois disso alguém começava a escrever COBOL.

Curiosamente, durante muitos anos a Inteligência Artificial fez exatamente o contrário.

Ela recebia um prompt como:

"Crie um sistema de vendas."

E imediatamente começava a gerar milhares de linhas de código.

Parecia impressionante.

Mas para quem viveu projetos corporativos, havia um problema evidente:

Ninguém desenvolve software sério dessa forma.

Foi exatamente essa percepção que levou a IBM a criar uma abordagem muito mais madura, demonstrada no tutorial "Extract structured data from messy documents with Docling for IBM watsonx and IBM Bob".

Mais do que apresentar uma ferramenta, o tutorial mostra uma mudança de paradigma na engenharia de software.


O desenvolvimento tradicional

Vamos imaginar um projeto COBOL.

O usuário diz:

"Precisamos importar Ordens de Compra."

Parece simples.

Mas imediatamente surgem dezenas de perguntas.

  • Qual o layout?

  • Quantos fornecedores existem?

  • Existe autenticação?

  • Há processamento paralelo?

  • Como tratar arquivos inválidos?

  • Qual o limite diário?

  • Como exportar os resultados?

Essas perguntas não são feitas pelo compilador.

São feitas pelo analista.

Durante décadas essa foi exatamente a função do Analista de Sistemas.

Antes do programador existir, existe o entendimento do negócio.


O velho erro da IA

Grande parte dos copilots atuais funciona assim:

Usuário

↓

Prompt

↓

Código

Isso funciona para pequenos exemplos.

Mas em sistemas corporativos surgem problemas.

Por exemplo:

"Crie um sistema de compras."

Qual banco?

Qual autenticação?

Quais APIs?

Qual arquitetura?

Como tratar erros?

Onde salvar?

Como testar?

Como implantar?

Sem essas respostas, o código pode até funcionar, mas dificilmente será um sistema robusto.


A proposta do IBM Bob

O IBM Bob muda completamente essa lógica.

O fluxo passa a ser:

Ideia

↓

Requisitos

↓

Especificação Técnica

↓

Arquitetura

↓

Implementação

↓

Testes

↓

Correções

↓

Aplicação

Perceba a diferença.

O código deixa de ser o primeiro passo.

Ele passa a ser uma consequência.

Essa abordagem é chamada de Spec-Driven Development (SDD).


O que é Spec-Driven Development?

Imagine construir um prédio.

Ninguém começa levantando paredes.

Primeiro vêm:

  • levantamento do terreno;

  • projeto arquitetônico;

  • projeto elétrico;

  • projeto hidráulico;

  • cálculos estruturais.

Somente depois aparece o concreto.

Na engenharia de software deveria ser igual.

O documento de especificação passa a ser o "projeto da construção".

É exatamente isso que Bob produz automaticamente.


O papel do Docling

Outro protagonista do tutorial é o Docling for watsonx.

À primeira vista pode parecer apenas uma biblioteca para ler PDFs.

Mas isso seria reduzir demais sua importância.

O Docling faz algo muito mais sofisticado.

Ele transforma documentos desestruturados em dados compreensíveis para IA.

Imagine uma Ordem de Compra.

Visualmente ela possui:

  • logotipo;

  • cabeçalho;

  • fornecedor;

  • data;

  • tabela;

  • rodapé;

  • observações.

Para um ser humano isso é trivial.

Para um computador tradicional tudo isso é apenas texto espalhado.

O Docling reconstrói a estrutura lógica do documento.

Ele entende:

  • títulos;

  • subtítulos;

  • listas;

  • tabelas;

  • colunas;

  • imagens;

  • relações hierárquicas.

Isso muda completamente o jogo.


PDF não é banco de dados

Esse talvez seja o conceito mais importante para um programador COBOL entender.

Durante anos trabalhamos com:

  • VSAM

  • DB2

  • IMS

  • Sequential Files

Todos possuem estrutura.

Um PDF não.

Ele é praticamente uma fotografia.

Extrair informação dele sempre foi difícil.

Bibliotecas antigas conseguiam apenas:

Texto

Texto

Texto

Texto

As tabelas desapareciam.

As colunas eram misturadas.

Os totais se perdiam.

O Docling preserva a estrutura.

Isso faz toda diferença.


O exemplo do tutorial

O exemplo utilizado é bastante interessante.

O usuário deseja um sistema capaz de:

  • receber vários PDFs;

  • identificar Ordens de Compra;

  • extrair fornecedores;

  • consolidar produtos;

  • calcular totais;

  • exportar CSV.

Nada extraordinário.

Mas observe como Bob trabalha.

Primeiro ele cria um documento chamado:

requirements-intent.md

Esse documento representa apenas a intenção.

Não existe código.


A IA faz perguntas

Em seguida Bob começa a agir como um Analista de Sistemas.

Ele pergunta:

Existe autenticação?

O processamento será paralelo?

Quantos PDFs?

Como tratar falhas?

É exatamente o tipo de pergunta que um analista humano faria.

Essa talvez seja a parte mais impressionante do tutorial.

A IA deixa de ser um "digitador automático".

Ela passa a participar do entendimento do problema.


A especificação técnica

Depois das respostas surge automaticamente:

TECHNICAL_SPEC.md

Esse documento contém:

  • visão geral;

  • arquitetura;

  • APIs;

  • diretórios;

  • modelos;

  • diagramas Mermaid;

  • componentes.

Quem trabalhou com metodologias tradicionais certamente lembrou imediatamente dos antigos documentos de Análise Estruturada.

A diferença é que agora eles são produzidos automaticamente.


A arquitetura

O sistema criado segue uma arquitetura bastante limpa.

Carbon Design

↓

Flask

↓

Upload

↓

Docling

↓

Markdown

↓

Parser

↓

Analytics

↓

CSV

Observe que cada componente possui responsabilidade única.

Esse princípio é chamado de Separation of Concerns.

É exatamente o mesmo conceito utilizado em aplicações CICS modernas.


O Carbon Design

Outro elemento importante é o Carbon Design System.

Programadores COBOL normalmente não trabalham com interfaces gráficas.

Mas vale entender sua importância.

O Carbon é para aplicações Web aquilo que o ISPF foi para o z/OS.

Um conjunto padronizado de componentes.

Botões.

Menus.

Formulários.

Tabelas.

Ícones.

Tudo consistente.

Isso reduz muito o esforço de desenvolvimento.


O Parser

Após o Docling converter o PDF em Markdown estruturado entra em ação o Parser.

Sua função lembra muito um programa COBOL Batch.

Entrada:

Markdown

Saída:

Objetos estruturados

Ele identifica:

  • fornecedor;

  • data;

  • produto;

  • quantidade;

  • preço;

  • total.

Ou seja, transforma texto em registros.

É praticamente um ETL.


O módulo Analytics

Depois do Parser vem o Analytics.

Aqui os dados passam a ser consolidados.

Por fornecedor.

Por produto.

Por ordem de compra.

Por valor.

Isso lembra bastante programas COBOL responsáveis por gerar relatórios financeiros.

A diferença é que agora os dados vieram de documentos PDF.


O momento mais interessante

Durante os testes algo falha.

Um teste unitário acusa erro.

O parser não tratava corretamente valores:

None

O que Bob faz?

Não pergunta ao usuário.

Não pede ajuda.

Ele:

  • localiza o erro;

  • altera apenas o trecho necessário;

  • executa novamente os testes.

Todos passam.

Esse comportamento lembra muito práticas modernas de DevOps.


Testes primeiro, confiança depois

Durante muitos anos ouvi uma frase:

"Meu programa compilou."

No mundo atual isso significa muito pouco.

O importante é:

Os testes passaram?

No tutorial vemos:

  • testes unitários;

  • testes de integração;

  • validação completa.

Esse é exatamente o fluxo esperado em engenharia moderna.


O resultado final

A aplicação permite:

✔ Upload de múltiplos PDFs

✔ Processamento automático

✔ Extração inteligente

✔ Consolidação

✔ Dashboard

✔ Exportação CSV

Tudo produzido praticamente a partir de documentação.


O que isso significa para um Programador COBOL?

Talvez você esteja pensando:

"Isso serve apenas para aplicações Web."

Na verdade, não.

Imagine adaptar exatamente esse fluxo para o Mainframe.

Recebemos diariamente:

  • SYSOUT

  • JES2

  • SMF

  • RMF

  • Dumps

  • Relatórios RACF

  • Catálogos

  • Logs IMS

  • Logs CICS

  • JCLs

  • Listings COBOL

  • EXPLAIN PLAN do Db2

  • Documentação técnica

  • Procedimentos operacionais

Todos esses documentos poderiam ser processados pelo Docling.

Depois enviados ao Granite.

Depois consultados via RAG.

Imagine perguntar:

"Mostre todos os programas COBOL que utilizam o arquivo CLIENTES e fazem EXEC CICS XCTL."

Ou então:

"Quais jobs executam depois do fechamento do movimento financeiro?"

Ou ainda:

"Explique este ABEND S0C7 utilizando os padrões encontrados em incidentes anteriores."

Essa é exatamente a direção para onde a engenharia de software está caminhando.


Uma analogia com o Batch

Podemos comparar todo esse fluxo com um Job Batch.

INPUT

↓

Validação

↓

Transformação

↓

Classificação

↓

Consolidação

↓

Relatório

↓

OUTPUT

A diferença é que agora o INPUT é um PDF.

E parte do processamento é realizada por modelos de IA.


O futuro do Analista de Sistemas

Durante muito tempo acreditou-se que IA substituiria programadores.

Na prática, o que observamos é diferente.

Ela está assumindo tarefas repetitivas:

  • documentação;

  • geração de código;

  • testes;

  • revisão;

  • correção.

Mas continua dependendo do conhecimento humano para:

  • entender regras de negócio;

  • validar arquitetura;

  • decidir prioridades;

  • compreender impactos.

Ou seja, o papel do analista se torna ainda mais estratégico.


Lições para quem está começando em COBOL

Se você é um Programador COBOL Júnior, talvez pense que precisa aprender apenas sintaxe.

Não.

A sintaxe muda.

Os princípios permanecem.

Aprenda:

  • análise de requisitos;

  • modelagem;

  • documentação;

  • arquitetura;

  • testes;

  • versionamento;

  • integração;

  • observabilidade.

Esses conhecimentos continuarão valiosos independentemente da linguagem utilizada.


Conclusão

O tutorial da IBM demonstra algo muito maior do que uma nova ferramenta.

Ele mostra que a Inteligência Artificial está amadurecendo.

Em vez de simplesmente gerar código, ela começa a participar de todo o ciclo de desenvolvimento:

  • entende o problema;

  • faz perguntas;

  • escreve especificações;

  • projeta arquitetura;

  • implementa;

  • testa;

  • corrige;

  • valida.

Para nós, profissionais de Mainframe, essa evolução é particularmente interessante.

Durante décadas aprendemos que um bom sistema nasce de uma boa especificação, de uma arquitetura sólida e de testes rigorosos. O IBM Bob resgata exatamente essa disciplina, agora potencializada pela IA. O Docling, por sua vez, amplia a capacidade de transformar documentos corporativos em informação estruturada, aproximando o universo dos PDFs, contratos, relatórios e ordens de compra das aplicações inteligentes baseadas em IA.

No fim das contas, a maior lição não é tecnológica, mas metodológica: o futuro pertence aos profissionais que sabem compreender o negócio antes de escrever código. Linguagens, frameworks e ferramentas continuarão evoluindo, mas a capacidade de analisar problemas, projetar soluções e garantir qualidade continuará sendo o verdadeiro diferencial de um engenheiro de software — seja ele programando em COBOL no IBM Z, em Python na nuvem ou utilizando agentes inteligentes como o IBM Bob.


domingo, 28 de junho de 2026

Backlog: O Dataset Invisível que Pode Salvar ou Destruir um Projeto Mainframe

 

Bellacosa Mainframe e o conceito do backlog na stack mainframe

☕ Um Café no Bellacosa Mainframe

Backlog: O Dataset Invisível que Pode Salvar ou Destruir um Projeto Mainframe

"No mundo IBM Z, um programa COBOL raramente quebra por causa de uma linha de código. Quase sempre ele quebra porque existe um backlog que ninguém quis enxergar."

Existe uma palavra que todo profissional de TI escuta diariamente: Backlog.

Ela aparece em reuniões ágeis, em SCRUM, em Kanban, nos relatórios do gerente, nos dashboards do Jira e até em apresentações do CIO.

Mas curiosamente, poucos programadores COBOL entendem o verdadeiro significado do backlog.

Para um Padawan Mainframe, backlog costuma parecer apenas uma lista enorme de tarefas.

Na realidade, backlog é muito mais parecido com um dataset VSAM KSDS.

Ele armazena tudo que ainda precisa ser processado.

Se ele estiver organizado, o sistema flui.

Se estiver corrompido...

Você acabou de criar o próximo ABEND da equipe.


Imagine um Batch Noturno

Pense em um JOB executando durante a madrugada.

Ele possui:

  • milhares de registros

  • prioridades

  • dependências

  • checkpoints

  • reprocessamentos

Agora substitua os registros por atividades.

Pronto.

Você acabou de entender o backlog.

O backlog é simplesmente o conjunto de trabalho que ainda será executado.

Mas existe uma diferença enorme entre:

muito trabalho

e

backlog saudável.


O Backlog Não É o Problema

O backlog é inevitável.

Todo sistema vivo possui backlog.

Até o z/OS trabalha com filas.

JES2 possui filas.

CICS possui filas.

MQ possui filas.

IMS possui filas.

DB2 possui locks esperando.

Tudo funciona através de filas.

O problema nunca foi possuir backlog.

O problema é possuir um backlog que ninguém entende.


Como Nasce um Backlog

Imagine um sistema bancário.

Hoje o gerente pede:

Criar PIX.

Depois:

alterar TED.

Depois:

corrigir boleto.

Depois:

adequação ao Banco Central.

Depois:

LGPD.

Depois:

Open Finance.

Depois:

PIX Automático.

Depois:

IA.

Depois:

APIs REST.

Cada solicitação entra.

Nem todas saem.

O resultado?

Um backlog crescente.


O Backlog Invisível

O pior backlog é o invisível.

Ele mora em frases como:

"Depois a gente vê."

"Na próxima Sprint."

"Isso fica para outro momento."

"É uma melhoria."

"Não é urgente."

Meses depois...

Existem centenas delas.


Backlog Técnico

Nem todo backlog é funcional.

Existe também:

  • melhoria de performance

  • reorganização de programas

  • limpeza de código

  • documentação

  • atualização de COPYBOOKS

  • reorganização DB2

  • índices

  • compressão VSAM

  • testes

Tudo isso entra no backlog.


Como Identificar um Backlog Doente

Um backlog começa a adoecer quando aparecem sintomas.

Sintoma 1

Todo mundo pergunta:

"O que devemos fazer agora?"

Isso significa ausência de prioridade.


Sintoma 2

Existem tarefas de três anos atrás.

Se ninguém fez em três anos...

Talvez nunca devesse existir.


Sintoma 3

Existem tarefas duplicadas.

Muito comum.

Um analista abre:

"Corrigir cálculo."

Outro abre:

"Ajustar juros."

Outro:

"Problema financeiro."

São o mesmo erro.


Sintoma 4

Ninguém sabe explicar a tarefa.

Descrição:

"Verificar erro."

Qual erro?

Onde?

Quando?

Por quê?


Sintoma 5

Todo item é prioridade máxima.

Quando tudo é urgente...

Nada é urgente.


Como um Programador COBOL Deve Ler um Backlog

Nunca leia apenas o título.

Leia:

  • requisito

  • regra de negócio

  • programas envolvidos

  • COPYBOOKS

  • arquivos

  • tabelas DB2

  • transações CICS

  • JCL

  • impacto

A tarefa começa muito antes do código.


O Erro do Padawan

O Padawan pensa:

"Recebi uma tarefa."

O profissional experiente pensa:

"Recebi um problema de negócio."

Isso muda tudo.


Como Evoluir um Backlog

Existe uma prática chamada:

Backlog Refinement

Ou refinamento.

No Mainframe isso seria parecido com preparar um JOB antes da produção.

Você elimina ambiguidades.


Durante o refinamento fazemos perguntas.

O usuário realmente quer isso?

Existe impacto financeiro?

Existe impacto jurídico?

Existe cálculo?

Existe histórico?

Existe rollback?

Existe auditoria?

Existe logging?

Existe batch?

Existe online?

Existe integração?


Quanto mais perguntas...

Menor o risco.


Um Backlog Não Deve Crescer Para Sempre

Imagine um dataset.

Se ninguém fizer housekeeping...

Ele cresce.

Depois cresce.

Depois cresce.

Depois o volume explode.

Depois aparece:

SPACE ABEND

O backlog também.


Como Priorizar

Uma técnica simples.

Divida em quatro grupos.

Incêndio

Sistema parado.


Financeiro

Pode gerar prejuízo.


Cliente

Afeta usuários.


Melhoria

Pode esperar.


A maioria dos times mistura tudo.


Backlog e COBOL

Um programa COBOL raramente possui apenas uma alteração.

Quando você abre um fonte...

Encontra:

Alteração 2003

Alteração 2006

Alteração 2009

Alteração 2014

Alteração 2018

Alteração 2021

Alteração 2025

Cada comentário representa um backlog encerrado.

O código conta a história da empresa.


O Backlog Bom

Possui:

✔ descrição

✔ prioridade

✔ responsável

✔ impacto

✔ dependência

✔ prazo

✔ critério de aceite

✔ documentação


O Backlog Ruim

Descrição:

"Ajustar."

Boa sorte.


A Grande Diferença Entre Backlog e Dívida Técnica

Muita gente mistura.

Mas são conceitos completamente diferentes.

Backlog

É trabalho conhecido.

Sabemos que precisa ser feito.

Está registrado.

Está visível.

Pode ser priorizado.


Dívida Técnica

É trabalho escondido.

Você decidiu fazer algo mais rápido.

Agora pagará juros.


Imagine um empréstimo.

Você compra uma casa.

Ainda deve dinheiro.

A casa existe.

Mas existe dívida.

No software é igual.


Exemplo.

Você precisava entregar uma alteração.

O correto seria:

  • modularizar

  • criar testes

  • atualizar documentação

Mas o prazo era curto.

Você fez um IF gigantesco.

Funcionou.

Pronto.

Nasceu uma dívida técnica.


Backlog Pode Não Ser Dívida

Exemplo.

Nova funcionalidade PIX.

Ela nunca existiu.

Está no backlog.

Não existe dívida.

É apenas trabalho futuro.


Dívida Técnica Pode Não Estar no Backlog

Muito comum.

Todo mundo sabe que existe.

Ninguém registra.

Ninguém fala.

Até o dia em que explode.


Como Identificar Dívida Técnica

Pergunte:

"Se eu tivesse mais tempo...

faria diferente?"

Se a resposta for SIM...

Existe dívida técnica.


Os Juros da Dívida Técnica

Assim como um banco cobra juros...

O software também.

Cada alteração demora mais.

Cada teste demora mais.

Cada deploy gera medo.

Cada manutenção aumenta.


Dívida Técnica no Mainframe

Exemplos.

Programa COBOL com:

12000 linhas.

Sem PERFORM.

GO TO para todos os lados.

COPYBOOK repetido.

Campos duplicados.

Comentários de 1998.

Variáveis mortas.

Parágrafos nunca chamados.

SQL repetido.

MOVE desnecessário.

PERFORM THROUGH gigantesco.

Tudo isso gera dívida.


Como Corrigir

Nunca tente pagar toda a dívida de uma vez.

Faça igual um financiamento.

Pague parcelas.

Sempre que alterar um programa:

melhore um pouco.

Renomeie variáveis.

Remova código morto.

Atualize comentários.

Crie testes.

Melhore SQL.

Refatore pequenos blocos.


A Regra do Escoteiro

Robert C. Martin criou uma regra famosa.

Deixe o código melhor do que encontrou.

No Mainframe ela é perfeita.


Backlog Funcional

Pedido do negócio.


Backlog Técnico

Pedido da TI.


Backlog Arquitetural

Mudanças estruturais.

Exemplos.

Migrar VSAM.

Migrar CICS.

Atualizar COBOL.

Atualizar compilador.

Migrar DB2.

Atualizar RACF.


O Backlog Nunca Acaba

Isso assusta iniciantes.

Mas é normal.

Software vivo nunca termina.

Ele evolui.


Curiosidade Mainframe nº 1

Nos anos 70 ninguém dizia "Backlog".

Chamavam de:

Pending Requests

Programming Queue

Change Queue

Maintenance Queue

A palavra backlog ficou popular muito depois com métodos ágeis.


Curiosidade nº 2

Em muitos bancos brasileiros ainda existem planilhas Excel paralelas ao Jira.

Sim.

O backlog oficial nem sempre é o verdadeiro.


Curiosidade nº 3

Algumas empresas possuem backlog maior que o código.

Há milhares de demandas abertas.

Mas apenas algumas centenas realmente serão desenvolvidas.


Curiosidade nº 4

O maior inimigo do backlog não é a falta de programadores.

É a falta de decisão.


Curiosidade nº 5

Muitos ABENDs históricos aconteceram porque uma melhoria pequena ficou anos esquecida.

Quando finalmente foi feita...

Ninguém mais entendia o motivo original.


Easter Egg IBM Z

Você já percebeu?

O JES2 organiza trabalhos.

O MQ organiza mensagens.

O CICS organiza transações.

O DB2 organiza dados.

O RACF organiza permissões.

O backlog organiza pessoas.

No fundo...

Todo o ecossistema IBM Z é baseado em gerenciamento de filas.


Easter Egg COBOL

O comando:

NEXT SENTENCE

parece simples.

Mas ele simboliza exatamente muitos backlogs.

Você pula para frente sem realmente resolver o problema.

Funciona.

Até deixar de funcionar.


Easter Egg DB2

Um índice mal planejado gera consultas lentas.

Um backlog mal priorizado gera equipes lentas.

Os dois possuem exatamente o mesmo problema:

falta de organização.


Easter Egg CICS

Em CICS existe o conceito de resposta rápida.

O usuário não pode esperar.

No backlog também.

Quanto mais tempo uma tarefa fica parada...

Maior a chance de perder contexto.


Easter Egg JCL

Imagine um JOB.

STEP010

STEP020

STEP030

STEP040

Existe ordem.

Existe dependência.

Existe fluxo.

Um backlog deveria funcionar exatamente assim.


Easter Egg VSAM

Um KSDS desorganizado sofre mais splits.

Uma equipe desorganizada sofre mais interrupções.


Easter Egg RACF

No RACF, tudo segue o princípio do menor privilégio.

No backlog, vale um princípio parecido:

o menor item possível.

Histórias pequenas fluem melhor do que demandas gigantescas.


O Conselho Final para Todo Padawan COBOL

Quando você entrar em um projeto Mainframe, não olhe apenas para o código-fonte. Observe a saúde do backlog. Um programa de 30 anos pode ser surpreendentemente fácil de manter se houver um backlog bem organizado, prioridades claras e comunicação constante entre negócio e tecnologia. Por outro lado, um sistema moderno pode se tornar um pesadelo quando acumula tarefas mal descritas, prioridades conflitantes e dívida técnica ignorada.

Aprenda a fazer perguntas antes de programar. Entenda a regra de negócio antes de abrir o editor COBOL. Documente suas descobertas, refine as histórias, questione requisitos ambíguos e aproveite cada manutenção para deixar o código um pouco melhor do que estava. Essa disciplina, repetida diariamente, transforma um Padawan em um verdadeiro Mestre Mainframe.

No universo IBM Z, backlog é o mapa da jornada, enquanto a dívida técnica é o peso que você carrega na mochila. O mapa pode crescer à medida que novos caminhos surgem, mas o peso só aumenta quando atalhos mal planejados são tomados. Os melhores profissionais aprendem a equilibrar os dois: mantêm um backlog claro, vivo e priorizado, enquanto pagam pequenas parcelas da dívida técnica a cada entrega.

No fim das contas, a maior lição é simples: software não é apenas código; é uma fila contínua de decisões. Assim como o JES2 coordena jobs, o CICS gerencia transações e o DB2 organiza dados, um bom desenvolvedor organiza seu trabalho, seu conhecimento e sua evolução. É essa capacidade de transformar caos em ordem que diferencia um programador que apenas entrega tarefas de um engenheiro que constrói sistemas capazes de sobreviver por décadas — exatamente como os grandes ambientes IBM Z que continuam sustentando bancos, seguradoras, governos e empresas em todo o mundo.


sábado, 27 de junho de 2026

O Grande Equívoco: A Modernização Não é Sair do Mainframe

 

Bellacosa Mainframe e a modernizacao na Stack mainframe



☕ Um Café no Bellacosa Mainframe

O Grande Equívoco: A Modernização Não é Sair do Mainframe

A primeira provocação é justamente esta.

A maior parte das pessoas lê:

Modernizar COBOL → Java → Kubernetes → Cloud

Mas essa não é necessariamente a melhor resposta.

Modernizar é diferente de migrar.

Existem quatro estratégias clássicas.

1. Encapsular

Não mexe no COBOL.

Expõe APIs.

COBOL

CICS

z/OS Connect

REST

Mobile

Exemplo:

ContaCorrente.cbl

vira

GET /saldo

em minutos.


2. Refatorar

Melhora código COBOL.

COBOL 74

Enterprise COBOL 6.5

AMODE 64

JSON PARSE

XML

UTF-8

LE

Continua rodando no Z.


3. Reescrever

Maior risco.

COBOL

Java

COBOL

Go

COBOL

C#

Mas...

80% dos projetos falham.

Motivos:

regras escondidas

efeitos colaterais

batchs esquecidos

interfaces desconhecidas

JCL perdido

scheduller

CA7

Control-M

MQ

etc.


4. Replatform

Executar COBOL fora do Z.

Micro Focus

Rocket

Heirloom

Raincode

AWS Blu Age


Etapa 1 — Mainframe

A imagem mostra.

IBM Z

COBOL

DB2

CICS

JCL

Correto.

Mas faltam dezenas de peças.

IMS

MQ

VSAM

RACF

SMF

RMF

WLM

JES2

DFSMS

GDG

TSO

ISPF

SMP/E

NetView

SA zOS

e muitas outras.

Um banco médio pode ter:

50 milhões de linhas COBOL

300 mil JCL

12 mil CICS

200 TB DB2

40 anos de histórico


Bellacosa Mainframe e o mainframe no Brasil


Etapa 2 — Discovery

Talvez seja a etapa mais importante.

Porque ninguém conhece realmente o sistema.

José aposentou em 2009.

Maria saiu em 2017.

Carlos faleceu.

O conhecimento sumiu.


Descobrir significa:

inventário

mapear

catalogar

entender


Exemplo

Programa

PAGA100

CALL PAGA101

CALL PAGA102

READ VSAM001

EXEC SQL

UPDATE CLIENTE

PUT MQ

SUBMIT JCL

Só isso já gera um grafo enorme.


Ferramentas

IBM ADDI

IBM Wazi Analyze

Sonar

Understand

CAST

Manta


Etapa 3 — Regras de Negócio

Este talvez seja o maior patrimônio.

Exemplo.

IF IDADE > 65

AND TEMPO-CONTRIB > 15

AND DATA-CORTE < 20211231

MOVE 'S' TO BENEFICIO

Isso não está em documento.

Está no código.

Há empresas cujo negócio inteiro está aqui.


A Regra Oculta

Um banco descobriu:

IF CODIGO = 87

MOVE 0 TO JUROS

Perguntaram.

Por quê?

Resposta:

"Ninguém sabe."

Era uma lei de 1986.

Implementada por um programador.

Nunca documentada.


Etapa 4 — Dependency Graph

Excelente ideia.

Pouca gente faz.

Visualmente.

Programa A

Programa B

VSAM

MQ

DB2

Batch

Scheduler

API


Ferramentas modernas conseguem mostrar isso.

Parece Neo4J.

Um mapa da galáxia.


Etapa 5 — IA

A IA é promissora.

Mas ainda está longe da autonomia.

Ela consegue:

explicar COBOL

gerar documentação

resumir JCL

identificar copybooks

sugerir Java

gerar testes


Ela não consegue sozinha.

Decidir.

Esta regra bancária pode mudar?

Não sabe.


Exemplo.

COBOL

COMPUTE TAXA =
SALDO * 0.01875

IA pergunta:

Por que 1,875%?

Arquiteto responde:

Resolução BACEN 2147.

Pronto.

Conhecimento capturado.


Etapa 6 — Documentação

Hoje muitas empresas possuem.

Zero documentação.

Somente:

SYS1.PROCLIB

JCL

COBOL

Copybooks


IA pode gerar.

Markdown

Confluence

Draw.io

OpenAPI

Mermaid


Etapa 7 — Reengenharia

Imagem cita.

Java

.NET

Go

Node

Boa visão.

Mas há diferenças.

Java

Excelente.

Ecossistema corporativo.

Spring.


Go

Ótimo.

Microserviços.

Baixo consumo.


Node

Excelente APIs.

Menor adequação para batchs enormes.


.NET

Muito usado em seguradoras.


E Rust?

Começa aparecer.

Muito seguro.

Mas pouco adotado.


Contêineres

Aqui existe um mito.

Containerizar não significa melhorar.

Empacotar um sistema ruim.

Produz.

Um container ruim.


Docker resolve.

Empacotamento.

Não arquitetura.


Kubernetes

Muito poderoso.

Mas caro operacionalmente.

Exige.

SRE

Observabilidade

GitOps

Segurança


Para muitas empresas.

OpenShift.

É mais comum.


Cloud

A parte mais polêmica.

A imagem sugere.

Nuvem.

Como destino natural.

Nem sempre.


Muitos estão voltando.

Cloud Repatriation.

37Signals.

Dropbox.

Basecamp.

Bancos.


Motivos.

Custos.

Latência.

Compliance.

Egress.

Licenciamento.


Observabilidade

Excelente ponto.

Antigamente.

SMF.

RMF.

Omegamon.

Hoje.

Prometheus

Grafana

OpenTelemetry

Elastic


Imagine.

SMF 110

OpenTelemetry

Grafana

Isso já acontece.


O Papel da IA

A figura acerta em cheio aqui.

A IA não substitui.

O arquiteto.

O analista.

O especialista de negócio.

Ela atua como.

Copiloto.


Ela lê.

20 milhões linhas COBOL.

Em minutos.


Mas ela não sabe.

Que:

Cliente Ouro

é diferente de

Cliente VIP

Porque isso é semântico.

É negócio.


Minha visão sobre a frase central


A maior oportunidade tecnológica da próxima década não será abandonar o Mainframe, mas integrá-lo ao ecossistema moderno de APIs, IA, DevOps, observabilidade e computação híbrida.

O IBM Z não está desaparecendo. Está se tornando um nó de alto valor dentro de arquiteturas distribuídas, orientadas a eventos e assistidas por IA.

Acredito que estamos diante de uma das maiores ondas de transformação desde a popularização da internet comercial e da computação em nuvem, mas provavelmente ela não será uma história de "COBOL versus Java". Será uma história de preservar décadas de capital intelectual enquanto se adicionam capacidades modernas, reduzindo risco, aumentando a velocidade de entrega e mantendo a confiabilidade que fez o Mainframe sobreviver por mais de meio século. Afinal, substituir tecnologia é relativamente simples; substituir quarenta anos de conhecimento de negócio embutido em milhões de linhas de código é muito mais difícil.


Bellacosa Mainframe e os ciclos historicos na tecnologia mainframe


A história do software pode ser entendida como uma sucessão de grandes ondas tecnológicas. Nos anos 1960 surgiu a Crise do Software, quando projetos se tornavam caros, atrasados e difíceis de manter, motivando o nascimento da Engenharia de Software. A Crise do Petróleo dos anos 1970 aumentou a pressão por eficiência, impulsionando a automação bancária, industrial e governamental.

Nos anos 1980 ocorreu o movimento de downsizing, migrando parte do processamento de grandes sistemas centralizados para servidores menores e estações de trabalho. Na década de 1990 surgiu o rightsizing, buscando equilibrar custos, desempenho e confiabilidade, reconhecendo que nem tudo deveria sair do mainframe.

A popularização da Internet revolucionou os negócios, exigindo aplicações conectadas, comércio eletrônico e integração global. No final dos anos 1990, o Y2K mobilizou milhares de profissionais para corrigir sistemas legados, preservando um enorme patrimônio tecnológico e renovando plataformas críticas.

A partir dos anos 2000, a Cloud Computing trouxe elasticidade, pagamento sob demanda e novas arquiteturas distribuídas, embora também revelasse desafios de custo, governança e dependência de fornecedores. Atualmente, a onda da Inteligência Artificial acelera desenvolvimento, documentação, testes e modernização de sistemas legados. Diferentemente das revoluções anteriores, a IA não elimina o conhecimento humano: amplia a capacidade dos especialistas de compreender, preservar e evoluir décadas de regras de negócio.

sexta-feira, 26 de junho de 2026

Como um Padawan COBOL Pode Entender Agentes, MLOps e IA Generativa Sem Abandonar o IBM Z

 

Bellacosa Mainframe apresenta como entender ia generativas e agentes

☕ O Holocron do Ecossistema de IA Moderna

Como um Padawan COBOL Pode Entender Agentes, MLOps e IA Generativa Sem Abandonar o IBM Z

"O Mainframe nunca esteve atrasado. Apenas esperou pacientemente que o restante da indústria redescobrisse conceitos que ele domina há cinquenta anos."

Bellacosa Mainframe

Introdução – O dia em que percebi que um GPT era apenas um programa CICS muito falante

Se você é um Padawan COBOL, provavelmente abriu o LinkedIn nos últimos meses e viu dezenas de especialistas dizendo coisas como:

"Você precisa aprender IA."

"Agentes vão substituir desenvolvedores."

"Prompt Engineering é a nova programação."

"Os modelos estão ficando commodities."

E talvez tenha pensado:

"Mas eu passei anos aprendendo COBOL, JCL, VSAM, CICS, Db2, RACF, JES2 e agora preciso jogar tudo fora para estudar agentes?"

A resposta curta é:

Não.

Na verdade, existe uma boa notícia.

Talvez você seja muito mais preparado para a era Agentic AI do que imagina.


O Grande Equívoco Sobre Inteligência Artificial

Muitas pessoas ainda acreditam que IA é isto:

Usuário

ChatGPT

Resposta

Fim

Essa visão é tão simplificada quanto dizer que um banco consiste apenas em um programa COBOL.

Nós sabemos que não é assim.

Num banco real existem:

JES2

Control-M

RACF

Db2

MQ

CICS

VSAM

SMF

RMF

Schedulers

Catálogos

Auditoria

Backup

Monitoramento

A IA corporativa está seguindo exatamente o mesmo caminho.

Um LLM sozinho é inteligente.

Mas também é limitado.

Ele:

Não executa transações;

Não conhece dados internos;

Não lembra clientes;

Não acessa CICS;

Não consulta Db2;

Não abre chamados;

Não aprova empréstimos;

Não faz deploy.

Ele é apenas um cérebro.

O restante precisa ser construído.


O Ecossistema Moderno de IA

A indústria começou a perceber que IA não é um produto.

IA é um ecossistema.

Uma pilha arquitetural.

Podemos imaginar algo semelhante:

Agentic AI

Workflow

MLOps

Intelligence

Data Foundation

Curiosamente, um profissional IBM Z olha para isso e pensa:

"Eu já vi algo parecido antes."

Porque viu.

Durante décadas.


Primeira Camada – Data Foundation

Esta deveria ser a base absoluta.

Sem dados não existe IA.

E dados ruins produzem IA ruim.

Garbage In.

Garbage Out.

Nada mudou.

Apenas ficou mais caro.

O que existe aqui?

Db2

IMS

VSAM

Oracle

Postgres

Kafka

Data Lakes

Data Catalogs

Feature Stores

Embeddings

Vector Databases


Um exemplo bancário

Imagine um banco.

Possui:

40 milhões clientes

15 anos histórico

Cartões

PIX

Seguros

CRM

GPT não sabe nada disso.

Ele conhece apenas internet.

Precisamos ensinar.

Entra o conceito de:

RAG

Retrieval Augmented Generation

Funciona assim:

Pergunta

Embeddings

Busca vetorial

Documentos internos

LLM

Resposta

Exemplo:

Cliente pergunta:

"Quanto falta para quitar meu financiamento?"

Agente consulta.

Db2.

Documentos.

Extratos.

Contratos.

Depois responde.


O paralelo Mainframe

Padawan COBOL rapidamente percebe:

RAG é quase um READ em uma memória extremamente sofisticada.


Segunda Camada – Core Intelligence

Aqui moram os modelos.

GPT

Claude

Gemini

Mistral

Llama

DeepSeek


Também existem:

Speech

Computer Vision

OCR

Recomendadores

Machine Learning

Reinforcement Learning


Generative AI

É a interface moderna.

Antigamente:

Tela verde.

PF3.

COMMAREA.

Hoje:

Chat.

Áudio.

Imagem.

Agentes.

Copilots.


Reasoning Models

Uma novidade importante.

Os modelos não apenas completam frases.

Eles planejam.

Dividem tarefas.

Analisam.

Validam.

Exemplo.

Padawan pergunta:

"Como migrar VSAM para PostgreSQL?"

Modelo:

Analisa.

Calcula.

Sugere.

Documenta.

Estima esforço.


Terceira Camada – Workflow

Aqui a mágica começa.

É a camada esquecida.

Mas talvez seja a mais importante.


Ferramentas:

n8n

LangGraph

CrewAI

AutoGen

Semantic Kernel

Temporal


Imagine um processo.

Cliente solicita empréstimo.

Agente Planejador

Agente Crédito

Agente Fraude

Agente Compliance

Agente Aprovação

Supervisor

Resposta


Padawan COBOL imediatamente percebe:

Isso parece um scheduler.

E parece mesmo.

JES2.

Control-M.

CA7.

IWS.

Jobtrac.

São praticamente ancestrais dos workflows cognitivos.


Quarta Camada – MLOps

Se existe uma disciplina que lembra Sysprog Mainframe é MLOps.


Deploy.

Rollback.

Monitoramento.

Versionamento.

Observabilidade.


Ferramentas.

MLFlow.

Kubeflow.

Ray.

KServe.

Argo.


Exemplo.

Modelo fraude.

Janeiro.

97% acurácia.

Março.

88%.

Abril.

79%.

Por quê?

Mudou comportamento clientes.

PIX.

Golpes.

Novas técnicas.

MLOps detecta.

Treina novamente.


Padawan percebe:

É quase RUNSTATS.

REORG.

REBIND.

Statistics.

Só que para modelos.


Quinta Camada – Agentic AI

Aqui está a revolução.

E talvez a maior oportunidade profissional da década.


Um chatbot responde.

Um agente trabalha.


Agente possui:

Objetivos.

Ferramentas.

Memória.

Planejamento.

Autonomia.

Capacidade execução.


Exemplo.

Agente RH.

Recebe CV.

Classifica.

Agenda entrevista.

Consulta Teams.

Envia email.

Produz resumo.

Armazena histórico.

Tudo sozinho.


Multi-Agent Systems

Especialização.

Assim como empresas.


Agente Jurídico.

Agente Segurança.

Agente Mainframe.

Agente Cobol.

Agente Arquitetura.

Agente FinOps.


Supervisor coordena.

Como um gerente.


O Que a Imagem Não Mostra

Existem duas camadas ausentes.

Governança

Fundamental.

LGPD.

GDPR.

Auditoria.

RBAC.

IAM.

Policies.

Approval Gates.


Quem aprovou?

Quem executou?

Quem auditou?

Quem pagou?

Quem autorizou?


Infraestrutura

GPU.

TPU.

CPU.

OpenShift.

Kubernetes.

IBM z17.

LinuxONE.

Cloud.


O IBM Z Sempre Esteve Preparado

Talvez a maior surpresa seja esta.

IBM Z nunca esteve distante da IA.

Ele apenas utilizava nomes diferentes.

IA ModernaIBM Z
WorkflowJES2
ObservabilidadeRMF
LogsSMF
SegurançaRACF
APIsz/OS Connect
EventosMQ
SchedulerIWS
GovernançaSAF
CI/CDDBB
MemóriaDb2
AgentesServiços especializados
Inferênciawatsonx

O Conselho Final para um Padawan COBOL

Se você está começando agora, não tente aprender tudo.

Estude em etapas.

Etapa 1

Entenda LLMs.

GPT.

Claude.

Embeddings.

RAG.


Etapa 2

Aprenda LangGraph.

CrewAI.

n8n.


Etapa 3

Entenda MLOps.

MLFlow.

Observabilidade.


Etapa 4

Integre Mainframe.

MQ.

z/OS Connect.

Db2.


Etapa 5

Construa agentes.

Agente COBOL.

Agente JCL.

Agente Db2.

Agente CICS.


O Holocron Final

Durante anos ouvimos que o Mainframe era uma tecnologia do passado.

Em 2026 começamos a perceber algo curioso.

A indústria inteira está reconstruindo conceitos que os profissionais IBM Z já conheciam muito bem:

  • Orquestração;

  • Governança;

  • Observabilidade;

  • Segurança;

  • Processamento confiável;

  • Execução transacional;

  • Gestão de workloads;

  • Auditoria completa.

A IA moderna não está eliminando o conhecimento dos veteranos do IBM Z.

Ela está valorizando exatamente aquilo que sempre diferenciou os melhores arquitetos de mainframe: a capacidade de pensar em ecossistemas complexos, sistemas resilientes, processos críticos e plataformas que funcionam vinte e quatro horas por dia sem margem para erros.

Talvez o futuro não pertença apenas aos construtores do maior modelo de linguagem.

Talvez pertença aos velhos Jedi do IBM Z que finalmente descobriram que seus holocrons sempre falaram sobre agentes, apenas utilizando nomes diferentes.

quinta-feira, 25 de junho de 2026

☕ O ABEND da Migração Mágica: Quando a IA Generativa Descobre que o Mainframe Não é Apenas um Arquivo COBOL

Bellacosa Mainframe quando a magia da migração via ia do mainframe falha


☕ O ABEND da Migração Mágica: Quando a IA Generativa Descobre que o Mainframe Não é Apenas um Arquivo COBOL

O Dia em que o Mercado Percebeu que o ChatGPT Não Conhece o Batch das 02h17

Existe um momento na carreira de todo profissional de Mainframe em que ele aprende uma lição importante.

A primeira é que JCL não foi criado para ser bonito.

A segunda é que ninguém documenta adequadamente um scheduler.

A terceira é que sempre haverá alguém chegando com um PowerPoint dizendo:

— Vamos aposentar o Mainframe em doze meses.

Nos últimos vinte anos ouvi essa frase tantas vezes quanto mensagens $HASP373, IEC161I ou aquele clássico telefonema de sexta-feira às 18h:

— Bellacosa, caiu a produção.

Recentemente, entretanto, surgiu um ingrediente novo nessa antiga receita corporativa.

A Inteligência Artificial Generativa.

E, junto dela, uma nova promessa digna dos antigos alquimistas digitais:

"Nossa IA converte milhões de linhas COBOL para Java automaticamente."

"Seu CICS vira microsserviços em poucos cliques."

"Seu VSAM agora é PostgreSQL."

"Seu batch vira Kubernetes."

"Seu legado desaparece em seis meses."

Foi justamente nesse contexto que a Gartner publicou uma análise que talvez represente um dos maiores banhos de água fria já aplicados no mercado de migração de Mainframe.

Segundo a consultoria, mais de 70% dos projetos de saída do Mainframe iniciados em 2026 não entregarão os benefícios esperados.

E o motivo é simples.

As pessoas estão superestimando o que a IA realmente sabe fazer.

E subestimando brutalmente o que um ambiente IBM Z realmente é.


O Maior Equívoco da Década: Achar que Mainframe é Apenas COBOL

Quando alguém diz:

— Temos cinquenta milhões de linhas COBOL.

Meu primeiro pensamento nunca é sobre COBOL.

Meu primeiro pensamento é:

Quantos schedulers existem?

Quantos GDGs?

Quantos catálogos?

Quantos exits?

Quantos produtos ISV?

Quantos jobs dependem de um único arquivo VSAM aberto em RLS?

Porque o código é apenas a ponta visível do iceberg.

Abaixo da linha d'água vivem criaturas muito mais antigas e perigosas.

CA-7.

Control-M.

ESP.

Zeke.

NetView.

RACF.

DFSMS.

SMF.

RMF.

MQ.

WLM.

CICSplex.

IMS.

DB2 Packages.

Plan Stability.

PassTickets.

SAF.

Exit routines escritas em Assembler por alguém que se aposentou em 2009 e hoje cultiva orquídeas em Campinas.

A IA consegue interpretar um trecho como:

IF SALDO > LIMITE
   MOVE 'BLOQUEAR' TO ACAO
END-IF

Ela pode até gerar um Java elegante.

Mas dificilmente responderá perguntas como:

Por que esse programa executa apenas às terças-feiras?

Por que ele depende do fechamento do SMF?

Por que aguarda um arquivo SWIFT vindo da Bélgica?

Por que existe um passo IEBGENER aparentemente inútil?

Por que um job precisa terminar antes das 02h17?

E principalmente:

Quem será responsabilizado se o PIX parar durante duas horas?


O Conhecimento Tribal: A Tecnologia Mais Difícil de Migrar

Costumo dizer aos alunos do Bellacosa Mainframe:

O ativo mais caro de um banco não é o hardware.

Não é o software.

Nem mesmo os dados.

É o conhecimento acumulado por pessoas.

José está há trinta e dois anos na instituição.

Maria administra o RACF desde 1997.

Carlos conhece cada mensagem DFSxxxx de cabeça.

João sabe exatamente qual dataset pode ser apagado e qual causará um desastre regulatório.

Nenhum deles está em um repositório Git.

Nenhum deles está em um Wiki.

Nenhum deles aparece em um prompt.

Esse conhecimento mora na memória das pessoas.

E a IA não faz leitura telepática.

Ela apenas processa aquilo que recebeu.

Quando recebe documentação incompleta, devolve respostas incompletas.

Quando recebe caos, produz caos estatisticamente coerente.


O Marketing da Varinha Mágica Digital

Não tenho dúvidas.

Existe muita tecnologia impressionante surgindo.

Copilots.

Agentes autônomos.

Análise semântica.

Descoberta automática de dependências.

RAG.

Embeddings.

Vetorização.

Tudo isso possui enorme potencial.

Mas também estamos vivendo uma epidemia de apresentações corporativas.

Parece que alguns vendedores descobriram a Pedra Filosofal da Computação.

Basta enviar um ZIP contendo quarenta milhões de linhas COBOL.

E, algumas horas depois, nasce uma arquitetura nativa de nuvem.

Observabilidade pronta.

CI/CD configurado.

Microsserviços desacoplados.

Eventos Kafka.

Terraform.

OpenTelemetry.

Kubernetes.

Documentação impecável.

Testes automatizados.

Compliance.

Segurança.

Alta disponibilidade.

Tudo isso sem compreender uma única regra de negócio.

É quase uma versão tecnológica daquele vendedor de elixires do Velho Oeste.

Só que agora utilizando a palavra GenAI.


O Mainframe Continua Evoluindo

Enquanto parte do mercado tenta organizar funerais prematuros para o IBM Z, a IBM continua investindo bilhões de dólares na plataforma.

Hoje temos:

COBOL 6.x;

z/OS Connect;

OpenTelemetry;

Ansible;

Zowe;

Git integrado;

DevOps moderno;

API Economy;

Containers Linux on Z;

IA embarcada;

Criptografia acelerada por hardware;

Processadores especializados.

Ou seja.

O Mainframe não está parado.

O Mainframe está fazendo aquilo que sempre fez melhor.

Adaptando-se.

Em 1964 ele sobreviveu ao surgimento dos minicomputadores.

Nos anos 80 sobreviveu às workstations.

Nos anos 90 sobreviveu ao Client/Server.

Nos anos 2000 sobreviveu à internet.

Nos anos 2010 sobreviveu à cloud.

Nos anos 2020 provavelmente sobreviverá ao hype da IA Generativa.

Porque, no final das contas, bancos continuam precisando fechar o dia.

Companhias aéreas continuam emitindo passagens.

Governos continuam pagando benefícios.

Seguradoras continuam processando milhões de eventos.

E quase ninguém gosta quando esses sistemas param.


Talvez a Pergunta Esteja Errada

A pergunta nunca deveria ser:

"Como saímos do Mainframe?"

A pergunta correta talvez seja:

"Qual workload realmente precisa sair?"

Talvez um portal web de RH possa migrar.

Talvez um batch de impressão possa ser substituído.

Talvez um sistema satélite seja reescrito.

Mas talvez o motor central de compensação bancária deva permanecer exatamente onde está.

Porque engenharia não é religião.

Arquitetura não é ideologia.

Tecnologia não é torcida organizada.

A melhor plataforma é aquela que resolve o problema com menor risco, melhor disponibilidade, maior previsibilidade financeira e retorno sustentável.


Considerações Finais

Suspeito que a Gartner não esteja dizendo:

"Nunca migrem."

Também não está afirmando:

"Mainframe venceu."

A mensagem parece muito mais madura.

A IA Generativa será extraordinariamente útil para documentar, explicar, testar, modernizar e integrar aplicações existentes.

Mas ainda estamos distantes de confiar bilhões de dólares em transações financeiras a um modelo estatístico incapaz de compreender por que um velho JOB chamado FINA987 precisa começar precisamente às 02h17 da madrugada.

E talvez seja justamente aí que esteja a maior ironia desta década.

A tecnologia mais avançada da atualidade descobriu que o Mainframe nunca foi apenas COBOL.

Ele sempre foi memória institucional.

Processos.

Pessoas.

Histórias.

E algumas dezenas de milhares de linhas de JCL escritas por um Sysprog que provavelmente continua tendo razão.

https://www.gartner.com/en/newsroom/press-releases/2026-06-18-gartner-predicts-more-than-70-percent-of-mainframe-exit-projects-will-fail-due-to-overestimation-of-generative-ais-capabilities

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

 

Bellacosa Mainframe e divida tecnica, engenharia do caos e resiliencia no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

Uma viagem dos cartões perfurados à engenharia de confiabilidade moderna

Existe uma curiosidade interessante sobre o universo Mainframe.

Boa parte dos desenvolvedores mais jovens acredita que sistemas COBOL foram escritos uma única vez, colocados em produção em algum momento dos anos 80 e simplesmente ficaram funcionando até hoje, imutáveis, como fósseis tecnológicos preservados em um museu digital.

A realidade é completamente diferente.

Poucas plataformas de tecnologia evoluíram tanto quanto o ecossistema IBM Z.

O hardware mudou.

O sistema operacional mudou.

Os compiladores mudaram.

As técnicas de desenvolvimento mudaram.

A forma de entregar software mudou.

As exigências regulatórias mudaram.

E os desenvolvedores também precisaram mudar.

Hoje falamos sobre APIs REST, Git, DevOps, Inteligência Artificial, Observabilidade, Chaos Engineering e Cloud Native. Entretanto, curiosamente, os sistemas que movimentam bilhões de dólares por dia continuam sendo executados por programas COBOL escritos há décadas.

Seria isso uma contradição?

Na verdade, não.

Talvez seja justamente uma demonstração de sucesso.

O primeiro legado não foi um erro

Em 1959 nasceu o COBOL.

Naquela época não existiam metodologias ágeis.

Não existia internet.

Não existiam smartphones.

Muitos programas eram escritos em cartões perfurados.

Armazenamento era caro.

Memória era limitada.

CPU era um recurso precioso.

As equipes construíam software pensando em algo muito importante:

Confiabilidade.

A aplicação precisava funcionar.

Sempre.

Mesmo que demorasse algumas horas para processar milhares de contas bancárias durante a madrugada.

Foi nesse ambiente que nasceu uma cultura extremamente disciplinada.

Documentação.

Padrões.

Controle de mudanças.

Testes.

Auditorias.

Processos.

Talvez os desenvolvedores daquela época não soubessem, mas estavam criando alguns dos primeiros conceitos de Engenharia de Confiabilidade.

Technical Debt: a dívida que todos nós fazemos

Em 1992, Ward Cunningham criou uma analogia brilhante.

Ele comparou decisões de desenvolvimento com empréstimos bancários.

Imagine que você precise entregar um sistema até sexta-feira.

Você poderia construir uma solução perfeita.

Ou poderia desenvolver algo funcional, mais simples, entregando rapidamente.

Você ganha velocidade.

Mas assume uma dívida.

E como toda dívida, ela possui juros.

Esses juros aparecem de várias formas.

Mais bugs.

Mais incidentes.

Mais retrabalho.

Maior consumo de CPU.

Maior dificuldade de manutenção.

Menor velocidade de inovação.

No Mainframe isso acontece frequentemente.

Talvez exista um programa COBOL com 25 mil linhas.

Talvez exista um COPYBOOK criado em 1987.

Talvez apenas um profissional conheça determinada aplicação.

Tudo isso representa dívida técnica.

O problema não é possuir dívida.

O problema é não saber que ela existe.

Nem toda dívida é ruim

Muitos desenvolvedores iniciantes acreditam que Technical Debt sempre significa erro.

Não é verdade.

Às vezes ela é estratégica.

Um banco pode precisar adequar sistemas rapidamente para atender uma nova regulamentação do BACEN.

Uma seguradora pode precisar disponibilizar um novo produto imediatamente.

Uma fintech pode lançar um MVP para validar mercado.

Nesses casos, assumir dívida técnica pode ser perfeitamente aceitável.

Desde que exista um plano para pagá-la posteriormente.

E aqui encontramos uma das primeiras lições importantes para um desenvolvedor COBOL júnior:

Escreva código pensando que alguém precisará entendê-lo daqui a dez anos.

Esse alguém pode ser você mesmo.

O mito da reescrita completa

Existe uma frase bastante comum em empresas:

"Precisamos jogar tudo fora."

Geralmente essa frase surge quando o ambiente está muito complexo.

Mas a IBM apresenta uma visão diferente.

Você não precisa substituir quarenta anos de sistemas.

Você pode modernizar gradualmente.

Esse conceito ficou conhecido como Strangler Pattern.

Imagine um sistema COBOL que processa contas correntes.

Ele continua funcionando.

Mas uma nova camada é criada.

z/OS Connect.

APIs REST.

Microserviços.

Containers.

Aplicações Java.

Python.

Inteligência Artificial.

O COBOL permanece processando transações críticas.

As aplicações modernas apenas consomem seus serviços.

A dívida começa a diminuir sem que seja necessário desligar o coração operacional da empresa.

Testes automatizados são seus melhores amigos

Durante muitos anos, testar em Mainframe significava reservar uma janela de homologação.

Executar jobs.

Analisar relatórios.

Esperar dias.

Hoje isso mudou.

Ferramentas como zUnit permitem criar testes automatizados.

Jenkins integra pipelines.

GitHub Actions executa validações.

DBB facilita builds.

Zowe aproxima o mundo Mainframe das práticas DevOps modernas.

Se você está começando em COBOL, desenvolva o hábito de pensar:

"O que acontece se o CPF estiver inválido?"

"E se a data vier vazia?"

"E se houver overflow?"

Programadores experientes não escrevem apenas funcionalidades.

Eles escrevem confiança.

Code Review: aprendendo com outros desenvolvedores

Uma das melhores maneiras de evoluir tecnicamente é revisar código.

Olhar programas COBOL antigos.

Analisar SQL.

Entender JCLs.

Perguntar.

Questionar.

Aprender.

Muitos problemas são identificados antes mesmo de chegar à produção.

Um cursor esquecido.

Um COMMIT ausente.

Um SORT desnecessário.

Uma consulta DB2 sem índice adequado.

Dois pares de olhos normalmente enxergam mais do que um.

Refatoração não significa reescrever

Refatorar é melhorar.

Não é destruir.

Não é começar do zero.

Pequenas melhorias acumuladas ao longo do tempo fazem enorme diferença.

Renomear variáveis.

Extrair rotinas.

Separar módulos.

Eliminar GOTO.

Criar serviços reutilizáveis.

Transformar programas gigantes em componentes menores.

Refatoração contínua é uma das formas mais eficientes de pagar Technical Debt.

Observabilidade: enxergando o que realmente acontece

Existe uma frase bastante conhecida:

Se você não consegue medir, não consegue melhorar.

No mundo IBM Z temos ferramentas extraordinárias.

SMF.

RMF.

OMEGAMON.

Instana.

Grafana.

Elas permitem compreender:

CPU.

I/O.

Latência.

Filas.

Conexões.

Transações.

Antes de corrigir qualquer problema, precisamos enxergá-lo.

Observabilidade é a base da engenharia moderna.

Chaos Engineering: quebrando para aprender

Talvez o conceito mais surpreendente para desenvolvedores COBOL seja Chaos Engineering.

A ideia surgiu popularmente na Netflix.

Mas a IBM mostra que ela pode ser aplicada em praticamente qualquer ambiente.

O princípio é simples.

Não espere uma falha em produção.

Provoque pequenas falhas.

Aprenda.

Corrija.

Teste novamente.

Por exemplo:

O que acontece se o IMS Connect ficar indisponível?

Se a fila MQ atingir 95% de ocupação?

Se um membro do Sysplex parar?

Se o DB2 responder lentamente?

Chaos Engineering não significa desligar servidores aleatoriamente.

É ciência.

Você cria uma hipótese.

Executa um experimento controlado.

Observa.

Aprende.

Melhora.

Repete.

Resiliência é um investimento

A IBM utiliza uma analogia muito interessante.

Imagine um ciclista.

Ele pode sair apenas com a bicicleta.

Ou levar uma bomba de ar.

Kit de reparo.

Câmara reserva.

Pneu reserva.

Carro de apoio.

Mecânico.

Quanto maior a disponibilidade desejada, maior será o custo.

Em tecnologia ocorre exatamente o mesmo.

Alta disponibilidade.

Disaster Recovery.

Cyber Recovery.

Backups.

Replicação.

GDPS.

Sysplex.

Active-Active.

Tudo possui custo.

O objetivo não é atingir disponibilidade infinita.

O objetivo é encontrar equilíbrio entre risco, orçamento e necessidade do negócio.

O desenvolvedor COBOL de 2026

O profissional COBOL moderno não é apenas alguém que conhece MOVE, PERFORM e READ.

Ele entende Git.

Conhece APIs.

Aprende DevOps.

Sabe interpretar métricas.

Participa de revisões.

Automatiza testes.

Compreende observabilidade.

Conhece conceitos de segurança.

Entende resiliência.

Estuda Inteligência Artificial.

E principalmente, continua cultivando algo que sempre esteve presente no universo Mainframe:

Disciplina técnica.

Os sistemas que movimentam bilhões de transações diariamente não permanecem relevantes por acaso.

Eles permanecem relevantes porque existem profissionais dispostos a compreender o passado, melhorar continuamente o presente e testar constantemente o futuro.

E talvez seja exatamente essa a maior lição do Mainframe.

Tecnologia muda.

Ferramentas mudam.

Buzzwords mudam.

Mas excelência em engenharia continua sendo atemporal.

E isso, felizmente, nunca sai de moda.

Até o próximo café.

☕ Bellacosa Mainframe


Bellacosa Mainframe Network

Siga nossas newsletters e comunidades no LinkedIn