Bellacosa Mainframe e o cemiterio dos Buzzwords

☕ Um Café no Bellacosa Mainframe

Capítulo 11 — O Cemitério dos Buzzwords

Enquanto Enterravam o Mainframe, os Modismos É que Foram Desaparecendo

Uma viagem bem-humorada pelos grandes modismos da indústria de TI que, em diferentes épocas, prometeram substituir completamente o mainframe, mas acabaram tornando-se apenas mais um capítulo da história da computação.

Por Vagner Bellacosa

Client/Server, Downsizing, Rightsizing, Cloud, Blockchain, Metaverso e outros modismos passaram. O IBM Mainframe continuou evoluindo e integrando cada uma dessas tecnologias.

"Na Tecnologia da Informação existem duas certezas: sempre surgirá um novo buzzword e alguém dirá que ele acabará com tudo o que veio antes."

— Bellacosa Mainframe

O ciclo dos buzzwords

Ao longo das últimas décadas, diversos conceitos ganharam enorme popularidade: Client/Server, Downsizing, Rightsizing, SOA, BPM, Virtualização, Cloud Computing, Containers, Blockchain, Metaverso e, mais recentemente, Inteligência Artificial.

Todos trouxeram contribuições importantes para a indústria. O erro não foi sua existência, mas a crença recorrente de que cada novidade eliminaria completamente tudo o que existia antes.

A estratégia vencedora

Enquanto o mercado frequentemente falava em substituição, o ecossistema IBM Z seguiu outro caminho: integração. Linux, Java, APIs REST, containers, OpenShift, Git, DevOps, Ansible, watsonx e IA passaram a conviver naturalmente com COBOL, CICS, Db2 e z/OS.

A grande lição

A História mostra que tecnologias realmente bem-sucedidas raramente eliminam completamente as anteriores. Elas evoluem, coexistem e se integram para resolver problemas de negócio de forma cada vez mais eficiente.

---

Bellacosa Mainframe e o museu da computação

Bem-vindo ao Museu da Computação

Imagine que exista um enorme museu.

Não um museu de computadores.

Um museu de previsões.

Cada sala possui um cartaz.

Um slogan.

Uma promessa.

Uma tecnologia revolucionária.

Ao lado...

Uma frase.

"Agora o Mainframe acabou de verdade."

Você entra na primeira sala.

Depois na segunda.

Na terceira.

Na décima.

Na vigésima.

E começa a perceber um padrão curioso.

Os nomes mudam.

A promessa continua exatamente a mesma.

---

Sala 1 — Client/Server

Ano: 1990.

A promessa:

"Agora tudo ficará distribuído."

O que realmente aconteceu?

Sim.

Aplicações distribuídas conquistaram o mercado.

Mas os grandes sistemas transacionais continuaram centralizados.

Hoje praticamente toda grande empresa utiliza ambos.

Resultado:

✔ Client/Server venceu.

✔ Mainframe também.

Empate por integração.

---

Sala 2 — RISC vai acabar com CISC

Ano: 1992.

Naquela época parecia que a arquitetura RISC resolveria todos os problemas da computação.

PowerPC.

SPARC.

MIPS.

Alpha.

PA-RISC.

Cada fabricante prometia o mesmo.

Mais desempenho.

Mais simplicidade.

Mais futuro.

Enquanto isso...

Os engenheiros da IBM continuavam evoluindo a arquitetura do mainframe.

Resultado?

RISC tornou-se extremamente importante.

Mas o IBM Z continuou evoluindo em paralelo.

Mais uma previsão que confundiu inovação com substituição.

---

Sala 3 — Windows NT dominará os datacenters

Quem viveu os anos 90 certamente se lembra.

Windows NT era apresentado como o sucessor natural dos grandes sistemas.

O marketing era gigantesco.

As demonstrações impressionavam.

As revistas adoravam.

O problema apareceu alguns anos depois.

Administrar milhares de servidores individuais revelou-se muito mais complexo do que muitos imaginavam.

Windows NT tornou-se uma plataforma importante.

Mas nunca substituiu o processamento crítico realizado pelos grandes sistemas corporativos.

---

Sala 4 — Java vai matar COBOL

Essa talvez seja uma das histórias mais divertidas.

Final da década de 1990.

Java dominava as conferências.

A frase mais comum era:

"Agora ninguém mais escreverá COBOL."

A IBM respondeu de maneira extremamente elegante.

Colocou Java dentro do mainframe.

Em vez de lutar contra Java...

Resolveu executá-lo.

Hoje Java e COBOL convivem naturalmente no IBM Z.

Mais uma vez...

Integração venceu.

---

Sala 5 — ERP elimina sistemas legados

Lembra dessa?

Bastaria instalar um grande ERP.

Pronto.

Todos os sistemas antigos desapareceriam.

Na prática...

Milhares de empresas descobriram que seus diferenciais competitivos estavam justamente naqueles sistemas chamados de "legado".

Resultado.

Os ERPs foram integrados aos sistemas existentes.

Não o contrário.

---

Sala 6 — SOA vai reescrever tudo

No início dos anos 2000 surgiu outro grande entusiasmo.

SOA.

Service-Oriented Architecture.

A promessa parecia familiar.

Tudo seria reescrito como serviços.

O que aconteceu?

Os serviços realmente apareceram.

Mas muitos deles passaram simplesmente a chamar programas COBOL já existentes.

CICS ganhou Web Services.

Depois REST.

Depois APIs modernas.

Mais uma vez...

O velho código apenas ganhou uma nova porta de entrada.

---

Sala 7 — Cloud vai acabar com os Datacenters

Essa previsão ainda aparece de tempos em tempos.

Segundo muitos especialistas...

Tudo iria para a nuvem.

Os datacenters desapareceriam.

Chegamos a 2026.

O que vemos?

Cloud.

Cloud híbrida.

Cloud privada.

Edge Computing.

IBM Z.

LinuxONE.

Todos convivendo.

A realidade novamente preferiu integração.

---

Sala 8 — Blockchain vai substituir bancos

Lembra de 2018?

Tudo seria Blockchain.

Contratos.

Documentos.

Identidade.

Cartórios.

Pagamentos.

Governos.

Algumas aplicações realmente prosperaram.

Outras desapareceram.

Os bancos?

Continuaram utilizando COBOL.

Db2.

CICS.

Mainframe.

E, curiosamente, várias soluções Blockchain passaram a integrar sistemas tradicionais.

---

Sala 9 — O Metaverso Corporativo

Talvez um dos buzzwords mais efêmeros.

Por algum tempo parecia que todas as reuniões aconteceriam em ambientes virtuais tridimensionais.

Empresas correram.

Investidores também.

Hoje...

As videoconferências continuam dominando.

O metaverso encontrou nichos específicos, mas não substituiu a forma como o mercado corporativo trabalha.

Mais uma previsão grandiosa que encontrou uma realidade bem mais pragmática.

---

Sala 10 — A Inteligência Artificial substituirá todos os programadores

Chegamos ao presente.

Agora o discurso mudou novamente.

A manchete da vez é:

"A IA escreverá todo o código."

Será?

A IA certamente mudou a forma como desenvolvemos software.

Produz documentação.

Sugere algoritmos.

Explica código.

Auxilia em testes.

Aumenta produtividade.

Mas alguém ainda precisa:

Entender o negócio.

Projetar arquitetura.

Validar regras.

Garantir segurança.

Tomar decisões.

Assim como aconteceu em 1990...

Existe uma enorme diferença entre automatizar tarefas e substituir conhecimento.

---

O padrão finalmente aparece

Observe todas essas previsões.

Client/Server.

RISC.

Windows NT.

Java.

ERP.

SOA.

Cloud.

Blockchain.

Metaverso.

IA.

Todas seguem praticamente o mesmo roteiro.

Primeiro aparece uma inovação verdadeira.

Depois surgem expectativas enormes.

Em seguida alguém anuncia:

"Agora acabou para o Mainframe."

Alguns anos passam.

A inovação permanece.

O Mainframe também.

---

A maior ironia de todas

Enquanto dezenas de tecnologias tentavam substituir o IBM Mainframe...

O IBM Mainframe fazia exatamente o contrário.

Incorporava cada uma delas.

Linux?

Venha.

Java?

Pode entrar.

REST?

Sem problema.

Containers?

Ótimo.

OpenShift?

Também.

Git?

Claro.

Python?

Bem-vindo.

Ansible?

Excelente.

Inteligência Artificial?

Vamos integrar.

Essa talvez seja a característica mais impressionante da plataforma IBM Z.

Ela raramente rejeita uma inovação.

Ela procura descobrir como utilizá-la.

---

O Padawan visita o cemitério

Nosso Padawan encontra um enorme portão.

Na entrada está escrito:

Cemitério dos Buzzwords

Ele começa a caminhar.

Primeira lápide.

"Client/Server substituirá tudo."

Segunda.

"COBOL acabou."

Terceira.

"O último mainframe será desligado."

Quarta.

"Cloud elimina os datacenters."

Quinta.

"IA elimina os programadores."

Ele continua andando.

Chega ao final do cemitério.

Olha para trás.

Percebe algo curioso.

Nenhuma lápide pertence ao IBM Mainframe.

Então escuta uma voz.

É o velho mestre.

— Está vendo?

— O quê?

— Buzzwords normalmente têm prazo de validade.

Arquiteturas bem projetadas costumam durar muito mais.

---

O segredo nunca foi resistir

Existe uma ideia equivocada.

Algumas pessoas imaginam que o IBM Mainframe sobreviveu porque resistiu às mudanças.

Não.

Ele sobreviveu justamente porque mudou.

Muito.

O System/360 de 1964 é completamente diferente do IBM z17 de 2026.

Mudaram:

Processadores.

Memória.

Compiladores.

Linguagens.

Virtualização.

Ferramentas.

Integração.

Observabilidade.

Automação.

DevOps.

Cloud.

IA.

O que permaneceu foi a filosofia.

Compatibilidade.

Disponibilidade.

Confiabilidade.

Escalabilidade.

---

O verdadeiro "dinossauro"

No primeiro capítulo vimos o mainframe ser chamado de dinossauro.

Chegamos agora ao final desta jornada.

E talvez possamos fazer uma pergunta provocativa.

Quem realmente envelheceu mal?

O IBM Mainframe?

Ou a ideia de que toda tecnologia nova precisa destruir completamente a anterior?

Porque o z17 continua evoluindo.

O COBOL continua recebendo novos recursos.

O Db2 continua inovando.

O CICS continua processando bilhões de transações.

O z/OS continua sendo atualizado.

Muitos dos buzzwords que prometeram acabar com eles...

Hoje aparecem apenas em livros de História da Computação.

---

A última aula para o Padawan

Sempre que surgir um novo modismo...

Não pergunte:

"Isso vai matar o Mainframe?"

Pergunte:

"Como o Mainframe vai incorporar isso?"

Essa pergunta possui muito mais chances de acertar o futuro.

Foi assim com:

Internet.

Java.

Linux.

Web Services.

Open Source.

Containers.

Cloud.

OpenShift.

DevOps.

E agora...

Inteligência Artificial.

Talvez a maior habilidade do IBM Mainframe nunca tenha sido processar bilhões de transações.

Sua maior habilidade foi outra.

Aprender continuamente sem abandonar aquilo que já funcionava.

Essa é uma lição que vale não apenas para computadores.

Vale também para arquitetos.

Para desenvolvedores.

Para empresas.

E, principalmente, para cada novo Padawan COBOL que inicia sua jornada.

Porque buzzwords vêm e vão.

Mas engenharia bem construída continua escrevendo a História.

Bellacosa Mainframe e o Funeral que nunca aconteceu

C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML

★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS

[ CAPÍTULOS ] [ SOBRE A SÉRIE ] [ BELLACOSA MAINFRAME ]

▼ DIRETÓRIO DE CAPÍTULOS ▼

CAPÍTULO 01 O Funeral que Nunca Aconteceu ABRIR CAPÍTULO 01 ↗	CAPÍTULO 02 A Década dos Buzzwords ABRIR CAPÍTULO 02 ↗
CAPÍTULO 03 O Professor que Arquivou o Funeral ABRIR CAPÍTULO 03 ↗	CAPÍTULO 04 Forbes (1989) ABRIR CAPÍTULO 04 ↗
CAPÍTULO 05 The New York Times (1989) ABRIR CAPÍTULO 05 ↗	CAPÍTULO 06 InfoWorld (1991) ABRIR CAPÍTULO 06 ↗
CAPÍTULO 07 The New York Times (1993) ABRIR CAPÍTULO 07 ↗	CAPÍTULO 08 Business Week (1994) ABRIR CAPÍTULO 08 ↗
CAPÍTULO 09 O Que Realmente Aconteceu ABRIR CAPÍTULO 09 ↗	CAPÍTULO 10 Por Que Tantas Previsões Erraram? ABRIR CAPÍTULO 10 ↗
CAPÍTULO 11 O Cemitério dos Buzzwords ABRIR CAPÍTULO 11 ↗	CAPÍTULO 12 O Legado dos Profetas e a Grande Lição para 2026 ABRIR CAPÍTULO 12 ↗
CAPÍTULO 13 Os Profetas da IA e o Próximo Funeral ABRIR CAPÍTULO 13 ↗	CAPÍTULO 14 — FINAL O Julgamento da História ABRIR CAPÍTULO FINAL ↗

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

 

Bellacosa Mainframe e o bug do milenio y2k

☕🔥 BUG DO MILÊNIO (Y2K) — O DIA EM QUE O MUNDO DESCOBRIU QUE O FUTURO CABIA EM 2 DÍGITOS

Uma visão 10 anos depois

O Bug do Milênio não foi apenas um problema técnico.

Foi:

• um choque filosófico,

• um terremoto econômico,

• uma guerra entre gerações tecnológicas,

• um divisor entre o mundo centralizado dos mainframes e o mundo distribuído dos PCs,

• e talvez o maior projeto coletivo da história da computação.

O mais fascinante?

O problema foi previsto em 1958.
E ignorado por quase 40 anos.

---

☕ COMO TUDO COMEÇOU

O mundo em 1958

Em 1958:

• COBOL ainda estava nascendo,

• memória era absurdamente cara,

• armazenamento era microscópico,

• computadores ocupavam salas inteiras,

• e cada byte economizado importava.

Um IBM 1401 tinha:

• cerca de 2 KB de memória.

DOIS KILOBYTES.

Hoje uma foto de WhatsApp é milhões de vezes maior.

---

☕ O PECADO ORIGINAL DA COMPUTAÇÃO CORPORATIVA

Datas eram gravadas assim:

Data Real	Gravado
1962	62
1975	75
1989	89

Por quê?

Porque:

• economizava espaço,

• reduzia custo,

• diminuía I/O,

• cabia nos cartões perfurados,

• acelerava processamento.

Num cartão de 80 colunas:

• dois bytes eram preciosos.

---

☕ BOB BEMER — O “PROFETA IGNORADO”

Bob Bemer, da IBM:

• percebeu imediatamente o risco,

• tentou alertar:

  • IBM,

  • ISO,

  • governos,

  • programadores.

Ele basicamente dizia:

“Um dia 99 vai virar 00.”

Mas ninguém queria ouvir.

Porque em 1958:

• o ano 2000 parecia ficção científica.

---

☕ O PROBLEMA REAL NÃO ERA A DATA

Aqui está o detalhe profundo que muita gente não entende:

O problema NÃO era “mostrar 00”.

O problema era:

☕ LÓGICA DE NEGÓCIO

Exemplo:

Data
991228
000105

O sistema comparava numericamente:

IF DT-PAGAMENTO > DT-VENCIMENTO

E então:

000105 < 991228

O computador concluía:

“2000 aconteceu ANTES de 1999.”

E isso quebrava:

• juros,

• seguros,

• aposentadorias,

• vencimentos,

• cálculo atuarial,

• bolsas,

• bancos,

• aviação,

• energia,

• telecom.

---

☕ O VERDADEIRO PÂNICO

O medo nunca foi:

• “o computador mostrar data errada”.

O medo era:

☠️ EFEITO CASCATA

Porque sistemas estavam interligados.

Um erro de data poderia:

• invalidar transações,

• gerar loop infinito,

• corromper arquivos,

• travar batch noturno,

• derrubar compensação bancária,

• falhar controle industrial.

---

☕ O MUNDO MAINFRAME DA ÉPOCA

Naquela época:

• bancos,

• governos,

• seguradoras,

• bolsas,

• companhias aéreas,

• telecomunicações

rodavam em:

• IBM Mainframe,

• COBOL,

• PL/I,

• Assembler,

• IMS,

• CICS,

• DB2,

• VSAM.

E quase tudo dependia de processamento batch.

---

☕ O IMPACTO DAS REDES SNA

Aqui entra um detalhe histórico gigantesco.

---

☕ SNA — SYSTEMS NETWORK ARCHITECTURE

A IBM criou o SNA nos anos 70.

Era:

• centralizado,

• hierárquico,

• controlado,

• extremamente confiável.

Paradigma SNA

Terminal → Controlador → Mainframe

Tudo girava ao redor do host.

O terminal:

• era “burro”,

• não processava quase nada.

Os famosos:

• 3270,

• 3278,

---

☕ ENTÃO CHEGA O TCP/IP

Nos anos 80 e 90:

• PCs explodem,

• redes LAN crescem,

• Unix avança,

• Internet nasce.

E surge outro paradigma:

☕ COMPUTAÇÃO DISTRIBUÍDA

Agora:

• vários servidores,

• várias aplicações,

• vários bancos,

• redes descentralizadas.

---

☕ DOWNSIZING — A GRANDE PROMESSA

No fim dos anos 80 surgiu a crença:

“Vamos abandonar mainframes.”

Isso ficou conhecido como:

☕ DOWNSIZING

Migrar:

• do grande host central,

• para servidores menores.

A promessa:

• mais barato,

• mais moderno,

• mais flexível.

---

☕ O “NOVO MUNDO”

Diziam que o futuro era:

• Clipper,

• Visual Basic,

• Delphi,

• PowerBuilder,

• Unix,

• Client/Server.

E o COBOL?
Segundo muitos:

“já estava morto”.

Só que…

---

☕ O QUE REALMENTE ACONTECEU

O downsizing funcionou:

• para sistemas periféricos,

• departamentos pequenos,

• aplicações locais.

Mas os sistemas CORE:

• continuaram no mainframe.

Porque:

• eram estáveis,

• rápidos,

• seguros,

• absurdamente escaláveis.

---

☕ RIGHTSIZING — A REALIDADE

Então nasceu o termo:

☕ RIGHTSIZING

Não era:

“tirar tudo do mainframe”.

Era:

“usar a tecnologia certa para cada carga.”

Mainframe:

• missão crítica,

• alta escala,

• transações massivas.

PC/Unix:

• interface,

• departmental,

• aplicações locais.

Esse foi o nascimento da arquitetura híbrida moderna.

---

☕ PARADIGMAS DE PROGRAMAÇÃO

O Y2K expôs uma guerra de paradigmas.

---

☕ MUNDO MAINFRAME

Paradigma:

• procedural,

• batch,

• orientado a registros,

• altíssima eficiência.

Exemplo COBOL:

READ ARQUIVO
AT END MOVE 'S' TO EOF
END-READ

Foco:

• performance,

• previsibilidade,

• I/O.

---

☕ MUNDO CLIENT/SERVER

Paradigma:

• orientado a eventos,

• GUI,

• objetos,

• interação humana.

Exemplo Visual Basic:

Private Sub Botao_Click()

---

☕ O Y2K MOSTROU ALGO BRUTAL

Sistemas “antigos”:

• ainda sustentavam o planeta.

Enquanto muita tecnologia “moderna”:

• ainda era imatura.

---

☕ O PASSO A PASSO DO CAOS

1. Anos 60–70

Economia de bytes.

---

2. Anos 80

Primeiros sinais aparecem no mercado financeiro.

---

3. Final dos 80

Downsizing promete resolver tudo.

---

4. Início dos 90

Percebem:

• sistemas antigos NÃO serão substituídos.

---

5. 1995–1999

Pânico mundial.

---

☕ A MAIOR CORRIDA TECNOLÓGICA DA HISTÓRIA

Empresas:

• contratavam qualquer programador COBOL disponível,

• aposentados voltaram ao mercado,

• havia guerra salarial,

• consultorias disputavam profissionais.

Foi literalmente:

• mobilização global.

---

☕ AS DUAS GRANDES SOLUÇÕES

---

☕ 1. EXPANSÃO

Transformar:

AAMMDD

em:

AAAAMMDD

Problema:

• quebra layout,

• muda tamanho de registro,

• afeta VSAM,

• afeta copybooks,

• afeta interfaces,

• afeta rede,

• afeta banco.

Era cirurgia cardíaca em avião voando.

---

☕ 2. JANELAMENTO (WINDOWING)

A solução “esperta”.

Usava:

• ano pivot.

Exemplo:

• pivot = 40.

Então:

• 39 = 2039,

• 41 = 1941.

---

☕ EXEMPLO REAL COBOL

Original:

IF DT-PAGAMENTO > DT-VENCIMENTO

Corrigido:

CALL 'JANELAMENTO'

Convertendo temporariamente:

• para AAAAMMDD.

---

☕ EASTER EGG HISTÓRICO

Muitos sistemas:

• escolheram pivot 2040.

Resultado?

O problema foi apenas EMPURRADO.

Ou seja:

☕ O BUG DO MILÊNIO AINDA EXISTE

Só está dormindo.

---

☕ Y2K38 — O PRÓXIMO FANTASMA

Unix usa:

• segundos desde 01/01/1970.

Em 32 bits:

• isso estoura em 2038.

Ou seja:

• outra bomba relógio histórica.

---

☕ IMPACTO NO MUNDO INFORMÁTICO

O Y2K mudou tudo.

---

☕ 1. GOVERNANÇA DE TI

Nasce:

• inventário de sistemas,

• gestão de dependência,

• análise de impacto.

---

☕ 2. TESTES CORPORATIVOS

Antes:

• quase ninguém fazia testes massivos integrados.

Depois do Y2K:

• virou obrigatório.

---

☕ 3. DOCUMENTAÇÃO

Empresas descobriram:

• ninguém sabia tudo que existia.

---

☕ 4. O COBOL SOBREVIVEU

E mais:

provou ser resiliente.

---

☕ 5. MAINFRAME SOBREVIVEU AO FUNERAL

O mundo percebeu:

substituir sistema crítico é MUITO mais difícil do que vender PowerPoint.

---

☕ A MAIOR LIÇÃO DO Y2K

O problema nunca foi técnico.

Foi:

• humano,

• econômico,

• político,

• organizacional.

Porque:

• TODOS sabiam do problema,

• durante QUARENTA anos.

E ninguém quis pagar a conta antes.

---

☕ CONCLUSÃO

O Bug do Milênio:

• não foi um bug simples,

• foi um retrato da evolução da computação.

Ele revelou:

• limitações do hardware,

• mudanças de paradigma,

• disputa entre arquiteturas,

• arrogância tecnológica,

• dependência de legado,

• e a incrível resistência dos sistemas mainframe.

E talvez a maior ironia da história seja esta:

Os sistemas que “iriam morrer”…
foram justamente os que salvaram o mundo da crise.

 

Bellacosa Mainframe e o que é rightsize

O que é Rightsizing?

Imagine que uma empresa possui um grande ambiente IBM Mainframe.

Durante muitos anos, era comum ouvir duas propostas completamente opostas:

• "Coloque tudo no Mainframe."

• "Tire tudo do Mainframe."

Com o tempo, as empresas perceberam que nenhuma dessas estratégias era perfeita.

Então surgiu uma terceira abordagem:

Coloque cada aplicação na plataforma onde ela funciona melhor.

Essa filosofia é chamada de Rightsizing.

Hoje ela é considerada uma das estratégias mais inteligentes para arquiteturas corporativas.

---

Definição simples

Rightsizing é a prática de escolher a plataforma mais adequada para cada aplicação ou carga de trabalho, considerando fatores como desempenho, custo, segurança, disponibilidade e facilidade de manutenção.

Em outras palavras:

Rightsizing significa utilizar o recurso certo para o trabalho certo.

---

Origem da palavra

A palavra inglesa é formada por:

• Right = correto

• Sizing = dimensionamento

Ou seja:

Dimensionamento correto.

Não significa diminuir nem aumentar.

Significa encontrar o tamanho e a plataforma ideais.

---

Uma analogia simples

Imagine uma empresa de transporte.

Ela possui:

• motocicletas;

• carros;

• caminhões;

• navios;

• aviões.

Seria inteligente usar um caminhão para entregar uma pizza?

Claro que não.

Também não faria sentido transportar centenas de toneladas em uma motocicleta.

Cada veículo possui sua finalidade.

O Rightsizing aplica exatamente esse princípio à tecnologia.

---

Como funciona?

Em vez de perguntar:

"Mainframe ou Cloud?"

Pergunta-se:

"Qual plataforma resolve melhor este problema?"

---

Exemplo

Uma empresa possui três sistemas.

Sistema Bancário

• milhões de transações;

• alta disponibilidade;

• segurança crítica.

Melhor escolha:

IBM Z Mainframe

---

Portal Institucional

• páginas web;

• marketing;

• notícias.

Melhor escolha:

Cloud

---

Inteligência Artificial

• treinamento de modelos;

• processamento paralelo.

Melhor escolha:

GPU na nuvem

---

Cada sistema utiliza a plataforma mais adequada.

---

Antes do Rightsizing

Durante muitos anos o pensamento era:

Tudo no Mainframe

Depois veio:

Tudo na Cloud

Hoje:

Mainframe

↓

Cloud

↓

Containers

↓

Linux

↓

Windows

↓

IBM Z

↓

GPU

↓

Cada aplicação onde faz mais sentido

---

Critérios utilizados

O analista avalia diversos fatores.

Desempenho

Onde o sistema executa melhor?

---

Segurança

Qual plataforma oferece menor risco?

---

Custos

Qual possui menor custo total?

Não apenas aquisição.

Mas:

• manutenção;

• energia;

• licenciamento;

• operação.

---

Disponibilidade

Qual suporta funcionar 24x7?

---

Escalabilidade

Precisa crescer rapidamente?

---

Regulamentação

Alguns dados precisam permanecer em ambiente controlado.

---

Tempo de resposta

Aplicações críticas podem exigir poucos milissegundos.

---

No Mainframe

O Rightsizing normalmente mantém no IBM Z:

• contas correntes;

• cartões;

• PIX;

• folha;

• seguros;

• compensação bancária;

• processamento financeiro.

Enquanto move para outras plataformas:

• portais web;

• aplicativos móveis;

• dashboards;

• IA;

• analytics;

• sites institucionais.

---

Exemplo completo

Aplicativo Android

↓

API Gateway

↓

z/OS Connect

↓

COBOL

↓

Db2

Enquanto:

Portal Web

↓

Cloud

↓

Kubernetes

↓

Java

↓

MongoDB

Cada sistema onde produz melhores resultados.

---

Rightsizing x Downsizing

Downsizing

Objetivo:

Substituir o Mainframe.

IBM Z

↓

Linux

---

Rightsizing

Objetivo:

Utilizar ambos.

IBM Z

↓

Cloud

↓

Linux

↓

Containers

↓

APIs

É uma estratégia de convivência.

---

Rightsizing x Upsizing

Existe também o contrário.

Quando uma empresa percebe que servidores distribuídos já não atendem mais.

Então migra determinadas cargas para plataformas maiores.

Isso é chamado por alguns autores de Upsizing.

---

Vantagens

• melhor desempenho;

• menor custo operacional;

• maior flexibilidade;

• alta disponibilidade;

• arquitetura híbrida;

• modernização gradual;

• menor risco.

---

Desvantagens

Também existem desafios.

• integração entre ambientes;

• múltiplas tecnologias;

• monitoramento mais complexo;

• necessidade de profissionais especializados.

---

Curiosidades

1. O Rightsizing substituiu o debate "Mainframe versus Cloud"

Hoje as grandes empresas não escolhem apenas uma plataforma. Elas combinam Mainframe, nuvem e servidores distribuídos de acordo com a necessidade.

---

2. IBM utiliza fortemente essa estratégia

O IBM Z foi projetado para operar em ambientes híbridos, integrando-se a Linux on Z, OpenShift, APIs REST, containers e nuvens públicas.

---

3. Bancos são grandes usuários

É comum encontrar:

• COBOL no Mainframe;

• Java em Linux;

• APIs em Kubernetes;

• Analytics na Cloud;

• IA utilizando GPUs.

Tudo funcionando em conjunto.

---

4. Rightsizing reduz riscos

Em vez de reescrever sistemas críticos, a empresa preserva o que funciona bem e moderniza apenas os componentes que realmente precisam evoluir.

---

Erros comuns de iniciantes

"Rightsizing significa reduzir servidores"

Não.

Ele significa escolher a plataforma mais adequada, que pode ser maior, menor ou igual à atual.

---

"Tudo deve ir para a Cloud"

Nem sempre.

Muitas cargas críticas continuam apresentando melhor desempenho e maior confiabilidade no Mainframe.

---

"Mainframe impede Rightsizing"

Pelo contrário.

O IBM Z moderno foi projetado para operar integrado com APIs REST, microsserviços, Linux, OpenShift e computação em nuvem.

---

Quando estudar Rightsizing?

Depois de aprender:

1. Arquitetura de Computadores.

2. Mainframe.

3. Sistemas Distribuídos.

4. Cloud Computing.

5. APIs REST.

6. Containers.

7. Kubernetes.

8. Engenharia de Software.

9. Modernização de Aplicações.

10. Arquiteturas Híbridas.

Assim você compreenderá como as empresas tomam decisões estratégicas sobre onde executar cada aplicação.

---

Rightsizing na prática

Imagine uma instituição financeira com dezenas de sistemas. Em vez de iniciar um projeto caro para migrar tudo para a nuvem ou concentrar tudo no Mainframe, ela analisa cada aplicação individualmente:

• O sistema de compensação bancária permanece no IBM Z devido ao alto volume de transações e à confiabilidade.

• O portal de atendimento ao cliente é hospedado na nuvem para facilitar escalabilidade.

• A análise de fraudes utiliza serviços de Inteligência Artificial com GPUs.

• As aplicações móveis acessam os sistemas centrais por meio de APIs.

O resultado é uma arquitetura equilibrada, onde cada componente utiliza a plataforma mais eficiente para sua função.

---

Conclusão

O Rightsizing é uma estratégia de arquitetura que busca colocar cada aplicação no ambiente mais adequado, equilibrando desempenho, custo, segurança, disponibilidade e facilidade de manutenção. Diferentemente do Downsizing, que propõe substituir o Mainframe, o Rightsizing valoriza uma visão pragmática: manter o que funciona bem e modernizar apenas onde isso traz benefícios reais.

No cenário atual, dominado por arquiteturas híbridas, APIs, nuvem, containers e Inteligência Artificial, o Rightsizing tornou-se uma das principais abordagens para empresas que desejam evoluir seus sistemas sem abrir mão da estabilidade e da confiabilidade do IBM Z. Para um Analista Mainframe, compreender esse conceito é essencial para participar das decisões estratégicas de modernização e transformação digital.