✨ 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
Bellacosa Mainframe apresenta a IA e o Deep Trought do Guia do Mochileiro das Galaxias
🤖 A IA do Guia do Mochileiro das Galáxias
Buzzwords, Deep Thought, mainframes e o déjà-vu tecnológico
(ao estilo Bellacosa Mainframe)
Se existe um livro que todo mainframer, mesmo sem saber, já leu em espírito, esse livro é O Guia do Mochileiro das Galáxias. Não é só ficção científica. É documentação técnica disfarçada de humor britânico, escrita por alguém que claramente já sofreu com sistemas, respostas inúteis e gestores fascinados por palavras da moda.
Douglas Adams não escreveu sobre IA como promessa. Ele escreveu sobre IA como espelho da humanidade. E isso, meus caros, é muito mais perigoso.
🧠 Deep Thought: a primeira IA corporativa da história
Vamos começar pelo elefante na sala: Deep Thought.
Deep Thought é apresentado como a maior e mais poderosa IA já criada. Seu propósito? Responder a Pergunta Fundamental sobre a Vida, o Universo e Tudo Mais.
Soa familiar?
Troque isso por:
“IA estratégica”
“Plataforma cognitiva”
“Modelo fundacional”
“IA generativa corporativa”
…e você tem exatamente o mesmo pitch que vemos hoje.
O problema?
Ninguém sabia qual era a pergunta.
E aqui está o primeiro tapa de luva de pelica de Douglas Adams: 👉 não adianta ter a resposta se você não sabe formular o problema.
Todo mainframer entende isso. Já viu batch rodando perfeitamente… processando dado errado?
🔢 A resposta é 42: quando a IA entrega o que foi pedido (não o que era necessário)
Depois de 7,5 milhões de anos de processamento (tempo típico de projeto estratégico mal definido), Deep Thought entrega sua resposta:
42
A reação? Frustração, raiva, incredulidade.
Mas Deep Thought não errou. Ele foi preciso. Ele entregou exatamente aquilo que foi solicitado.
Isso é IA raiz.
Paralelo com hoje
Modelos de IA atuais respondem estatisticamente
Eles não entendem contexto humano
Eles não questionam objetivos
Eles não dizem “isso não faz sentido”
Assim como Deep Thought, a IA moderna não pensa. Ela executa.
E aqui entra o olhar mainframe:
IA sem governança é só um batch muito rápido rodando no dataset errado.
🖥️ A Terra como computador: Sysplex biológico mal documentado
Quando Deep Thought percebe a falha, ele propõe algo genial (e aterrador):
Criar um computador ainda maior para descobrir qual é a pergunta.
Esse computador é… a Terra.
A Terra, no universo de Adams, é:
Um sistema distribuído
Com bilhões de “processos” (humanos)
Rodando em paralelo
Sem documentação
Sem versionamento
Sem plano de rollback
Ou seja: 👉 um Sysplex sem manual, sem RACF e com usuários root soltos.
Qualquer mainframer sente o calafrio.
🤯 IA hoje: Deep Thought com GPU e marketing agressivo
Avança para 2020+.
Temos:
LLMs
Transformers
GPUs
Cloud infinita
Dashboards lindos
E apresentações cheias de buzzwords
Mas no fundo?
🔁 O mesmo ciclo:
Não sabemos exatamente o problema
Jogamos IA em cima
Ficamos impressionados com respostas
Descobrimos limitações
Criamos mais buzzwords
Douglas Adams já avisava:
quanto mais poderosa a máquina, maior a ilusão de que ela sabe o que está fazendo.
🧩 Buzzword: o verdadeiro vilão da história
Agora vamos ao ponto que dói.
Buzzword é o Vogon corporativo
No Guia, os Vogons são burocratas que:
Falam difícil
Criam regras sem sentido
Não se importam com impacto
Executam ordens cegamente
Troque Vogon por:
Evangelista de IA
Consultoria PowerPoint
Influencer tech
“Especialista” de LinkedIn
Buzzwords são:
“IA cognitiva”
“Inteligência autônoma”
“Consciência artificial”
“IA que pensa”
Tudo isso é… poesia Vogon.
Mainframers sabem:
Tecnologia boa não precisa de adjetivo. Ela funciona.
🧮 Mainframe x IA: quem realmente pensa?
Aqui entra um ponto impopular.
O mainframe nunca prometeu pensar.
Ele promete:
Consistência
Confiabilidade
Previsibilidade
Segurança
Escala
Já a IA moderna promete:
Criatividade
Inteligência
Autonomia
Decisão
Substituição humana
Quem está sendo honesto?
Deep Thought nunca fingiu ser humano. Ele apenas executou sua função com perfeição lógica.
🎌 Anime, IA e o mesmo dilema filosófico
Para quem gosta de anime, o paralelo é imediato:
Ghost in the Shell: o que é consciência?
Serial Experiments Lain: onde termina o humano?
Psycho-Pass: quem decide o que é correto?
Evangelion: sistemas gigantes controlados por humanos quebrados
Douglas Adams estava falando da mesma coisa, só que rindo.
🛠️ O papel do humano: operador, não espectador
No mundo do Guia, o problema nunca foi a IA.
Foi:
Expectativa errada
Pergunta mal formulada
Transferência de responsabilidade
Fascínio cego por tecnologia
Isso é assustadoramente atual.
IA não substitui:
Arquitetura
Análise
Ética
Experiência
Contexto
Ela amplifica — para o bem ou para o mal.
☕ Conclusão: sempre leve uma toalha (e um manual técnico)
O Guia do Mochileiro das Galáxias não é contra tecnologia. Ele é contra fé cega em tecnologia.
Como mainframers, aprendemos cedo:
Leia o manual
Entenda o sistema
Desconfie de promessas mágicas
Teste, valide, audite
E como fãs de anime, sabemos:
Toda IA poderosa revela mais sobre o humano do que sobre si mesma
Deep Thought não falhou. Nós falhamos ao esperar que ele resolvesse nossa bagunça existencial.
No fim, a maior lição de Adams é simples e cruel:
Não é a IA que precisa evoluir. Somos nós.
E enquanto isso, cuidado com os buzzwords. Eles costumam chegar antes da demolição do planeta.
Douglas Adams: o Homem que Descobriu que o Universo Rodava em Produção sem Documentação
🌌 Vida, obra, computadores, toalhas, rinocerontes, prazos impossíveis e a curiosa história do escritor que parecia ter escapado de um dos próprios livros
DON'T PANIC.
Há escritores que criam personagens.
Há escritores que criam universos.
E há Douglas Adams, que conseguiu realizar uma façanha consideravelmente mais improvável:
criou um universo tão parecido consigo mesmo que, depois de algum tempo, ficou difícil descobrir onde terminava Douglas Adams e começava O Guia do Mochileiro das Galáxias.
Ele era enorme.
Literalmente.
Tinha quase dois metros de altura.
Gostava de computadores, guitarras, ciência, tecnologia, carros, animais, viagens, ideias absurdas e prazos — embora sua relação com estes últimos fosse comparável à relação de um programa COBOL de 1973 com uma especificação OpenAPI.
Sabia que existiam.
Reconhecia sua importância.
Mas preferia encontrá-los passando rapidamente ao longe.
Douglas Noël Adams nasceu em Cambridge, Inglaterra, em 11 de março de 1952, estudou em Brentwood e depois literatura inglesa no St John's College, Cambridge. Antes de se tornar mundialmente famoso, passou por uma coleção de empregos e experiências que parecem ter sido escolhidos por um gerador aleatório de profissões: escritor, produtor de rádio, roteirista, performer e, em certos períodos, trabalhos completamente distantes da carreira literária. (Douglas Adams)
Mais tarde escreveria para Monty Python, trabalharia em Doctor Who, criaria Dirk Gently, se apaixonaria por computadores, ajudaria causas ambientais, desenvolveria jogos e acabaria criando uma das obras mais deliciosamente absurdas da cultura pop.
Tudo isso antes de morrer, inesperadamente, em 2001, aos 49 anos.
Mas começar pelo fim seria terrivelmente organizado.
E Douglas Adams provavelmente desconfiaria disso.
Portanto:
pegue sua toalha.
Vamos começar pelo lugar mais apropriado.
No meio do caos.
🌍 CAPÍTULO 1
Um inglês de quase dois metros tentando descobrir o que fazer da vida
Douglas Adams não surgiu magicamente carregando um exemplar do Guia do Mochileiro das Galáxias.
Antes do sucesso houve algo que todo programador conhece muito bem:
tentativa
erro
tentativa
erro
boletos e conta para pagar
tentativa
erro
ideia estranha
tentativa
Em Cambridge, Adams se envolveu com o ambiente de comédia estudantil e com o Footlights, tradicional celeiro britânico de humoristas.
Seu interesse era escrever comédia.
Não exatamente ficção científica.
Essa distinção é importante.
Adams chegou a explicar que se considerava fundamentalmente um escritor de comédia, usando os mecanismos da ficção científica para satirizar praticamente todo o resto. (Enciclopédia)
Isso explica muita coisa.
As naves espaciais são cenário.
Os alienígenas são ferramentas.
Os computadores gigantes são piadas.
O verdadeiro assunto é:
nós.
A burocracia.
A arrogância.
A tecnologia.
O governo.
A religião.
A economia.
Os restaurantes.
As filas.
Os formulários.
Os especialistas.
E principalmente nossa incrível capacidade de construir sistemas complicadíssimos para resolver problemas que talvez não precisassem existir.
Um programador mainframe reconhece imediatamente esse universo.
🐍 CAPÍTULO 2
Antes das galáxias havia Monty Python
Existe uma conexão maravilhosa entre Adams e Monty Python.
Ele trabalhou com Graham Chapman e conseguiu créditos no programa.
Douglas está inclusive entre o pequeno grupo de pessoas externas ao núcleo principal do Python que recebeu crédito de roteiro na série original. Também apareceu rapidamente diante das câmeras em episódios da quarta temporada.
E aqui encontramos parte do código-fonte de seu humor.
Imagine:
Monty Python
+
ficção científica
+
rádio BBC
+
filosofia
+
burocracia britânica
+
computadores
+
chá
+
um sujeito olhando para o universo e perguntando:
"Mas quem aprovou essa arquitetura?"
Resultado:
Douglas Adams.
Seu nonsense não era simplesmente aleatório.
Essa é uma das grandes lições para quem tenta imitá-lo.
Por trás do absurdo existe lógica.
Uma lógica impecável.
O problema é que a premissa inicial é completamente insana.
📺 CAPÍTULO 3
Doctor Who entra no CPD
Antes e durante a explosão de Hitchhiker's, Adams também trabalhou em outra instituição britânica:
Doctor Who.
Foi roteirista e chegou a atuar como script editor da série.
Entre suas contribuições estão histórias relacionadas a:
The Pirate Planet;
City of Death;
Shada;
e trabalhos na temporada 17.
Isso é importantíssimo para entender Adams.
Porque Doctor Who permitia exatamente aquilo de que ele gostava:
pegar uma ideia filosófica absurda...
...transformá-la em problema tecnológico...
...colocar personagens britânicos no meio...
...e observar a civilização entrar em pane.
Em outras palavras:
produção.
🚀 CAPÍTULO 4
O Guia nasceu no rádio
Aqui existe uma curiosidade maravilhosa para uma geração acostumada a pensar primeiro em livros.
O Guia do Mochileiro das Galáxias não nasceu como livro.
Nasceu como programa de rádio da BBC Radio 4.
A primeira transmissão aconteceu em março de 1978. (Douglas Adams)
Depois veio praticamente tudo:
RÁDIO
↓
LIVROS
↓
TV
↓
DISCOS
↓
TEATRO
↓
JOGO DE COMPUTADOR
↓
FILME
↓
mais adaptações
↓
fãs discutindo cronologia
↓
42
O próprio site dedicado à obra de Adams registra essa extraordinária multiplicação de formatos. (Douglas Adams)
Portanto, chamar Hitchhiker's simplesmente de "uma série de livros" é quase como chamar z/OS de editor de texto.
Tecnicamente há texto envolvido.
Mas estamos omitindo alguns detalhes.
🌍 CAPÍTULO 5
Arthur Dent: o homem que só queria sua casa
E aqui encontramos nosso primeiro suspeito de ser Douglas Adams disfarçado.
Arthur Dent.
Arthur não é Luke Skywalker.
Não quer salvar a galáxia.
Não possui poderes.
Não tem treinamento Jedi.
Não descobriu ser herdeiro de nenhuma dinastia.
Arthur gostaria basicamente de:
ter sua casa
tomar chá
entender o que está acontecendo
Infelizmente, o universo possui outros planos.
Sua casa será demolida para construir uma estrada.
Pouco depois...
a Terra será demolida para construir uma via expressa hiperespacial.
E essa simetria contém Douglas Adams inteiro.
O indivíduo é esmagado pela burocracia local.
A humanidade inteira é esmagada pela burocracia cósmica.
A escala muda.
A estupidez administrativa permanece perfeitamente compatível.
📋 CAPÍTULO 6
Vogons: o verdadeiro terror do universo
Esqueça monstros.
Esqueça Daleks.
Esqueça invasões alienígenas.
Adams compreendeu algo muito mais assustador.
O formulário.
Os Vogons representam uma das maiores contribuições da literatura para a compreensão da burocracia.
Eles não precisam odiar você.
Isso seria pessoal demais.
Eles possuem:
procedimentos.
regulamentos.
autorizações.
protocolos.
E provavelmente algum equivalente galáctico do:
TICKET STATUS: CLOSED
REASON:
WORKING AS DESIGNED
A Terra será destruída?
Lamentável.
Os planos estavam disponíveis.
Você não consultou?
Problema seu.
Qualquer pessoa que já tenha enfrentado uma mudança corporativa aprovada por quinze departamentos reconhecerá imediatamente a espécie.
📚 CAPÍTULO 7
A trilogia de cinco livros
Douglas Adams também conseguiu melhorar a matemática.
Sua famosa "trilogia" acabou composta por cinco romances escritos por ele:
1. The Hitchhiker's Guide to the Galaxy
1979
2. The Restaurant at the End of the Universe
1980
3. Life, the Universe and Everything
1982
4. So Long, and Thanks for All the Fish
1984
5. Mostly Harmless
1992
O site oficial registra a sequência e suas datas, incluindo o sucesso comercial extraordinário da série. (Douglas Adams)
Uma trilogia com cinco livros.
Porque quando você criou uma piada cósmica sobre a incapacidade humana de organizar a realidade, seria decepcionante começar obedecendo à aritmética.
Para descobrir a pergunta correspondente à resposta 42, é construído um computador ainda mais sofisticado.
Chamado:
Terra.
Sim.
Nós.
O planeta inteiro.
Um sistema computacional gigantesco.
Executando durante milhões de anos.
Até que...
pouco antes de terminar o processamento...
os Vogons destroem a máquina.
Se isso não parece um projeto de TI cancelado três semanas antes do go-live depois de oito anos de desenvolvimento, você ainda não trabalhou tempo suficiente em uma grande organização.
🐟 CAPÍTULO 11
Babel Fish
Outra criação genial:
Babel Fish.
Um pequeno peixe capaz de permitir comunicação entre idiomas.
Décadas depois, "Babel Fish" tornou-se referência cultural para sistemas de tradução automática; serviços tecnológicos chegaram a adotar diretamente o nome inspirado na criação de Adams. (Estante Virtual)
Hoje olhamos para tradução automática e IA generativa e pensamos:
Douglas provavelmente passaria quinze minutos fascinado.
Depois perguntaria:
— Muito interessante. Agora quantos bilhões gastamos construindo máquinas para podermos finalmente discutir com estrangeiros em tempo real?
interconectividade fundamental de todas as coisas.
O método investigativo dele poderia ser resumido assim:
tudo está conectado
↓
portanto qualquer pista pode importar
↓
inclusive aquela completamente absurda
↓
especialmente aquela completamente absurda
Qualquer analista investigando um incidente em produção às três da manhã entende perfeitamente.
O Db2 está lento.
Por quê?
Porque houve alteração no storage.
Por quê?
Porque um processo batch mudou.
Por quê?
Porque alguém alterou um parâmetro.
Por quê?
Porque houve migração seis meses atrás.
Por quê?
Porque...
Dirk sorri.
Interconectividade fundamental de todas as coisas.
🌳 CAPÍTULO 13
Last Chance to See
Existe ainda outro Douglas Adams.
Menos conhecido.
E talvez ainda mais interessante.
O ambientalista.
Com o zoólogo Mark Carwardine, Adams participou do projeto que resultaria em:
Last Chance to See
Uma viagem para encontrar espécies ameaçadas de extinção.
Não era simplesmente comédia.
Era conservação.
Era ciência.
Era encantamento diante da biodiversidade.
Adams tornou-se patrono fundador da Save the Rhino e chegou, em 1994, a participar de uma subida ao Kilimanjaro envolvendo uma fantasia de rinoceronte para ajudar a arrecadar dinheiro e conscientização. (Save the Rhino)
Pare por alguns segundos.
O homem que escreveu sobre um peixe tradutor universal...
subiu uma montanha...
vestido de rinoceronte...
para tentar salvar rinocerontes reais.
Douglas Adams não precisava inventar um personagem chamado Douglas Adams.
A produção já estava suficientemente absurda.
🍎 CAPÍTULO 14
Douglas Adams, o nerd
Aqui nossa história fica particularmente interessante.
Douglas Adams adorava tecnologia.
Computadores não eram apenas ferramentas de escrita para ele.
Eram brinquedos intelectuais.
O Macintosh o fascinou.
Ele foi um dos primeiros entusiastas britânicos da plataforma e manteve enorme interesse por computadores pessoais e tecnologias digitais. (Wikipedia)
Lembre-se da época.
Estamos falando dos anos 1980 e 1990.
Quando dizer:
"computadores vão mudar nossa maneira de comunicar, criar e pensar"
ainda não era frase obrigatória de keynote.
Adams percebeu cedo que computadores poderiam ser meios culturais.
Não apenas calculadoras.
🎮 CAPÍTULO 15
E naturalmente ele fez jogos
Em 1984 surgiu o jogo baseado em:
The Hitchhiker's Guide to the Galaxy.
Adams participou também de projetos como:
Bureaucracy;
Starship Titanic.
Seu catálogo oficial inclui esses experimentos tecnológicos ao lado dos livros e trabalhos audiovisuais. (Douglas Adams)
E Bureaucracy merece aplausos.
Porque transformar burocracia em videogame é reconhecer que o verdadeiro survival horror sempre foi preencher documentos corretamente.
🎸 CAPÍTULO 16
Pink Floyd aparece porque naturalmente aparece
Douglas Adams também era amigo de David Gilmour, do Pink Floyd.
O próprio material oficial de Adams, ao aconselhar aspirantes a escritores, enfatiza duas coisas bastante menos românticas:
escrever alguma coisa e possuir determinação para continuar. (Douglas Adams)
A inspiração é maravilhosa.
O problema é que eventualmente alguém precisa salvar o arquivo.
✍️ CAPÍTULO 18
O segredo técnico do humor de Adams
Se você escreve artigos, histórias ou documentação e quer aprender alguma coisa com Douglas Adams, não copie apenas as piadas.
Copie a arquitetura.
1. Comece com algo normal
Uma casa será demolida.
2. Aumente absurdamente a escala
Agora a Terra será demolida.
3. Mantenha a lógica administrativa
Existe documentação.
4. Faça o personagem reagir como uma pessoa comum
— Como assim?
5. Trate o absurdo como rotina
— Os documentos estavam disponíveis.
Essa é a mágica.
O narrador nunca precisa gritar que aquilo é engraçado.
O universo considera tudo perfeitamente razoável.
☕ CAPÍTULO 19
Douglas Adams aplicado ao mainframe
Imagine um diálogo.
— Por que esse programa existe?
— Porque processa o arquivo XPTO.
— Por que o arquivo XPTO existe?
— Porque alimenta o sistema ABC.
— Por que ABC precisa disso?
— Não sabemos.
— Quem escreveu?
— Aposentou em 1994.
— Existe documentação?
— Sim.
— Onde?
— Num dataset arquivado.
— Qual?
— Não sabemos.
— Então como sabemos que funciona?
— O job termina RC=0.
Arthur Dent provavelmente perguntaria:
— Isso é normal?
Ford Prefect responderia:
— Em sistemas enterprise, aparentemente sim.
🥚 CAPÍTULO 20
Easter eggs para carregar na toalha
Algumas pequenas delícias do universo Adams:
42 escapou dos livros e virou referência cultural gigantesca, aparecendo repetidamente em tecnologia, matemática recreativa e cultura hacker. (Douglas Adams)
Bellacosa Mainframe o perigo da tecnologia sem objetivo
☕ Um Café no Bellacosa Mainframe
🧠 DEEP THOUGHT E A DUNGEON DO 42 — QUANDO O COBOL DESCOBRIU QUE A RESPOSTA CORRETA NÃO SERVE PARA NADA SE NINGUÉM SOUBER A PERGUNTA
Tecnologia, COBOL, sistemas de informação, semiótica, automação, sistemas sociotécnicos, modernização, IA, agentes, conhecimento, responsabilidade — e o dia em que um programador COBOL descobriu que até o maior computador do Universo pode entregar uma resposta inútil quando ninguém sabe exatamente qual problema queria resolver.
🎬 PRÓLOGO — A RESPOSTA É 42
Imagine que você acabou de entrar em uma grande empresa como programador COBOL.
Primeiro emprego.
Primeiro crachá.
Primeiro acesso ao TSO.
Primeiro READY.
Primeira vez olhando para uma tela ISPF e pensando:
— Meu Deus... onde fui me meter?
Você recebe sua primeira missão.
Um programa COBOL antigo está apresentando comportamento estranho.
O líder técnico explica:
— Precisamos modernizar isso.
Você pergunta:
— Qual é o problema?
Silêncio.
Alguém responde:
— É COBOL.
Você insiste:
— Sim. Mas qual é o problema?
Novo silêncio.
Então começam as respostas:
— É antigo.
— Precisamos ir para cloud.
— Precisamos colocar APIs.
— Precisamos usar inteligência artificial.
— Precisamos de microsserviços.
— Precisamos de Kubernetes.
— Precisamos modernizar.
Você olha novamente para o programa.
Ele executa diariamente.
Processa milhões de registros.
O tempo de processamento está dentro da janela batch.
Não existem incidentes graves associados a ele.
O custo é conhecido.
A operação conhece o sistema.
E aparentemente ninguém consegue explicar exatamente qual problema está sendo resolvido pela modernização.
Nesse momento, uma voz grave ecoa pela sala:
42.
Todos olham assustados.
É Deep Thought.
O lendário computador de O Guia do Mochileiro das Galáxias acaba de entrar na War Room.
E ele tem uma péssima notícia:
vocês estão procurando respostas antes de descobrir a pergunta.
Pegue o café.
Abra o ISPF.
Hoje nossa dungeon não começa com COBOL.
Começa com algo muito mais perigoso:
uma solução procurando um problema.
🧙 CAPÍTULO 1 — A CHANTAGEM TECNOLÓGICA
Existe uma crença recorrente na indústria de tecnologia:
tecnologia nova é necessariamente melhor.
O mecanismo funciona mais ou menos assim:
Tecnologia nova
↓
Marketing
↓
Promessa de produtividade
↓
Medo de ficar para trás
↓
Compra
↓
Implantação
↓
Problemas inesperados
↓
Nova tecnologia prometendo resolver os problemas
↓
REPEAT
Esse medo ganhou até uma expressão moderna:
FOMO — Fear Of Missing Out.
O medo de ficar de fora.
A empresa olha para a concorrência usando inteligência artificial e pergunta:
— Por que ainda não temos IA?
Poucos perguntam:
— Qual problema nosso exige IA?
Essa diferença parece pequena.
Não é.
É a diferença entre engenharia e fetichismo tecnológico.
Podemos chamar esse fenômeno de chantagem tecnológica:
“Se você não comprar nossa nova tecnologia, sua empresa ficará ultrapassada.”
Ontem eram PCs.
Depois cliente-servidor.
Depois downsizing.
Depois Internet.
Depois SOA.
Depois cloud.
Depois containers.
Depois blockchain.
Depois inteligência artificial generativa.
Agora:
Agentic AI.
Não significa que essas tecnologias sejam ruins.
Pelo contrário.
Muitas transformaram profundamente a computação.
O problema começa quando a tecnologia deixa de ser meio e passa a ser objetivo.
⚔️ CAPÍTULO 2 — A SOLUÇÃO QUE SAIU PROCURANDO UM PROBLEMA
Imagine uma empresa que compra uma poderosa plataforma de inteligência artificial.
TECNOLOGIA
↓
COMPRA
↓
PROJETO
↓
PROCURA POR CASO DE USO
Quando ouvimos:
“Agora precisamos encontrar casos de uso para justificar a plataforma.”
Deep Thought provavelmente responderia:
Porque começamos pela resposta.
Ainda não sabemos a pergunta.
🧠 CAPÍTULO 3 — DEEP THOUGHT E O MAIOR PROBLEMA DE REQUISITOS DO UNIVERSO
Em O Guia do Mochileiro das Galáxias, uma civilização constrói um computador gigantesco chamado Deep Thought.
Sua missão é encontrar a resposta para:
a Vida, o Universo e Tudo Mais.
Depois de um período absurdamente longo de processamento, Deep Thought finalmente anuncia a resposta:
42.
Problema resolvido?
Não.
Ninguém sabe exatamente qual era a pergunta.
Essa é uma das melhores metáforas acidentais sobre engenharia de requisitos.
Um computador pode executar perfeitamente:
INPUT
↓
ALGORITHM
↓
OUTPUT
Mas existe uma pergunta anterior:
O que estamos tentando descobrir?
E outra posterior:
O que significa o resultado?
Sem essas duas coisas, podemos possuir processamento perfeito e ainda assim produzir algo inútil.
🖥️ CAPÍTULO 4 — COMPUTADORES NÃO RESOLVEM PROBLEMAS
Calma.
Eles obviamente resolvem determinados problemas computacionais.
Mas existe uma distinção importante.
Computadores executam representações formalizadas de problemas.
Antes de chegar ao COBOL, alguma coisa precisa acontecer.
Imagine um banco.
A organização estabelece:
determinadas contas devem ser bloqueadas quando determinadas condições forem satisfeitas.
Depois isso vira regra de negócio.
Depois especificação.
Finalmente podemos ter:
IF SALDO-CLIENTE < ZERO
MOVE 'B' TO STATUS-CONTA
END-IF.
Para a CPU isso é maravilhoso.
Temos uma condição.
Temos dados.
Temos uma ação.
Mas Deep Thought pergunta:
— Por que saldo negativo significa bloqueio?
Boa pergunta.
Talvez existam:
limites de crédito;
cheque especial;
clientes diferenciados;
transações contestadas;
depósitos ainda não compensados;
determinações judiciais;
exceções operacionais.
Portanto, antes daquele pequeno IF, existiu um mundo inteiro.
REALIDADE
↓
POLÍTICA
↓
REGRA DE NEGÓCIO
↓
ESPECIFICAÇÃO
↓
ALGORITMO
↓
COBOL
O programador normalmente encontra apenas o último andar dessa pirâmide.
🏺 CAPÍTULO 5 — O PROGRAMA COBOL É UM FÓSSIL ORGANIZACIONAL
Agora você encontra:
IF WS-TYPE = '7'
AND WS-CODE NOT = '91'
AND WS-FLAG = 'Y'
PERFORM 8300-PROCESSAR
END-IF.
Sua primeira reação pode ser:
— Que porcaria é essa?
Cuidado.
Talvez você esteja diante de um fóssil.
WS-TYPE = '7' pode ter surgido em 1989.
WS-CODE NOT = '91' pode ter aparecido depois de uma fraude em 1997.
WS-FLAG = 'Y' pode representar uma exigência regulatória de 2008.
E o PERFORM pode ter sido alterado depois de uma fusão empresarial em 2014.
Você não está simplesmente lendo código.
Está praticando:
arqueologia organizacional.
Um sistema legado pode ser uma espécie de memória institucional executável.
Isso explica por que reescrever sistemas antigos é muito mais difícil do que traduzir linguagens.
🏰 CAPÍTULO 6 — SISTEMAS DE INFORMAÇÃO NÃO SÃO APENAS COMPUTADORES
Um erro comum de iniciantes é pensar:
Sistema de Informação
=
Hardware + Software + Banco de Dados
Na realidade temos algo muito maior:
PESSOAS
│
│
PROCESSOS ── INFORMAÇÃO ── TECNOLOGIA
│
│
REGRAS
│
│
CULTURA
Existe ainda:
poder;
autoridade;
confiança;
experiência;
legislação;
comunicação;
exceções;
conhecimento tácito.
Isso é chamado de visão sociotécnica.
O computador é apenas uma parte do sistema.
📜 CAPÍTULO 7 — EXISTE UM SISTEMA QUE NÃO ESTÁ NO COMPUTADOR
Imagine um processo de crédito.
O manual diz:
Pedido
↓
Análise
↓
Score
↓
Aprovação
Esse é o sistema formal.
Mas na prática acontece:
Pedido
↓
Analista
↓
Consulta sistema
↓
Liga para gerente
↓
"Conheço esse cliente."
↓
Consulta documento antigo
↓
Conversa com supervisor
↓
Exceção
↓
Aprovação
Isso também é um sistema de informação.
Só que parte dele é informal.
O perigo aparece quando alguém automatiza somente:
Pedido → Score → Aprovação
e acredita ter automatizado todo o processo.
Não automatizou.
Automatizou apenas a parte que conseguiu formalizar.
🔒 CAPÍTULO 8 — “O SISTEMA NÃO DEIXA”
Quem nunca ouviu:
“Não posso fazer. O sistema não deixa.”
Essa frase merece atenção.
O computador não acordou naquela manhã e decidiu impedir alguma coisa.
Alguém:
definiu uma política;
transformou-a em regra;
especificou uma condição;
programou;
testou;
colocou em produção.
Portanto:
"O SISTEMA NÃO DEIXA"
normalmente significa:
"UMA DECISÃO HUMANA FOI
FORMALIZADA EM SOFTWARE"
Mas existe um efeito psicológico interessante.
Depois que a regra entra no computador, ganha aparência de autoridade.
— Por que meu pedido foi recusado?
— O sistema recusou.
Como se o computador fosse uma entidade independente.
📡 CAPÍTULO 9 — DADO NÃO É INFORMAÇÃO
Considere:
327
O que significa?
Nada.
Agora:
327 ms
Melhor.
Depois:
CICS RESPONSE TIME = 327 ms
Agora temos informação contextualizada.
Mas ainda falta alguma coisa.
Imagine que historicamente aquela transação responde entre 80 e 150 ms.
Agora:
BASELINE = 120 ms
ATUAL = 327 ms
Um especialista interpreta:
Existe degradação.
Investigando, encontra:
Db2 LOCK CONTENTION
↓
WAIT
↓
CICS RESPONSE TIME
↓
327 ms
um processo de 1987 executando lindamente dentro de containers.
Modernização tecnológica não garante modernização organizacional.
Antes de reescrever o programa, deveríamos perguntar:
— Essa regra ainda é necessária?
— Esse processo ainda faz sentido?
— Essa informação ainda precisa ser coletada?
— Essa aprovação ainda controla algum risco?
— Essa exceção ainda existe?
Às vezes a melhor linha de código modernizada é aquela que descobrimos que pode ser eliminada.
🦖 CAPÍTULO 15 — LEGACY NÃO SIGNIFICA INÚTIL
Tecnologia antiga possui algo que tecnologia nova ainda não conseguiu comprar:
história operacional.
COBOL, CICS, Db2 e z/OS possuem décadas de:
documentação;
correções;
conhecimento;
práticas operacionais;
troubleshooting;
compatibilidade;
experiência.
Tecnologia nova oferece possibilidades fantásticas.
Mas também pode trazer:
bugs desconhecidos;
escassez de especialistas;
documentação imatura;
mudanças rápidas;
APIs instáveis;
dependências novas.
Portanto:
NOVO ≠ MELHOR
e:
VELHO ≠ RUIM
A pergunta correta é:
ADEQUADO?
Deep Thought aprova.
💰 CAPÍTULO 16 — O LOCK-IN MAIS PERIGOSO NÃO É TECNOLÓGICO
Todo mundo conhece vendor lock-in.
Mas existe outro:
conceptual lock-in.
Quando compramos determinada tecnologia, começamos a enxergar todos os problemas através dela.
Quem vende blockchain encontra blockchain em tudo.
Quem vende RPA encontra processos para robotizar.
Quem vende cloud encontra workloads para migrar.
Quem vende GenAI encontra copilots.
Quem vende Agentic AI encontra agentes.
É a velha história:
Quando sua única ferramenta é um martelo, muitos problemas começam misteriosamente a parecer pregos.
A ferramenta passou a definir o problema.
Esse é o momento de chamar Deep Thought.
🚨 CAPÍTULO 17 — DEBUGGING DA ORGANIZAÇÃO
Imagine:
CLIENTES RECEBERAM COBRANÇA DUPLICADA.
O programador procura o programa.
Isso é necessário.
Mas uma verdadeira investigação pergunta:
Por que duplicação era possível?
Por que não havia idempotência?
Por que reconciliação não detectou?
Por que monitoramento não alertou?
Por que reprocessamento foi autorizado?
Por que o operador acreditou que era seguro?
A documentação explicava isso?
Quem conhecia a exceção?
Qual decisão organizacional criou essa condição?
Você deixou de simplesmente depurar COBOL.
Agora está:
debugando a organização.
Essa é uma habilidade extraordinária para quem trabalha com sistemas críticos.
🧭 CAPÍTULO 18 — PASSO A PASSO ANTES DE AUTOMATIZAR
Antes de escolher tecnologia, faça este exercício.
PASSO 1 — Defina o problema
Não escreva:
“Precisamos de IA.”
Escreva:
“Recebemos 30 mil solicitações mensais e 40% são classificadas manualmente.”
EXECUÇÃO CORRETA
≠
PROBLEMA CORRETAMENTE RESOLVIDO
☕ EPÍLOGO — O PROGRAMADOR COBOL QUE APRENDEU A PERGUNTAR
Nosso jovem programador volta para a War Room.
Alguém pergunta:
— Então vamos migrar o programa?
Ele responde:
— Talvez.
— Java?
— Talvez.
— Cloud?
— Talvez.
— IA?
— Talvez.
O gerente começa a perder a paciência.
— Então qual é a sua recomendação?
O programador olha novamente para o programa COBOL de 35 anos.
Depois pergunta:
Qual problema estamos tentando resolver?
Silêncio.
Deep Thought sorri em algum lugar do Universo.
Porque naquele instante o iniciante deixou de ser simplesmente alguém que escreve COBOL.
Começou a pensar como engenheiro.
Tecnologia não existe isoladamente.
Computadores fazem parte de sistemas sociais.
Dados precisam de contexto.
Sinais precisam de interpretação.
Regras carregam decisões humanas.
Código carrega história.
Automação carrega responsabilidade.
IA não elimina esses problemas.
Amplifica-os.
E modernização não significa trocar uma linguagem velha por uma linguagem nova.
Significa compreender suficientemente bem o sistema para decidir conscientemente o que deve permanecer, o que deve mudar, o que deve ser automatizado e o que nunca deveria ter existido.
Talvez essa seja uma das maiores lições para qualquer programador COBOL entrando no mundo dos sistemas corporativos:
Não se apaixone primeiro pela resposta. Apaixone-se pelo problema.
Porque hardware muda.
Linguagens mudam.
Arquiteturas mudam.
Mainframes evoluem.
Cloud evolui.
IA evolui.
Os vendedores continuarão chegando com respostas extraordinárias.
Mas alguém ainda precisará fazer aquela pergunta incômoda na reunião:
“Qual era mesmo o problema?”
E quando ninguém souber responder...
há sempre uma resposta tecnicamente disponível.
IDENTIFICATION DIVISION.
PROGRAM-ID. DEEP-THOUGHT.
PROCEDURE DIVISION.
MOVE 42 TO WS-ANSWER
DISPLAY
'THE ANSWER TO LIFE,'
' THE UNIVERSE AND EVERYTHING: '
WS-ANSWER
STOP RUN.
MAXCC=0000.
Resposta encontrada.
Projeto entregue.
Produção estável.
Só faltou um pequeno requisito:
descobrir a pergunta.
☕💻
EASTER EGG FINAL: se este artigo fosse um job de produção, eu verificaria o spool às 03:17. Deep Thought provavelmente estaria esperando por lá, tentando descobrir por que alguém abriu um incidente para corrigir um 42 que estava funcionando exatamente como especificado.
Máxima Bellacosa
O job pode terminar com MAXCC=0000, entregar 42 e ainda assim o projeto inteiro estar errado — porque ninguém perguntou se aquela era a pergunta que precisava ser respondida.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
