 |
| Bellacosa Mainframe e a convergencia tecnologica |
☕ Um Café no Bellacosa Mainframe
O Paciente Convergência: Quando IA, Cloud, Mainframe, Edge, Blockchain e Quantum Entram Juntos na Sala de Emergência
Imagine a seguinte cena.
São 02h17 da manhã.
O telefone toca.
Do outro lado, alguém da operação fala aquela frase que nenhum programador gosta de ouvir:
— “Temos um problema em produção.”
Você abre o notebook ainda meio sonolento. O sistema de pedidos está funcionando. O CICS está respondendo. O Db2 não apresenta lock anormal. As filas MQ parecem saudáveis. O Kubernetes diz que seus pods estão felizes. A aplicação mobile não caiu. O processamento de cartão está normal.
Mesmo assim, os clientes não conseguem receber seus pedidos.
Interessante.
O paciente parece saudável.
Mas está morrendo.
É nessa hora que entra nosso imaginário Dr. House do mainframe, manca até a sala de war room, olha para os dashboards, ignora solenemente a apresentação de PowerPoint da consultoria e pergunta:
— “Qual foi a última coisa que vocês mudaram?”
Silêncio.
Alguém responde:
— “Nada.”
House provavelmente sorriria.
Porque em informática, quando alguém diz que “nada mudou”, quase sempre alguma coisa mudou.
E esse é exatamente o problema que enfrentaremos cada vez mais no futuro.
Não teremos apenas um sistema.
Teremos um ecossistema inteiro tomando decisões em conjunto.
IA, cloud, mainframe, edge computing, carros autônomos, casas inteligentes, robôs industriais, digital twins, APIs, IoT, blockchain, dinheiro programável, agentes autônomos e, eventualmente, computação quântica.
O desafio não será simplesmente fazer cada tecnologia funcionar.
O desafio será fazer todas funcionarem juntas sem matar o paciente.
É disso que trata a ideia de Enterprise Operating Model, ou Modelo Operacional Empresarial.
Prepare o café.
Hoje nosso paciente não é um programa COBOL.
É a empresa inteira.
A doença do “próximo objeto brilhante”
A indústria de tecnologia sofre há décadas de uma doença bastante conhecida.
Podemos chamá-la de:
Síndrome do Shiny Object.
Toda geração acredita que encontrou a tecnologia que finalmente substituirá tudo que existia antes.
Nos anos 1950, o computador eletrônico mudaria tudo.
Nos anos 1960, time-sharing mudaria tudo.
Nos anos 1970, bancos de dados mudariam tudo.
Nos anos 1980, o PC mataria o mainframe.
Nos anos 1990, a Internet mataria praticamente todo mundo.
Nos anos 2000, Java substituiria COBOL.
Depois vieram virtualização, SOA, SaaS, smartphones, cloud, containers, microservices, blockchain, machine learning e inteligência artificial generativa.
Agora começamos a ouvir:
“Quantum vai mudar tudo.”
Talvez.
Mas existe um pequeno detalhe histórico.
Quase nenhuma dessas tecnologias matou completamente as anteriores.
Elas foram empilhadas.
O resultado é que um banco moderno pode ter, simultaneamente:
COBOL escrito em 1987, Java escrito em 2004, APIs REST implementadas em 2018, containers Kubernetes de 2023 e modelos de IA desenvolvidos em 2026.
Tudo funcionando na mesma transação.
Esse é o primeiro grande conceito que um programador COBOL iniciante precisa entender:
modernização raramente significa substituição total.
Na maioria das grandes empresas, modernização significa integração.
O futuro é menos parecido com uma demolição e mais parecido com uma cidade antiga.
Roma não destruiu completamente todas as construções anteriores antes de construir novas ruas.
Ela cresceu por camadas.
A informática corporativa também.
O futuro é uma pilha arqueológica
Imagine uma transação bancária simples.
Você abre o aplicativo e consulta seu saldo.
Na sua cabeça, existe apenas:
Aplicativo → Banco → Saldo
Bonito.
Limpo.
Quase poético.
Agora vamos abrir o paciente.
Pode existir algo parecido com:
Smartphone
↓
Internet
↓
CDN
↓
WAF
↓
API Gateway
↓
Identity Provider
↓
Kubernetes
↓
Microservice Java
↓
Kafka ou MQ
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
↓
Resposta
E ainda estou simplificando.
A transação aparentemente simples do cliente atravessou talvez dez ou quinze tecnologias.
Por isso existe uma enorme ironia no mundo moderno.
Quanto mais simples parece a interface para o usuário, mais complexa frequentemente é a infraestrutura escondida atrás dela.
É quase uma regra:
simplicidade na frente costuma exigir complexidade muito bem administrada atrás.
Diagnóstico diferencial nº 1: “A IA vai controlar tudo”
House colocaria essa hipótese no quadro.
AI controls everything.
E riscaria alguns minutos depois.
IA provavelmente será importantíssima.
Mas existe uma diferença fundamental entre três funções:
detectar, recomendar e executar.
Imagine uma fábrica.
Sensores detectam vibração anormal em um motor.
Um algoritmo identifica que aquele padrão costuma aparecer algumas horas antes da falha de um rolamento.
A IA então recomenda:
“Substituir rolamento em até quatro horas.”
Isso é recomendação.
Agora imagine que um agente de IA consulte estoque, descubra que não existe a peça, procure fornecedores, encontre disponibilidade, faça a compra, contrate transporte e reagende a produção.
Isso é execução.
São níveis completamente diferentes de responsabilidade.
E quanto mais avançamos do primeiro para o segundo, maior a necessidade de governança.
Porque surge a pergunta favorita de qualquer auditor:
Quem autorizou isso?
AI acelera decisões. Wisdom decide quais decisões merecem existir.
Na imagem original existe uma expressão particularmente interessante:
Strategy + Wisdom.
Estratégia e sabedoria.
Não “Strategy + AI”.
Isso é importante.
Modelos de IA podem avaliar milhões de combinações rapidamente.
Mas capacidade de calcular não é igual a responsabilidade.
Imagine um modelo dizendo:
“Bloquear esse cliente reduz o risco de fraude em 82%.”
Excelente.
Mas talvez seja um cliente empresarial responsável por uma folha de pagamento de vinte mil funcionários.
Bloquear automaticamente pode causar enorme impacto.
Tecnicamente a decisão parecia correta.
Contextualmente pode ser desastrosa.
E aqui aparece uma diferença profunda:
inteligência encontra opções.
sabedoria entende consequências.
Essa será uma das funções humanas mais importantes num ambiente cada vez mais automatizado.
O Digital Twin entra na sala
Agora nosso paciente apresenta outro sintoma.
Uma fábrica começa a apresentar atrasos.
Nenhuma máquina ainda quebrou.
Mas o digital twin detecta que provavelmente haverá problema em seis horas.
O que é um digital twin?
Pense nele como uma representação digital de algo físico.
Pode ser uma turbina.
Uma linha de montagem.
Uma fábrica.
Um navio.
Um prédio.
Até uma cidade.
Sensores enviam continuamente informações para esse modelo.
Temperatura.
Vibração.
Pressão.
Velocidade.
Consumo energético.
Carga.
Produção.
O sistema virtual acompanha o comportamento do sistema real.
Agora podemos perguntar:
“E se aumentarmos a produção em 15%?”
Em vez de testar diretamente na fábrica, podemos simular primeiro.
É quase como possuir uma versão de laboratório do mundo real.
Para um programador COBOL, uma analogia simples seria:
produção versus ambiente de testes.
Você não experimenta qualquer coisa diretamente no sistema que processa milhões de reais.
Primeiro testa em ambiente controlado.
Digital twins levam esse princípio ao mundo físico.
O Easter Egg do mainframe
Aqui existe uma curiosidade deliciosa.
O conceito parece futurista, mas a ideia fundamental não é tão diferente das simulações usadas há décadas.
Mainframes já simulavam sistemas econômicos, meteorológicos, industriais e científicos muito antes de alguém usar o termo “digital twin”.
Ou seja:
às vezes a indústria inventa um nome novo para uma ideia antiga que finalmente encontrou hardware barato o suficiente para ficar popular.
Quem trabalha com mainframe aprende cedo essa lição.
O futuro adora reutilizar conceitos do passado usando nomes mais bonitos.
A casa deixa de ser apenas uma casa
Outra previsão interessante é transformar residências em nós de uma infraestrutura distribuída.
Imagine uma casa com:
painéis solares,
bateria,
carregador de veículo elétrico,
sensores,
roteador avançado,
dispositivos IoT,
processamento edge.
Durante o dia, os painéis produzem eletricidade.
Parte alimenta a casa.
Parte carrega a bateria.
Parte pode ser vendida para a rede.
O veículo estacionado talvez também funcione como armazenamento energético.
Enquanto isso, algum processamento pode ocorrer localmente.
A casa passa a ser simultaneamente:
residência,
gerador,
bateria,
ponto de processamento,
nó de comunicação.
Isso muda completamente a arquitetura tradicional.
Antes:
Consumidor ← Companhia elétrica
No futuro:
Consumidor ↔ Rede elétrica
O consumidor pode também produzir.
Na computação acontece fenômeno parecido.
Antes:
Terminal → Data Center
Depois:
PC → Servidor
Agora:
Cloud ↔ Edge ↔ Dispositivo
O processamento espalha-se pela infraestrutura.
Edge Computing para quem programa COBOL
Edge Computing parece uma coisa misteriosa até você remover a palavra bonita.
Edge significa simplesmente executar processamento perto de onde os dados estão sendo produzidos.
Imagine uma câmera industrial analisando cem imagens por segundo.
Mandar todas para uma cloud distante pode ser caro e lento.
Então existe um pequeno computador perto da máquina.
Ele analisa as imagens localmente.
Só envia eventos relevantes.
Por exemplo:
100 imagens/s
↓
Edge AI
↓
Detectou defeito?
↓ ↓
não sim
↓ ↓
descarta envia evento
Isso reduz latência, tráfego e custo.
É parecido com algo que mainframes fazem há décadas através da ideia de colocar determinadas funções perto do processamento necessário.
A tecnologia muda.
Os princípios arquiteturais frequentemente permanecem.
O carro vira um data center com rodas
Durante grande parte do século XX, automóvel era essencialmente uma máquina mecânica.
Hoje já possui dezenas de módulos eletrônicos.
No futuro próximo, veículos cada vez mais avançados poderão operar como enormes plataformas computacionais móveis.
Câmeras observam o ambiente.
Radar calcula distância.
LIDAR pode construir mapas tridimensionais.
GPS fornece posição.
IA interpreta sinais.
Software decide aceleração, frenagem e direção.
Agora acrescente serviços.
O carro pode encontrar carregadores.
Reservar uma vaga.
Negociar horário de recarga.
Pagar estacionamento.
Pagar pedágio.
Comprar energia.
Receber atualização de software.
Reportar diagnóstico.
Tudo isso transforma o carro em uma espécie de cliente corporativo ambulante.
Para quem conhece arquitetura mainframe, pense nele como um terminal extremamente sofisticado gerando continuamente transações.
E quem processará essas transações?
Parte no veículo.
Parte no edge.
Parte na cloud.
Parte em data centers convencionais.
E muito provavelmente parte continuará chegando a mainframes.
Porque se seu carro compra energia automaticamente e o pagamento passa por um grande banco...
alguma coisa precisa atualizar a conta.
E não seria surpresa nenhuma encontrar no final dessa viagem algo parecido com:
EXEC SQL
UPDATE CONTA
SET SALDO = SALDO - :WS-VALOR
WHERE NUM_CONTA = :WS-CONTA
END-EXEC.
Ali está ele.
COBOL.
Quieto.
Sem aparecer na apresentação futurista.
Processando o futuro.
É quase o Alfred do Batman.
Não aparece muito nas cenas de ação.
Mas tente administrar a mansão sem ele.
Diagnóstico diferencial nº 2: “Cloud substituirá tudo”
House escreveria:
Cloud killed the data center.
Depois daria aquela olhada sarcástica.
Cloud trouxe uma mudança gigantesca.
Mas grandes empresas caminham para uma arquitetura cada vez mais híbrida.
Algumas cargas fazem sentido na cloud.
Outras no edge.
Outras em data centers privados.
Outras no mainframe.
Imagine uma empresa escolhendo onde executar cada tarefa dependendo de:
latência,
regulação,
custo,
segurança,
localidade dos dados,
capacidade,
disponibilidade.
A pergunta deixa de ser:
“Cloud ou mainframe?”
E passa a ser:
“Qual é o melhor lugar para executar esta parte?”
Isso é Hybrid Infrastructure.
Trusted Data: o combustível da convergência
Agora chegamos a uma camada crítica.
Dados confiáveis.
Existe um velho lema:
Garbage In, Garbage Out.
Coloque lixo na entrada e obterá lixo na saída.
Com IA podemos atualizar a frase:
Garbage In, Garbage Out at Artificial Intelligence Speed.
Se os dados estiverem errados, a IA não cria verdade magicamente.
Imagine dois sistemas.
CRM diz:
Cliente: ATIVO
ERP diz:
Cliente: CANCELADO
Sistema financeiro diz:
Cliente: BLOQUEADO
Qual é verdadeiro?
Bem-vindo ao mundo corporativo.
Trusted Data significa trabalhar para que dados tenham qualidade, procedência, contexto, segurança e significado conhecido.
E aqui entra algo importante para iniciantes.
Banco de dados não significa automaticamente dado confiável.
Você pode armazenar informação perfeitamente errada dentro do Db2.
Tecnologia garante persistência.
Governança garante significado.
Contexto: o ingrediente invisível
Imagine pedir para uma IA:
“Qual foi o faturamento?”
Ela pergunta:
“De quê?”
Da empresa?
Do Brasil?
Do mês?
Do trimestre?
Bruto?
Líquido?
Realizado?
Previsto?
Sem contexto, a resposta pode estar tecnicamente correta e ainda ser completamente inútil.
Por isso sistemas corporativos de IA dependem enormemente de contexto.
Quem é o usuário?
Que função exerce?
Que dados pode acessar?
Qual processo está executando?
Qual decisão precisa tomar?
Qual regra regulatória se aplica?
Contexto será tão importante para agentes de IA quanto LINKAGE SECTION é para um programa COBOL chamado por outro programa.
Sem parâmetros corretos, até excelente código faz besteira.
People + Process
Agora chegamos à parte que quase toda apresentação tecnológica tenta esconder.
Pessoas.
Você pode comprar servidor.
Pode licenciar software.
Pode contratar cloud.
Pode implementar IA.
Mas mudar comportamento organizacional é difícil.
Imagine uma empresa onde compras trabalham de uma forma, logística de outra, segurança de outra, tecnologia de outra e financeiro de outra.
Cada departamento criou seus próprios processos durante décadas.
Agora aparece um agente de IA atravessando todos eles.
Quem é responsável?
Quem aprova?
Quem interrompe?
Quem corrige?
Essa é a razão pela qual processo é arquitetura.
Um sistema não é apenas código.
É código dentro de uma organização.
Security + Governance: o RACF encontrou a inteligência artificial
Para alguém vindo do mainframe, governança não é novidade.
Imagine tentar entrar num dataset z/OS protegido.
RACF pergunta:
Quem é você?
O que quer acessar?
Tem autorização?
O acesso deve ser registrado?
Isso acontece há décadas.
Agora aplique a mesma filosofia a agentes de IA.
Imagine um agente dizendo:
“Preciso consultar a conta bancária do cliente.”
Governança pergunta:
Quem solicitou?
Qual agente?
Qual identidade?
Qual permissão?
Qual finalidade?
Por quanto tempo?
Podemos auditar?
Perceba como o mundo “novo” começa a reencontrar princípios antigos do mainframe.
Identidade.
Autorização.
Auditoria.
Segregação de funções.
Least privilege.
Nada disso nasceu ontem.
Connect, Govern, Scale
Na figura existem três verbos particularmente importantes.
Connect. Govern. Scale.
Eles quase resumem toda a arquitetura corporativa moderna.
Connect significa ligar os mundos.
Um sistema legado precisa conversar com uma API.
Uma API conversa com um agente.
O agente consulta um digital twin.
O digital twin recebe sensores IoT.
O pagamento volta para o core bancário.
Sem integração, temos ilhas.
Govern significa controlar essa integração.
Quem pode fazer o quê?
Como sabemos que aconteceu?
Como interrompemos uma automação errada?
Como cumprimos requisitos legais?
Scale significa fazer tudo continuar funcionando quando deixamos o laboratório.
Um chatbot para 20 funcionários pode ser trivial.
Um sistema atendendo 10 milhões de usuários é outra criatura.
Escalar exige capacidade, redundância, observabilidade, cache, filas, tolerância a falhas, controle de custos e planejamento.
Todo sysprog lendo isso provavelmente está sorrindo.
Porque a palavra “scale” talvez seja nova na apresentação.
O problema não é.
O agente autônomo comprou uma peça. Agora temos um problema.
Vamos montar um cenário.
Uma fábrica possui sensores conectados.
O digital twin prevê falha numa prensa.
IA confirma 92% de probabilidade.
Um agente recebe autorização para evitar interrupção da produção.
Ele consulta ERP.
Não há peça disponível.
Consulta fornecedores.
Fornecedor A entrega em três dias.
Fornecedor B entrega em seis horas, porém 18% mais caro.
O sistema estima que seis horas de fábrica parada custariam R$ 2 milhões.
Decisão:
comprar do fornecedor B.
O agente cria pedido.
Reserva transporte.
Atualiza programação.
Autoriza pagamento.
Peça chega.
Produção continua.
Bonito.
Agora House levanta a mão.
“Quem definiu que 18% mais caro estava dentro do limite de autoridade do agente?”
Silêncio.
Pronto.
Encontramos a doença.
Não era IA.
Era governança.
Programmable Money e Smart Contracts
A ideia de dinheiro programável acrescenta outra camada.
Hoje muitas transações exigem sistemas separados validando eventos.
No futuro podemos ter mecanismos onde pagamento está programaticamente relacionado ao cumprimento de determinada condição.
Por exemplo:
Produto entregue
↓
Sensor confirma recebimento
↓
Sistema valida contrato
↓
Pagamento autorizado
↓
Registro de propriedade atualizado
Blockchain pode participar de alguns desses cenários.
Mas aqui precisamos controlar o entusiasmo.
Blockchain não precisa aparecer em tudo.
Se existe apenas uma empresa controlando todo o processo, talvez um banco de dados tradicional seja melhor.
Blockchain tende a ganhar sentido quando existe necessidade de compartilhamento de estado ou confiança entre múltiplas entidades que não desejam depender completamente de um único controlador.
A pergunta correta não é:
“Como colocamos blockchain aqui?”
É:
“Existe um problema que blockchain resolve melhor do que alternativas mais simples?”
House aprovaria essa pergunta.
E o quantum?
Computação quântica recebe uma quantidade extraordinária de marketing.
Vale separar realidade de ficção.
Computadores quânticos não são simplesmente mainframes absurdamente rápidos.
Eles funcionam segundo princípios computacionais diferentes.
Provavelmente serão especialmente úteis em determinadas classes de problemas.
Otimização.
Simulação molecular.
Pesquisa de materiais.
Algumas operações matemáticas.
Problemas científicos específicos.
E possivelmente determinados problemas de inteligência artificial e logística.
Mas quase certamente teremos ambientes quantum-classical.
Ou seja:
computadores tradicionais executam a maior parte do sistema.
Computador quântico funciona como acelerador para um cálculo específico.
Algo parecido conceitualmente com o papel das GPUs hoje.
Seu programa empresarial não desaparecerá.
Ele poderá pedir ajuda a um recurso quântico para uma parte particularmente complicada.
O easter egg assustador: Harvest Now, Decrypt Later
Computação quântica também introduz uma preocupação de segurança.
Alguns dados precisam permanecer confidenciais durante décadas.
Um adversário pode capturar dados criptografados hoje e armazená-los.
Mesmo sem conseguir quebrar a criptografia atual, ele espera.
Talvez daqui a anos exista tecnologia capaz de fazê-lo.
Essa estratégia é chamada frequentemente de:
Harvest Now, Decrypt Later.
Colete agora.
Decifre depois.
Por isso empresas já trabalham com post-quantum cryptography.
O computador quântico plenamente capaz de quebrar determinados esquemas talvez ainda esteja distante.
Mas dados roubados hoje podem continuar valiosos no futuro.
Segurança precisa pensar décadas à frente.
O COBOL padawan deve aprender tudo isso?
Sim.
Mas não precisa virar especialista em tudo amanhã.
Aqui está o ponto importante.
O programador COBOL moderno não deveria estudar COBOL como se fosse uma ilha isolada.
Aprenda COBOL profundamente.
Depois entenda JCL.
Entenda Db2.
CICS.
VSAM.
MQ.
Depois compreenda APIs.
HTTP.
JSON.
REST.
Git.
CI/CD.
Containers conceitualmente.
Cloud.
Observabilidade.
Segurança.
IA.
Não porque você abandonará COBOL.
Mas porque seu COBOL estará conectado a esses mundos.
Seu programa pode continuar tendo:
IDENTIFICATION DIVISION.
PROGRAM-ID. PAGAMENTO.
Só que o programa pode ser chamado por um aplicativo mobile atravessando cinco camadas que não existiam quando COBOL foi criado.
Esse é o verdadeiro mainframe moderno.
A anatomia completa do paciente
Se precisássemos desenhar a empresa do futuro como uma arquitetura simplificada, teríamos algo assim:
MUNDO FÍSICO
│
┌──────────────┼──────────────┐
│ │ │
Casas Carros Fábricas
│ │ │
IoT Edge Digital Twin
└──────────────┼──────────────┘
│
Eventos
│
Inteligência AI
│
AI Agents
│
APIs / Workflows
│
┌───────────┼───────────┐
│ │ │
Cloud Mainframe Edge
│ │ │
Kubernetes CICS Devices
│ │
Java COBOL
│
Db2
│
Transações
│
Financeiro
│
Smart Contracts /
Digital Assets
Agora coloque envolvendo tudo:
identidade,
segurança,
governança,
observabilidade,
auditoria,
gestão de riscos,
regulação.
Esse é o Enterprise Operating Model.
O verdadeiro significado de Operating Model
Existe uma confusão comum.
Operating Model não é arquitetura de software.
Não é organograma.
Não é metodologia ágil.
Não é cloud strategy.
Ele descreve como a organização transforma estratégia em operação.
Quem decide?
Como decisões circulam?
Como dados circulam?
Quem possui responsabilidade?
Como tecnologia participa?
Como processos são executados?
Como riscos são controlados?
Como mudanças entram em produção?
Como erros são descobertos?
Como o sistema escala?
Como tudo isso é financiado?
Perceba que tecnologia é apenas uma parte.
Essa talvez seja a ideia mais importante de todo o artigo.
O famoso “não fizemos nenhuma mudança”
Voltamos para nossa war room.
House ainda está diante do quadro.
Todos os componentes parecem saudáveis.
Mas pedidos estão atrasados.
Finalmente alguém descobre:
um fornecedor alterou sua API.
Uma mudança pequena.
Campo:
"available": true
virou:
"availability": "AVAILABLE"
O agente de compras não conseguiu interpretar.
Ele concluiu que não havia fornecedores disponíveis.
O digital twin detectou corretamente o problema.
A IA recomendou corretamente a substituição.
O workflow estava correto.
O sistema bancário estava funcionando.
O mainframe estava funcionando.
O caminhão estava disponível.
Tudo funcionava.
Exceto a integração.
House apaga todo o quadro e escreve:
CONVERGENCE FAILURE.
Essa será uma classe cada vez mais comum de incidentes.
Não é servidor caído.
Não é COBOL errado.
Não é banco de dados quebrado.
É o comportamento emergente de muitos sistemas corretos interagindo incorretamente.
Isso muda a observabilidade
No passado, monitorávamos máquinas.
CPU.
Memória.
Disco.
Depois monitoramos aplicações.
Tempo de resposta.
Erros.
Transações.
Agora precisamos observar jornadas completas.
Um pagamento pode atravessar vinte componentes.
Você precisa acompanhar a transação inteira.
Por isso conceitos como tracing distribuído, correlation IDs, logs centralizados e métricas tornam-se tão importantes.
No mundo mainframe isso possui parentes antigos.
SMF.
RMF.
CICS monitoring.
Db2 accounting traces.
Logs.
MQ statistics.
Mais uma vez:
o mundo distribuído está redescobrindo algumas preocupações que grandes computadores corporativos enfrentam há décadas.
Curiosidade: o mainframe sempre foi um Operating Model em miniatura
Pense numa grande instalação z/OS.
Você encontra:
RACF controlando identidade.
WLM administrando prioridades.
JES controlando workloads batch.
CICS processando transações.
Db2 armazenando dados.
MQ entregando mensagens.
SMF registrando atividade.
RMF observando recursos.
DFSMS gerenciando storage.
Tudo precisa operar coordenadamente.
Isso é quase um pequeno modelo operacional tecnológico.
Talvez seja por isso que profissionais experientes de mainframe frequentemente compreendem rapidamente conceitos modernos de governança e confiabilidade.
Mudam as ferramentas.
Os problemas fundamentais permanecem.
House finalmente dá o diagnóstico
Depois de 1.500 palavras, muitos cafés e provavelmente três discussões com o departamento de compliance, podemos escrever o diagnóstico no quadro.
O problema não é falta de tecnologia.
Temos tecnologia extraordinária.
Temos computadores capazes de executar trilhões de operações.
Redes globais.
IA generativa.
Cloud planetária.
Robôs.
Sensores.
Satélites.
Mainframes gigantescos.
Talvez em breve computadores quânticos cada vez mais úteis.
A doença está em outro lugar.
Integração sem coordenação.
Uma empresa pode possuir as melhores ferramentas e ainda fracassar se seus dados forem inconsistentes, seus processos conflitantes, sua governança fraca e suas responsabilidades mal definidas.
Por isso a frase mais importante daquela imagem talvez seja:
The next wave isn't one technology. It's the convergence.
A próxima onda não será uma tecnologia.
Será a convergência.
Mas eu acrescentaria uma segunda frase:
Convergência sem governança é apenas complexidade distribuída.
E esse é o ponto onde o Enterprise Operating Model deixa de ser uma expressão bonita de consultoria e passa a ser arquitetura de sobrevivência.
☕ Diagnóstico final do Bellacosa Mainframe
Para nosso jovem padawan COBOL, fica uma lição preciosa.
Não tenha medo porque aparecem palavras como AI, Quantum, Edge, Digital Twin, Blockchain e Cloud Native.
Abra o paciente.
Observe os órgãos.
Descubra quem chama quem.
Quem grava dados.
Quem envia mensagens.
Quem autentica.
Quem autoriza.
Quem registra.
Quem recupera.
Quem responde quando tudo dá errado.
Você descobrirá que, por baixo de muitos nomes novos, continuam existindo questões que programadores enfrentam desde os primeiros grandes sistemas comerciais:
dados, processamento, comunicação, segurança, confiabilidade e responsabilidade.
A grande mudança é que agora essas coisas estão espalhadas por carros, casas, fábricas, clouds, dispositivos, data centers e mainframes.
O sistema deixou de caber dentro do computador.
Agora o sistema é o próprio mundo conectado.
E talvez, às 02h17 de alguma madrugada de 2035, um jovem analista receba um chamado porque um caminhão autônomo não conseguiu retirar uma peça comprada por um agente de IA depois que um digital twin previu a falha de um robô industrial.
Ele abrirá os logs.
Passará pelo Kubernetes.
Examinará Kafka.
Consultará o agente.
Verificará a API.
Seguirá a transação até o IBM Z.
E finalmente encontrará no fundo da arquitetura um programa:
IDENTIFICATION DIVISION.
PROGRAM-ID. BLCSPG01.
PROCEDURE DIVISION.
IF WS-AUTORIZACAO = 'N'
MOVE 'TRANSACTION NOT AUTHORIZED'
TO WS-MENSAGEM
END-IF.
GOBACK.
O programa foi escrito em 1997.
Nunca recebeu um prêmio.
Nunca apareceu numa palestra de inteligência artificial.
Nunca ganhou uma hashtag no LinkedIn.
E está funcionando perfeitamente.
O problema?
Alguém esqueceu de atualizar uma tabela de autorização.
House olha para o jovem programador.
O jovem olha para House.
House olha novamente para o monitor.
E sentencia:
“Everybody lies. Especially configuration tables.”
Fim do caso.
O mainframe continua processando.
O agente volta a comprar.
O caminhão sai.
A fábrica não para.
E em algum lugar, completamente indiferente a todas as previsões sobre sua morte, um pequeno programa COBOL executa seu próximo COMMIT.
☕ Bem-vindo à convergência.
O futuro não será cloud.
Não será IA.
Não será quantum.
Não será mainframe.
Será tudo isso trabalhando junto.
E alguém terá que entender como todas essas peças se conectam.
Talvez esse alguém seja justamente o programador COBOL que decidiu olhar além da PROCEDURE DIVISION.
