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

Koko wa Ore ni Makasete Saki ni Ike to Itte kara 10-nen ga Tattara Densetsu ni Natteita

 

Bellacosa Mainframe e o heroi overpower em koko wa ore ni makasete saki ni ike to itte kara 10-nen ga tattara densetsu ni natteita

☕ Um Café no Bellacosa Mainframe

Koko wa Ore ni Makasete Saki ni Ike to Itte kara 10-nen ga Tattara Densetsu ni Natteita (ここは俺に任せて先に行けと言ってから10年がたったら伝説になっていた。)

Quando um Programador COBOL Descobre que Sustentar a Produção por 10 Anos Vale Muito Mais do que Receber os Créditos do Projeto

"No IBM Z existe um profissional que raramente aparece nas apresentações da diretoria. Enquanto todos comemoram novas aplicações, ele permanece silenciosamente mantendo milhares de transações por segundo funcionando sem interrupções. Luck é exatamente esse profissional."


Ficha Técnica

Título original:
ここは俺に任せて先に行けと言ってから10年がたったら伝説になっていた。

Romaji
Koko wa Ore ni Makasete Saki ni Ike to Itte kara 10-nen ga Tattara Densetsu ni Natteita

Título internacional
I Became a Legend After My 10 Year-Long Last Stand

Autor
Ezogingitsune

Ilustrações (Light Novel)
DeeCHA

Mangá
Arte de Chako Abeno, composição de Kitsune Tennōji.

Estúdio
Gekkou

Diretor
Hiroyuki Kanbe

Roteiro
Mitsutaka Hirota

Música
Tomotaka Ōsumi

Estreia do anime
Julho de 2026 (estreia em TV em 6 de julho de 2026; distribuição antecipada em streaming em 3 de julho). (Wikipedia)

Episódios
12 episódios (1ª temporada). (Anilist)


Sinopse

Após derrotar o Rei Demônio, ainda resta um problema gigantesco.

Milhares de demônios continuam chegando através de uma fenda entre dimensões.

Para impedir uma nova invasão, o poderoso mago Luck Lock Franzen diz aos companheiros:

"Deixem isso comigo. Sigam em frente."

O grupo acredita que voltará em poucos minutos.

Mas isso nunca acontece.

Luck permanece lutando durante dez anos.

Quando finalmente consegue fechar a passagem, retorna ao mundo humano e descobre que tudo mudou.

Seus amigos envelheceram.

O reino prosperou.

Seu sacrifício tornou-se uma lenda.

Agora, ele precisa descobrir qual é seu lugar em um mundo que continuou existindo sem ele. (Wikipedia)


A história

A maioria das fantasias termina quando o Rei Demônio é derrotado.

Esta começa justamente depois.

O anime explora uma pergunta rara:

Como é a vida de um herói depois da batalha?

Luck perdeu uma década inteira de convivência.

Enquanto salvava o mundo, deixou de viver.

Essa inversão transforma uma fantasia de ação em um drama sobre tempo, identidade e pertencimento.


Principais personagens

Luck Lock Franzen

Um arquimago extremamente poderoso.

Sua força nunca é usada para demonstrar superioridade.

Ela representa responsabilidade.

Quanto mais poderoso ele é, maior é o peso que decide carregar sozinho.


Eric

O herói original.

Representa aqueles que continuam vivendo enquanto outros sustentam os bastidores.


Golan

O guerreiro veterano.

A amizade entre ele e Luck transmite respeito e lealdade, sem rivalidade.


Sia Wolcott

Caçadora experiente que amplia a narrativa após o retorno de Luck, trazendo novos conflitos e mostrando que o mundo seguiu em frente. (Wikipedia)


O Studio Gekkou

Embora seja um estúdio relativamente novo, o Gekkou buscou uma adaptação fiel ao material original, priorizando cenários amplos, magia com efeitos limpos e um ritmo mais contemplativo do que frenético. A direção de Hiroyuki Kanbe e o roteiro de Mitsutaka Hirota reforçam a evolução emocional do protagonista acima do espetáculo visual. (Wikipedia)


O que torna este anime diferente?

O protagonista já começa extremamente poderoso.

Mas esse nunca é o foco.

A história trata de:

  • responsabilidade;

  • sacrifício;

  • maturidade;

  • passagem do tempo;

  • consequências das escolhas.

Não existe treinamento infinito.

Não existe sistema de níveis.

Não existe evolução baseada apenas em poder.

Existe crescimento humano.


Temáticas

O peso da responsabilidade

Luck nunca pergunta:

"Quem vai me salvar?"

Ele pergunta:

"Quem precisa ser salvo?"

É uma diferença enorme.


O tempo perdido

Os dez anos simbolizam algo que dinheiro nenhum compra.

Tempo.

O anime mostra como o verdadeiro preço do heroísmo não é o perigo.

É tudo aquilo que deixamos de viver.


Reconhecimento tardio

Quando retorna, Luck é considerado uma lenda.

Mas poucos conhecem quem ele realmente é.

Isso acontece com inúmeros profissionais veteranos.

Todos conhecem o sistema.

Poucos conhecem quem o construiu.


Humildade

Mesmo sendo um dos maiores magos do mundo, Luck continua tratando todos com respeito.

Sua grandeza nunca depende da necessidade de provar que é forte.


Aventuras

Cada arco combina fantasia clássica com exploração do novo mundo:

  • reencontros emocionantes;

  • cidades transformadas;

  • novas gerações de aventureiros;

  • caçadas a monstros;

  • missões mágicas;

  • proteção de inocentes;

  • descoberta de conspirações.

As batalhas existem.

Mas quase sempre servem para desenvolver personagens.


As mensagens ocultas

O verdadeiro herói trabalha invisível

Os maiores feitos normalmente acontecem longe dos holofotes.


Nem toda vitória produz felicidade imediata

Salvar o mundo não devolve automaticamente os anos perdidos.


O mundo continua

Mesmo quando estamos enfrentando nossos maiores desafios.

Essa é talvez a mensagem mais madura do anime.


Experiência vale mais que talento

Luck não vence apenas por possuir magia poderosa.

Ele vence porque aprendeu durante dez anos enfrentando situações impossíveis.


O impacto cultural

A obra chamou atenção por fugir do padrão dos protagonistas impulsivos e focar em um adulto responsável. Também reforçou uma tendência recente da fantasia japonesa: histórias sobre o "pós-aventura", em que as consequências emocionais da jornada recebem mais destaque do que a batalha final. (Anilist)


Ao estilo Bellacosa Mainframe

Este anime praticamente descreve a vida de muitos profissionais IBM Z.

Imagine um banco.

Existe um sistema COBOL iniciado nos anos 1980.

Durante décadas ele processa:

  • PIX;

  • cartões;

  • TED;

  • folha de pagamento;

  • crédito;

  • financiamentos;

  • seguros.

Enquanto todos falam sobre Cloud, Kubernetes, IA e microsserviços, alguém continua garantindo que bilhões de transações funcionem diariamente.

Esse profissional raramente recebe prêmios.

Mas, se ele desaparecer por uma semana, a empresa inteira percebe seu valor.

Luck representa exatamente esse especialista.

Ele ficou "segurando a produção" por dez anos.

Quando voltou, todos o chamavam de lenda.

No Mainframe acontece o mesmo.

Os verdadeiros heróis quase nunca aparecem nas apresentações de PowerPoint.

Eles aparecem às três da manhã, quando um ABEND ameaça parar a produção.

Eles conhecem JCL, COBOL, CICS, Db2, IMS, VSAM, RACF e JES2 não porque leram um manual, mas porque viveram milhares de incidentes reais.

Luck não é apenas um mago.

Ele é o equivalente ao engenheiro que passou uma década mantendo um ambiente crítico funcionando sem interrupções.

No Bellacosa Mainframe, costumo dizer que a verdadeira engenharia não é criar algo que funciona por cinco minutos em um laboratório.

É construir algo que continua funcionando dez anos depois.

Luck entende isso.

E todo grande profissional IBM Z também.


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.


LV999 no Murabito: O Programador que Recebeu Autoridade SYSADM no Universo — A Análise Definitiva do Isekai que Hackeia o Próprio Sistema Operacional do Mundo

 



☕ Um Café no Bellacosa Mainframe

LV999 no Murabito: O Programador que Recebeu Autoridade SYSADM no Universo — A Análise Definitiva do Isekai que Hackeia o Próprio Sistema Operacional do Mundo

"No IBM Z existe uma regra simples: privilégios definem o que você pode fazer. Em LV999 no Murabito, o protagonista descobre que o verdadeiro poder não é ter uma classe lendária... é entender como o sistema foi construído."


Ficha Técnica

ItemInformação
Título OriginalLV999の村人 (LV999 no Murabito)
Título InternacionalThe Level 999 Villager
Autor (Light Novel)星月子猫 (Hoshitsuki Koneko)
Ilustradorふーみ (Fuumi)
Mangá岩元健一 (Kenichi Iwamoto)
GêneroIsekai, Fantasia, Ação, Aventura, Mistério, RPG, Drama
DemografiaShounen
Publicação da Novel2016
Mangá2017
AnimeEstreia prevista para 2026
EstúdioBrain's Base
EpisódiosAinda não oficialmente confirmados (espera-se 12 ou 13 na primeira temporada)

Sinopse

Imagine um mundo onde absolutamente tudo funciona como um MMORPG.

Cada pessoa nasce com uma classe.

  • Herói

  • Guerreiro

  • Mago

  • Sacerdote

  • Mercador

  • Ferreiro

  • Aldeão

A classe determina literalmente toda sua vida.

O protagonista nasce como...

Murabito (Aldeão).

A pior classe existente.

Mas existe um detalhe.

Seu nível chega a 999.

A partir desse momento, todas as regras deixam de fazer sentido.


A História

Diferentemente da maioria dos isekais, aqui não acompanhamos alguém que foi atropelado pelo Truck-kun.

Nem um reencarnado.

Nem um invocado.

É um mundo que sempre existiu.

Kagami vive nele desde o nascimento.

Mas ele começa a perceber algo estranho.

Por que existem níveis?

Quem criou esse sistema?

Por que monstros aparecem?

Por que ouro surge após derrotá-los?

Por que as pessoas aceitam tudo isso sem questionar?

Essas perguntas mudam completamente o rumo da obra.

O anime deixa de ser uma aventura RPG e passa a investigar a arquitetura invisível daquele universo.


O Grande Diferencial

Nos primeiros capítulos parece apenas outro anime de protagonista overpower.

Na realidade...

não é.

A história rapidamente muda de direção.

O verdadeiro inimigo não é o Rei Demônio.

É o próprio sistema que controla o mundo.

Essa mudança lembra bastante obras como:

  • Matrix

  • Overlord

  • Log Horizon

  • Deca-Dence

mas mantendo identidade própria.


Personagens Principais

Kagami

O protagonista.

Extremamente inteligente.

Não luta apenas usando força.

Questiona tudo.

É praticamente um "engenheiro reverso" do universo.


Alice

Uma das personagens mais importantes.

Representa o lado emocional da história.

Seu desenvolvimento acompanha o amadurecimento do protagonista.


Rei Demônio

Muito diferente do arquétipo clássico.

Sua existência possui razões muito mais profundas do que simplesmente conquistar o mundo.


Os Heróis

Funcionam quase como processos automatizados.

Executam aquilo que foram programados para fazer.

Sem jamais questionar.


Temática

A obra fala sobre:

  • livre-arbítrio

  • desigualdade social

  • destino

  • meritocracia

  • preconceito

  • inteligência

  • manipulação

  • engenharia social

  • sistemas fechados

  • evolução tecnológica

É muito mais filosófica do que parece.


O que existe de diferente?

Aqui ninguém ganha poder por amizade.

Nem por treinamento milagroso.

O protagonista vence porque entende o funcionamento do sistema.

É quase um administrador de banco de dados descobrindo como o catálogo do DB2 funciona internamente.


A Analogia Bellacosa Mainframe

Imagine que aquele mundo seja um IBM Z.

As classes são o RACF.

Cada usuário recebe um perfil.

USER A
CLASS HERO

USER B
CLASS MAGE

USER C
CLASS MERCHANT

USER D
CLASS VILLAGER

Todos acreditam que isso nunca pode mudar.

Mas Kagami encontra algo equivalente a possuir autoridade SYSADM.

Ele percebe que o sistema inteiro pode ser alterado.

A partir daí, deixa de jogar.

Passa a administrar.

É exatamente a diferença entre:

usar um aplicativo

e

entender o sistema operacional.


Aventura

Cada arco revela um novo nível de complexidade.

Primeiro:

monstros.

Depois:

nações.

Depois:

demônios.

Depois:

a origem das classes.

Depois:

a arquitetura do mundo.

Cada resposta gera perguntas ainda maiores.


Mensagens Ocultas

1. A sociedade aceita regras sem perguntar

Todos vivem presos ao sistema.

Pouquíssimos perguntam quem criou esse sistema.

Isso lembra empresas antigas.

"Mantemos assim porque sempre foi assim."


2. Especialização excessiva limita pessoas

Cada classe define um destino.

Isso é semelhante ao mercado de trabalho.

"Cobol só programa COBOL."

"Java só programa Java."

A obra mostra que conhecimento supera especialização.


3. O verdadeiro poder é conhecimento

O nível 999 impressiona.

Mas o que realmente muda tudo é compreender a arquitetura.

No mundo IBM Z isso vale ouro.


4. Liberdade exige responsabilidade

Quando você entende como tudo funciona...

também passa a carregar o peso das decisões.


Engenharia de Software Disfarçada

A obra fala sobre:

  • arquitetura

  • dependências

  • sistemas legados

  • evolução

  • manutenção

  • compatibilidade

  • regras de negócio

Mesmo sem usar esses nomes.


Comparação com Mainframe

LV999IBM Z
ClassesRACF
NíveisAutorizações
Mundoz/OS
Rei DemônioProcesso crítico
HeróisBatch Jobs
KagamiSysprog
Sistema do MundoKernel do z/OS
Quebrar as regrasAlterar parâmetros do sistema

O Estúdio Brain's Base

O Brain's Base é conhecido por equilibrar ação, humor e desenvolvimento de personagens. Entre seus trabalhos mais reconhecidos estão:

  • Durarara!!

  • Baccano!

  • Natsume Yuujinchou

  • Spice and Wolf (1ª temporada)

Sua direção costuma privilegiar narrativa consistente e personagens carismáticos, o que combina bem com uma obra que depende tanto de mistério quanto de combates.


Houve censura?

Até o momento, não há registros relevantes de censura oficial envolvendo a light novel, o mangá ou a adaptação em anime. A série não é conhecida por violência extrema, erotização excessiva ou temas que tenham provocado alterações significativas em diferentes mercados.


Impacto Cultural

Embora não tenha alcançado a popularidade de gigantes como Mushoku Tensei, Overlord ou Re:ZERO, LV999 no Murabito conquistou um público fiel por fugir da fórmula do "protagonista apelão". Muitos leitores destacam justamente a mudança de foco: da evolução de atributos para a investigação das regras do mundo e de sua origem.

Sua adaptação para anime tende a ampliar esse alcance, especialmente entre fãs de fantasia com forte componente de mistério.


Classificação

Gêneros

  • Fantasia

  • Isekai (ambientação de fantasia inspirada em RPG)

  • Ação

  • Aventura

  • Mistério

  • Drama

Público recomendado

  • Adolescentes e adultos.

Classificação indicativa estimada

  • 14 anos ou mais, devido a cenas de combate e temas filosóficos.


Veredito Bellacosa Mainframe

História: 9,3/10
Construção de Mundo: 9,6/10
Personagens: 8,9/10
Mistério: 9,7/10
Ação: 8,8/10
Originalidade: 9,5/10
Analogia com IBM Z: 10/10

Conclusão

À primeira vista, LV999 no Murabito parece apenas mais um isekai com um protagonista absurdamente forte. Porém, sua verdadeira força está em mostrar que o maior poder não é possuir os melhores atributos, mas compreender as regras invisíveis que governam todo o sistema.

Sob a ótica do Bellacosa Mainframe, Kagami não é simplesmente um aventureiro de nível 999. Ele se comporta como um Sysprog do IBM Z: alguém que deixa de enxergar apenas as aplicações e passa a entender o kernel, as permissões, a arquitetura e a lógica que sustentam toda a plataforma.

É uma obra que recompensa quem gosta de desmontar sistemas, investigar suas origens e perguntar "por quê?". Para profissionais de tecnologia — especialmente aqueles acostumados com ambientes complexos como o IBM Z — essa perspectiva torna a experiência ainda mais rica do que aparenta à primeira vista.

domingo, 28 de junho de 2026

Ryoumin 0-Nin Start no Henkyou Ryoushu-sama

 

Bellacosa Mainframe apresenta ryoumin 0-nin start no henkyou ryoushu-sama

☕ Um Café no Bellacosa Mainframe

Ryoumin 0-Nin Start no Henkyou Ryoushu-sama (領民0人スタートの辺境領主様)

Quando um Programador COBOL Descobre que o Verdadeiro Desafio Nunca Foi Escrever Código — Foi Construir um Ecossistema Inteiro do Zero

Se existe um anime que conversa diretamente com quem trabalha há anos em IBM Z, não é porque fala de computadores. É porque fala de algo muito mais importante: construção de legado.

Enquanto a maioria dos isekais gira em torno de derrotar o Rei Demônio ou obter habilidades absurdamente poderosas, Ryoumin 0-Nin Start no Henkyou Ryoushu-sama escolhe um caminho completamente diferente.

O protagonista recebe uma recompensa gigantesca.

Mas essa recompensa é praticamente inútil.

Ele ganha um território enorme...

...com zero habitantes.

Para qualquer administrador de sistemas isso soa familiar.

Receber um ambiente vazio significa possuir apenas infraestrutura. Valor de verdade só aparece quando processos, pessoas, conhecimento e organização começam a existir.

É exatamente essa jornada que torna esta obra tão interessante.


Dados da obra

Título original:
領民0人スタートの辺境領主様

Romanização:
Ryoumin 0-Nin Start no Henkyou Ryoushu-sama

Título internacional:
The Frontier Lord Begins with Zero Subjects

Autor (Light Novel):
Fuurou (風楼)

Ilustrador:
Kinta

Mangá:
Yumbo

Web Novel:
Shousetsuka ni Narou (2018)

Light Novel:
Earth Star Entertainment

Mangá:
Comic Earth Star

Anime

  • Estúdio: animation studio42

  • Diretor: Kenichi Imaizumi

  • Roteiro: Kunihiko Okada

  • Character Design: Keiichi Tsuboyama

  • Estreia: julho de 2026. (Studio42)


Quantidade de episódios

A primeira temporada estreou em julho de 2026 e está em exibição. O número total de episódios ainda não foi oficialmente confirmado pela produção. (TVアニメ『領民0人スタートの辺境領主様』公式サイト)


Gênero

  • Fantasia

  • Slice of Life

  • Kingdom Building

  • Aventura

  • Drama

  • Administração

  • Romance leve

  • Desenvolvimento de território


Classificação

Indicado para adolescentes e adultos.

Apesar de possuir cenas de combate, o foco está muito mais na construção de comunidades do que em violência.


Sinopse

Dias passou praticamente toda sua vida lutando pelo reino.

Após inúmeras campanhas militares torna-se um herói nacional.

Como recompensa, o rei entrega um enorme território.

Quando finalmente chega ao local...

...descobre apenas um enorme campo vazio.

Sem cidade.

Sem moradores.

Sem castelo.

Sem fazendas.

Sem estradas.

Sem economia.

Seu domínio começa literalmente com zero habitantes.

O primeiro encontro importante acontece com Alna, uma jovem de um povo de chifres azuis, cuja amizade muda completamente o destino daquela fronteira. A partir daí, Dias transforma uma terra abandonada em uma comunidade próspera, atraindo colonos, agricultores, artesãos e comerciantes. (BS Asahi)


Resumo da história

O anime acompanha um veterano de guerra que precisa aprender uma profissão completamente diferente.

Durante décadas ele aprendeu apenas:

  • lutar;

  • proteger;

  • obedecer ordens.

Agora precisa aprender:

  • administrar;

  • negociar;

  • produzir alimentos;

  • resolver conflitos;

  • liderar pessoas;

  • planejar o futuro.

Essa mudança de perspectiva é o coração da narrativa.


Personagens principais

Dias

O protagonista.

Um guerreiro praticamente imbatível.

Curiosamente, sua maior qualidade não é sua força.

É sua humildade.

Ele sabe que não entende nada sobre agricultura, economia ou administração e aceita aprender com qualquer pessoa.


Alna

A primeira moradora importante.

Gentil, trabalhadora e extremamente otimista.

Ela representa a ligação entre Dias e o novo mundo que está sendo construído.


Klaus

Ajuda na expansão e organização da comunidade, contribuindo para o desenvolvimento da fronteira.


Senai

Participa dos desafios sociais e políticos da nova vila, trazendo novas perspectivas ao grupo.


Eldan

Um dos personagens experientes que ampliam o universo político e administrativo da obra.


O que torna esta obra diferente?

A maioria dos isekais segue uma fórmula conhecida:

  • protagonista overpower;

  • derrotar demônios;

  • salvar o reino.

Aqui acontece o contrário.

O grande inimigo é:

  • falta de mão de obra;

  • ausência de infraestrutura;

  • escassez de alimentos;

  • isolamento;

  • clima;

  • administração.

É quase um simulador de construção de cidades transformado em anime.


As aventuras

As aventuras são surpreendentemente "mundanas", mas extremamente interessantes.

Dias precisa:

  • construir casas;

  • abrir estradas;

  • desenvolver agricultura;

  • criar relações diplomáticas;

  • resolver conflitos internos;

  • atrair novos moradores;

  • organizar defesa;

  • criar comércio;

  • integrar diferentes povos.

Cada pequeno avanço muda completamente a economia da região.


Temáticas

A obra aborda:

  • liderança;

  • responsabilidade;

  • reconstrução;

  • cooperação;

  • imigração;

  • diversidade cultural;

  • crescimento econômico;

  • desenvolvimento sustentável;

  • confiança;

  • amizade;

  • planejamento de longo prazo.


Mensagens ocultas

1. Liderar é servir

Dias nunca governa impondo medo.

Ele trabalha junto.

No Mainframe acontece exatamente o mesmo.

Os melhores líderes são aqueles que entram na madrugada durante uma migração crítica.


2. Nenhum sistema nasce pronto

Todo grande banco começou pequeno.

Toda cidade começou pequena.

Toda aplicação COBOL começou com o primeiro programa.

O anime mostra exatamente isso.


3. Pessoas são mais importantes que tecnologia

O título já entrega essa filosofia.

Zero habitantes.

Não existe economia sem pessoas.

Não existe software sem usuários.

Não existe empresa sem profissionais.


4. Especialistas não sabem tudo

Dias domina combate.

Mas precisa aprender agricultura.

Da mesma forma:

Um excelente programador COBOL precisa compreender:

  • negócios;

  • SQL;

  • APIs;

  • DevOps;

  • observabilidade;

  • segurança.

Especialização nunca elimina aprendizado contínuo.


5. Crescimento verdadeiro é lento

Nada aparece magicamente.

Cada novo morador representa investimento.

Cada construção representa planejamento.

É uma metáfora muito bonita sobre evolução contínua.


Impacto cultural

Mesmo antes da adaptação para TV, a light novel e o mangá já eram conhecidos entre fãs de slow life e kingdom building. A estreia do anime em julho de 2026 ampliou a visibilidade da obra, especialmente entre quem aprecia fantasias focadas em gestão e desenvolvimento de comunidades, em vez de batalhas incessantes. As primeiras discussões da comunidade destacam justamente esse ritmo mais calmo e o foco na construção de um território. (Anime United)


Bellacosa Mainframe — A Grande Analogia

Existe uma frase muito conhecida entre profissionais IBM Z:

"Colocar um sistema em produção é apenas o início."

Qualquer desenvolvedor consegue criar um programa.

Poucos conseguem mantê-lo útil durante décadas.

Dias descobre exatamente essa diferença.

Receber um território é fácil.

Difícil é fazê-lo prosperar.

No universo Mainframe acontece o mesmo.

Escrever um programa COBOL pode levar dias.

Construir um ecossistema corporativo que sobreviva por quarenta anos exige algo muito maior: arquitetura, documentação, governança, padronização, integração, monitoramento e, acima de tudo, pessoas.

No fim, Ryoumin 0-Nin Start no Henkyou Ryoushu-sama mostra que o maior poder de um herói não é derrotar monstros. É criar um ambiente onde outras pessoas possam crescer. Essa é a essência dos grandes arquitetos de software e dos veteranos do IBM Z: deixar um legado que continue funcionando muito depois que eles seguirem para a próxima missão.

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.