 |
| Bellacosa Mainframe e os faotres criticos de sucesso em it |
☕ Um Café no Bellacosa Mainframe
👑 LLOYD DE SALOUM E A DUNGEON DOS FATORES CRÍTICOS DE SUCESSO
Quando o programador COBOL descobriu que MAXCC=0000 não significa que o projeto deu certo
Patrocínio, Analistas de Negócios, talentos, usuários, padrões, segurança, especialistas, pilotos, catálogo de aplicações, prototipação, simplicidade, governança, IA — e o dia em que Lloyd descobriu que administrar sistemas de informação era muito mais complicado do que parecer incompetente.
🎬 PRÓLOGO — LLOYD RECEBE UMA MISSÃO
Imagine que Lloyd de Saloum recebeu uma missão aparentemente simples.
O Reino precisava de um novo sistema de informação.
O rei explicou:
— Lloyd, precisamos modernizar o sistema.
Lloyd olhou para o programador COBOL ao seu lado.
— Quanto tempo?
O jovem abriu o Enterprise Developer, respirou fundo e respondeu:
— Depende. Quantos programas?
Lloyd sorriu.
— Você já começou errado.
— Como assim?
— Eu não perguntei quantos programas existem. Primeiro precisamos descobrir qual problema estamos tentando resolver.
Bem-vindo à dungeon.
Porque uma das primeiras lições que um programador precisa aprender é que software e sistema de informação não são exatamente a mesma coisa.
Você pode escrever um programa COBOL perfeito.
Pode compilar sem warnings.
Pode executar:
MAXCC=0000Pode consumir pouca CPU.
Pode possuir SQL extremamente otimizado.
Pode responder em 50 milissegundos no CICS.
Pode sobreviver a milhares de transações por segundo.
E ainda assim ser um completo fracasso para a empresa.
Como?
É isso que Lloyd vai ensinar.
🏰 CAPÍTULO 1 — SOFTWARE NÃO É O REINO
Quando começamos a programar, temos tendência a enxergar o sistema pelo código.
Para um iniciante COBOL:
IDENTIFICATION DIVISION.
PROGRAM-ID. PEDIDO01.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-CLIENTE.
05 WS-CODIGO PIC 9(08).
05 WS-NOME PIC X(40).
PROCEDURE DIVISION.
PERFORM PROCESSAR-PEDIDO
STOP RUN.Isso parece ser o sistema.
Não é.
É apenas uma pequena parte dele.
Um Sistema de Informação envolve:
pessoas;
processos;
dados;
aplicações;
infraestrutura;
regras;
controles;
interfaces;
conhecimento;
objetivos organizacionais.
O COBOL é uma engrenagem dentro dessa máquina.
Imagine um sistema de cartões.
Ele pode possuir COBOL, CICS, Db2, VSAM, MQ e JCL.
Mas também existem operadores, atendentes, analistas, equipes antifraude, clientes, fornecedores, bandeiras, regras regulatórias, processos de conciliação e dezenas de sistemas externos.
Portanto:
SISTEMA DE INFORMAÇÃO
PESSOAS
+
PROCESSOS
+
DADOS
+
TECNOLOGIA
+
CONTROLES
+
OBJETIVOSEssa visão muda tudo.
👑 CAPÍTULO 2 — O PRIMEIRO MONSTRO: NÃO EXISTE PATROCINADOR
Lloyd chega à primeira sala da dungeon.
Na porta existe uma placa:
PROJETO ESTRATÉGICO DE MODERNIZAÇÃO
Dentro da sala existem 47 pessoas.
Todos discutindo.
Financeiro:
— Não temos orçamento.
Operações:
— Não podemos parar.
Desenvolvimento:
— Precisamos de seis meses.
Negócio:
— Queremos em dois.
Segurança:
— Essa arquitetura não será aprovada.
Usuário:
— Ninguém perguntou nada para nós.
Lloyd olha para o programador.
— Quem manda nesse projeto?
Silêncio.
Encontramos o primeiro problema.
O patrocinador
Todo projeto importante precisa de alguém com autoridade suficiente para defendê-lo dentro da organização.
É o sponsor, ou patrocinador.
Ele não é apenas a pessoa que assinou o orçamento.
Um bom patrocinador ajuda a:
estabelecer prioridades;
resolver conflitos;
conseguir recursos;
defender o projeto;
cobrar decisões;
eliminar obstáculos;
alinhar áreas diferentes.
Imagine:
PATROCINADOR
|
+----------+----------+
| |
NEGÓCIO TI
| |
USUÁRIOS DESENVOLVIMENTO
| |
+--------PROJETO------+Sem patrocinador, cada departamento pode tentar otimizar seus próprios interesses.
O projeto fica parecido com um job esperando recursos indefinidamente.
JOB STATUS: WAITINGPatrocinador de PowerPoint
Existe ainda uma criatura particularmente perigosa.
O sponsor nominal.
No PowerPoint:
Executive Sponsor: Diretor Fulano
Na vida real:
Fulano nunca comparece.
Não toma decisões.
Não resolve conflitos.
Não conhece os objetivos.
Nesse caso existe um nome preenchendo uma célula da planilha, mas não existe verdadeiro patrocínio.
🧙 CAPÍTULO 3 — O ANALISTA QUE CONHECIA O SEGREDO DO COPYBOOK
Na segunda sala Lloyd encontra um programa antigo.
01 CLIENTE-RECORD.
05 CLIENTE-ID PIC 9(08).
05 CLIENTE-TIPO PIC X.
05 CLIENTE-STATUS PIC X.O programador pergunta:
— Posso aumentar CLIENTE-ID?
Lloyd responde:
— Pode.
Pausa.
— Mas antes descubra quantos sistemas morrerão.
Essa é a diferença entre conhecer um programa e conhecer uma aplicação.
Um bom Analista de Negócios precisa entender por que aquela aplicação existe.
Ele conhece:
NEGÓCIO
|
PROCESSOS
|
REGRAS
|
DADOS
|
APLICAÇÃO
|
TECNOLOGIAImagine mudar:
PIC 9(08)para:
PIC 9(12)Parece simples.
Quatro bytes.
Mas esse campo talvez esteja presente em:
arquivos VSAM;
tabelas Db2;
copybooks;
COMMAREAs;
mensagens MQ;
APIs;
relatórios;
arquivos enviados para terceiros;
processos batch;
sistemas distribuídos.
A alteração de quatro posições pode atravessar cinquenta aplicações.
Esse é um dos motivos pelos quais conhecimento de negócio é tão importante quanto conhecimento técnico.
👻 CAPÍTULO 4 — O FANTASMA CHAMADO CONHECIMENTO TRIBAL
Lloyd encontra um comentário dentro de um programa:
*> ALTERADO JRS 17/08/1998
*> NAO RETIRAR ESTA REGRAPergunta:
— Por quê?
Resposta:
— Pergunta para o Carlos.
— Onde está Carlos?
— Aposentou-se em 2017.
Temos um problema.
Chamamos informalmente isso de conhecimento tribal.
Parte fundamental do funcionamento da aplicação está armazenada na cabeça de algumas pessoas.
Existe documentação, mas determinadas respostas continuam dependendo de:
"Pergunta para fulano."
Isso cria o chamado Bus Factor.
A pergunta é desconfortável:
Quantas pessoas precisam desaparecer simultaneamente para o projeto entrar em grave dificuldade?
Se a resposta for:
Uma.
Temos risco organizacional.
IF KNOWLEDGE-OF-SYSTEM = ONE-PERSON
MOVE 'CRITICAL'
TO ORGANIZATIONAL-RISK
END-IF.Esse programa provavelmente compilaria.
A empresa talvez não.
🎯 CAPÍTULO 5 — DIRECIONANDO TALENTOS PARA ALVOS
Agora Lloyd recebe dez especialistas.
A tentação administrativa é simplesmente distribuí-los pelas equipes.
Mas pessoas não são CPUs intercambiáveis.
Imagine:
ANA
COBOL ★★★★★
CICS ★★★★★
Db2 ★★★☆☆
Performance ★★★★★
APIs ★★☆☆☆E:
BRUNO
COBOL ★★★☆☆
CICS ★★★☆☆
Db2 ★★★★★
SQL ★★★★★
Performance ★★★★☆Surge um problema de consumo excessivo de CPU em transações CICS.
Quem você colocaria para investigar?
Provavelmente Ana.
Surge um SQL responsável por milhões de GETPAGEs.
Bruno parece candidato interessante.
Isso é direcionar talentos para alvos.
Não basta possuir talentos.
É necessário saber onde eles produzem maior impacto.
Empresas modernas fazem isso através de mecanismos como:
skill inventory;
competency mapping;
capability mapping;
workforce planning.
É quase um catálogo de especialistas.
⚔️ CAPÍTULO 6 — A TECNOLOGIA NÃO É A QUEST
Lloyd encontra três vendedores na próxima sala.
O primeiro grita:
— CLOUD!
O segundo:
— KUBERNETES!
O terceiro:
— INTELIGÊNCIA ARTIFICIAL!
Lloyd pergunta:
— Qual problema estamos resolvendo?
Silêncio.
Esse talvez seja um dos maiores ensinamentos de toda esta dungeon.
A sequência correta é:
OBJETIVO EMPRESARIAL
↓
PROBLEMA
↓
REQUISITOS
↓
ARQUITETURA
↓
TECNOLOGIAMas existe uma doença recorrente em TI:
TECNOLOGIA NOVA
↓
ONDE PODEMOS USAR?Blockchain passou por isso.
Cloud passou por isso.
Microsserviços passaram por isso.
Containers passaram por isso.
Agora IA generativa passa por isso.
A tecnologia pode ser extraordinária.
Mas isso não significa que seja adequada para todo problema.
Lloyd olha para o COBOLer:
— Nunca pergunte primeiro qual tecnologia devemos usar.
Pergunte:
Qual problema estamos tentando resolver?
👥 CAPÍTULO 7 — OS USUÁRIOS INVADIRAM A DUNGEON
Chegamos a outro fator crítico:
participação dos usuários.
O gerente entrega o fluxograma oficial.
PEDIDO
↓
VALIDAÇÃO
↓
APROVAÇÃO
↓
FATURAMENTOTudo lindo.
Então Lloyd decide observar Maria trabalhando.
Maria recebe o pedido.
Copia um número.
Abre Excel.
Consulta outro sistema.
Liga para João.
João confirma alguma coisa.
Maria escreve uma observação.
Depois retorna ao sistema original.
Fluxo real:
SISTEMA A
↓
EXCEL
↓
SISTEMA B
↓
TELEFONE
↓
JOÃO
↓
SISTEMA ANada disso estava na documentação.
Essa diferença entre processo formal e processo real é fundamental.
Por isso usuários precisam participar.
Eles sabem onde:
existem atalhos;
aparecem exceções;
ocorrem retrabalhos;
existem controles manuais;
a interface atrapalha;
o processo documentado não corresponde à realidade.
Um sistema construído sem usuários pode resolver magnificamente um problema que só existia no PowerPoint.
📐 CAPÍTULO 8 — PADRÕES: A BUROCRACIA QUE SALVA O PROGRAMADOR
Programadores jovens frequentemente enxergam padrões como restrições.
Lloyd coloca 500 programas COBOL sobre a mesa.
Imagine cada programador inventando:
nomes;
tratamento de erros;
mensagens;
logging;
códigos de retorno;
acesso a Db2;
estruturas JCL;
documentação.
Seria uma dungeon arqueológica.
Padrões estabelecem previsibilidade.
PADRÕES CORPORATIVOS
|
+-- Coding
+-- Naming
+-- Security
+-- Logging
+-- APIs
+-- Testing
+-- DocumentationQuando você abre um programa e reconhece sua estrutura, sua carga cognitiva diminui.
Você não precisa reaprender o universo a cada membro novo.
Esse é um dos segredos escondidos da longevidade dos sistemas mainframe.
COBOL ajuda.
Hardware confiável ajuda.
Mas sistemas permanecem décadas porque organizações também desenvolveram disciplina operacional ao redor deles.
🔐 CAPÍTULO 9 — A PORTA PROIBIDA
A velha recomendação dizia:
Criar regras rígidas para uso inadequado da informática.
Parece uma frase dos anos 1980.
Mas ela ficou ainda mais relevante.
Hoje temos:
SHADOW IT
SHADOW CLOUD
SHADOW SaaS
SHADOW AIImagine um programador pegando um programa COBOL proprietário e colando em uma IA pública:
Explique este código.
A intenção pode ser legítima.
Mas talvez existam no código:
regras proprietárias;
nomes internos;
estruturas de dados;
informações sensíveis;
comentários;
endpoints;
credenciais indevidamente armazenadas.
Portanto, governança moderna precisa combinar:
POLÍTICAS
+
EDUCAÇÃO
+
CONTROLES
+
AUDITORIA
+
FERRAMENTAS APROVADASSimplesmente dizer "proibido" não resolve tudo.
Quando existe uma necessidade legítima e nenhuma ferramenta oficial, usuários frequentemente inventam alternativas.
🧙♂️ CAPÍTULO 10 — OUÇA O MAGO
Na sala seguinte aparecem quatro especialistas.
O DBA diz:
— Esse SQL é perigoso.
Segurança:
— Essa API está excessivamente exposta.
Operações:
— Isso vai complicar suporte.
Desenvolvimento:
— Precisamos entregar.
Quem está certo?
Possivelmente todos.
Cada especialista observa uma dimensão diferente.
NEGÓCIO
|
|
SEGURANÇA ------+------ DESENVOLVIMENTO
|
|
OPERAÇÕESO papel da arquitetura e da governança é equilibrar essas forças.
Ouvir especialistas não significa entregar toda decisão ao especialista.
Significa garantir que decisões sejam tomadas conhecendo os riscos identificados por quem domina aquela área.
Existe uma regra preciosa:
Quando alguém experiente diz "isso me preocupa", não descarte a frase apenas porque ainda não existe um incidente.
Investigação custa menos que desastre.
🧪 CAPÍTULO 11 — PRIMEIRO MANDE UM SOLDADO
O reino possui 800 aplicações.
Alguém propõe migrar todas.
Lloyd responde:
— Vamos começar com três.
Isso é um piloto.
Em vez de:
IDEIA
↓
800 APLICAÇÕES
↓
DEUS NOS AJUDEfazemos:
IDEIA
↓
PILOTO
↓
MEDIÇÃO
↓
ERROS
↓
CORREÇÃO
↓
ESCALAO piloto permite validar:
performance;
segurança;
processo;
ferramentas;
treinamento;
deployment;
observabilidade;
rollback;
suporte;
custos.
Existe uma palavra maravilhosa aqui:
evidência.
Depois do piloto você deixa de discutir apenas opiniões.
Passa a possuir dados.
📚 CAPÍTULO 12 — O CATÁLOGO DAS MAGIAS DO REINO
Lloyd pergunta:
— Quantas aplicações existem?
TI responde:
— Aproximadamente 1.200.
— Aproximadamente?
— Talvez 1.500.
Encontramos outro monstro.
Uma organização deveria possuir um catálogo de aplicações.
Por exemplo:
APLICAÇÃO: CARD-AUTH
Owner: Payments
Criticidade: Alta
Tecnologia: COBOL/CICS/Db2
Interfaces: MQ/REST
Dados: PCI
RTO: 15 minutos
RPO: zero
Equipe: Cards
Dependências: 17
Última revisão: 2026Isso funciona como um mapa do reino.
Sem catálogo, perguntas aparentemente simples ficam difíceis:
Quais aplicações usam determinado banco?
Quais possuem dados pessoais?
Quem é responsável por esta interface?
Quais dependem daquele serviço?
O que será afetado se desligarmos esta aplicação?
O catálogo transforma aplicações isoladas em um portfólio administrável.
🪶 CAPÍTULO 13 — LLOYD ESCOLHE A SOLUÇÃO MAIS SIMPLES
Precisamos transferir um arquivo diariamente.
Surge uma arquitetura:
MICROSERVICES
+
KUBERNETES
+
KAFKA
+
API GATEWAY
+
EVENT MESH
+
SERVERLESSLloyd olha para aquilo.
— Quantos arquivos?
— Um.
— Quantas vezes?
— Uma por noite.
Talvez isto resolva:
JCL
↓
ARQUIVO
↓
SFTPFim.
Isso não significa que microsserviços ou Kafka sejam ruins.
Significa apenas que complexidade precisa justificar sua existência.
A solução correta é aquela suficientemente robusta para satisfazer os requisitos, não aquela que possui maior quantidade de tecnologias modernas.
No mainframe aprendemos isso cedo.
Às vezes um SORT resolve aquilo que alguém estava preparando 300 linhas de COBOL para fazer.
Conhecer ferramentas também significa saber quando não escrever código.
🧱 CAPÍTULO 14 — PROTÓTIPO NÃO É PILOTO
Esses dois conceitos são confundidos.
Protótipo
Responde perguntas como:
É isso que queremos construir?
Essa interface faz sentido?
Essa ideia funciona?
Exemplo:
IDEIA
↓
PROTÓTIPO
↓
USUÁRIO TESTA
↓
FEEDBACK
↓
AJUSTEPiloto
Está mais próximo de:
Isso funciona na realidade operacional?
SOLUÇÃO
↓
GRUPO CONTROLADO
↓
USO REAL
↓
MÉTRICAS
↓
AVALIAÇÃOO protótipo ajuda a descobrir.
O piloto ajuda a validar.
Um protótipo pode até ser descartável.
Essa é uma distinção importante.
Não transforme automaticamente código experimental em produção apenas porque a demonstração funcionou.
🔄 CAPÍTULO 15 — A DUNGEON MUDA DE LUGAR
Finalmente Lloyd encontra o último princípio:
rever os fatores.
Nenhuma arquitetura é eternamente correta.
Nenhum catálogo permanece atualizado sozinho.
Nenhuma regra de segurança dura para sempre.
Nenhum conhecimento continua relevante automaticamente.
Precisamos de ciclo:
PLANEJAR
↓
CONSTRUIR
↓
MEDIR
↓
APRENDER
↓
REVISAR
↓
PLANEJAR NOVAMENTEUma aplicação secundária pode tornar-se crítica.
Um sistema crítico pode perder importância.
Uma ameaça inexistente pode aparecer.
Uma integração pode transformar um pequeno programa em dependência de cinquenta sistemas.
O ambiente muda.
Portanto, governança não é uma atividade realizada uma vez.
É processo contínuo.
🤖 CAPÍTULO 16 — LLOYD ENCONTRA A IA
Se trouxermos os princípios para 2026, precisamos acrescentar novas dimensões.
Principalmente:
governança de dados;
privacidade;
observabilidade;
resiliência;
continuidade;
dependências;
gestão de fornecedores;
FinOps;
gestão do conhecimento;
segurança de software;
governança de IA;
Shadow AI.
IA deixa ainda mais clara a velha regra:
Tecnologia deve servir aos objetivos da organização.
Perguntar:
"Onde colocamos IA?"
é menos útil que perguntar:
"Qual problema possui características que justificam IA?"
Talvez um LLM possa ajudar a documentar COBOL.
Excelente.
Mas precisamos perguntar:
Que código será enviado?
↓
Onde será processado?
↓
Dados são confidenciais?
↓
Modelo pode errar?
↓
Quem valida?
↓
Existe auditoria?
↓
Qual impacto do erro?O princípio antigo continua funcionando.
A tecnologia mudou.
A governança permaneceu necessária.
🧠 CAPÍTULO 17 — O SISTEMA SOCIOTÉCNICO
Agora podemos juntar tudo.
Um sistema empresarial não é:
COBOL + CICS + DB2Ele é algo muito maior:
OBJETIVOS
|
v
PESSOAS ---> PROCESSOS ---> TECNOLOGIA
| | |
+----------> DADOS <----------+
|
v
CONTROLESChamamos isso, em sentido amplo, de uma visão sociotécnica.
Tecnologia influencia pessoas.
Pessoas modificam processos.
Processos geram dados.
Dados alimentam sistemas.
Sistemas alteram novamente os processos.
Tudo está conectado.
Por isso um projeto puramente técnico pode falhar.
🕒 CAPÍTULO 18 — O EASTER EGG DAS 03:17
São 03:17 da manhã.
O telefone toca.
Produção caiu.
O programador entra no war room.
Pergunta:
— Qual aplicação?
Alguém responde:
— Não sabemos exatamente.
— Quem é o owner?
— Estamos procurando.
— Quais aplicações dependem dela?
— Talvez faturamento.
— Existe documentação?
— O Carlos sabia.
— Carlos?
— Aposentou.
Lloyd aparece silenciosamente no canto da sala tomando café.
Ele não precisa dizer nada.
Todos os fatores críticos que pareciam burocracia durante o projeto acabaram de se transformar em problemas reais.
Patrocínio.
Especialistas.
Catálogo.
Documentação.
Padrões.
Conhecimento.
Controles.
Testes.
Responsabilidades.
A dívida organizacional acabou de vencer.
E produção cobra juros.
🗺️ CAPÍTULO 19 — O MAPA COMPLETO DA DUNGEON
Podemos finalmente organizar tudo:
OBJETIVO EMPRESARIAL
|
v
PATROCÍNIO
|
v
CONHECER O NEGÓCIO
|
v
OUVIR USUÁRIOS
|
v
OUVIR ESPECIALISTAS
|
v
REQUISITOS
|
v
PROTÓTIPO
|
v
ARQUITETURA
|
v
PADRÕES
|
v
DESENVOLVIMENTO
|
v
TESTES
|
v
PILOTO
|
v
PRODUÇÃO
|
v
OBSERVABILIDADE
|
v
CATÁLOGO + DOCUMENTAÇÃO
|
v
GESTÃO DO CONHECIMENTO
|
v
REVISÃO
|
+----------+
|
v
NOVO CICLOVeja que programação ocupa apenas uma parte do mapa.
Isso não diminui a importância do programador.
Faz exatamente o contrário.
Transforma o programador em alguém capaz de compreender onde seu código existe dentro de uma organização.
☕ EPÍLOGO — MAXCC=0000 NÃO É O FINAL DA HISTÓRIA
Lloyd finalmente retorna ao castelo.
O jovem COBOLer mostra orgulhoso o resultado:
IEF142I JOB001 STEP01 - STEP WAS EXECUTED
COND CODE 0000— Funcionou! — comemora o programador.
Lloyd sorri.
— O programa funcionou.
— Não é a mesma coisa?
— Não.
E aqui está talvez a maior lição desta dungeon.
Podemos ter:
CPU = OK
MEMÓRIA = OK
CICS = OK
DB2 = OK
BATCH = OK
MQ = OK
MAXCC = 0000e mesmo assim:
USUÁRIO = INSATISFEITO
NEGÓCIO = NÃO ATENDIDO
CUSTO = EXCESSIVO
ADOÇÃO = BAIXA
RISCO = ALTOTecnicamente, tudo verde.
Empresarialmente, vermelho.
Por isso os fatores críticos de sucesso existem.
Patrocínio garante direção.
Analistas preservam contexto.
Talentos são colocados onde produzem valor.
Tecnologia responde aos objetivos empresariais.
Usuários participam.
Padrões reduzem caos.
Regras protegem recursos e informações.
Especialistas revelam riscos.
Pilotos produzem evidência.
Catálogos mostram o território.
Soluções simples evitam complexidade gratuita.
Protótipos permitem aprender barato.
Revisões impedem que decisões antigas se transformem em dogmas.
E gestão do conhecimento impede que quarenta anos de inteligência corporativa saiam pela porta junto com o crachá de alguém que se aposentou.
Lloyd coloca a mão no ombro do aprendiz.
— Agora você está começando a entender Sistemas de Informação.
O programador olha novamente para o JES.
MAXCC=0000Aquilo que cinco minutos antes parecia o final da missão agora parecia apenas uma pequena etapa.
Porque o computador não sabe se o projeto foi um sucesso.
Ele sabe apenas se executou aquilo que mandamos executar.
Descobrir se mandamos fazer a coisa certa continua sendo responsabilidade humana.
E talvez seja exatamente por isso que, mesmo depois de décadas de evolução tecnológica, ainda precisamos de programadores que entendam não apenas máquinas...
...mas também o reino que existe ao redor delas.
Sem comentários:
Enviar um comentário