Divaguei muito fugindo ao tópico central, hoje vamos falar sobre Mainframe ,esta overview tem como objetivo apresentar aos padawan, detalhes sobre o mais antigo sistema operacional em funcionamento, por incrível que parece, surgiu nos anos 70, passou por transformações e inovações mas em sua essência, digamos o Kernel, é uma atualização hiper turbina do OS/360 o sistema operacional dos potentes computadores IBM.
Leia na integra
✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
domingo, 25 de fevereiro de 2024
sábado, 24 de fevereiro de 2024
🔻 Dia 730 – O Segundo Inverno: quando o mundo aprendeu a conviver com a guerra
🔻 Dia 730 – O Segundo Inverno: quando o mundo aprendeu a conviver com a guerra
Por Bellacosa Mainframe | Crônicas do Front Adormecido
Dois anos.
A contagem virou calendário, e o calendário virou cicatriz.
Hoje é 24 de fevereiro de 2024, e a guerra na Ucrânia continua — menos barulhenta, mais pesada. O som das bombas se misturou ao da rotina, e o mundo aprendeu a viver com o absurdo.
A guerra já não é manchete; é plano de fundo. Um ruído constante na história moderna.
🕯️ O Segundo Inverno
As cidades ucranianas estão cobertas de neve e saudade.
Os abrigos viraram casas, os generadores viraram vizinhos, e as escolas voltaram a abrir com paredes remendadas por esperança.
As crianças brincam entre crateras, e os adultos fingem não notar o som distante dos drones. A vida insiste.
Mas há algo novo no ar — um cansaço que nem o heroísmo cura. O mundo parou de se perguntar “quando acaba?” e começou a perguntar “como continua?”
⚙️ A Máquina da Guerra Não Parou
A Rússia consolidou o império de fumaça: territórios ocupados, fronteiras movediças, discursos que misturam nostalgia e medo.
O Ocidente, cansado de prometer ajuda infinita, fala agora em “equilíbrio estratégico” — expressão elegante para dizer que a esperança perdeu orçamento.
As sanções ainda existem, mas perderam dentes. O gás voltou a circular, o comércio se adaptou, e a hipocrisia global aprendeu a se maquiar de neutralidade.
🛰️ O Campo Invisível: A Guerra Digital Evolui
Se em 2022 o front era físico, e em 2023 era psicológico, em 2024 ele é informacional.
Inteligências artificiais fabricam testemunhos, vozes, até líderes falsos. A verdade, aquela velha companheira, virou peça rara — e valiosa.
A desinformação é a nova bomba. Invisível, silenciosa, eficaz.
🕊️ A Ucrânia, Ainda
Ainda de pé. Ainda lutando.
Zelensky é agora uma figura trágica e quase mítica — o homem que envelheceu dez anos por cada inverno.
O país sobrevive, não pela força, mas pela teimosia. Pela crença de que resistir é existir.
Nas trincheiras, há mais soldados do que sonhos. Mas há também poetas, pintores, músicos — artistas de guerra, moldando dor em arte, e caos em memória.
🌍 O Mundo Que Se Acostumou
A guerra deixou de ser um choque e virou um hábito — e talvez esse seja o verdadeiro colapso moral do século XXI.
Os noticiários já não choram, os influenciadores não postam bandeiras azuis e amarelas, os protestos perderam o brilho.
Mas lá, no leste da Europa, o tempo ainda tem cheiro de pólvora.
💬 Para o Padawan que observa o terceiro inverno se aproximando:
Nem toda guerra termina com tratado. Algumas apenas desbotam, até que o mundo esqueça as razões e só lembre das ruínas.
Aprenda isto:
A paz não é o contrário da guerra.
É o intervalo frágil entre duas desilusões.
🕯️ Dois anos depois, o planeta aprendeu a conviver com o absurdo.
E a Ucrânia, sozinha no frio, ainda carrega a chama que o mundo cansou de olhar.
sexta-feira, 23 de fevereiro de 2024
RAD (Rapid Application Development) — Como Implementar RAD na Prática, Principais Metodologias, Ferramentas - Parte II
 |
| Bellacosa Mainframe apresenta o rad parte ii |
☕ Um Café no Bellacosa Mainframe
RAD (Rapid Application Development)
Parte II — Como Implementar RAD na Prática, Principais Metodologias, Ferramentas e o Papel da Inteligência Artificial
"Desenvolver rapidamente nunca significou programar rapidamente. Significou aprender rapidamente."
Recapitulando
Na primeira parte desta série vimos que o RAD nasceu como resposta a um problema que ainda existe.
Empresas mudam rapidamente.
Os negócios mudam rapidamente.
Os clientes mudam rapidamente.
O software precisa acompanhar esse ritmo.
James Martin percebeu isso no início dos anos 90, muito antes de ouvirmos falar de Scrum, DevOps, Cloud Computing ou Inteligência Artificial.
Mas existe uma pergunta ainda mais importante.
Como colocar RAD em prática?
É exatamente isso que veremos agora.
Porque conhecer a teoria é relativamente simples.
O verdadeiro desafio está em transformar uma equipe tradicional em uma equipe capaz de entregar software continuamente.
A filosofia do RAD
Antes de falar de ferramentas precisamos compreender uma característica importante.
RAD não é uma ferramenta.
RAD não é uma linguagem.
RAD não é um framework.
RAD é uma filosofia de desenvolvimento.
Essa diferença muda tudo.
Uma empresa pode utilizar Java.
Outra COBOL.
Outra Python.
Outra C#.
Outra JavaScript.
Todas podem aplicar RAD.
O que muda não é a tecnologia.
É a maneira como ela é utilizada.
O primeiro passo: definir um problema pequeno
O maior erro cometido por equipes iniciantes é querer desenvolver todo o sistema de uma única vez.
RAD faz exatamente o contrário.
Começa pequeno.
Muito pequeno.
Imagine um banco.
Ao invés de desenvolver todo o Internet Banking...
Começa apenas pela consulta de saldo.
Depois extrato.
Depois PIX.
Depois investimentos.
Depois cartões.
Cada funcionalidade nasce praticamente como um pequeno projeto.
Essa abordagem reduz riscos.
Se algo der errado...
O prejuízo é pequeno.
Segundo passo: montar uma equipe enxuta
RAD funciona melhor quando existe pouca burocracia.
Normalmente encontramos equipes compostas por:
Analista de Negócios
Usuário-chave
Desenvolvedor
Especialista em Banco de Dados
Testador
Arquiteto
Não significa que grandes empresas trabalhem apenas com seis pessoas.
Significa que cada módulo possui autonomia.
Quanto menor a cadeia de aprovação...
Maior a velocidade.
Terceiro passo: envolver o usuário desde o primeiro dia
Este talvez seja o segredo mais importante.
No desenvolvimento tradicional o usuário aparece em três momentos.
Levantamento.
Homologação.
Produção.
No RAD ele participa praticamente todos os dias.
Imagine um gerente de crédito.
Na segunda-feira ele vê uma tela.
Na terça sugere mudanças.
Na quarta recebe uma nova versão.
Na quinta encontra outro detalhe.
Na sexta aprova.
Foram cinco dias.
Não cinco meses.
Quarto passo: criar um protótipo
Muitos desenvolvedores acreditam que um protótipo precisa funcionar.
Nem sempre.
Às vezes basta desenhar as telas.
Hoje existem dezenas de ferramentas para isso.
Figma.
Balsamiq.
Adobe XD.
Draw.io.
PowerPoint.
Até papel e caneta funcionam.
O objetivo não é impressionar.
É descobrir rapidamente se a ideia faz sentido.
Quinto passo: construir um MVP
Outro conceito herdado pelo desenvolvimento moderno.
MVP significa:
Minimum Viable Product
Ou Produto Mínimo Viável.
É a menor versão possível capaz de gerar valor.
Não significa software incompleto.
Significa software focado.
Imagine um sistema de empréstimos.
Ao invés de desenvolver quarenta funcionalidades...
Construa apenas cinco.
Se resolverem o problema principal...
O MVP cumpriu seu papel.
Sexto passo: validar rapidamente
Depois do MVP vem o momento mais importante.
Mostrar ao usuário.
Sem apresentações longas.
Sem centenas de slides.
Sem documentos enormes.
Coloque o sistema na frente dele.
Observe.
Escute.
Anote.
Melhore.
Repita.
Esse ciclo acontece inúmeras vezes.
Sétimo passo: melhorar continuamente
RAD nunca considera o software terminado.
Sempre existe espaço para melhorias.
Esse conceito influenciou diretamente o DevOps.
A aplicação evolui continuamente.
Pequenas melhorias.
Pequenos ajustes.
Pequenas correções.
Pequenas entregas.
O resultado costuma ser muito superior a uma única entrega gigantesca.
Como medir se o RAD está funcionando?
Toda metodologia precisa de indicadores.
Caso contrário ela vira opinião.
Algumas métricas importantes são:
Tempo até a primeira entrega
Quanto tempo levou para o usuário ver algo funcionando?
Dias?
Semanas?
Meses?
Quanto menor esse tempo...
Melhor.
Tempo de resposta às mudanças
Quanto tempo leva para alterar uma regra?
Horas?
Dias?
Semanas?
Se pequenas alterações exigem meses...
O processo ainda é pesado.
Número de retrabalhos
Se o usuário rejeita constantemente o software...
Algo está errado.
RAD busca reduzir retrabalho através do feedback constante.
Satisfação do usuário
Talvez seja o indicador mais importante.
Software existe para resolver problemas.
Não para produzir documentação.
As metodologias que herdaram conceitos do RAD
Embora o RAD seja uma metodologia própria, diversos movimentos posteriores incorporaram suas ideias.
Scrum
Sprint.
Incrementos.
Revisões.
Backlog.
Todos esses conceitos possuem enorme afinidade com RAD.
A principal diferença é que Scrum adicionou uma estrutura mais formal para gerenciamento.
Extreme Programming (XP)
XP talvez seja a metodologia que mais herdou conceitos do RAD.
Ela enfatiza:
feedback constante;
integração contínua;
programação em pares;
testes automatizados;
pequenas entregas.
Na prática, XP leva o RAD para um nível técnico ainda maior.
Lean Software Development
O Lean nasceu inspirado no Sistema Toyota.
Seu foco é eliminar desperdícios.
Curiosamente...
RAD também fazia exatamente isso.
Ambos valorizam aquilo que gera valor ao cliente.
DevOps
Muitos imaginam que DevOps trata apenas de infraestrutura.
Não.
DevOps também reduz o tempo entre desenvolver e colocar em produção.
Essa busca pela velocidade é um dos princípios centrais do RAD.
Agile
Podemos dizer que o RAD foi um dos grandes precursores do movimento ágil.
Nem todos concordam com essa afirmação.
Mas basta observar os princípios.
Feedback rápido.
Cliente presente.
Entregas frequentes.
Iterações.
Tudo isso já aparecia no RAD.
Ferramentas clássicas do RAD
Nos anos 90 existia uma verdadeira explosão de ferramentas RAD.
Algumas desapareceram.
Outras evoluíram.
Outras continuam presentes.
Entre elas:
PowerBuilder
Uma das maiores referências da época.
Construía aplicações corporativas rapidamente.
Oracle Forms
Durante muitos anos dominou aplicações empresariais.
Principalmente no ambiente Oracle.
Visual Basic
Talvez o maior símbolo do RAD para plataformas Windows.
Arrastar componentes.
Criar telas.
Conectar banco.
Gerar aplicações em poucas horas.
Delphi
Um dos ambientes RAD mais famosos da história.
Compilação extremamente rápida.
Excelente desempenho.
Grande produtividade.
Até hoje possui uma comunidade fiel.
GeneXus
Muito conhecido na América Latina.
Gera aplicações automaticamente para diversas plataformas.
Utilizado inclusive em grandes instituições financeiras.
Magic xpa
Ferramenta RAD voltada ao ambiente corporativo.
Muito utilizada em integração de sistemas.
Ferramentas modernas
O conceito continua vivo.
Mudaram apenas os nomes.
Hoje encontramos:
Microsoft Power Apps
Google AppSheet
OutSystems
Mendix
ServiceNow App Engine
Salesforce Lightning
Oracle APEX
Retool
FlutterFlow
Bubble
Appian
Zoho Creator
Todas seguem praticamente a mesma ideia.
Construir rapidamente.
Validar rapidamente.
Entregar rapidamente.
RAD e Low-Code
É impossível falar de RAD sem mencionar Low-Code.
Na prática...
Low-Code tornou o RAD muito mais poderoso.
Imagine criar uma tela.
Conectar um banco.
Criar APIs.
Publicar na nuvem.
Tudo isso praticamente sem escrever código.
O RAD encontrou no Low-Code um parceiro natural.
RAD e No-Code
O No-Code leva esse conceito ainda mais longe.
Usuários de negócio conseguem construir soluções simples.
Sem depender completamente da TI.
Isso acelera protótipos.
Validações.
Experimentos.
Naturalmente, sistemas críticos ainda exigem desenvolvimento profissional.
Especialmente no Mainframe.
Inteligência Artificial e RAD
Talvez este seja o maior salto desde os anos 90.
Hoje a IA consegue:
Gerar código.
Criar documentação.
Escrever testes.
Produzir APIs.
Criar consultas SQL.
Explicar código legado.
Converter linguagens.
Criar protótipos.
Documentar regras de negócio.
Isso reduz drasticamente o tempo de desenvolvimento.
Mas existe um detalhe importante.
A IA acelera.
Ela não substitui engenharia.
Alguém continua precisando tomar decisões arquiteturais.
Performance no RAD
Existe outro mito bastante conhecido.
"Software desenvolvido rapidamente é lento."
Não necessariamente.
Performance depende muito mais da arquitetura.
Uma aplicação construída em RAD pode apresentar excelente desempenho quando possui:
arquitetura bem definida;
banco de dados otimizado;
índices corretos;
consultas eficientes;
cache adequado;
testes de carga;
monitoramento constante.
O problema não está na velocidade do desenvolvimento.
Está na ausência de engenharia.
Governança
Projetos RAD também precisam de controle.
Sem governança surge o caos.
Algumas práticas recomendadas:
Versionamento no Git.
Code Review.
Integração Contínua.
Pipeline automatizado.
Testes automatizados.
Documentação mínima.
Monitoramento.
Catálogo de APIs.
Padronização de componentes.
Segurança
Outro erro comum.
"Ainda é protótipo."
Quantos incidentes começaram exatamente assim?
Mesmo durante prototipação devemos considerar:
Autenticação.
Autorização.
Criptografia.
Proteção de dados.
LGPD.
Auditoria.
Logs.
Quanto antes a segurança entrar no projeto...
Menor o custo.
Quando RAD não é a melhor escolha?
Existem situações em que outras abordagens podem ser mais adequadas.
Por exemplo:
Projetos militares.
Sistemas embarcados extremamente críticos.
Software aeroespacial.
Equipamentos médicos.
Aplicações certificadas.
Ambientes altamente regulados.
Nesses casos o custo da documentação extensa pode ser menor que o risco de falhas.
Mesmo assim, muitos princípios do RAD continuam sendo utilizados durante prototipação e validação.
O erro mais comum
Muitos gestores acreditam que RAD significa fazer tudo mais rápido.
Na realidade significa aprender mais rápido.
Existe uma enorme diferença.
Velocidade sem aprendizado produz retrabalho.
Aprendizado contínuo produz velocidade.
Essa talvez seja a maior lição deixada por James Martin.
O que um programador COBOL pode aproveitar hoje?
Mesmo trabalhando exclusivamente com IBM Z, praticamente todos os conceitos desta parte podem ser aplicados.
Você pode criar protótipos de telas antes de desenvolver transações CICS.
Pode validar regras de negócio com usuários antes de alterar programas COBOL.
Pode utilizar APIs simuladas para testar integrações.
Pode automatizar builds, testes e deploys em pipelines DevOps.
Pode expor programas COBOL como serviços REST por meio do z/OS Connect e receber feedback em ciclos curtos.
Pode utilizar Inteligência Artificial para documentar código legado, sugerir refatorações e acelerar a criação de testes.
O ambiente mudou muito desde 1991, mas o objetivo continua exatamente o mesmo: reduzir a distância entre a necessidade do negócio e a entrega de uma solução funcional.
No próximo café entraremos definitivamente no universo IBM Mainframe. Veremos como aplicar RAD em aplicações COBOL, CICS, IMS, DB2, VSAM e z/OS, como integrar essa metodologia com DevOps, Git, APIs, z/OS Connect, testes automatizados e modernização, além de entender por que o RAD continua extremamente relevante na era do IBM Z e da Inteligência Artificial.
quinta-feira, 22 de fevereiro de 2024
IBM Z Resiliência: A Engenharia Invisível que Mantém o Mundo Funcionando (E Quase Ninguém Percebe)
 |
| Bellacosa Mainframe e a ibm z resiliencia |
☕ Um Café no Bellacosa Mainframe
IBM Z Resiliência: A Engenharia Invisível que Mantém o Mundo Funcionando (E Quase Ninguém Percebe)
"Quando tudo funciona, ninguém lembra do Sysprog. Quando tudo para... todo mundo lembra."
Introdução – O paradoxo da excelência
Existe uma curiosidade muito interessante sobre a profissão de System Programmer (Sysprog) e System Administrator (Sysadmin) no universo IBM Z.
Se você fizer um trabalho perfeito durante dez anos, provavelmente ninguém vai notar.
Mas basta cinco minutos de indisponibilidade para que diretores, gestores, usuários, imprensa e até clientes passem a perguntar:
"O que aconteceu com o sistema?"
Esse é o maior paradoxo da infraestrutura crítica.
Quanto melhor você trabalha...
menos visível você fica.
E justamente por isso existe um tema que deveria ser obrigatório para qualquer profissional que trabalha com IBM Z:
Resiliência.
Não Backup.
Não Disaster Recovery.
Não Alta Disponibilidade isoladamente.
Mas sim Resiliência.
São conceitos diferentes.
E entender essa diferença muda completamente a forma como um Sysprog enxerga um ambiente de missão crítica.
O que realmente significa Resiliência?
A maioria das pessoas responde rapidamente:
"É conseguir recuperar o sistema."
Na verdade...
Essa resposta está incompleta.
Resiliência significa:
continuar entregando o serviço mesmo quando alguma coisa está dando errado.
Perceba a diferença.
Recuperação acontece depois.
Resiliência começa antes.
Essa filosofia está presente na arquitetura IBM Z desde seus primeiros projetos.
O Mainframe nasceu paranoico
Essa talvez seja a primeira curiosidade da apresentação.
Os computadores distribuídos normalmente são construídos pensando em desempenho.
O IBM Z foi construído pensando em falhas.
Pode parecer estranho.
Mas faz todo sentido.
Durante décadas, bancos, governos, bolsas de valores e empresas de telecomunicações não podiam simplesmente dizer:
"Desculpe, voltamos amanhã."
Logo, toda a engenharia foi criada assumindo uma premissa:
Alguma coisa vai falhar.
A pergunta nunca foi:
"Será que vai falhar?"
A pergunta correta sempre foi:
"Quando falhar... como vamos impedir que alguém perceba?"
Essa pequena mudança de mentalidade explica praticamente toda a arquitetura IBM Z.
A grande diferença entre Cloud e Mainframe
Existe uma frase que gosto muito.
"Na Cloud você escala."
No IBM Z...
Você continua funcionando.
São objetivos diferentes.
Cloud normalmente resolve aumento de carga.
Mainframe resolve continuidade operacional.
Não significa que um substitui o outro.
Eles resolvem problemas diferentes.
RAS: o DNA invisível do IBM Z
Todo Sysprog deveria decorar três letras.
RAS.
Reliability.
Availability.
Serviceability.
Essas três palavras são provavelmente as mais importantes de toda a arquitetura IBM Z.
Reliability
Confiabilidade.
O hardware foi projetado para falhar menos.
Mas mais importante...
Foi projetado para detectar quando está começando a falhar.
Memórias ECC.
Processadores redundantes.
Correção automática de erros.
Diagnóstico permanente.
Enquanto outros equipamentos apenas quebram...
O IBM Z normalmente avisa antes.
Curiosidade
Você provavelmente já trabalhou em um ambiente onde uma memória apresentou erro.
A diferença é que no Mainframe isso muitas vezes acontece...
...sem ninguém perceber.
O hardware corrigiu sozinho.
Esse é um daqueles "superpoderes" invisíveis.
Availability
Disponibilidade.
Talvez o conceito mais famoso.
Mas muita gente interpreta errado.
Disponibilidade não significa:
"O servidor está ligado."
Significa:
O negócio continua funcionando.
Um servidor ligado sem processar transações...
continua indisponível.
Serviceability
Essa é a parte mais fascinante.
Capacidade de manutenção.
Imagine trocar um componente crítico...
sem desligar o equipamento.
Isso parece impossível para quem vem do mundo x86.
No IBM Z isso faz parte do dia a dia.
Easter Egg nº 1
Você sabia que existem técnicos que substituem componentes internos do IBM Z enquanto ele continua processando milhões de transações?
Parece ficção científica.
Mas acontece.
Resiliência começa muito antes do desastre
Um erro comum é associar resiliência apenas ao Disaster Recovery.
Na verdade...
Disaster Recovery representa apenas uma pequena parte da estratégia.
Antes dele existem dezenas de mecanismos trabalhando continuamente.
ARM.
Parallel Sysplex.
GDPS.
Storage replicado.
WLM.
SMF.
Monitoramento.
Automação.
Tudo isso forma um enorme quebra-cabeça.
ARM — O operador que nunca dorme
Automatic Restart Manager.
Se um serviço cai...
ele pode reiniciar automaticamente.
Sem operador.
Sem ligação telefônica.
Sem abrir chamado.
Sem drama.
Imagine um Batch crítico.
Ele sofre um ABEND.
Sem ARM.
Operador.
Diagnóstico.
Restart.
Tempo.
Com ARM.
Detecção.
Restart.
Continuidade.
Essa diferença pode representar minutos.
Ou milhões de reais.
GDPS
Aqui entramos em outro nível.
Geographically Dispersed Parallel Sysplex.
Não estamos falando apenas de aplicações.
Estamos falando de Data Centers inteiros.
Imagine:
Uma enchente.
Um incêndio.
Falha elétrica.
Ataque físico.
Mesmo assim...
o ambiente continua funcionando.
Isso é GDPS.
Easter Egg nº 2
A maior parte das pessoas acredita que o maior inimigo do ambiente é o hardware.
Na prática...
um dos maiores SPOFs continua sendo...
o ser humano.
O operador continua sendo um SPOF
Single Point of Failure.
Existe uma brincadeira famosa entre Sysprogs.
"O maior ponto único de falha fica sentado na cadeira."
Parece piada.
Mas é verdade.
Boa parte dos incidentes graves começa com:
DELETE errado.
IPL errado.
PARMLIB errada.
JCL errada.
ALTER errado.
Por isso automação é tão importante.
DR Test
Existe outra máxima.
DR não testado...
...não existe.
Todo mundo gosta de mostrar diagramas bonitos.
Mas quando chega o momento do teste...
descobrem que:
Scripts estão desatualizados.
Documentação não funciona.
Equipe mudou.
Dependências não foram consideradas.
E justamente por isso os DR Tests existem.
Curiosidade
Algumas instituições financeiras realizam simulações completas de desastre.
Literalmente desligam parte do ambiente.
Tudo controlado.
Tudo documentado.
Tudo medido.
O objetivo não é provar que funciona.
É descobrir onde ainda pode falhar.
RPO e RTO
Esses dois indicadores aparecem em praticamente todas as entrevistas para Sysprog.
RPO.
Quanto dado posso perder?
RTO.
Quanto tempo posso ficar parado?
São perguntas simples.
Mas extremamente difíceis de responder.
Porque dependem do negócio.
Um banco e um supermercado possuem o mesmo RPO?
Não.
Um PIX pode exigir praticamente zero perda.
Já outro sistema administrativo pode aceitar alguns minutos.
Tudo depende da criticidade.
Parallel Sysplex
Talvez a maior obra de engenharia já construída no universo dos sistemas operacionais comerciais.
Diversos sistemas.
Compartilhando recursos.
Compartilhando dados.
Compartilhando carga.
Tudo funcionando como se fosse um único computador.
Quem vem do mundo Linux costuma dizer:
"Parece um cluster."
Não.
É muito mais sofisticado.
Easter Egg nº 3
Existe uma brincadeira antiga entre Sysprogs.
"Parallel Sysplex é aquele cluster que não resolve discutir quem é o líder."
Quem conhece algoritmos distribuídos entende a piada.
O futuro da profissão
Existe uma pergunta recorrente.
"O Sysprog vai acabar?"
Minha resposta é sempre a mesma.
Não.
Mas o Sysprog que conhece apenas ISPF...
talvez tenha dificuldades.
Hoje o profissional precisa conhecer:
REST APIs.
Python.
Ansible.
Zowe.
Git.
DevOps.
Observabilidade.
OpenTelemetry.
Containers.
OpenShift.
Cloud.
Não para abandonar o Mainframe.
Mas para integrá-lo.
O novo Sysprog
O novo profissional mistura tradição com modernização.
Continua dominando:
JCL.
SDSF.
RACF.
SMF.
RMF.
Mas também conversa naturalmente sobre:
GitHub.
CI/CD.
VS Code.
Terraform.
Automation.
IaC.
Esse profissional será extremamente valorizado.
Plano de estudos sugerido
Mês 1
Conceitos de RAS
RPO
RTO
SLA
Mês 2
Sysplex
Coupling Facility
WLM
Mês 3
GDPS
Storage
Replicação
Mês 4
ARM
Automação
NetView
System Automation
Mês 5
Zowe
Python
APIs
Ansible
Mês 6
Exercícios
DR Test
Laboratórios
Simulações
Onde aprender mais?
Para quem realmente quer se aprofundar, eu recomendaria estudar nesta ordem:
IBM Documentation
A documentação oficial continua sendo a principal referência técnica para IBM Z, z/OS, GDPS, Parallel Sysplex, WLM e demais componentes.
IBM Redbooks
Os Redbooks são praticamente livros técnicos escritos por especialistas da IBM e clientes. Um dos mais relevantes para este tema é Getting Started with IBM Z Resiliency, além de publicações sobre Parallel Sysplex, GDPS e z/OS.
IBM TechXchange
Apresentações de arquitetos IBM, sessões técnicas, estudos de caso e demonstrações práticas.
IBM Z Xplore
Ambiente gratuito para laboratórios, permitindo explorar tecnologias IBM Z de forma prática.
IBM SkillsBuild e IBM Learning
Cursos introdutórios e avançados sobre resiliência, z/OS, System Automation, GDPS, RACF, CICS, Db2 e diversas outras áreas.
SHARE Conference
Talvez o maior evento técnico do mundo voltado ao ecossistema IBM Z. É um excelente lugar para acompanhar tendências, novidades e relatos de grandes clientes.
Comunidade
Grupos técnicos, blogs especializados, fóruns e iniciativas como o Bellacosa Mainframe ajudam a transformar conhecimento técnico em conteúdo acessível, conectando teoria, prática e experiência de campo.
A maior lição
Depois de mais de sessenta anos de evolução tecnológica, existe uma conclusão interessante.
O maior diferencial do IBM Z nunca foi simplesmente seu hardware.
Nunca foi apenas o z/OS.
Nunca foi apenas o COBOL.
O verdadeiro diferencial sempre foi a filosofia de engenharia.
Projetar sistemas assumindo que falhas vão acontecer.
Não para reagir ao desastre.
Mas para impedir que ele se transforme em indisponibilidade.
Essa é a essência da resiliência.
E talvez seja exatamente por isso que, enquanto tantas tecnologias surgem e desaparecem, o IBM Z continua processando a maior parte das transações financeiras do planeta.
☕ Reflexão Final
"Um bom Sysprog mantém o sistema funcionando. Um excelente Sysprog faz com que ninguém perceba que dezenas de falhas aconteceram durante o dia. A verdadeira excelência em resiliência não é eliminar as falhas, mas construir uma arquitetura onde elas deixam de ser um problema para o negócio."
Essa é a filosofia que torna o IBM Z muito mais do que um computador: ele é uma plataforma construída para manter empresas, governos e economias funcionando, mesmo quando o inesperado acontece.
quarta-feira, 21 de fevereiro de 2024
Metodologia Waterfall, o que é, para que serve, virtudes e defeitos
 |
| Bellacosa Mainframe apresenta a metodologia waterfall |
Metodologia Waterfall: O Modelo Clássico que Ainda Sustenta os Maiores Sistemas do Mundo
Muito antes de termos Scrum, Kanban, DevOps, CI/CD e equipes ágeis entregando software em ciclos rápidos, existia uma metodologia que estabeleceu as bases da engenharia de software moderna: a Metodologia Waterfall, também conhecida como Modelo em Cascata. Criada para organizar projetos complexos de forma previsível e controlada, ela continua sendo amplamente utilizada em setores onde segurança, conformidade, documentação e rastreabilidade são essenciais, como bancos, seguradoras, governos, indústrias, telecomunicações, aeroespacial e, principalmente, no universo dos IBM Mainframes.
O princípio do Waterfall é simples e poderoso: cada fase do projeto deve ser concluída antes do início da próxima. Dessa forma, levantamento de requisitos, análise, projeto, desenvolvimento, testes, implantação e manutenção seguem uma sequência lógica, reduzindo ambiguidades e permitindo um rigoroso controle de qualidade.
Embora muitos considerem o Waterfall ultrapassado diante das metodologias ágeis, a realidade é bem diferente. Bilhões de transações financeiras executadas diariamente em sistemas COBOL, CICS, Db2 e IBM Z continuam sendo desenvolvidas e mantidas utilizando princípios herdados desse modelo. Em ambientes onde uma alteração incorreta pode causar prejuízos milionários, previsibilidade vale mais do que velocidade.
Neste artigo você entenderá o que é a Metodologia Waterfall, como ela surgiu, quais são suas etapas, vantagens, desvantagens, diferenças em relação ao Agile, Scrum e DevOps, quando ela ainda representa a melhor escolha e por que continua sendo um dos pilares da engenharia de software corporativa. Seja você um estudante, desenvolvedor, analista de sistemas ou profissional de Mainframe, conhecer o Waterfall é compreender as origens da disciplina que moldou praticamente toda a indústria de desenvolvimento de software moderna.
 |
| Bellacosa Mainframe e a metodologia de desenvolvimento waterfall |
Muitas linhas foram escritas, defensores e detratores, propagandistas de outras metodologias, coachs e consultores tentando vender seu peixe, pintando um monstro, atacando uma metodologia, que como tudo na vida, ela tem seus pros e contras.
terça-feira, 20 de fevereiro de 2024
Quality Engineering sem Mistérios
 |
| Bellacosa Mainframe e a engenharia de qualidade sem misterios para a Stack Mainframe |
☕ Um Café no Bellacosa Mainframe
Quality Engineering sem Mistérios
O Guia Definitivo do Programador COBOL Padawan para Entender a Engenharia da Qualidade Aplicada ao IBM Z — Inspirado em Star Trek
"Em qualquer missão da Frota Estelar, sobreviver não depende apenas de tecnologia. Depende de processos bem definidos, verificações constantes e disciplina operacional."
— Adaptado da filosofia do Sr. Spock
Introdução — O que um Programador COBOL tem a ver com Engenharia da Qualidade?
Quando um programador COBOL iniciante escuta palavras como FMEA, PPAP, MSA, SPC, CAPA ou APQP, normalmente pensa:
"Isso deve ser coisa do pessoal da fábrica..."
Na verdade...
Não.
Esses conceitos nasceram na manufatura, principalmente na indústria automobilística japonesa e americana, mas seus princípios são praticamente universais.
Na IBM, por exemplo, boa parte da cultura de engenharia que permitiu que o IBM System/360, depois o System/370, o zSeries, o IBM Z e atualmente o IBM z16/z17 alcançassem níveis absurdos de disponibilidade foi construída exatamente sobre esses fundamentos.
Aliás...
Existe uma curiosidade interessante.
A indústria automotiva mede defeitos em peças.
O mundo mainframe mede defeitos em informações.
Ambos perseguem exatamente o mesmo objetivo:
Zero defeito.
No universo de Star Trek isso fica ainda mais evidente.
Imagine a USS Enterprise.
Ela possui:
motores
computadores
sensores
bancos de dados
replicadores
sistemas médicos
controle de voo
Agora imagine se cada módulo fosse desenvolvido sem controle de qualidade.
A Enterprise nunca sairia do estaleiro de Utopia Planitia.
No IBM Z acontece exatamente a mesma coisa.
Engenharia da Qualidade não é encontrar erros
Este é um dos maiores equívocos dos iniciantes.
Muita gente acredita que qualidade significa:
"Encontrar bugs."
Na verdade...
Encontrar bugs é apenas uma pequena parte.
A Engenharia da Qualidade tenta impedir que o bug exista.
Essa filosofia pode ser resumida assim:
Inspecionar
↓
Encontrar defeitos
Prevenir
↓
Eliminar defeitos antes que apareçam
É exatamente a diferença entre apagar incêndios e construir um prédio que não pega fogo.
A Jornada Completa da Qualidade
No mundo automotivo existe praticamente uma sequência lógica.
Planejamento
↓
Projeto
↓
Análise de Riscos
↓
Plano de Controle
↓
Validação
↓
Produção
↓
Monitoramento
↓
Correção
↓
Melhoria Contínua
Curiosamente...
Essa sequência lembra muito o ciclo de desenvolvimento de um sistema COBOL.
Levantamento
↓
Análise
↓
Codificação
↓
Compilação
↓
Teste
↓
Homologação
↓
Produção
↓
Monitoramento
↓
Correções
Nada mudou.
Mudou apenas o produto.
APQP — O Planejamento da Missão
Imagine o Capitão Kirk recebendo uma nova missão.
Spock pergunta:
Capitão... já sabemos os riscos?
McCoy pergunta:
O suporte médico foi planejado?
Scotty pergunta:
Os motores suportam essa missão?
Uhura pergunta:
As comunicações foram testadas?
Todos estão fazendo APQP.
O que significa?
Advanced Product Quality Planning.
É um planejamento extremamente detalhado.
Seu objetivo é garantir que o produto nascerá corretamente.
No mundo mainframe seria equivalente ao momento em que uma nova aplicação bancária começa.
Antes da primeira linha de COBOL já precisamos definir:
requisitos
banco de dados
segurança RACF
interfaces MQ
jobs
SLAs
backups
monitoramento
capacidade
rollback
Perceba...
Nenhuma linha de código foi escrita.
Mesmo assim boa parte do sucesso do projeto já foi decidida.
FMEA — O Dr. Spock prevê o futuro
Esta talvez seja minha ferramenta favorita.
Failure Mode and Effects Analysis.
Traduzindo:
Análise dos Modos de Falha.
Ela faz uma pergunta simples:
O que pode dar errado?
Depois:
Qual será o impacto?
Depois:
Como impedir?
Imagine um programa COBOL.
READ CLIENTE
IF NOT FOUND
O que pode acontecer?
Arquivo vazio.
Dataset inexistente.
Erro de autorização.
Registro inválido.
VSAM corrompido.
Todas essas possibilidades deveriam aparecer no FMEA.
No universo Star Trek...
Spock faria exatamente isso antes da missão começar.
Exemplo Mainframe
Programa realiza TED bancária.
Possíveis falhas:
Saldo insuficiente.
Abend S0C7.
Deadlock DB2.
Timeout CICS.
Fila MQ cheia.
Sistema remoto indisponível.
Agora imagine cada um deles recebendo:
Severidade.
Probabilidade.
Facilidade de detecção.
Esse é exatamente o FMEA.
SPC — O RMF da Indústria
SPC significa Statistical Process Control.
Aqui entra estatística.
Imagine acompanhar diariamente:
CPU
↓
Tempo de resposta
↓
IOPS
↓
Uso de DASD
↓
Quantidade de ABENDs
↓
Tempo de Batch
Tudo isso pode ser colocado em gráficos.
É exatamente isso que o SPC faz.
No mundo industrial mede:
temperatura
pressão
espessura
diâmetro
peso
No IBM Z mede:
CPU
Paging
EXCP
Response Time
Storage
Buffer Pools
Locks
Tudo baseado em estatística.
Easter Egg
RMF é praticamente um gigantesco SPC para sistemas operacionais.
MSA — Posso confiar na minha medição?
Imagine dois operadores.
Um diz:
CPU = 60%
Outro diz:
CPU = 85%
Quem está certo?
Antes de confiar no número...
Precisamos confiar na ferramenta.
MSA faz exatamente isso.
No mundo industrial analisa:
paquímetro
micrômetro
scanner
laser
No mainframe seria equivalente a validar:
RMF
SMF
OMEGAMON
Grafana
Instana
Zabbix
Se a ferramenta mede errado...
Todas as decisões seguintes estarão erradas.
QA x QC
Essa pergunta aparece praticamente em todas as entrevistas.
QA
Quality Assurance.
Garante o processo.
QC
Quality Control.
Verifica o produto.
Imagine uma compilação COBOL.
QA seria:
Padronizar coding standards.
Checklist.
Code Review.
Pipeline.
Testes obrigatórios.
QC seria:
Executar o programa.
Validar saída.
Comparar resultados.
Encontrar erros.
QA evita.
QC detecta.
PPAP — A Homologação Definitiva
Imagine entregar um novo sistema para produção.
O gerente pergunta:
Você testou?
Sim.
Documentou?
Sim.
Backup?
Sim.
Rollback?
Sim.
Plano B?
Sim.
Plano C?
Sim.
Aprovação?
Sim.
Esse "pacote de confiança" é praticamente um PPAP.
Na indústria significa provar que a linha inteira consegue fabricar corretamente.
No mainframe seria provar que:
o sistema inteiro está pronto para produção.
Control Plan
Depois que tudo foi planejado...
Como garantir que ninguém saia do padrão?
Control Plan responde isso.
No desenvolvimento COBOL poderia conter:
Toda alteração passa por Git.
↓
Build automático.
↓
Compilação Enterprise COBOL.
↓
Testes ZUnit.
↓
Code Review.
↓
Deploy via DBB.
↓
Homologação.
↓
Produção.
Tudo documentado.
CAPA
Corrective and Preventive Action.
Imagine ocorreu um ABEND S0C4.
Correção:
ajustar ponteiro.
Prevenção:
criar regra de inspeção para ponteiros.
Outro exemplo.
Deadlock DB2.
Correção:
alterar ordem dos UPDATE.
Prevenção:
documentar padrão corporativo.
Perceba.
A prevenção vale muito mais.
Root Cause Analysis
A pergunta mais importante da engenharia.
Por quê?
Imagine:
Programa caiu.
Por quê?
Arquivo indisponível.
Por quê?
Storage cheio.
Por quê?
Job anterior não apagou temporários.
Por quê?
PROC estava errada.
Agora encontramos a verdadeira causa.
Não era o COBOL.
Era o processo.
Os famosos 5 Porquês
Toyota popularizou essa técnica.
Pergunte cinco vezes:
Por quê?
Até chegar na raiz.
No mundo mainframe isso resolve inúmeros incidentes.
8D — A Investigação da Frota Estelar
Imagine um incidente gravíssimo.
Sistema bancário parado.
Kirk convoca uma força-tarefa.
Cada disciplina representa uma etapa.
D1
Equipe.
D2
Problema.
D3
Conter.
D4
Descobrir causa.
D5
Corrigir.
D6
Validar.
D7
Evitar repetição.
D8
Registrar aprendizado.
É praticamente um Post Mortem moderno.
Poka-Yoke — O Idiot Proof
Talvez o conceito japonês mais genial.
Impedir o erro antes que aconteça.
No COBOL:
Obrigar CPF com 11 dígitos.
Obrigar DATA AAAAMMDD.
Obrigar código de agência válido.
Obrigar commit antes do término.
Tudo isso é Poka-Yoke.
Kaizen — O Espírito Vulcano
Kaizen significa:
Melhoria contínua.
Todos os dias.
Pouco.
Mas sempre.
No IBM Z isso significa:
Melhor SQL.
Menor consumo de CPU.
Menos EXCP.
Menos SORT.
Mais cache.
Mais paralelismo.
Nenhuma mudança isolada faz milagre.
Mil pequenas melhorias mudam uma organização inteira.
Process Flow Diagram
É literalmente desenhar o processo.
No COBOL:
Cliente
↓
Tela CICS
↓
Programa COBOL
↓
DB2
↓
MQ
↓
Sistema Externo
↓
Resposta
↓
Tela
Quanto melhor o diagrama...
Mais fácil identificar gargalos.
Cp e Cpk
São indicadores estatísticos.
Na indústria medem:
Capacidade do processo.
No IBM Z poderiam representar:
Capacidade de throughput.
Capacidade do Batch.
Capacidade do CICS.
Capacidade do DB2.
Embora não sejam usados formalmente dessa forma, a filosofia é semelhante.
GD&T
Geometric Dimensioning and Tolerancing.
Pode parecer distante do COBOL.
Mas existe uma analogia.
Na indústria define tolerâncias.
No software definimos:
Layout Copybook.
Formato JSON.
API Contract.
Record Layout.
Todos precisam seguir exatamente o padrão.
5S no Mainframe
Seiri
Eliminar datasets inúteis.
Seiton
Organizar bibliotecas.
Seiso
Eliminar jobs antigos.
Seiketsu
Padronizar nomenclaturas.
Shitsuke
Disciplina operacional.
O ISPF agradece.
OEE
Overall Equipment Effectiveness.
Na indústria mede:
Disponibilidade
Performance
Qualidade
No IBM Z seria algo como:
Disponibilidade do Sysplex.
Performance do Batch.
Qualidade dos serviços.
LPA
Layered Process Audit.
Imagine auditorias periódicas.
Operador.
Supervisor.
Gerente.
Arquiteto.
Todos verificam o mesmo processo sob perspectivas diferentes.
QMS
Quality Management System.
É o "sistema operacional" da qualidade.
No IBM seria equivalente ao conjunto de:
ITIL
COBIT
ISO 9001
Políticas internas
Procedimentos
Fluxos
Normas
IATF 16949
É a principal norma automotiva.
Ela integra praticamente tudo o que vimos.
Pode ser comparada, conceitualmente, a grandes frameworks de governança utilizados em ambientes corporativos de TI, onde processos, auditorias, gestão de riscos e melhoria contínua precisam funcionar de forma integrada.
Como tudo isso conversa com o IBM Z?
A maior lição deste artigo é perceber que o IBM Z sempre foi uma plataforma orientada à qualidade.
Quando você utiliza:
RACF
WLM
RMF
SMF
JES2
GDGs
DB2
CICS
IMS
ZUnit
Git
DBB
Ansible
Jenkins
você está, na prática, aplicando muitos dos mesmos princípios da Engenharia da Qualidade: prevenção, padronização, rastreabilidade, medição, auditoria e melhoria contínua.
A tecnologia muda, mas os fundamentos permanecem.
Curiosidades para impressionar em uma entrevista
☕ A Toyota foi uma das grandes responsáveis por popularizar FMEA, 5S, Kaizen, Poka-Yoke e os 5 Porquês, influenciando metodologias de qualidade em diversos setores.
☕ O conceito de melhoria contínua inspirou práticas modernas como Lean Manufacturing, Lean Software Development e parte da cultura DevOps.
☕ O ciclo Planejar → Executar → Medir → Corrigir aparece em praticamente todas as áreas da engenharia, da manufatura ao desenvolvimento de software.
☕ Em ambientes IBM Z, métricas provenientes de RMF, SMF e ferramentas de observabilidade cumprem papel semelhante ao SPC, permitindo identificar tendências antes que se transformem em incidentes.
☕ O famoso Post Mortem adotado por empresas como Google, Microsoft e IBM segue princípios muito próximos do RCA (Root Cause Analysis) e do método 8D: entender profundamente a causa raiz, implementar ações corretivas permanentes e compartilhar o aprendizado para evitar recorrências.
O Conselho Final do Sr. Spock
Ao terminar sua conversa com o capitão Kirk, Spock olha para um jovem engenheiro recém-chegado à Enterprise e diz:
"Um excelente engenheiro não é aquele que resolve problemas rapidamente. É aquele que projeta sistemas onde os problemas raramente acontecem."
Essa frase resume toda a Engenharia da Qualidade.
Seja em uma linha de montagem produzindo milhões de componentes automotivos ou em um IBM Z processando bilhões de transações financeiras, o verdadeiro objetivo nunca foi apenas corrigir defeitos. O objetivo é construir processos tão robustos, previsíveis e bem controlados que a qualidade deixe de ser uma inspeção no final do caminho e passe a fazer parte da própria essência do sistema.
E essa é uma lição que todo Programador COBOL Padawan leva consigo ao iniciar sua jornada rumo ao nível de Mestre. Afinal, como diria Spock:
"A lógica constrói sistemas. A qualidade garante que eles permaneçam funcionando quando toda a galáxia depende deles."
segunda-feira, 19 de fevereiro de 2024
IA Agêntica: Muito Além do ChatGPT — Como Pensar Como um Arquiteto de Sistemas Inteligentes
 |
| Bellacosa Mainframe e a ia agentica |
☕ Um Café no Bellacosa Mainframe
IA Agêntica: Muito Além do ChatGPT — Como Pensar Como um Arquiteto de Sistemas Inteligentes
"O futuro da programação não será escrever mais código. Será ensinar agentes inteligentes a escrever, colaborar e tomar decisões com responsabilidade."
Durante muitos anos, aprender programação significava dominar uma linguagem.
Depois vieram os frameworks.
Depois a nuvem.
Depois DevOps.
Depois Containers.
Depois Kubernetes.
Agora estamos entrando em uma nova fase.
A era da IA Agêntica (Agentic AI).
Se você é um programador júnior, principalmente vindo do mundo corporativo, talvez esteja pensando:
"Isso é só mais um nome bonito para ChatGPT?"
A resposta é um enorme não.
Estamos diante de uma mudança comparável ao nascimento da Internet ou da computação em nuvem.
Hoje não estamos ensinando computadores apenas a responder perguntas.
Estamos ensinando computadores a trabalhar.
E isso muda absolutamente tudo.
Pegue seu café.
Hoje vamos entender como funciona a arquitetura dos agentes inteligentes.
O que realmente é IA Agêntica?
Um chatbot responde.
Um agente resolve problemas.
Existe uma enorme diferença.
Imagine que você diga:
"Meu programa COBOL está com erro."
Um chatbot provavelmente responderá:
"Mostre o código."
Um agente faria algo completamente diferente.
Ele poderia:
localizar o programa no Git
abrir o histórico de alterações
identificar quem modificou
executar os testes
consultar o banco de dados
pesquisar documentação IBM
comparar versões
sugerir correções
criar um Pull Request
pedir sua aprovação
atualizar o Jira
Percebe?
Ele não apenas conversa.
Ele trabalha.
É exatamente por isso que chamamos essa nova geração de Agentes de IA.
Um agente é como um operador de Mainframe
Quem trabalha com IBM Z entende isso muito rápido.
Imagine um operador experiente do z/OS.
Ele observa:
JOBs
filas JES2
consumo de CPU
logs
CICS
DB2
RACF
Storage
Depois toma decisões.
Um agente faz exatamente isso.
A diferença é que ele faz isso em segundos.
Os 12 pilares da IA Agêntica
Esses conceitos aparecem em praticamente todas as arquiteturas modernas.
Não importa se você usa:
OpenAI
Claude
Gemini
Microsoft Copilot
Amazon Bedrock
IBM watsonx
LangGraph
CrewAI
AutoGen
Todos utilizam praticamente os mesmos fundamentos.
Vamos entender cada um.
1. MCP — O USB-C da Inteligência Artificial
Durante anos cada ferramenta criou sua própria API.
Cada integração era diferente.
Hoje existe o MCP.
Model Context Protocol.
Pense nele como o USB-C.
Você conecta qualquer dispositivo.
Na IA acontece o mesmo.
O agente conversa com GitHub.
Depois Jira.
Depois Slack.
Depois PostgreSQL.
Depois SAP.
Depois IBM Z.
Tudo utilizando um mesmo protocolo.
Para quem é desenvolvedor isso significa menos código, menos manutenção e muito mais reutilização.
Curiosidade
O MCP está se tornando para a IA o que HTTP foi para a Internet.
Estamos assistindo ao nascimento de um novo padrão mundial.
2. O Loop do Agente
Todo agente vive preso em um ciclo.
Perceber
↓
Planejar
↓
Executar
↓
Observar
↓
Aprender
↓
Repetir
Isso parece simples.
Mas é exatamente como um ser humano trabalha.
Imagine um DBA.
Ele percebe uma lentidão.
Analisa índices.
Planeja um REORG.
Executa.
Observa.
Se não resolveu, tenta novamente.
O agente faz exatamente isso.
Dica Bellacosa
Se seu agente apenas responde perguntas...
Ele ainda não é um verdadeiro agente.
3. Ferramentas
Essa talvez seja a maior surpresa para quem está começando.
Modelos de IA não fazem quase nada sozinhos.
Eles apenas pensam.
Quem realmente trabalha são as ferramentas.
Exemplos:
executar SQL
enviar e-mails
criar PDFs
chamar APIs
consultar banco
executar JCL
abrir chamados
gerar gráficos
Sem ferramentas...
O agente é apenas um excelente escritor.
Analogia
Imagine um excelente mecânico.
Sem ferramentas.
Ele continua sabendo consertar motores.
Mas não consegue fazer nada.
4. O Orquestrador
Agora imagine uma empresa.
Existe um gerente.
Ele não faz tudo.
Ele distribui trabalho.
Na IA esse gerente chama-se Orquestrador.
Ele recebe um objetivo.
Depois decide quem fará cada parte.
É praticamente um Scrum Master misturado com um arquiteto de software.
Exemplo
Recebe:
"Atualize toda documentação do sistema."
Ele divide.
Agente Git.
Agente Markdown.
Agente UML.
Agente Testes.
Agente QA.
Cada especialista resolve sua parte.
5. Subagentes
Você provavelmente sabe um pouco de tudo.
Mas conhece alguém que sabe muito de DB2.
Outro domina RACF.
Outro conhece CICS.
Outro é especialista em COBOL.
Os agentes funcionam exatamente assim.
Cada um possui uma especialidade.
Isso reduz erros.
Aumenta qualidade.
E melhora desempenho.
Easter Egg
Isso lembra muito os personagens de um RPG.
Cada classe possui habilidades específicas.
Um Guerreiro não lança magia.
Um Mago não usa armadura pesada.
Na IA acontece exatamente igual.
6. Memória
Sem memória não existe inteligência.
Existe apenas repetição.
Os agentes possuem vários tipos de memória.
Curto prazo
Lembram da conversa atual.
Longo prazo
Lembram de dias, meses ou anos.
Memória Vetorial
Guardam conhecimento por similaridade.
Memória Episódica
Lembram do que aconteceu.
Memória Semântica
Lembram conceitos.
Imagine perguntar:
Continue aquele artigo sobre COBOL.
Sem memória...
O agente pergunta:
"Qual artigo?"
Com memória...
Ele continua exatamente de onde parou.
Curiosidade
Nos próximos anos veremos agentes com memória de meses ou até anos de interação.
Será algo semelhante a um colega de trabalho.
7. Grounding
Esse talvez seja o conceito mais importante de todos.
Grounding significa:
Responder usando fatos.
Não imaginação.
Imagine perguntar:
"Quantos JOBs estão em HOLD?"
Sem grounding:
"Talvez existam 12."
Com grounding:
Consulta SDSF.
Depois responde.
Muito mais seguro.
RAG não é Grounding
Muita gente confunde.
RAG é apenas uma técnica.
Grounding é um conceito muito maior.
Pode utilizar:
APIs
sensores
bancos
documentos
logs
arquivos
sistemas ERP
8. Guardrails
Imagine um carro sem freios.
Bonito.
Rápido.
Perigoso.
Guardrails são os freios da IA.
Eles impedem ações inadequadas.
Por exemplo:
❌ apagar banco
❌ excluir usuários
❌ enviar PIX
❌ alterar produção
Sem autorização.
Analogia Mainframe
Guardrails lembram muito o RACF.
Nem todo usuário pode fazer tudo.
9. Sandboxing
Nunca execute código desconhecido diretamente na produção.
Jamais.
Primeiro teste.
Depois valide.
Depois publique.
Sandbox é exatamente isso.
Uma área isolada.
Exemplo
O agente gera um script Python.
Antes de executá-lo:
Sandbox.
Se funcionar...
Produção.
Curiosidade
Grande parte das plataformas modernas de IA executa código em ambientes isolados justamente para evitar impactos em sistemas reais.
10. Human in the Loop
A IA ajuda.
Mas a decisão final continua sendo humana.
Imagine:
"Excluir 40 milhões de registros."
Você realmente deixaria uma IA fazer isso automaticamente?
Provavelmente não.
Ela sugere.
Você aprova.
Empresas adoram isso
Porque reduz riscos.
E mantém governança.
11. Janela de Contexto
Todo modelo possui limite.
Imagine uma mesa.
Quanto maior a mesa...
Mais documentos você consegue abrir.
Quanto menor...
Menos informações cabem.
A janela de contexto funciona exatamente assim.
Hoje alguns modelos trabalham com centenas de milhares de tokens.
Isso permite analisar:
livros
projetos
documentação
códigos enormes
Dica Bellacosa
Mais contexto não significa necessariamente melhor resposta.
Contexto ruim gera respostas ruins.
12. Sistemas Multiagentes
Chegamos ao nível mais avançado.
Imagine uma empresa inteira.
Cada funcionário faz uma parte.
O gerente coordena tudo.
Os agentes fazem exatamente isso.
Existe:
Agente Financeiro.
Agente Jurídico.
Agente Marketing.
Agente Segurança.
Agente DevOps.
Agente DBA.
Todos colaborando.
Como isso pode funcionar no IBM Mainframe?
Imagine um incidente em produção.
09:42.
CPU dispara.
O que acontece?
O orquestrador entra em ação.
Ele chama:
✔ Agente RMF
Analisa desempenho.
✔ Agente JES2
Verifica JOBs.
✔ Agente DB2
Analisa SQL.
✔ Agente CICS
Verifica transações.
✔ Agente RACF
Confirma segurança.
✔ Agente Documentação
Consulta procedimentos.
✔ Agente DevOps
Prepara correção.
Tudo isso em paralelo.
Em poucos segundos.
É praticamente um NOC inteiro trabalhando simultaneamente.
A profissão do futuro
Durante décadas existiram:
Programadores.
Depois vieram:
Arquitetos.
Depois:
DevOps.
Agora começa a surgir uma nova profissão.
Engenheiro de Agentes de IA (AI Agent Engineer).
Esse profissional não escreve apenas código.
Ele projeta equipes inteiras de agentes.
Define:
ferramentas
memória
protocolos
segurança
comunicação
colaboração
aprovação humana
É uma mistura de desenvolvedor, arquiteto, analista de negócios e engenheiro de software.
Dicas para quem está começando
Se você deseja entrar no universo da IA Agêntica, siga uma trilha sólida de aprendizado:
Domine lógica de programação antes de depender da IA.
Aprenda Python, pois é a linguagem mais usada para orquestrar agentes.
Entenda APIs REST e GraphQL para conectar ferramentas.
Estude bancos relacionais e vetoriais.
Aprenda Git e GitHub para colaboração.
Conheça Docker para criar ambientes isolados (sandbox).
Estude conceitos de segurança, autenticação e autorização.
Explore RAG, MCP, LangGraph, CrewAI e AutoGen.
Pratique com pequenos agentes antes de construir sistemas complexos.
Nunca esqueça que a IA amplia o conhecimento existente; ela não substitui fundamentos de arquitetura, algoritmos e boas práticas.
Curiosidades
🤖 Um único agente pode utilizar dezenas de ferramentas diferentes durante uma única tarefa.
🧠 Memórias vetoriais não armazenam frases exatamente como um banco SQL; elas representam significados em espaços matemáticos de alta dimensão.
⚙️ Muitos agentes modernos já executam ciclos autônomos de planejamento, correção e replanejamento antes de apresentar uma resposta.
🌐 O conceito de múltiplos agentes trabalhando em conjunto lembra sistemas distribuídos e arquiteturas de microsserviços, mas aplicado ao raciocínio.
🏢 Empresas estão criando "equipes digitais", nas quais agentes especializados colaboram com profissionais humanos em atividades de engenharia, atendimento, operações e análise de dados.
Easter Eggs para os apaixonados por tecnologia
🥚 Easter Egg #1 – O operador invisível
Se você trabalhou com operadores de console no z/OS, talvez perceba que um agente moderno se comporta como um operador experiente que nunca dorme, nunca esquece um procedimento e consulta toda a documentação antes de agir.
🥚 Easter Egg #2 – Os Vingadores da IA
Um sistema multiagente lembra uma equipe de super-heróis: cada membro possui um poder específico, mas as missões realmente complexas só são resolvidas quando todos atuam juntos sob uma boa liderança.
🥚 Easter Egg #3 – A ponte entre o legado e o futuro
Quem domina COBOL, CICS, DB2, JCL e RACF já entende conceitos como especialização, governança, filas, transações e segurança. Surpreendentemente, esses mesmos princípios aparecem nas arquiteturas mais modernas de IA Agêntica. O legado não está ficando para trás; ele está servindo de base para construir a próxima geração de sistemas inteligentes.
Conclusão
A IA Agêntica não representa apenas uma evolução dos chatbots; ela inaugura uma nova forma de construir software. Em vez de aplicações que apenas respondem comandos, passamos a projetar ecossistemas de agentes capazes de perceber eventos, planejar estratégias, utilizar ferramentas, colaborar entre si, aprender com experiências anteriores e operar dentro de regras rígidas de segurança e governança.
Para o programador júnior, essa é uma oportunidade extraordinária. Quem aprender desde cedo conceitos como MCP, memória, grounding, orquestração, subagentes, guardrails e sistemas multiagentes estará preparado para desenvolver as soluções que definirão a próxima década da engenharia de software.
No fim das contas, a tecnologia muda, as ferramentas evoluem e os modelos ficam cada vez mais poderosos. Porém, um princípio permanece inalterado desde os primeiros computadores até os modernos agentes inteligentes: bons sistemas nascem de boas arquiteturas. E compreender esses doze pilares é o primeiro passo para deixar de apenas usar IA e começar a construir, de forma consciente e profissional, a inteligência que moverá as empresas do futuro.
"Na computação, quem entende apenas as ferramentas acompanha as tendências. Quem entende os princípios constrói o futuro." — Bellacosa Mainframe
Subscrever:
Mensagens (Atom)
