 |
| Bellacosa Mainframe e o gerente de informatica |
☕ Um Café no Bellacosa Mainframe
👻 CRY ANDRICH E A DUNGEON DO EXECUTIVO DE INFORMÁTICA — QUANDO O GERENTE DE CPD DESCOBRIU QUE TECNOLOGIA NÃO ERA O NEGÓCIO
CPD, CIO, liderança, estratégia, Peopleware, sucessão, segurança, clientes, mainframe, COBOL, transformação digital, IA — e o dia em que Cry descobriu que subir na hierarquia podia ser muito mais perigoso do que entrar em uma dungeon.
🎬 PRÓLOGO — CRY SÓ QUERIA SE APOSENTAR
Imagine a cena.
Cry Andrich entra silenciosamente na sala da presidência.
Na mesa estão espalhados relatórios, gráficos, projetos, contratos, diagramas de arquitetura e uma pilha de solicitações marcadas como:
URGENTE.
O presidente olha para ele.
— Cry, precisamos conversar sobre o futuro da informática.
Cry imediatamente percebe o perigo.
Não era um dragão.
Não era uma dungeon nível 10.
Não era uma relíquia amaldiçoada.
Era pior.
Era uma reunião executiva.
Cry respira fundo.
Talvez finalmente pudesse dizer:
— Gostaria de me aposentar.
Mas o presidente continua:
— Decidimos elevar a informática no organograma. A partir de agora você responderá diretamente à presidência.
Cry empalidece.
— Isso significa mais responsabilidade?
— Muito mais.
— Mais reuniões?
— Certamente.
— Orçamento?
— Bilionário.
— Segurança?
— Também.
— Pessoas?
— Centenas.
— Estratégia?
— Naturalmente.
Cry olha para a porta.
Talvez enfrentar monstros fosse realmente mais fácil.
Bem-vindo, jovem padawan do COBOL.
Hoje nossa dungeon não será um programa com SOC7, um JCL ERROR, um AEY9 no CICS ou um SQLCODE -911.
Vamos investigar uma criatura muito mais complicada:
o executivo de informática.
E descobrir por que, décadas atrás, especialistas já anunciavam:
“O atual gerente de informática vai desaparecer lentamente.”
O mais curioso?
Eles estavam parcialmente certos.
O gerente desapareceu.
Mas aquilo em que ele se transformou ficou muito mais poderoso.
E muito mais perigoso.
🏰 CAPÍTULO 1 — QUANDO EXISTIA O REINO DO CPD
Para entender essa história precisamos voltar algumas décadas.
Antes de cloud.
Antes de Internet comercial.
Antes de smartphones.
Antes de Kubernetes.
Antes de Java.
Antes de Python.
Antes de alguém entrar numa reunião e dizer:
“Vamos colocar inteligência artificial nisso.”
Grandes empresas possuíam estruturas conhecidas como:
CPD — Centro de Processamento de Dados.
O computador era literalmente um recurso central.
Imagine uma instalação empresarial contendo:
Computação era cara.
Muito cara.
Consequentemente, precisava ser controlada.
O CPD tornava-se quase um castelo tecnológico dentro da empresa.
De um lado estavam os usuários.
Do outro:
+---------------------------+
| CPD |
| |
| MAINFRAME |
| OPERADORES |
| PROGRAMADORES |
| ANALISTAS |
| FITAS / DISCOS |
| PROGRAMAS |
+---------------------------+
E governando aquele pequeno reino:
o gerente de informática.
Seu trabalho frequentemente envolvia administrar máquinas, pessoas, orçamento, capacidade de processamento e projetos.
Isso fazia sentido.
Mas havia uma armadilha.
O computador estava começando a deixar de ser apenas uma ferramenta administrativa.
Ele começava a se tornar parte do próprio negócio.
⚠️ CAPÍTULO 2 — O GERENTE ESTÁ EM PERIGO
Em determinado painel sobre o futuro da informática surgiu uma provocação extraordinária:
O executivo de informática está em perigo.
Não porque os computadores desapareceriam.
Exatamente o contrário.
Os computadores estavam ficando melhores.
Hardware evoluía.
Software evoluía.
Bancos de dados evoluíam.
Telecomunicações evoluíam.
Só que alguns executivos responsáveis por informática continuavam pensando como administradores de máquinas.
Esse descompasso produzia uma situação curiosa:
TECNOLOGIA ████████████████████
GESTÃO █████████
A capacidade tecnológica avançava mais rapidamente do que a capacidade organizacional de utilizá-la.
Isso continua acontecendo.
Em 2026 uma empresa pode comprar:
cloud;
containers;
GPUs;
LLMs;
agentes de IA;
observabilidade;
DevOps;
APIs;
plataformas de dados.
E ainda assim não conseguir responder:
Que problema estamos tentando resolver?
Cry olha para os executivos.
— Então compraram a espada lendária antes de descobrir qual monstro precisavam matar?
Exatamente, Cry.
Exatamente.
🇯🇵 CAPÍTULO 3 — O JAPÃO E O MONSTRO DA GESTÃO
Na discussão original apareceu uma observação provocativa:
O Japão teria chegado ao nível de desenvolvimento industrial alcançado não simplesmente pela evolução tecnológica, mas pela evolução gerencial.
Precisamos tomar cuidado para não transformar isso numa simplificação histórica.
O Japão obviamente teve enorme desenvolvimento tecnológico.
Mas existe uma ideia importante escondida nessa afirmação.
Tecnologia sozinha não produz excelência operacional.
Durante o desenvolvimento industrial japonês do pós-guerra ganharam enorme importância ideias relacionadas a:
Nomes como W. Edwards Deming e Joseph Juran aparecem frequentemente nessa história.
A lição é simples:
máquinas melhores não compensam automaticamente processos ruins.
No mainframe isso é cristalino.
Você pode possuir um IBM Z extremamente poderoso.
Mas se executar um processo empresarial absurdo nele, terá apenas:
um processo absurdo executado extremamente rápido.
Easter egg COBOL:
IF PROCESSO-RUIM = 'S'
PERFORM PROCESSAR-BESTEIRA
THRU PROCESSAR-BESTEIRA-EXIT
END-IF.
Upgrade de CPU não resolve requisito ruim.
👑 CAPÍTULO 4 — CRY É PROMOVIDO CONTRA A PRÓPRIA VONTADE
Uma das recomendações do painel era:
elevar o nível hierárquico da informática, preferencialmente com subordinação direta à presidência.
Isso parece apenas mudança no organograma.
Não é.
Observe:
PRESIDENTE
|
DIRETOR ADMINISTRATIVO
|
GERENTE FINANCEIRO
|
GERENTE DE INFORMÁTICA
Nesse cenário, informática pode ser percebida predominantemente como uma função administrativa.
Agora alteramos:
PRESIDENTE
|
+------------+------------+
| | |
CFO CIO COO
A conversa muda.
Tecnologia passa a participar das discussões sobre:
estratégia;
produtos;
expansão;
eficiência;
segurança;
riscos;
clientes;
investimentos.
Nascia progressivamente aquilo que hoje associamos ao:
CIO — Chief Information Officer.
Mas existe uma pegadinha.
Mover o gerente para o andar da presidência não transforma automaticamente alguém em executivo estratégico.
Se ele continuar dizendo apenas:
“CPU está em 72%.”
a presidência pode responder:
“E daí?”
O executivo precisa traduzir tecnologia.
🧙 CAPÍTULO 5 — A MAGIA DA TRADUÇÃO EXECUTIVA
Aqui está uma habilidade importantíssima.
O técnico diz:
CPU.
O executivo precisa compreender:
capacidade.
O técnico diz:
indisponibilidade.
O executivo traduz:
perda financeira e impacto sobre clientes.
O técnico diz:
vulnerabilidade.
Executivamente:
risco.
O técnico diz:
latência.
Negócio:
experiência do cliente e capacidade transacional.
Podemos montar nossa pequena copybook:
CPU → CAPACIDADE
INCIDENTE → RISCO
DOWNTIME → PERDA
LATÊNCIA → EXPERIÊNCIA
SEGURANÇA → CONTINUIDADE
DADOS → DECISÃO
AUTOMAÇÃO → PRODUTIVIDADE
MODERNIZAÇÃO → CAPACIDADE FUTURA
Isso não significa esconder detalhes técnicos.
Significa saber conversar em diferentes níveis.
Cry pode conversar com aventureiros sobre espadas.
Mas diante do rei precisa explicar:
quantas dungeons podem ser conquistadas, quanto custará e quantos aventureiros provavelmente voltarão vivos.
É outra linguagem.
⚔️ CAPÍTULO 6 — O MELHOR PROGRAMADOR NÃO É NECESSARIAMENTE O MELHOR GERENTE
Outra recomendação do painel era melhorar os critérios de promoção.
Essa questão continua atualíssima.
Imagine:
PROGRAMADOR
↓
PROGRAMADOR SÊNIOR
↓
ANALISTA
↓
COORDENADOR
↓
GERENTE
Parece natural.
Mas existe um problema.
Um excelente programador COBOL talvez domine:
COBOL;
JCL;
CICS;
Db2;
VSAM;
MQ;
RACF;
dumps;
performance.
Isso não significa automaticamente que ele domine:
Gerenciar pessoas é outra profissão.
Quando promovemos automaticamente o melhor técnico, podemos produzir um fenômeno perverso:
perdemos um excelente programador e ganhamos um gerente medíocre.
Foi justamente para evitar isso que muitas organizações desenvolveram carreiras técnicas paralelas.
O profissional pode tornar-se:
Senior → Staff → Principal → Distinguished
sem necessariamente precisar gerenciar pessoas.
👻 CAPÍTULO 7 — CRY PRECISA DE UM SEGUNDO HOMEM
O painel destacou outra coisa surpreendentemente moderna:
É necessário preparar o segundo homem para ocupar o cargo.
Hoje chamaríamos isso de:
planejamento sucessório.
E existe uma conexão deliciosa com engenharia de software:
Bus Factor.
Imagine um sistema crítico.
Existe apenas uma pessoa capaz de explicar determinado processo.
— Quem conhece o programa?
— O João.
— Quem sabe por que existe aquela regra?
— João.
— Quem sabe recuperar o batch?
— João.
— Documentação?
— Pergunta para o João.
— Quem criou aquilo?
— João, em 1989.
Agora fazemos a pergunta proibida:
E se João não estiver disponível?
Silêncio.
No monitor:
IGD99999I
JOAO NOT FOUND
Temos um SOC7 organizacional.
Conhecimento concentrado é risco.
O mesmo vale para liderança.
Um bom executivo precisa preparar pessoas capazes de assumir responsabilidades.
Cry provavelmente tentaria preparar imediatamente cinco sucessores.
Não necessariamente por boas práticas de governança.
Talvez porque finalmente alguém pudesse deixá-lo se aposentar.
Mas funcionaria.
🎯 CAPÍTULO 8 — PRIMEIRO O PROBLEMA, DEPOIS A TECNOLOGIA
Uma recomendação essencial era:
adequar os recursos de informática às prioridades da empresa.
Isso muda completamente a ordem da conversa.
Forma perigosa:
Temos Kubernetes. Onde podemos usá-lo?
Forma correta:
Qual problema precisamos resolver?
Depois perguntamos qual tecnologia ajuda.
Imagine um banco executando:
COBOL
CICS
Db2
MQ
IBM Z
Alguém aparece:
— Precisamos migrar tudo para microsserviços!
Cry pergunta:
— Por quê?
— Porque microsserviços são modernos.
Cry começa a procurar a saída da sala.
Modernidade não é requisito funcional.
Talvez o problema verdadeiro seja:
parceiros precisam acessar determinadas funções do CICS através de APIs.
Excelente.
Podemos então investigar soluções apropriadas.
Talvez não seja necessário reescrever milhões de linhas de COBOL.
Essa é maturidade tecnológica:
não começar pela ferramenta.
❤️ CAPÍTULO 9 — O USUÁRIO NÃO É O INIMIGO
Outra recomendação dizia:
Encarar os usuários como clientes — “Clientes em primeiro lugar”.
Isso representa uma mudança cultural enorme.
O velho estereótipo do CPD era:
Usuário:
— Preciso de uma alteração.
Informática:
— Abra uma solicitação.
Usuário:
— É urgente.
Informática:
— Tudo é urgente.
Mas tratar o usuário como cliente não significa fazer tudo o que ele pede.
Significa compreender por que ele está pedindo.
Usuário:
“Quero mais um campo nessa tela.”
Analista iniciante:
“OK.”
Analista experiente:
“Para que você precisa dele?”
Talvez descubramos que o problema pode ser resolvido eliminando duas telas.
Essa investigação está na essência de:
análise de requisitos;
UX;
product management;
design thinking;
service management.
O programador deixa de perguntar apenas:
Como implementar?
E passa a perguntar:
Por que implementar?
Essa pequena palavra — por quê — pode economizar milhões.
🔐 CAPÍTULO 10 — PROTEJAM A BIBLIOTECA!
Outra recomendação do painel:
manter cuidados especiais na segurança da biblioteca e dos programas.
Para o jovem programador de 2026 isso pode parecer curioso.
Biblioteca?
Estamos falando de livros?
Não.
No universo mainframe, bibliotecas são fundamentais.
Você encontrará:
PDS;
PDSE;
source libraries;
copybooks;
JCL;
procedures;
load libraries.
Imagine:
SOURCE
↓
COMPILE
↓
LINK-EDIT
↓
LOAD MODULE
↓
PRODUCTION
Agora responda:
Quem pode modificar cada etapa?
Essa pergunta é gigantesca.
Se alguém consegue substituir clandestinamente um programa antes da produção, temos risco de fraude, sabotagem ou comprometimento.
Aquela antiga preocupação conecta-se diretamente a conceitos modernos:
controle de acesso;
RACF;
segregação de funções;
change management;
auditoria;
code review;
CI/CD;
supply-chain security;
rastreabilidade.
A tecnologia mudou.
O problema fundamental permaneceu:
Como garantir que aquilo executado em produção seja realmente aquilo que foi autorizado?
🧠 CAPÍTULO 11 — O EXECUTIVO DO FUTURO
O painel descrevia quatro funções para o futuro gerente:
atuar corporativamente;
comandar definição de políticas;
funcionar como agente da evolução tecnológica;
gerenciar equipes multidisciplinares.
Perceba a mudança.
Antes:
GERENTE
↓
COMPUTADOR
Depois:
TECNOLOGIA
|
PESSOAS ← EXECUTIVO → PROCESSOS
|
ESTRATÉGIA
|
CLIENTE
Estamos diante de um sistema sociotécnico.
Tecnologia não existe isoladamente.
Existe dentro de organizações compostas por pessoas, interesses, incentivos, regras, processos e cultura.
📣 CAPÍTULO 12 — CRY PRECISA VENDER A IDEIA
O perfil esperado também incluía:
capacidade de vender inovações.
Não estamos falando necessariamente de vendas comerciais.
Estamos falando de convencer.
Imagine o CIO:
— Precisamos investir R$ 20 milhões modernizando determinado ambiente.
CEO:
— Está funcionando?
CIO:
— Sim.
CEO:
— Então por que gastar R$ 20 milhões?
Fim da apresentação.
O executivo precisa transformar tecnologia em argumento empresarial.
Por exemplo:
“O ambiente funciona, mas quatro especialistas concentram grande parte do conhecimento crítico, determinadas dependências estão limitando novas integrações e nosso tempo médio para implementar mudanças aumentou.”
Agora existe uma discussão.
O executivo precisa conversar usando quatro palavras mágicas:
CUSTO
RISCO
OPORTUNIDADE
RESULTADO
Tecnologia pela tecnologia raramente convence uma diretoria.
🧑🤝🧑 CAPÍTULO 13 — A PARTY MULTIDISCIPLINAR
Nageki no Bourei wa Intai shitai oferece uma ótima metáfora.
Uma party não precisa de seis pessoas com exatamente a mesma habilidade.
Precisa de capacidades complementares.
Na tecnologia moderna temos algo semelhante:
COBOL DEVELOPER
DBA
SECURITY
NETWORK
SRE
DEVOPS
CLOUD ENGINEER
DATA ENGINEER
UX
PRODUCT MANAGER
BUSINESS ANALYST
AI ENGINEER
Nenhum executivo consegue ser o maior especialista em tudo isso.
Sua responsabilidade passa a ser orquestrar conhecimento.
É como um maestro.
Ele não precisa tocar todos os instrumentos durante o concerto.
Precisa compreender como todos entram na mesma música.
📚 CAPÍTULO 14 — PEOPLEWARE: O MONSTRO ERA HUMANO
A bibliografia recomendava Peopleware, de Tom DeMarco e Timothy Lister.
Isso é revelador.
Existe uma tentação histórica na informática:
procurar produtividade principalmente em ferramentas.
Novo computador.
Nova linguagem.
Novo compilador.
Novo framework.
Nova metodologia.
Nova IA.
Mas software é trabalho intelectual.
Interrupções importam.
Ambiente importa.
Confiança importa.
Conhecimento importa.
Comunicação importa.
Cultura importa.
Liderança importa.
Você pode fornecer ao programador COBOL o melhor ambiente do planeta.
Se ele for interrompido a cada oito minutos, talvez sua produtividade desabe.
Computador executa instruções.
Ser humano precisa reconstruir contexto mental.
É uma diferença brutal.
📕 CAPÍTULO 15 — BRAVERMAN ENTRA NA DUNGEON
Outra recomendação bibliográfica era Harry Braverman e sua discussão sobre trabalho e capital monopolista.
Aqui a conversa fica ainda maior.
Tecnologia não muda somente máquinas.
Ela pode mudar:
E então chegamos diretamente à inteligência artificial.
Pergunte:
A IA substituirá trabalho?
Mas também pergunte:
A IA redistribuirá conhecimento?
Quem controlará os modelos?
Quem verificará resultados?
O trabalhador ficará mais poderoso ou mais dependente?
Quem será responsável pelo erro?
Conhecimento continuará nas pessoas ou será progressivamente incorporado aos sistemas?
Percebeu?
Discussões aparentemente novas possuem raízes muito antigas.
🤖 CAPÍTULO 16 — ENTÃO CHEGOU A IA
Agora transportamos nosso painel para 2026.
Cry entra novamente na reunião.
Executivo:
— Precisamos de inteligência artificial.
Cry:
— Para quê?
Executivo:
— Porque todo mundo está usando.
Cry olha novamente para a porta.
Estamos repetindo a dungeon.
Antes:
MAINFRAME
CLIENTE-SERVIDOR
ERP
INTERNET
CLOUD
BLOCKCHAIN
Agora:
GENERATIVE AI
LLM
RAG
AGENTS
A pergunta correta continua:
Qual problema estamos tentando resolver?
Antes de colocar um agente de IA em produção, precisamos discutir:
objetivo;
dados;
permissões;
segurança;
validação;
auditoria;
responsabilidade;
métricas;
intervenção humana.
IA não elimina gestão.
Pode tornar boa gestão ainda mais necessária.
🏯 CAPÍTULO 17 — O GERENTE REALMENTE DESAPARECEU?
A previsão dizia:
“O atual gerente de informática vai desaparecer lentamente.”
Curiosamente, aconteceu algo parecido.
Não desapareceu a liderança tecnológica.
Ela se multiplicou.
Surgiram funções como:
CIO
CTO
CISO
CHIEF DATA OFFICER
CHIEF DIGITAL OFFICER
VP ENGINEERING
A antiga função explodiu em diversas especialidades.
O gerente responsável por “computadores” transformou-se em executivos responsáveis por diferentes dimensões da tecnologia empresarial.
Portanto, a previsão continha um paradoxo maravilhoso:
o gerente de informática morreria justamente porque informática se tornaria importante demais.
🧙 CAPÍTULO 18 — A ÚLTIMA LIÇÃO DE CRY
Para o programador COBOL iniciante, existe uma mensagem importantíssima aqui.
No começo você aprenderá:
IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION
Depois:
JCL
Depois:
VSAM
Db2
CICS
MQ
RACF
Mas continue subindo.
Pergunte:
Por que esse programa existe?
↓
Qual processo ele suporta?
↓
Quem utiliza esse processo?
↓
Que regra empresarial existe aqui?
↓
Que risco esse programa controla?
↓
Quanto dinheiro passa por ele?
↓
O que acontece se ele parar?
↓
Por que a empresa precisa dele?
Nesse momento você deixa de conhecer apenas código.
Começa a conhecer sistemas.
Depois deixa de conhecer apenas sistemas.
Começa a conhecer negócios.
Esse é um salto extraordinário na carreira.
👻 EPÍLOGO — CRY FINALMENTE CONSEGUIU SE APOSENTAR?
Naturalmente não.
Cry treinou um sucessor.
Documentou processos.
Criou políticas.
Protegeu bibliotecas.
Montou equipes multidisciplinares.
Alinhou tecnologia à estratégia.
Passou a tratar usuários como clientes.
Criou planejamento sucessório.
Explicou riscos para a presidência.
Implementou governança.
Modernizou aplicações.
Integrações foram criadas.
APIs chegaram ao CICS.
COBOL continuou processando transações.
IA começou a ajudar na análise de sistemas legados.
Finalmente Cry apareceu diante do presidente.
— Agora existe uma organização capaz de funcionar sem mim. Posso me aposentar?
O presidente sorriu.
— Excelente trabalho, Cry.
Cry sorriu também.
— Então...
— Por isso decidimos promovê-lo.
Silêncio.
Ao longe, um operador percebeu algo estranho no console.
18:03:17 EXECUTIVE ABEND DETECTED
18:03:17 REASON: PROMOTION
18:03:17 ACTION: CONTACT CRY ANDRICH
Sim.
03:17 estava lá.
Quem conhece, conhece. ☕
E talvez essa seja a maior ironia daquela antiga previsão sobre o gerente de informática.
O computador ficou menor.
Depois ficou distribuído.
Depois virtual.
Depois foi para cloud.
Depois ganhou APIs.
Depois começou a conversar conosco.
Agora existem modelos generativos e agentes capazes de executar tarefas.
Mas a pergunta fundamental continua exatamente onde estava:
O que o cliente realmente precisa?
Um IBM Z pode executar bilhões de transações.
COBOL pode sobreviver por décadas.
Cloud pode entregar capacidade em minutos.
Uma IA pode analisar milhões de informações.
Mas nenhuma tecnologia transforma automaticamente capacidade técnica em propósito empresarial.
É por isso que o executivo de informática descrito como estando “em perigo” não precisava simplesmente aprender mais tecnologia.
Precisava compreender algo muito maior:
pessoas, clientes, processos, estratégia e mudança.
O programador COBOL que compreender essa lição cedo terá uma enorme vantagem.
Porque um dia alguém poderá perguntar:
— Você sabe COBOL?
Você responderá:
— Sim.
— CICS?
— Sim.
— Db2?
— Sim.
— Mainframe?
— Sim.
Então virá a pergunta realmente importante:
“Você entende por que esse sistema existe?”
Nesse momento não procure a resposta no manual do COBOL.
Não estará lá.
Olhe para o negócio.
Olhe para as pessoas.
Olhe para o cliente.
E lembre-se da primeira regra da dungeon:
0317-REGRA-DE-OURO.
IF TECNOLOGIA > NECESSIDADE-DO-CLIENTE
DISPLAY
'VOCE PROVAVELMENTE ESTA RESOLVENDO'
' O PROBLEMA ERRADO'
ELSE
PERFORM ENTENDER-O-PROBLEMA
PERFORM ESCOLHER-A-TECNOLOGIA
PERFORM MEDIR-O-RESULTADO
END-IF.
Porque linguagens mudam.
Máquinas mudam.
Cargos mudam.
Buzzwords mudam.
Até o gerente de informática mudou de nome.
Mas compreender qual problema precisa ser resolvido, para quem, por quê e com quais consequências continua sendo uma das habilidades mais valiosas da computação.
READY
WHAT DOES THE CLIENT ACTUALLY NEED?
_
