 |
| Bellacosa Mainframe entenda o messy middle |
☕ Um Café no Bellacosa Mainframe
The Messy Middle: Por que a Modernização Corporativa Não Acontece em Linha Reta
Como IBM Fusion, OpenShift, máquinas virtuais, containers, dados, inteligência artificial e IBM Z convivem no mundo real
“A modernização não acontece quando uma empresa abandona tudo o que construiu. Ela acontece quando consegue conectar o que já funciona ao que precisará funcionar amanhã.”
Imagine, Padawan, que você trabalha em um grande banco.
De um lado existe um programa COBOL criado há trinta anos, processando milhões de transações todos os dias. Ele consulta o Db2, conversa com o CICS, envia mensagens pelo IBM MQ e produz arquivos utilizados por dezenas de outros sistemas.
Do outro lado existe uma nova aplicação desenvolvida com microsserviços, APIs REST, containers, Kubernetes, inteligência artificial e interfaces web modernas.
Entre esses dois mundos aparecem máquinas virtuais, storages, servidores Linux, ambientes VMware, clusters OpenShift, ferramentas de segurança, plataformas de observabilidade, pipelines de DevOps, soluções de backup, data lakes e diversos fornecedores.
A diretoria deseja inovação.
A área de negócios quer velocidade.
A equipe de segurança quer controle.
A infraestrutura deseja reduzir custos.
Os desenvolvedores querem autonomia.
Os responsáveis pelos sistemas críticos querem estabilidade.
E ninguém pode simplesmente desligar o sistema que mantém o banco funcionando.
Bem-vindo ao The Messy Middle, o “meio bagunçado” da modernização corporativa.
Esse conceito descreve a realidade em que a maioria das grandes empresas vive: elas não abandonaram o passado, ainda não chegaram completamente ao futuro e precisam operar todos os ambientes simultaneamente.
Não existe uma ponte limpa e reta entre o legado e o cloud native.
Existe uma enorme zona de convivência.
É justamente nesse espaço que tecnologias como IBM Fusion, Red Hat OpenShift, IBM Storage Scale, IBM Ceph, OpenShift Virtualization, Content Aware Storage, watsonx, z/OS Connect e IBM Z ganham importância.
Neste café, vamos desmontar essa arquitetura passo a passo, como se estivéssemos analisando um programa COBOL complexo durante um incidente de produção.
1. O mito da modernização perfeita
Durante muitos anos, o mercado de tecnologia vendeu uma narrativa extremamente sedutora.
A história era mais ou menos assim:
Sistemas antigos
↓
Migração para a nuvem
↓
Containers
↓
Kubernetes
↓
Microsserviços
↓
Tudo moderno
Parecia simples.
As máquinas virtuais desapareceriam.
Os datacenters seriam desligados.
Os programas monolíticos seriam reescritos.
Os sistemas legados seriam aposentados.
Todas as aplicações seriam transformadas em microsserviços executados em containers.
Mas a realidade corporativa recusou-se a seguir esse desenho.
Aplicações críticas não podem ser desligadas apenas porque surgiu uma tecnologia mais nova.
Imagine um sistema COBOL que controla:
contas bancárias;
cartões de crédito;
pagamentos;
apólices de seguro;
folhas de pagamento;
reservas de passagens;
arrecadação governamental;
processamento hospitalar.
Esse sistema pode ter décadas de existência, mas isso não significa que esteja obsoleto.
Ele pode continuar rápido, seguro, auditável e extremamente confiável.
O problema normalmente não está no fato de ele ser antigo.
O problema aparece quando ele precisa:
integrar-se com novos canais;
responder mais rapidamente às mudanças;
expor serviços por APIs;
consumir dados modernos;
participar de iniciativas de inteligência artificial;
ser observado por ferramentas contemporâneas;
compartilhar informações com outras plataformas.
Modernizar, portanto, não significa necessariamente reescrever.
Frequentemente significa integrar, organizar, automatizar, expor, governar e evoluir.
2. O que é o The Messy Middle?
O termo “Messy Middle” representa a fase intermediária — e muitas vezes permanente — em que empresas operam tecnologias de diferentes gerações.
Podemos visualizar esse ambiente assim:
IBM Z e COBOL
+
VMware e máquinas virtuais
+
Linux
+
Aplicações Java
+
Containers
+
OpenShift
+
Nuvem pública
+
Storage tradicional
+
Data lakes
+
Inteligência artificial
=
THE MESSY MIDDLE
A palavra “messy” não significa necessariamente que tudo esteja errado.
Ela indica que existem muitos elementos diferentes, interdependentes e difíceis de coordenar.
Uma grande organização pode manter simultaneamente:
programas COBOL no z/OS;
aplicações Java no WebSphere;
servidores Windows;
bancos Oracle;
ambientes VMware;
Linux em máquinas virtuais;
containers Kubernetes;
clusters OpenShift;
serviços em AWS;
workloads em Azure;
armazenamento NAS;
object storage;
IBM Storage Scale;
Ceph;
plataformas de IA;
ferramentas de segurança;
centenas de integrações.
Cada tecnologia foi adotada para resolver algum problema.
Com o tempo, porém, a soma dessas soluções cria uma nova dificuldade: a complexidade operacional.
3. Platform sprawl: quando cada solução cria outra plataforma
Existe uma expressão importante nesse debate: platform sprawl.
Ela pode ser traduzida como proliferação ou dispersão de plataformas.
Acontece quando cada novo projeto cria um novo ambiente, uma nova ferramenta, uma nova equipe e um novo conjunto de processos.
Imagine a seguinte evolução:
Projeto A → Kubernetes próprio
Projeto B → VMware separado
Projeto C → Nuvem pública
Projeto D → Outro storage
Projeto E → Nova ferramenta de backup
Projeto F → Nova plataforma de IA
Em pouco tempo, a empresa possui:
vários clusters;
múltiplos consoles;
diferentes modelos de segurança;
diversas ferramentas de monitoramento;
pipelines incompatíveis;
backups administrados separadamente;
equipes isoladas;
custos duplicados;
padrões operacionais inconsistentes.
Isso pode parecer modernização porque existem containers, APIs e nuvem.
Mas, na prática, pode ser apenas a velha fragmentação usando roupas novas.
Por isso a frase é tão poderosa:
“Isso não é modernização. É platform sprawl usando uma jaqueta mais bonita.”
Modernização verdadeira não consiste apenas em adicionar tecnologia.
Ela precisa reduzir atrito, simplificar operações, aumentar governança e permitir que diferentes workloads convivam de forma consistente.
4. As máquinas virtuais ainda importam
É comum ouvir que VMs serão substituídas completamente por containers.
Essa previsão ignora a realidade das empresas.
Máquinas virtuais continuam importantes porque milhares de aplicações foram construídas para esse modelo.
Algumas aplicações:
dependem de sistemas operacionais específicos;
possuem licenças vinculadas à VM;
utilizam middleware tradicional;
não foram desenhadas para containers;
não possuem justificativa financeira para reescrita;
são estáveis e pouco alteradas;
suportam processos críticos.
Transformar cada aplicação em container pode custar mais do que o benefício gerado.
Um sistema que funciona bem dentro de uma VM não precisa ser reescrito apenas para seguir uma tendência.
A pergunta correta não é:
“Por que essa aplicação ainda está em VM?”
A pergunta mais inteligente é:
“Existe pressão técnica ou de negócio suficiente para mudar essa aplicação?”
Se a resposta for não, a VM pode continuar sendo a melhor opção.
O desafio passa a ser administrá-la dentro de uma plataforma mais consistente.
É aí que entra o OpenShift Virtualization, permitindo que máquinas virtuais e containers convivam sob uma camada operacional comum.
5. Containers crescem, mas não de maneira uniforme
Containers são excelentes para diversos tipos de aplicação.
Eles proporcionam:
portabilidade;
isolamento;
automação;
escalabilidade;
padronização;
rapidez de implantação;
integração com pipelines;
uso eficiente de recursos.
Mas nem toda aplicação precisa ser containerizada.
Uma aplicação web moderna pode nascer diretamente em containers.
Um microsserviço stateless pode escalar horizontalmente com facilidade.
Já um sistema antigo, com dependências rígidas e estado persistente, pode exigir grande esforço para adaptação.
Por isso o crescimento dos containers é desigual.
Algumas áreas avançam rapidamente.
Outras continuam com VMs.
Outras mantêm workloads no mainframe.
E todas precisam conversar.
O Messy Middle é justamente essa convivência.
6. O problema não é Kubernetes
Muitas discussões de modernização começam com a pergunta errada:
“A empresa está migrando para Kubernetes?”
Essa pergunta coloca a tecnologia antes do problema.
Kubernetes é uma ferramenta poderosa, mas não é um objetivo de negócio.
Nenhum cliente acorda desejando Kubernetes.
Ele deseja:
uma transação mais rápida;
um aplicativo disponível;
um atendimento melhor;
uma resposta imediata;
um processo automatizado;
menor custo;
maior segurança.
A pergunta correta é:
“Quais aplicações estão sob pressão para mudar?”
Essa pressão pode aparecer de diversas formas.
Aplicação lenta para evoluir
Uma pequena alteração demora meses porque depende de muitos departamentos.
Escalabilidade limitada
A aplicação suporta mil usuários, mas precisa atender cem mil.
Integração difícil
O sistema não possui APIs ou depende de arquivos manuais.
Dados isolados
As informações estão presas em bancos, documentos ou servidores inacessíveis.
Operação cara
A infraestrutura exige muitas licenças, equipes e ferramentas.
Falta de observabilidade
Ninguém sabe exatamente por que a aplicação fica lenta ou falha.
Dificuldade para usar IA
O sistema possui dados valiosos, mas eles não estão preparados para modelos de inteligência artificial.
Esses são os verdadeiros sinais de que uma conversa sobre plataforma se tornou urgente.
7. O que é IBM Fusion?
IBM Fusion é uma plataforma criada para ajudar empresas a consolidar e administrar workloads híbridos, especialmente ambientes que envolvem:
máquinas virtuais;
containers;
dados;
armazenamento;
inteligência artificial;
OpenShift.
A proposta não é obrigar a empresa a escolher apenas um modelo.
A proposta é fornecer uma base mais consistente para vários modelos coexistirem.
A arquitetura apresentada na imagem coloca IBM Fusion acima de uma fundação composta por tecnologias como:
Red Hat OpenShift;
IBM Storage Scale;
IBM Ceph;
Content Aware Storage.
Sobre essa fundação podem operar:
VMs | Containers | Dados | IA
Essa visão é importante porque reconhece que a empresa não vai modernizar tudo de uma vez.
Ela precisará sustentar o atual enquanto prepara o próximo.
8. As duas opções: Fusion Software e Fusion HCI
IBM Fusion oferece dois caminhos principais.
8.1 Fusion Software
Fusion Software é indicado para organizações que já possuem infraestrutura.
A empresa pode ter:
servidores;
rede;
storage;
datacenter;
equipamentos certificados;
investimentos recentes.
Nesse cenário, não faz sentido substituir tudo.
O software é instalado sobre a infraestrutura existente, permitindo aproveitar o investimento já realizado.
Podemos representar assim:
Infraestrutura existente
+
Fusion Software
+
OpenShift
+
Serviços de dados
=
Plataforma híbrida
Essa opção é interessante para empresas que desejam modernizar gradualmente.
Ela segue uma filosofia muito conhecida no mainframe:
Não descarte o que funciona. Acrescente uma camada melhor de controle.
8.2 Fusion HCI
HCI significa Hyperconverged Infrastructure, ou infraestrutura hiperconvergente.
Nesse modelo, hardware e software são fornecidos de maneira integrada.
A solução combina:
computação;
armazenamento;
rede;
virtualização;
OpenShift;
serviços de dados;
automação.
A grande vantagem é reduzir o trabalho de integração.
Em vez de a empresa escolher separadamente:
servidor;
storage;
firmware;
drivers;
sistema operacional;
plataforma de containers;
ferramentas de administração;
ela recebe uma arquitetura integrada e validada.
Isso reduz:
tempo de implantação;
incompatibilidades;
esforço operacional;
quantidade de fornecedores;
risco de configuração.
9. OpenShift é a camada central
Red Hat OpenShift aparece no centro da arquitetura porque ele fornece a plataforma de execução e orquestração.
OpenShift é uma distribuição corporativa de Kubernetes, mas vai além do Kubernetes puro.
Ele oferece:
gerenciamento de clusters;
Operators;
políticas de segurança;
integração com pipelines;
GitOps;
monitoramento;
logging;
registro de imagens;
service mesh;
gerenciamento de identidade;
automação de implantação;
suporte empresarial.
Para um programador COBOL Padawan, uma analogia pode ajudar.
Imagine que Kubernetes seja o equivalente a um conjunto de serviços fundamentais do z/OS.
OpenShift adiciona uma camada integrada de administração, segurança, operação e suporte.
Ele não é apenas o “motor”.
Ele também fornece parte do painel, dos procedimentos, das políticas e dos instrumentos necessários para operar o motor com segurança.
10. OpenShift Virtualization: VMs e containers no mesmo ambiente
Uma das ideias mais práticas dessa arquitetura é permitir que VMs sejam executadas dentro do ecossistema OpenShift.
Isso resolve um problema importante.
A empresa pode ter:
aplicações novas em containers;
aplicações antigas em VMs;
equipes trabalhando com ambos os modelos.
Sem OpenShift Virtualization, esses ambientes podem ser gerenciados por plataformas completamente diferentes.
Com ele, torna-se possível aproximar:
VMs
+
Containers
+
Políticas
+
Observabilidade
+
Automação
Isso não significa que a VM virou container.
Significa que ambos podem ser administrados dentro de uma plataforma comum.
É uma estratégia gradual.
Primeiro, a empresa pode migrar a VM para uma infraestrutura mais padronizada.
Depois, avalia se vale a pena modernizar a aplicação.
Essa abordagem evita o erro clássico de tentar reescrever tudo de uma vez.
11. Storage deixou de ser apenas disco
Durante muito tempo, armazenamento foi tratado como uma camada invisível.
O programador gravava um arquivo.
O banco armazenava registros.
A infraestrutura cuidava dos discos.
Com inteligência artificial, analytics, machine learning e grandes volumes de conteúdo não estruturado, isso mudou completamente.
Storage passou a desempenhar funções estratégicas.
Agora ele precisa:
movimentar grandes volumes;
alimentar GPUs;
atender clusters;
escalar horizontalmente;
armazenar objetos;
fornecer arquivos;
expor blocos;
indexar conteúdo;
aplicar políticas;
suportar IA;
preservar governança.
Por isso a base da arquitetura destaca Storage Scale, Ceph e Content Aware Storage.
12. IBM Storage Scale
IBM Storage Scale, anteriormente conhecido como GPFS, é um sistema de arquivos distribuído projetado para grandes volumes e alto desempenho.
Ele é utilizado em cenários como:
inteligência artificial;
supercomputação;
analytics;
data lakes;
grandes repositórios;
processamento paralelo;
ambientes de pesquisa.
A ideia principal é permitir que diversos servidores acessem grandes conjuntos de dados com alto throughput.
Imagine centenas de nós tentando ler dados para treinar um modelo de IA.
Um storage convencional pode tornar-se um gargalo.
Storage Scale foi criado para cenários em que o acesso paralelo e a escala são essenciais.
Para o Padawan COBOL, pense em uma diferença semelhante a esta:
Arquivo simples usado por um programa
versus
Sistema de arquivos distribuído usado por centenas de nós
A lógica fundamental continua sendo armazenar e recuperar dados.
Mas a escala e a arquitetura mudam radicalmente.
13. IBM Ceph
Ceph é uma plataforma de armazenamento distribuído.
Ela pode fornecer diferentes tipos de storage:
block storage;
file storage;
object storage.
Isso é importante porque aplicações diferentes precisam de formatos diferentes.
Uma VM pode precisar de block storage.
Uma aplicação pode precisar de sistema de arquivos.
Um data lake pode precisar de object storage.
Ceph permite reunir essas necessidades sobre uma arquitetura distribuída.
Em vez de manter soluções totalmente separadas para cada caso, a empresa pode utilizar uma plataforma mais integrada.
14. Content Aware Storage: quando o armazenamento entende o conteúdo
Content Aware Storage é um dos conceitos mais interessantes da arquitetura.
A maioria das empresas possui enormes quantidades de conteúdo não estruturado:
contratos;
documentos;
PDFs;
relatórios;
imagens;
gravações;
e-mails;
políticas internas;
históricos de atendimento;
manuais;
documentos jurídicos;
registros de manutenção.
Esses arquivos existem, mas frequentemente estão invisíveis para aplicações modernas e para sistemas de IA.
Eles podem estar espalhados em:
compartilhamentos de rede;
SharePoint;
servidores de arquivos;
object storage;
caixas postais;
ferramentas departamentais;
sistemas antigos.
O armazenamento consciente de conteúdo busca não apenas guardar arquivos, mas também facilitar sua classificação, descoberta, indexação e uso.
Isso transforma o storage em uma parte ativa da arquitetura de dados.
15. As empresas não têm falta de dados
Uma das frases mais importantes de toda essa discussão é:
“A maioria das organizações não possui falta de dados. Possui dificuldade de ativar os dados.”
Grandes empresas já possuem uma quantidade imensa de informação.
Um banco possui:
contratos;
transações;
cadastros;
reclamações;
históricos;
análises;
documentos;
políticas;
registros de fraude;
comunicações;
dados operacionais.
Uma seguradora possui:
apólices;
sinistros;
laudos;
fotos;
pareceres;
documentos médicos;
históricos de atendimento.
Uma indústria possui:
manuais;
ordens de manutenção;
telemetria;
relatórios;
desenhos;
registros de falhas;
documentos de engenharia.
O problema é que esses dados estão fragmentados.
Eles existem, mas não estão necessariamente:
catalogados;
acessíveis;
governados;
conectados;
pesquisáveis;
classificados;
seguros;
preparados para IA.
Essa é a diferença entre possuir dados e conseguir utilizá-los.
16. Data activation: transformar dado parado em valor
Ativação de dados significa tornar a informação utilizável por processos, pessoas, aplicações e modelos.
Podemos representar assim:
Dado armazenado
↓
Descoberta
↓
Classificação
↓
Governança
↓
Indexação
↓
Acesso controlado
↓
Aplicação ou IA
↓
Valor de negócio
Imagine um contrato de cem páginas guardado em um diretório.
Ele contém informação valiosa.
Mas, enquanto permanecer apenas como arquivo, seu valor está limitado.
Quando é indexado, classificado, associado a metadados e disponibilizado para busca semântica, passa a responder perguntas como:
Qual contrato vence no próximo mês?
Quais cláusulas contêm determinado risco?
Quais clientes possuem uma condição específica?
Qual política interna se aplica ao caso?
Qual documento fundamenta uma decisão?
A IA não cria magicamente conhecimento.
Ela depende de acesso seguro e contextualizado ao conhecimento que já existe.
17. IA precisa de dados confiáveis e governados
Modelos generativos podem responder perguntas, resumir documentos e apoiar decisões.
Mas, dentro de uma empresa, não basta conectar um chatbot a uma pasta de arquivos.
É necessário controlar:
quem pode consultar;
quais dados podem ser utilizados;
onde os dados estão;
qual é a versão correta;
quais informações são confidenciais;
como registrar auditoria;
como evitar vazamento;
como manter rastreabilidade;
como respeitar políticas internas.
Por isso o desafio de IA é também um desafio de infraestrutura, dados e segurança.
Uma arquitetura típica pode ser:
Documentos corporativos
↓
Classificação
↓
Extração de conteúdo
↓
Indexação
↓
Vetorização
↓
Banco vetorial
↓
RAG
↓
Modelo de IA
↓
Resposta com contexto
RAG significa Retrieval-Augmented Generation.
Em vez de o modelo responder apenas com o conhecimento adquirido no treinamento, ele consulta informações corporativas autorizadas antes de gerar a resposta.
Isso aumenta a relevância e reduz respostas sem fundamento.
18. E onde entra o IBM Z?
Para quem trabalha com COBOL, esse ponto é fundamental.
IBM Fusion não substitui o IBM Z.
OpenShift não precisa substituir o COBOL.
A inteligência artificial não precisa eliminar o CICS.
A arquitetura moderna pode aproveitar o mainframe como sistema de registro e processamento crítico.
Veja um exemplo:
Aplicação móvel
↓
API Gateway
↓
OpenShift
↓
Microsserviço
↓
z/OS Connect
↓
CICS
↓
Programa COBOL
↓
Db2
O usuário utiliza um aplicativo moderno.
A interface pode ter sido criada em React.
A API pode estar em OpenShift.
Mas a transação financeira continua sendo processada por COBOL no IBM Z.
Isso é modernização por integração.
Não por destruição.
19. Um exemplo bancário completo
Imagine que um banco deseja criar um assistente de IA para ajudar clientes a entender seus contratos.
Os contratos estão em PDFs.
Os dados cadastrais estão no Db2.
As transações são processadas por COBOL.
A interface do cliente está em uma aplicação web.
Uma arquitetura possível seria:
Cliente
↓
Portal Web
↓
Aplicação em OpenShift
↓
Serviço de IA
↓
Busca em documentos indexados
↓
Content Aware Storage
↓
Consulta de dados autorizados
↓
API
↓
z/OS Connect
↓
COBOL / CICS / Db2
O assistente poderia responder:
“Sua tarifa está prevista na cláusula 8 do contrato e foi aplicada em determinada data.”
Para fazer isso corretamente, ele precisa combinar:
documento;
regra;
cadastro;
transação;
autorização;
contexto.
Nenhum desses elementos sozinho resolve o problema.
A plataforma precisa conectá-los.
20. Segurança quer controle; desenvolvimento quer velocidade
Uma das tensões centrais do Messy Middle ocorre entre segurança e agilidade.
A equipe de desenvolvimento deseja:
criar ambientes rapidamente;
implantar várias vezes por dia;
testar novas tecnologias;
automatizar processos.
A equipe de segurança deseja:
revisar acessos;
controlar imagens;
restringir privilégios;
aplicar políticas;
auditar operações;
impedir exposição de dados.
Nenhum lado está errado.
Sem velocidade, a empresa perde competitividade.
Sem segurança, a empresa assume riscos inaceitáveis.
A plataforma moderna precisa transformar segurança em política automatizada.
Em vez de revisar tudo manualmente, ela pode aplicar controles como código.
Exemplos:
políticas de rede;
controle de imagens;
autenticação centralizada;
secrets management;
criptografia;
segmentação;
auditoria;
RBAC;
integração com Vault;
compliance automatizado.
Assim, segurança deixa de ser apenas uma barreira no final do projeto e passa a fazer parte da plataforma.
21. O custo do VMware e a revisão das plataformas
Muitas empresas construíram enormes ambientes sobre VMware.
Durante anos, esse modelo tornou-se praticamente padrão em datacenters corporativos.
Mas mudanças de licenciamento, custo e estratégia de fornecedores fizeram várias organizações reconsiderarem sua dependência.
A pergunta passou a ser:
“Continuaremos executando todas as VMs da mesma maneira?”
Isso criou interesse em alternativas como:
OpenShift Virtualization;
KVM;
plataformas hiperconvergentes;
nuvens privadas;
modernização gradual.
A pressão financeira pode acelerar uma decisão arquitetural.
Uma aplicação que ninguém pretendia mover pode entrar em discussão quando o custo de sua plataforma aumenta.
Isso mostra que modernização nem sempre começa por inovação.
Às vezes começa por economia.
22. Operational debt: a dívida operacional
Programadores conhecem dívida técnica.
Ela ocorre quando decisões rápidas ou inadequadas tornam o código mais difícil de manter.
Existe também a dívida operacional.
Ela aparece quando a infraestrutura acumula complexidade.
Exemplo:
12 ferramentas de monitoramento
8 plataformas de backup
6 clusters Kubernetes
5 ambientes VMware
4 soluções de storage
3 gerenciadores de identidade
2 catálogos de serviços
1 equipe tentando entender tudo
Cada ferramenta pode ser boa isoladamente.
Mas o conjunto torna a operação lenta, cara e frágil.
A dívida operacional produz:
dependência de especialistas;
dificuldade de diagnóstico;
processos manuais;
baixa padronização;
atualizações demoradas;
riscos de segurança;
custos ocultos;
aumento do tempo de resposta.
Uma plataforma unificada busca reduzir essa dívida.
Não elimina toda complexidade, mas tenta torná-la administrável.
23. Passo a passo para identificar os pontos de pressão
Uma empresa não precisa começar modernizando tudo.
Ela deve procurar os pontos onde existe maior pressão.
Passo 1 — Liste as aplicações críticas
Identifique quais sistemas sustentam processos importantes.
Pergunte:
Qual aplicação gera receita?
Qual interromperia o negócio se parasse?
Qual possui maior volume?
Qual atende mais clientes?
Qual possui maior risco?
Passo 2 — Descubra onde existe lentidão de mudança
Verifique:
quanto tempo demora um deploy;
quantas aprovações são necessárias;
quantas equipes participam;
quanto tempo leva para criar um ambiente;
quantos processos são manuais.
Passo 3 — Identifique dados presos
Pergunte:
Onde estão os documentos?
Quem pode acessá-los?
Existem catálogos?
Os dados possuem dono?
Podem ser consumidos por APIs?
São utilizáveis por IA?
Passo 4 — Meça a duplicação
Procure:
storages repetidos;
clusters similares;
ferramentas com a mesma função;
pipelines diferentes;
múltiplas soluções de segurança;
equipes refazendo o mesmo trabalho.
Passo 5 — Analise custos
Inclua:
licenças;
hardware;
nuvem;
suporte;
mão de obra;
indisponibilidade;
retrabalho;
complexidade.
Passo 6 — Avalie a pressão de IA
Pergunte:
Quais dados a IA precisará?
Onde eles estão?
Eles são confiáveis?
Quem pode consultá-los?
A infraestrutura suporta o volume?
Há governança?
Há observabilidade?
Passo 7 — Escolha um caso de uso real
Não comece com uma transformação abstrata.
Escolha um problema concreto.
Por exemplo:
migrar um conjunto de VMs;
modernizar uma aplicação;
criar busca inteligente de documentos;
integrar um sistema COBOL via API;
consolidar storage;
reduzir ferramentas;
criar uma plataforma para IA.
24. O papel do programador COBOL Padawan
Talvez você esteja pensando:
“Mas isso parece assunto de arquiteto, infraestrutura e cloud. O que um programador COBOL tem a ver com isso?”
Tem tudo a ver.
O programador COBOL conhece:
regras de negócio;
estruturas de dados;
transações;
arquivos;
processos batch;
integrações;
dependências;
impactos;
comportamento histórico.
Em muitas empresas, o conhecimento mais valioso não está na documentação.
Está na mente dos profissionais que entendem os sistemas centrais.
Quando uma aplicação precisa ser exposta como API, alguém deve explicar:
o que o programa faz;
quais campos são obrigatórios;
quais códigos de retorno existem;
quais regras são aplicadas;
quais tabelas são consultadas;
quais transações são afetadas;
quais riscos existem.
Esse alguém frequentemente é o programador COBOL.
O profissional de mainframe não deve olhar OpenShift, Fusion, APIs e IA como ameaças.
Deve enxergá-los como novas formas de levar o valor do IBM Z para outros ambientes.
25. Uma trilha de estudos para o Padawan
Para compreender esse novo cenário, uma trilha prática pode ser organizada assim.
Fundamentos
Linux;
redes;
HTTP;
JSON;
REST;
Git.
Containers
Docker;
imagens;
registries;
volumes;
redes;
containers stateless e stateful.
Kubernetes
Pods;
Deployments;
Services;
ConfigMaps;
Secrets;
Persistent Volumes;
Operators.
OpenShift
projetos;
rotas;
pipelines;
segurança;
observabilidade;
GitOps;
OpenShift Virtualization.
Integração IBM Z
z/OS Connect;
CICS web services;
IBM MQ;
APIs;
eventos;
Kafka;
JSON no COBOL.
Dados e IA
dados estruturados;
dados não estruturados;
object storage;
RAG;
embeddings;
vetorização;
governança;
watsonx.
Operação
observabilidade;
SRE;
automação;
segurança;
custo;
capacidade;
continuidade.
O objetivo não é tornar o programador COBOL especialista em tudo.
É permitir que ele compreenda onde seu sistema se encaixa.
26. Build on what exists. Prepare for what is next.
A mensagem central da imagem pode ser resumida em uma frase:
“Construa sobre o que já existe. Prepare-se para o que virá.”
Essa frase descreve uma modernização pragmática.
Não se trata de preservar tudo para sempre.
Também não se trata de destruir tudo imediatamente.
Trata-se de avaliar cada workload com inteligência.
Algumas aplicações serão mantidas.
Outras serão integradas.
Algumas VMs serão migradas.
Outras aplicações serão containerizadas.
Certos sistemas serão reescritos.
Outros continuarão no mainframe.
Alguns dados serão movidos.
Outros permanecerão onde estão e serão acessados por APIs.
A arquitetura ideal não nasce de uma ideologia tecnológica.
Ela nasce das necessidades do negócio.
27. The Messy Middle não é temporário
Talvez a maior revelação seja esta:
O Messy Middle pode durar muitos anos.
Algumas empresas talvez nunca cheguem a um ambiente completamente homogêneo.
E tudo bem.
Grandes organizações são complexas porque seus negócios são complexos.
Aquisições trazem novos sistemas.
Regulações exigem controles diferentes.
Aplicações possuem ciclos distintos.
Departamentos têm prioridades diferentes.
Tecnologias evoluem em velocidades diferentes.
Quando uma empresa termina uma migração, outra tecnologia já apareceu.
Portanto, o objetivo não deve ser eliminar toda diversidade.
Deve ser criar coordenação.
A imagem mostra a passagem de:
Legacy & Fragmented
para:
Modern & Coordinated
Observe que ela não diz “moderno e uniforme”.
Ela diz “moderno e coordenado”.
Essa diferença é crucial.
Uma empresa pode ter mainframe, VMs, containers e nuvem.
O problema não é a diversidade.
O problema é a falta de coordenação.
28. A lição final para o Padawan
No mainframe, aprendemos que sistemas críticos não podem depender de improviso.
Eles precisam de:
padrões;
governança;
segurança;
disponibilidade;
recuperação;
controle;
capacidade;
observabilidade.
O mundo cloud native começou valorizando velocidade e flexibilidade.
Agora ele está redescobrindo muitas das disciplinas que o mainframe pratica há décadas.
IBM Fusion e OpenShift representam uma tentativa de unir esses mundos.
De um lado:
a estabilidade;
a governança;
os dados corporativos;
os sistemas existentes.
Do outro:
a automação;
os containers;
a agilidade;
a inteligência artificial;
as novas experiências digitais.
No centro está o Messy Middle.
Não como um defeito a ser escondido.
Mas como o verdadeiro ambiente operacional da empresa moderna.
Conclusão
A modernização corporativa não é uma caminhada limpa do legado até a nuvem.
Ela é uma longa convivência entre tecnologias, equipes, dados, riscos e objetivos diferentes.
Máquinas virtuais continuam importantes.
Containers continuam crescendo.
O IBM Z continua sustentando processos críticos.
A inteligência artificial depende de dados confiáveis.
A segurança exige controle.
As equipes de aplicação desejam velocidade.
A infraestrutura precisa reduzir custos e complexidade.
IBM Fusion surge como uma proposta para organizar essa convivência, oferecendo duas abordagens: Fusion Software, aproveitando infraestrutura existente, e Fusion HCI, fornecendo uma base integrada de hardware e software.
Red Hat OpenShift atua como plataforma central.
OpenShift Virtualization aproxima VMs e containers.
IBM Storage Scale e Ceph fornecem serviços de dados em escala.
Content Aware Storage ajuda a transformar documentos e conteúdo não estruturado em conhecimento utilizável.
O IBM Z permanece como fonte confiável de processamento, transações e dados críticos, conectado ao mundo moderno por APIs, eventos, MQ, z/OS Connect e outras tecnologias.
A grande pergunta não é:
“Quando tudo estará em Kubernetes?”
A grande pergunta é:
“Onde a aplicação está sob pressão, onde o dado está preso e onde a complexidade está impedindo o negócio de avançar?”
É nesses pontos que a modernização deve começar.
Porque o futuro não será construído apenas substituindo o passado.
Ele será construído conectando o que já existe, organizando o presente e preparando a empresa para aquilo que ainda está por vir.
E o programador COBOL Padawan que compreender esse cenário deixará de ser apenas o guardião de programas antigos.
Ele se tornará uma das pontes mais importantes entre o sistema que mantém o mundo funcionando e a plataforma que ajudará a construir o próximo capítulo da computação corporativa.
