Bellacosa Mainframe o mercado da informatica é muito louco

☕ Um Café no Bellacosa Mainframe

Dr. Strangelove, Watson e a Máquina que se Recusava a Morrer

💣 Como System/360, COBOL, watsonx, LinuxONE, IA, burocracia corporativa e uma aposta de US$ 5 bilhões explicam por que às vezes o maior risco de uma empresa é ter medo de arriscar

“Gentlemen, you can’t fight in here! This is the War Room!”

Se você começou a estudar COBOL recentemente, provavelmente alguém já lhe contou uma das três histórias oficiais do planeta Mainframe:

COBOL é velho.
Mainframe é velho.
A IBM é aquela empresa muito antiga que fabrica computadores enormes que bancos inexplicavelmente ainda usam.

Parabéns.

Você acabou de receber aproximadamente o mesmo nível de precisão histórica de alguém explicando a Segunda Guerra Mundial dizendo:

“Foi uma briga grande que aconteceu antes da internet.”

Pegue seu café.

Hoje entraremos na War Room do Bellacosa Mainframe.

Na parede existe um mapa-múndi iluminado.

Em algum lugar um executivo segura uma pasta escrita:

CONFIDENTIAL — STRATEGIC TRANSFORMATION

Outro executivo pergunta se precisamos criar um Steering Committee para decidir quem participará do Steering Committee.

Enquanto isso, no subsolo, um programa COBOL escrito em 1978 processa R$ 4 bilhões antes do almoço e não parece particularmente impressionado.

Nosso assunto começa com uma pergunta simples:

Como uma empresa decide apostar seu próprio futuro?

Mas logo essa pergunta nos levará a Thomas Watson, IBM System/360, canibalização tecnológica, burocracia, Watson AI, Watson Health, watsonx, LinuxONE, IBM Z, Spyre, IA generativa e finalmente ao pobre programador COBOL iniciante tentando compreender por que um programa criado antes de ele nascer continua funcionando.

E, ao melhor estilo Dr. Strangelove, descobriremos que talvez o problema nunca tenha sido a bomba.

Talvez o problema seja descobrir quem tem autorização para apertar o botão.

☕ CAPÍTULO 1 — Antes do COBOL havia executivos malucos o suficiente para apostar a companhia

Quando estudamos tecnologia antiga, cometemos um erro clássico.

Olhamos para trás sabendo quem venceu.

Você vê o IBM System/360 e pensa:

“Claro que deu certo.”

Não.

Em 1964 ninguém recebeu do futuro um WhatsApp dizendo:

Thomas, relaxa. Vai funcionar. Abraços, 2026.

A IBM descreve o System/360 como uma aposta de aproximadamente US$ 5 bilhões, realizada ao longo de quatro anos, considerada um verdadeiro bet-the-business gamble. (IBM)

Cinco bilhões de dólares dos anos 1960.

Não era:

POC
↓
MVP
↓
piloto
↓
feedback
↓
release incremental

Era praticamente:

IBM
 |
 +---- dinheiro
 |
 +---- engenheiros
 |
 +---- fábricas
 |
 +---- reputação
 |
 +---- clientes
 |
 +---- carreira dos executivos
 |
 └----> SYSTEM/360
          |
          +---- se funcionar: futuro
          |
          └---- se falhar: procure emprego

Isso muda completamente nossa leitura da história.

Thomas J. Watson Jr. não sabia que estava construindo uma lenda.

Ele sabia que estava construindo um risco gigantesco.

🧠 CAPÍTULO 2 — O que havia de revolucionário no System/360?

Programador COBOL iniciante, atenção aqui.

Essa parte ajuda a entender praticamente todo o DNA do mainframe moderno.

Antes do System/360, fabricantes frequentemente criavam famílias de computadores bastante diferentes entre si.

Você comprava uma máquina pequena.

Sua empresa crescia.

Precisava de uma máquina maior.

Fantástico.

Só havia um pequeno problema.

Seu software poderia precisar ser profundamente alterado ou reescrito.

Imagine comprar um notebook novo e descobrir:

“Excelente máquina, senhor. Infelizmente todos os seus programas precisarão ser reprogramados.”

Não parece uma experiência de usuário particularmente elegante.

O System/360 atacou justamente essa fragmentação.

A proposta era criar uma família compatível de computadores, cobrindo diferentes níveis de capacidade dentro de uma arquitetura comum. A IBM descreve essa compatibilidade como uma das mudanças centrais introduzidas pelo System/360. (IBM)

Para o cliente isso significava algo extraordinário:

empresa pequena
      ↓
System/360 menor
      ↓
empresa cresce
      ↓
System/360 maior
      ↓
software continua relevante

Observe a ideia.

Não estamos mais vendendo apenas computadores.

Estamos vendendo uma arquitetura.

Essa distinção parece pequena.

Mudou a indústria.

💣 CAPÍTULO 3 — Dr. Strangelove explica canibalização

Agora imagine a reunião.

— Senhor Watson, temos vários computadores vendendo muito bem.

— Excelente.

— E vamos desenvolver uma família nova que poderá substituir esses produtos?

— Sim.

— Mesmo que eles sejam lucrativos?

— Sim.

— Então vamos concorrer conosco mesmos?

— Exatamente.

Nesse momento Dr. Strangelove levanta lentamente da cadeira.

Willkommen à canibalização tecnológica.

Canibalização significa criar um produto que ameaça parte da receita de outro produto da própria empresa.

Empresas adoram inovação até descobrirem que a inovação pretende mexer no faturamento existente.

Imagine:

PRODUTO A

Receita: $$$$$$$$
Clientes: muitos
Executivos: felizes
Bonificações: felizes

                 ↓

PRODUTO B

Tecnologia melhor
Potencial enorme
Receita inicial: $
Clientes: poucos
Executivos do produto A: subitamente preocupados

Do ponto de vista da empresa inteira, B talvez seja o futuro.

Do ponto de vista do diretor responsável por A:

B é Godzilla chegando em Tóquio.

E aqui começamos a compreender por que inovação em grandes empresas é um problema político, não apenas técnico.

🏢 CAPÍTULO 4 — O organograma também compila

Imagine uma empresa com um sistema chamado:

CUSTOMER-MASTER

Existe um gerente.

Acima dele existe um diretor.

Acima do diretor existe um vice-presidente.

Abaixo deles:

CUSTOMER-MASTER
      |
      +-- Development
      |
      +-- Support
      |
      +-- Sales
      |
      +-- Architecture
      |
      +-- Operations
      |
      +-- Budget
      |
      +-- 387 PowerPoints

Então aparece alguém dizendo:

“Tenho uma nova arquitetura capaz de substituir quase tudo isso.”

Tecnicamente:

fantástico.

Politicamente:

SOC7 organizacional.

Porque tecnologia distribui poder.

Produtos criam departamentos.

Departamentos criam cargos.

Cargos criam orçamento.

Orçamento cria influência.

Influência cria estruturas que começam a defender sua própria existência.

Portanto existe uma regra Bellacosa de arquitetura corporativa:

Todo software suficientemente antigo acaba ganhando um organograma.

E organogramas possuem uma característica peculiar:

raramente aceitam DELETE sem CONFIRM.

🩺 CAPÍTULO 5 — Management não é exatamente Leadership

Agora chegamos ao coração da discussão.

Um bom gerente pode perguntar:

Como reduzimos o custo desta operação em 4%?

Excelente pergunta.

Um líder estratégico pode perguntar:

Esta operação deveria existir daqui a dez anos?

Essa pergunta é muito mais perigosa.

Porque management tende a otimizar aquilo que existe.

Leadership precisa ocasionalmente decidir que aquilo que existe não deveria continuar existindo da mesma maneira.

Pense num programa COBOL.

Você recebe:

01 WS-TAXA PIC 9(03)V99.

Pode melhorar o código ao redor.

Documentar.

Criar testes.

Refatorar.

Otimizar SQL.

Tudo ótimo.

Mas talvez a pergunta estrutural seja:

Por que calculamos essa taxa aqui?

Essa pergunta pode revelar que toda a lógica deveria estar em outro domínio.

Leadership organizacional funciona parecido.

🧨 CAPÍTULO 6 — O projeto raramente morre com um tiro

Hollywood imagina decisões corporativas assim:

— PROJETO CANCELADO!

Na prática:

— Excelente ideia.

— Vamos analisar.

— Precisamos envolver stakeholders.

— Architecture precisa revisar.

— Finance precisa calcular ROI.

— Legal quer conversar.

— Risk solicita documentação.

— Security quer threat model.

— Procurement precisa verificar fornecedores.

— Precisamos criar governance.

— Vamos montar um working group.

— O working group recomenda um steering committee.

— O steering committee solicita nova análise.

Seis meses depois:

PROJECT STATUS
--------------
ON HOLD

Ninguém matou o projeto.

Ele faleceu calmamente cercado pela família.

Causa mortis:

burocratic latency.

Esse fenômeno é importante porque grandes empresas podem produzir decisões individualmente razoáveis que coletivamente geram resultados absurdos.

Security estava certo.

Finance estava certo.

Legal estava certo.

Architecture estava certo.

Procurement estava certo.

Todos estavam certos.

E o concorrente lançou o produto.

🧠 CAPÍTULO 7 — Thomas Watson Jr. não liderava uma startup

Existe uma tentação perigosa de imaginar a velha IBM como um pequeno laboratório romântico cheio de cientistas fumando cachimbo.

Nada disso.

Era uma organização gigantesca.

Watson Jr. aprofundou fortemente a posição da IBM em computação e pesquisa. A própria IBM destaca sua decisão de criar em 1956 uma divisão independente de pesquisa reportando à alta administração. (IBM)

Portanto o argumento não pode ser:

“IBM antiga inovava porque não tinha burocracia.”

Tinha.

O ponto interessante é outro:

a estratégia possuía autoridade suficiente para atravessar a burocracia.

Isso muda tudo.

Burocracia pode ser necessária.

Em bancos, saúde, seguros, telecomunicações e governo, processos existem porque erros custam muito.

O problema começa quando:

GOVERNANCE > DECISION

Governança deveria ajudar a empresa a decidir corretamente.

Não impedir a empresa de decidir.

🧪 CAPÍTULO 8 — Watson entra no Jeopardy!

Pulamos algumas décadas.

Chegamos à inteligência artificial.

IBM Watson ficou mundialmente famoso quando demonstrou uma capacidade impressionante em linguagem natural e recuperação de informação.

Tecnologicamente, aquilo ajudou a colocar IA novamente no imaginário empresarial.

Então apareceu um perigo conhecido.

O marketing começou a construir expectativas gigantescas.

Existe um abismo entre:

“Esta tecnologia consegue executar uma demonstração extraordinária.”

“Esta tecnologia pode resolver genericamente problemas empresariais extremamente complexos.”

Pense no COBOL.

Um programa que calcula juros perfeitamente não significa que ele também consegue:

detectar fraude;
emitir cartão;
controlar estoque;
validar CPF;
administrar seguro;
calcular aposentadoria.

A tecnologia pode ser boa.

A generalização é que pode ser perigosa.

🏥 CAPÍTULO 9 — Watson Health e a dívida da expectativa

Saúde é um excelente exemplo.

Parece intuitivo pensar:

muitos artigos médicos
+
IA
=
diagnóstico fantástico

Só que medicina possui:

dados incompletos;
linguagem ambígua;
protocolos diferentes;
populações diferentes;
resultados probabilísticos;
prontuários inconsistentes;
responsabilidade clínica;
regulamentação;
conhecimento em constante mudança.

Transformar tecnologia impressionante numa plataforma clínica universal é enormemente mais difícil que uma demonstração controlada.

Em 2022, IBM anunciou a venda a Francisco Partners de determinados ativos de dados e analytics ligados ao Watson Health. (IBM Newsroom)

Isso não significa:

“Watson era uma fraude.”

Essa seria uma conclusão simplista.

Significa que existe diferença entre:

TECHNOLOGY SUCCESS

BUSINESS MODEL SUCCESS

e ainda outra diferença:

BUSINESS MODEL SUCCESS

versus:

PLATFORM SUCCESS

Programadores precisam aprender isso cedo.

Código funcionando é apenas uma camada do problema.

💳 CAPÍTULO 10 — Technical Debt ganhou um irmão: Expectation Debt

Você provavelmente ouvirá muito sobre technical debt.

É a dívida técnica acumulada quando fazemos atalhos.

Mas existe outra dívida:

expectation debt.

Ela aparece assim:

CAPACIDADE REAL = 7

MARKETING = 47

O cliente compra expectativa 47.

Recebe tecnologia 7.

Mesmo que 7 seja excelente, a percepção será:

“Falhou.”

Isso é devastador.

Há produtos tecnicamente bons destruídos por expectativas impossíveis.

Uma regra importante:

Nunca venda amanhã como se estivesse disponível ontem.

Mainframe sobreviveu décadas em parte porque sua reputação empresarial é construída sobre previsibilidade.

Quando alguém promete 99,999..., existe engenheiro passando noites garantindo que aquela vírgula não seja poesia.

🤖 CAPÍTULO 11 — Então apareceu watsonx

Em 2023, IBM apresentou watsonx como uma plataforma empresarial de IA e dados. Originalmente, a estrutura foi apresentada em torno de componentes como watsonx.ai, watsonx.data e watsonx.governance, abordando desenvolvimento de modelos, dados e governança. (IBM Newsroom)

Aqui precisamos separar marketing de arquitetura.

watsonx não é simplesmente:

Watson + X

embora o departamento internacional de piadas corporativas agradeça a oportunidade.

Existe uma mudança conceitual importante.

Watson frequentemente era percebido como:

IBM possui uma IA capaz de resolver seu problema.

watsonx aproxima-se mais de:

IBM oferece componentes para você construir, operar e governar IA empresarial.

Isso é muito diferente.

Observe:

WATSON

problema
   ↓
IA IBM
   ↓
resposta

Agora:

WATSONX

modelos
   +
dados
   +
governança
   +
integração
   +
infraestrutura
   ↓
solução empresarial

Arquitetonicamente, isso talvez seja até mais coerente com o DNA histórico da IBM.

🏗 CAPÍTULO 12 — IBM geralmente é brilhante quando transforma tecnologia em infraestrutura

Esse ponto é fundamental.

System/360 não ganhou porque fazia uma demonstração bonita.

Ganhou porque criou uma arquitetura.

IBM historicamente é muito forte quando pega uma tecnologia complicada e pergunta:

Como transformamos isso em infraestrutura empresarial utilizável durante décadas?

Esse é exatamente o tipo de pergunta que interessa ao mundo COBOL.

COBOL não venceu porque era sexy.

COBOL venceu porque resolveu problemas empresariais.

Db2 não existe para impressionar pessoas no churrasco.

CICS não costuma aparecer em videoclipes.

IMS dificilmente ganhará influenciadores fazendo unboxing.

Entretanto:

SELECT
TRANSFER
COMMIT

precisa funcionar.

Às 03:17.

No domingo.

Durante fechamento.

Com metade da empresa dormindo.

Essa é outra filosofia de tecnologia.

🐧 CAPÍTULO 13 — O elefante Linux dentro do mainframe

Agora chegamos ao LinuxONE.

E aqui o programador iniciante costuma ter uma revelação.

— Bellacosa, Linux no mainframe?

Sim.

Respire.

O mundo não acabou.

LinuxONE é uma plataforma IBM baseada na arquitetura de sistemas empresariais da companhia para executar workloads Linux e open source. A geração LinuxONE 5 usa Telum II e pode ser expandida com aceleradores Spyre para aplicações envolvendo IA generativa e diferentes arquiteturas de modelos. (IBM)

Isso destrói uma caricatura muito comum:

MAINFRAME = COBOL

Não.

Mais correto:

MAINFRAME
  |
  +-- COBOL
  +-- Java
  +-- C/C++
  +-- Python
  +-- Linux
  +-- Containers
  +-- APIs
  +-- Databases
  +-- AI

COBOL é extremamente importante.

Mas mainframe é arquitetura, não linguagem.

🧠 CAPÍTULO 14 — LinuxONE talvez sofra de um problema de categoria mental

Diga:

“Mainframe Linux.”

Muitas pessoas imaginam:

computador velho rodando coisa nova.

Agora diga:

“plataforma Linux empresarial para consolidação massiva, alta disponibilidade, segurança, containers, dados e IA.”

A arquitetura não mudou.

Mudou a âncora cognitiva.

Isso é marketing estratégico.

Compare:

MAINFRAME QUE RODA LINUX

com:

ENTERPRISE LINUX PLATFORM

As duas descrições podem apontar para tecnologias semelhantes.

Mas uma olha para trás.

A outra olha para frente.

É por isso que a discussão sobre liderança importa até para você que está estudando PERFORM UNTIL.

Quem define a categoria define como o mercado enxerga a tecnologia.

🚀 CAPÍTULO 15 — Spyre entra na sala

Eis uma parte particularmente interessante da história contemporânea.

IBM Spyre é um acelerador destinado a inferência de IA em plataformas IBM Z e LinuxONE. A documentação atual da IBM o descreve como um acelerador PCIe voltado a ampliar capacidades de inferência, incluindo IA generativa; IBM também o posiciona para casos de IA generativa e agentic AI em LinuxONE 5. (IBM)

Por que isso é interessante?

Porque empresas possuem dados extremamente importantes em:

Db2
VSAM
IMS
SAP
Oracle
Core Banking
CICS

Tradicionalmente podemos imaginar:

TRANSAÇÃO
    ↓
extrair dados
    ↓
mover
    ↓
transformar
    ↓
enviar
    ↓
IA externa
    ↓
resultado

Mas outra filosofia seria:

TRANSAÇÃO
    ↓
DADOS
    ↓
INFERÊNCIA PRÓXIMA
    ↓
DECISÃO

Essa diferença pode ser gigantesca em latência, segurança, movimentação de dados e arquitetura.

💳 CAPÍTULO 16 — Imagine um programa COBOL detectando fraude

Você está começando COBOL.

Seu programa possui:

IF WS-VALOR > 10000
    PERFORM ANALISA-TRANSACAO
END-IF

Abordagem clássica:

regras fixas.

valor > limite?
país diferente?
horário estranho?
cartão novo?

Agora imagine complementar essa lógica com inferência.

COBOL
   ↓
TRANSAÇÃO
   ↓
modelo de fraude
   ↓
score
   ↓
COBOL
   ↓
aprova / revisa / bloqueia

O COBOL não precisa desaparecer.

Ele pode continuar controlando a transação.

A IA vira um novo componente da arquitetura.

Esta é uma dica importantíssima:

Modernização não significa necessariamente substituição.

Às vezes modernizar significa:

LEGADO
+
NOVO COMPONENTE
=
SISTEMA MODERNO

🦖 CAPÍTULO 17 — “Legacy” é uma palavra perigosamente mal utilizada

Quando alguém diz:

“Legacy system.”

Pergunte:

“Legacy em qual sentido?”

Velho?

Crítico?

Difícil de substituir?

Estável?

Lucrativo?

Bem compreendido?

Mal documentado?

Um programa escrito em 1988 pode ser tecnicamente antigo.

Mas se processa corretamente milhões de operações por dia, possui décadas de regras empresariais e custa menos que sua substituição, talvez ele não seja simplesmente “lixo velho”.

Ele pode ser:

capital intelectual executável.

Imagine:

IF CLIENTE-TIPO = 'A'
   AND OPERACAO = '37'
   AND DATA-CONTRATO < 19980101
       PERFORM REGRA-ANTIGA.

O programador jovem pensa:

“Que porcaria.”

O programador experiente pergunta:

“Por que contratos anteriores a 1998 possuem tratamento diferente?”

Depois de três semanas alguém encontra uma legislação extinta cuja regra ainda se aplica aos contratos históricos.

Parabéns.

Aquela linha estranha era direito empresarial fossilizado dentro de software.

🏛 CAPÍTULO 18 — Eis a ironia magnífica da IA

Durante vinte anos ouvimos:

“O problema são os sistemas legados.”

Agora chega IA e pergunta:

“Onde estão os dados empresariais confiáveis, históricos e transacionais?”

Silêncio.

DBA olha para o mainframe.

Programador COBOL olha para o Db2.

Operador olha para CICS.

Mainframe responde:

“Bom dia.”

😂

O que parecia passivo pode virar ativo.

Modelos de IA estão se tornando mais acessíveis.

Mas modelos sem contexto empresarial são apenas modelos.

A vantagem competitiva pode estar nos dados.

E gigantescos volumes desses dados continuam próximos de sistemas centrais.

🛰 CAPÍTULO 19 — Talvez o futuro não seja “mainframe versus cloud”

Essa guerra é preguiçosa.

MAINFRAME
VERSUS
CLOUD

Parece cartaz de luta livre.

A realidade empresarial é muito mais interessante:

                 CLIENTE
                    |
                 API
                    |
              OpenShift
             /         \
        CLOUD         ON-PREM
          |              |
       serviços       LinuxONE
                         |
                        Z
                         |
                    CICS/Db2
                         |
                       COBOL

Isso é hybrid cloud de verdade.

Não significa colocar tudo na cloud.

Nem deixar tudo no mainframe.

Significa colocar cada workload onde faz sentido.

A arquitetura adulta não pergunta:

“Qual tecnologia vence?”

Pergunta:

“Qual combinação minimiza risco e maximiza valor?”

🧠 CAPÍTULO 20 — O COBOLzeiro iniciante precisa aprender arquitetura antes de decorar verbo

Você aprenderá:

MOVE
COMPUTE
PERFORM
EVALUATE
READ
WRITE
REWRITE
CALL

Ótimo.

Mas não pare aí.

Pergunte sempre:

Passo 1 — De onde vem o dado?

VSAM?

Db2?

IMS?

MQ?

API?

Passo 2 — Quem chama meu programa?

JCL?

CICS?

Outro COBOL?

Java?

Scheduler?

Passo 3 — Para onde vai o resultado?

Arquivo?

Tabela?

Fila?

API?

Relatório?

Passo 4 — Qual é a unidade de recuperação?

Se falhar aqui:

ROLLBACK?

Restart?

Checkpoint?

Passo 5 — Quem depende disso?

Outro job?

CICS transaction?

Fechamento contábil?

PIX?

Cartão?

Passo 6 — Qual regra empresarial está escondida no código?

Isso transforma você de:

digitador COBOL

em:

engenheiro de sistemas.

🕵️ CAPÍTULO 21 — Dica Bellacosa: nunca ataque código antigo antes de interrogá-lo

Você encontra:

IF WS-CODIGO NOT = ZERO
    NEXT SENTENCE
ELSE
    PERFORM 9000-TRATA
END-IF.

Sua reação:

“Vou modernizar isso.”

Devagar, jovem Padawan.

Primeiro investigue:

Quem chama?
Existem testes?
O ponto final altera escopo?
Há GO TO envolvido?
Qual compiler option?
Existe copybook?
O programa é chamado dinamicamente?
Existem registros históricos dependentes?
Qual retorno esperado?
Existe processamento de exceção downstream?

Em mainframe, curiosidade vale mais que arrogância.

Easter egg: procure nos fontes por comentários como:

* DO NOT REMOVE

Nenhum arqueólogo sente mais medo ao abrir uma tumba do que um COBOLzeiro lendo isso.

📈 CAPÍTULO 22 — “Mas a IBM moderna está morta?”

Não.

Essa simplificação também seria errada.

Em 2025, a IBM reportou receita anual de aproximadamente US$ 67,5 bilhões, crescimento de 6% em moeda constante e free cash flow de US$ 14,7 bilhões. Ao final do ano, a companhia informou que seu book of business acumulado relacionado a IA generativa havia ultrapassado US$ 12,5 bilhões. (IBM Newsroom)

Portanto a crítica à IBM contemporânea precisa ser sofisticada.

Não:

“A IBM não consegue inovar.”

Isso não é sustentado pelos fatos.

IBM continua investindo em:

Z;
LinuxONE;
IA;
Research;
quantum;
Red Hat;
hybrid cloud;
software;
segurança.

A pergunta mais interessante é:

Consegue transformar todas essas peças numa visão tecnológica única tão poderosa quanto System/360 representou em sua época?

Essa é outra conversa.

🧩 CAPÍTULO 23 — O quebra-cabeça IBM contemporâneo

Olhe as peças:

IBM Z
   +
LinuxONE
   +
Red Hat
   +
OpenShift
   +
watsonx
   +
Spyre
   +
Db2
   +
Research
   +
Quantum
   +
Consulting

Isso não parece uma empresa sem tecnologia.

Parece uma empresa com tecnologia demais para explicar em uma única frase.

E aí surge um desafio estratégico.

System/360 tinha uma mensagem conceitual muito forte:

uma família compatível de computadores.

Agora tente resumir a IBM moderna em oito palavras.

Hybrid Cloud and AI?

Correto.

Mas ainda abstrato.

Uma visão estratégica forte precisa fazer o engenheiro, vendedor, cliente e investidor visualizarem o mesmo futuro.

💣 CAPÍTULO 24 — O verdadeiro Doomsday Device é não escolher

No filme Dr. Strangelove, existe uma máquina do juízo final construída para impedir ataques.

Há apenas um pequeno problema.

A lógica da máquina depende de o adversário saber que ela existe.

Dr. Strangelove praticamente enlouquece:

Qual é o propósito de uma máquina do juízo final secreta?

No mundo corporativo acontece algo semelhante.

Você pode possuir:

chips extraordinários;
mainframes extraordinários;
pesquisadores extraordinários;
IA extraordinária;
software extraordinário.

Mas se ninguém entende como essas peças formam uma tese:

qual é o propósito estratégico do arsenal?

Tecnologia precisa de arquitetura.

Arquitetura precisa de estratégia.

Estratégia precisa de escolha.

Escolha precisa de liderança.

🧨 CAPÍTULO 25 — A pergunta Watsoniana

Talvez a pergunta mais brutal que um CEO possa responder seja:

Qual produto lucrativo estamos dispostos a canibalizar para criar nosso próximo negócio?

Porque inovar onde nada está ameaçado é fácil.

Difícil é dizer:

“Essa receita existe hoje, mas acreditamos que outra arquitetura será melhor amanhã.”

Isso é System/360.

Watson Jr. comprometendo bilhões antes de saber o resultado.

Nós vemos:

1964
   ↓
SUCESSO

Ele via:

1964
   ↓
?????????

Essa diferença chama-se:

hindsight bias.

🎲 CAPÍTULO 26 — Teoria dos jogos dentro da empresa

Outro conceito importante para o COBOLzeiro.

Imagine dois executivos:

Diretor A: controla produto antigo.

Diretor B: controla produto novo.

Para a IBM:

Produto novo vencedor = ótimo.

Para A:

Produto novo vencedor = talvez perca poder.

Portanto o comportamento racional individual pode divergir do comportamento ideal para a organização.

Isso é um problema clássico de incentivos.

Aplicado a software:

Empresa quer:
simplificar arquitetura.

Equipe quer:
preservar sistema que domina.

Não necessariamente por maldade.

Pessoas respondem a incentivos.

Por isso transformações tecnológicas falham frequentemente mesmo quando todos concordam teoricamente com elas.

📜 CAPÍTULO 27 — Uma lição que COBOL ensina sobre liderança

COBOL possui uma característica curiosa:

é explícito.

IF SALDO < ZERO
   PERFORM COBRA-TARIFA
END-IF

Pode ser verboso.

Mas sabemos quem decidiu o quê.

Organizações modernas às vezes fazem o contrário.

IF PROJETO-FALHAR
    RESPONSABILIDADE = NINGUEM
END-IF

😂

Quando autoridade está fragmentada demais, ninguém consegue dizer sim.

Mas todos conseguem impedir.

Chamemos isso de:

PIC X(01) VALUE 'N'.

🚨 CAPÍTULO 28 — War Room: exercício para o iniciante

Imagine que você trabalha num banco.

Existe:

PROGRAMA: CRD001
IDADE: 31 anos
LINGUAGEM: COBOL
BANCO: Db2
ONLINE: CICS
VOLUME: 12 milhões transações/dia

Diretor aparece:

“Precisamos colocar IA.”

Erro número 1:

reescrever tudo.

Erro número 2:

enviar todas as transações para um chatbot.

Erro número 3:

criar 47 microsserviços porque alguém assistiu uma palestra.

O caminho inteligente começa assim.

ETAPA 1 — Entenda o fluxo

Terminal/API
    ↓
CICS
    ↓
CRD001
    ↓
Db2

ETAPA 2 — Identifique onde IA agrega valor

Talvez:

detecção de fraude

ETAPA 3 — Preserve processamento determinístico

COBOL continua fazendo:

validação
limites
regras legais
contabilização
commit

ETAPA 4 — Acrescente inferência

TRANSAÇÃO
   ↓
MODELO
   ↓
FRAUD-SCORE

ETAPA 5 — COBOL decide

EVALUATE TRUE
   WHEN FRAUD-SCORE > 900
      PERFORM BLOQUEIA
   WHEN FRAUD-SCORE > 700
      PERFORM REVISA
   WHEN OTHER
      PERFORM APROVA
END-EVALUATE

Agora temos modernização.

Não religião tecnológica.

🔬 CAPÍTULO 29 — O programador COBOL moderno precisa conhecer mais que COBOL

Sua trilha deveria progressivamente incluir:

COBOL
 |
 +-- JCL
 |
 +-- VSAM
 |
 +-- Db2
 |
 +-- CICS
 |
 +-- RACF
 |
 +-- MQ
 |
 +-- APIs
 |
 +-- z/OS Connect
 |
 +-- Git
 |
 +-- pipelines
 |
 +-- Linux
 |
 +-- containers
 |
 +-- observabilidade
 |
 └-- AI

Não precisa dominar tudo amanhã.

Mas precisa saber que tudo isso existe.

O mainframe moderno não é uma ilha.

É um aeroporto internacional.

COBOL é uma companhia aérea gigantesca operando nele.

🥚 EASTER EGG — O programa de 1978

Imagine um fonte:

      *---------------------------------------------*
      * CUSTOMER SETTLEMENT PROCESS                 *
      * AUTHOR: A. JOHNSON                          *
      * DATE:   12/SEP/1978                         *
      *---------------------------------------------*

O senhor Johnson escreveu aquilo.

Usando terminal que hoje estaria num museu.

Provavelmente nunca viu:

smartphone;
Kubernetes;
ChatGPT;
Linux;
GitHub;
Wi-Fi;
SSD;
JSON.

Talvez tenha se aposentado em 1997.

O programa continua rodando.

Em 2026 chega um desenvolvedor recém-formado.

Abre o código.

Diz:

“Nossa, isso é muito velho.”

O programa olha silenciosamente.

Já enterrou:

sete frameworks JavaScript;
quatro arquiteturas client/server;
três gerações de middleware;
SOAP;
CORBA;
Silverlight;
Flash;
dois datacenters;
onze diretores de tecnologia.

Então volta a processar arquivo.

MAXCC=0000

🧠 CAPÍTULO 30 — THINK

A palavra THINK possui raízes profundas na cultura histórica da IBM. A própria história corporativa relaciona Watson e posteriormente Watson Jr. a essa filosofia de pensar como instrumento prático para melhorar o negócio e enfrentar problemas grandes. (IBM)

O importante é entender o significado.

THINK não é:

pense eternamente.

THINK é:

questione pressupostos.

Para você, programador COBOL:

Por que esse arquivo existe?

Por que este job roda às 02:00?

Por que DISP=OLD?

Por que temos REDEFINES aqui?

Por que existe esta regra desde 1994?

Por que movemos estes dados para fora do mainframe?

Por que esta aplicação precisa ser reescrita?

Qual problema estamos realmente tentando resolver?

Essas perguntas valem ouro.

☢️ CAPÍTULO 31 — A síndrome do “vamos modernizar tudo”

Entre na War Room.

General Turgidson aponta para um mapa.

— Temos 14 milhões de linhas COBOL.

Executivo:

— Precisamos migrar tudo.

Bellacosa:

— Por quê?

Silêncio.

Executivo:

— Porque é legado.

— Está falhando?

— Não.

— Está caro?

— Não calculamos.

— Clientes reclamam?

— Não.

— Existe limitação tecnológica?

— Não sabemos.

— Então qual problema estamos resolvendo?

Outro silêncio.

Em algum canto Dr. Strangelove tenta impedir o próprio braço de fazer uma saudação indevida.

😂

Modernização deveria começar com um problema.

Nunca com um slogan.

🛠 CAPÍTULO 32 — Checklist mental Bellacosa para qualquer modernização

Antes de reescrever um COBOL, responda:

1. O sistema funciona?

2. Qual é o custo real?

3. Qual risco reduziremos?

4. Qual capacidade nova precisamos?

5. Podemos adicionar essa capacidade sem substituir tudo?

6. Onde estão as regras empresariais?

7. Existem testes suficientes?

8. Quem conhece o comportamento atual?

9. Qual estratégia de rollback?

10. Como provaremos equivalência funcional?

Se ninguém consegue responder, não existe projeto de modernização.

Existe uma aventura.

E aventura em produção costuma terminar no telefone.

💡 CAPÍTULO 33 — Cinco lições para levar para sua carreira COBOL

1. Arquitetura vive mais que produto

System/360 nasceu em 1964.

Suas ideias arquitetônicas deixaram descendentes que atravessaram décadas.

Aprenda arquitetura.

2. Compatibilidade possui valor econômico

Código antigo não sobrevive apenas porque empresas têm preguiça.

Sobrevive porque migração custa dinheiro e cria risco.

3. Estabilidade é uma feature

Dev jovem:

“Mas não mudou em quinze anos!”

Operações:

“Exatamente.”

4. Modernização não significa substituição

Talvez seu programa COBOL possa consumir API, produzir eventos, integrar IA ou participar de uma arquitetura híbrida.

5. Pergunte “por quê?” antes de perguntar “como?”

Essa é talvez a habilidade mais Watsoniana de todas.

🚀 CAPÍTULO 34 — O possível futuro

Imagine:

                     CLIENTES
                        |
                       API
                        |
                 z/OS Connect
                        |
              +---------+---------+
              |                   |
            CICS              OpenShift
              |                   |
            COBOL               Linux
              |                   |
             Db2               watsonx
              |                   |
              +---------+---------+
                        |
                     AI MODEL
                        |
                     SPYRE

Nenhuma dessas tecnologias precisa necessariamente destruir as outras.

Esse talvez seja o grande erro da discussão “legado versus moderno”.

O futuro provavelmente será:

legado + moderno + aquilo que ainda nem recebeu buzzword.

🎬 EPÍLOGO — Dr. Strangelove encontra o JCL

03:42 da madrugada.

War Room.

Um telão mostra:

JOB SETTLE01
STATUS: RUNNING

General pergunta:

— Esse é o sistema novo de inteligência artificial?

Operador responde:

— Não, senhor.

— Blockchain?

— Não.

— Kubernetes?

— Não.

— Quantum?

— Não.

— Agentic AI?

— Não.

— Então o que é?

Operador aproxima os óculos.

— COBOL.

Silêncio.

STEP010  RC=0000
STEP020  RC=0000
STEP030  RC=0000

Dr. Strangelove olha fascinado.

— Mein Gott... há quanto tempo funciona?

— Desde 1978.

— E ninguém substituiu?

— Tentaram.

— Quantas vezes?

— O senhor quer a resposta técnica ou a resposta que cabe no PowerPoint?

Thomas Watson Jr. apostou bilhões para construir uma arquitetura que poderia tornar produtos existentes obsoletos. System/360 tornou-se um dos grandes pontos de inflexão da história da computação. (IBM)

Décadas depois, a IBM continua possuindo engenheiros, pesquisa, hardware, software, Linux, mainframe, IA e tecnologias capazes de produzir novas combinações extraordinárias.

A discussão nunca deveria ser simplesmente:

“IBM antiga boa, IBM moderna ruim.”

Isso seria nostalgia barata.

A pergunta realmente valiosa é:

Uma organização gigantesca ainda consegue concentrar pessoas, dinheiro, autoridade e reputação em uma única aposta antes de possuir garantia de que ela funcionará?

Essa pergunta vale para IBM.

Vale para Microsoft.

Vale para Google.

Vale para bancos.

Vale para qualquer empresa.

E, curiosamente, vale para sua carreira.

Você pode passar os próximos vinte anos apenas mantendo programas.

Ou pode aprender por que eles existem.

Pode decorar COBOL.

Ou entender o sistema.

Pode tratar mainframe como tecnologia de 1964.

Ou perceber que aquela plataforma sobreviveu justamente porque continuou incorporando coisas que não existiam quando nasceu.

Talvez esse seja o verdadeiro legado dos Watson.

Não uma máquina.

Não um logo.

Não um slogan.

Mas a ideia quase irresponsável de que uma empresa de tecnologia precisa, ocasionalmente, estar preparada para construir aquilo que ameaça aquilo que ela já construiu.

Na parede da nossa War Room imaginária, portanto, colocaremos uma placa.

Não:

INNOVATE.

Muito genérico.

Não:

TRANSFORMATION.

RH já reservou essa palavra.

Não:

AI-POWERED HYBRID CLOUD DIGITAL-FIRST COGNITIVE ENTERPRISE.

A placa seria muito pequena.

Coloque apenas:

THINK.

E embaixo, numa fonte menor, reservado exclusivamente ao programador COBOL que chegou até aqui:

//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*

Porque podemos filosofar sobre liderança, inovação, Watson, IA e o futuro da computação durante duas horas.

Mas quando produção cair às 03:17...

eu quero o dump.

https://eljefemidnightlunch.blogspot.com/2026/08/a-causa-de-r-300-milhoes-e-o-if-do.html

https://eljefemidnightlunch.blogspot.com/2026/08/o-golpe-de-mestre-algoritmico-teoria.html

Translate

sexta-feira, 3 de julho de 2026