☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta gestão. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta gestão. Mostrar todas as mensagens

terça-feira, 3 de maio de 2022

Genjitsu Shugi Yuusha no Oukoku Saikenki – Segunda Temporada Quando Reconstruir um Reino é Apenas o Primeiro Passo. Agora é Hora de Mantê-lo Funcionando.

 

Bellacosa Mainframe e a segunda temporada de genitsu shugi yuusga

☕ Um Café no Bellacosa Mainframe

Genjitsu Shugi Yuusha no Oukoku Saikenki – Segunda Temporada

Quando Reconstruir um Reino é Apenas o Primeiro Passo. Agora é Hora de Mantê-lo Funcionando.

"Construir um sistema é difícil. Mantê-lo disponível 24 horas por dia, durante décadas, é o verdadeiro desafio. A segunda temporada mostra exatamente essa diferença."


Ficha Técnica

ItemInformação
Título Original現実主義勇者の王国再建記 第二部 (Genjitsu Shugi Yuusha no Oukoku Saikenki Daini-bu)
Título InternacionalHow a Realist Hero Rebuilt the Kingdom – Part 2
Obra OriginalLight Novel de Dojyomaru
IlustraçõesFuyuyuki
EstúdioJ.C.Staff
DiretorTakashi Watanabe
ExibiçãoJaneiro a abril de 2022
Episódios13
Total da série26 episódios
DuraçãoAproximadamente 24 minutos por episódio
GêneroIsekai, Fantasia, Política, Administração, Romance, Estratégia, Aventura
Classificação Indicativa14 anos

Introdução

A primeira temporada mostrou como recuperar um reino em crise.

A segunda responde uma pergunta muito mais interessante:

Como manter um governo funcionando quando todos esperam resultados?

Agora Souma não é mais um administrador improvisado.

Ele é oficialmente o rei.

Isso muda tudo.

Os problemas deixam de ser internos.

Agora surgem conflitos internacionais, diplomacia, espionagem, alianças militares e equilíbrio econômico entre nações.

É exatamente a diferença entre implantar um novo sistema e administrar um ambiente IBM Z em produção.


Sinopse

Após estabilizar Elfrieden, Kazuya Souma precisa consolidar suas reformas enquanto enfrenta ameaças externas, negociações diplomáticas e disputas entre reinos. Ao mesmo tempo, fortalece alianças, amplia sua equipe e conduz mudanças capazes de transformar o equilíbrio político do continente.


Resumo

A segunda temporada amplia o mundo.

Enquanto a primeira era quase totalmente administrativa, esta passa a explorar:

  • relações internacionais;

  • economia continental;

  • inteligência militar;

  • sucessão política;

  • comércio;

  • casamentos diplomáticos;

  • alianças estratégicas;

  • expansão territorial.

O reino cresce.

E seus problemas também.


A História

Governar nunca foi apenas administrar dinheiro.

É administrar pessoas.

Na segunda temporada aparecem desafios como:

  • negociar sem demonstrar fraqueza;

  • evitar guerras desnecessárias;

  • proteger fronteiras;

  • integrar novos territórios;

  • administrar culturas diferentes;

  • preparar sucessores.

O foco deixa de ser "salvar um reino".

Agora é construir uma potência estável.


O Estúdio J.C.Staff

A J.C.Staff manteve a identidade da primeira temporada.

Não houve mudança significativa no estilo artístico.

O ritmo continua baseado em:

  • diálogos;

  • planejamento;

  • política;

  • desenvolvimento de personagens.

As batalhas continuam existindo.

Mas nunca são o centro da narrativa.


Os Personagens

Kazuya Souma

Evolui de administrador para estadista.

Aprende que liderar significa equilibrar interesses conflitantes.


Liscia Elfrieden

Assume papel muito mais ativo.

Participa das decisões de governo.

Mostra crescimento político.


Hakuya Kwonmin

Continua sendo o cérebro estratégico.

Praticamente um Primeiro-Ministro.

Sua capacidade analítica cresce ainda mais.


Aisha Udgard

Permanece como principal força militar.

Sua lealdade representa estabilidade institucional.


Juna Doma

Sua influência diplomática aumenta.

Atua em inteligência e comunicação.


Roroa Amidonia

Rouba diversas cenas.

Sua visão econômica demonstra que mercados podem ser tão importantes quanto exércitos.


Novos líderes e diplomatas

A segunda temporada amplia o elenco.

Cada governante representa um modelo diferente de liderança.


O Grande Diferencial

Na maioria dos isekais:

vencer o inimigo encerra a história.

Aqui...

É apenas o começo.

O foco está em:

  • consolidar instituições;

  • fortalecer economia;

  • administrar alianças;

  • evitar guerras;

  • desenvolver infraestrutura;

  • manter estabilidade.

É uma abordagem extremamente rara.


As Aventuras

Embora existam conflitos militares, o verdadeiro desafio acontece nas mesas de negociação.

Souma enfrenta:

  • conflitos diplomáticos;

  • casamentos políticos;

  • rebeliões;

  • anexações;

  • espionagem;

  • comércio internacional;

  • reformas administrativas;

  • planejamento militar.

Cada decisão produz consequências de longo prazo.


Temática

A segunda temporada trata principalmente de:

Governança

Não basta conquistar.

É preciso administrar.


Liderança

Grandes líderes desenvolvem novos líderes.


Economia

Dinheiro movimenta impérios.


Diplomacia

Uma guerra evitada vale mais que uma guerra vencida.


Planejamento

Toda decisão produz efeitos futuros.


Instituições

Pessoas passam.

As instituições permanecem.


As Mensagens Ocultas

1. Bons líderes formam sucessores

O protagonista distribui responsabilidades.

Não centraliza poder.


2. Especialistas fazem diferença

Cada ministro domina sua área.

Nenhum tenta saber tudo.


3. Informação reduz riscos

Espionagem.

Inteligência.

Análise.

Tudo baseado em dados.


4. Prosperidade reduz conflitos

Quanto melhor a economia...

Menor a necessidade de guerra.


5. Cooperação vence competição

Alianças duram mais do que conquistas militares.


6. A estabilidade é invisível

Quando tudo funciona...

Poucos percebem o esforço necessário.

Quem trabalha com sistemas críticos conhece bem essa realidade.


O Paralelo com IBM Mainframe

Na primeira temporada, Souma era como uma equipe assumindo um ambiente legado e iniciando um programa de modernização.

Na segunda temporada, ele se parece com um CIO responsável por uma plataforma IBM Z em plena produção.

Os desafios agora incluem:

  • alta disponibilidade;

  • continuidade do negócio;

  • integração entre sistemas;

  • governança;

  • segurança;

  • expansão controlada;

  • escalabilidade;

  • planejamento de capacidade.

Trocar tudo por algo "mais moderno" deixaria o reino vulnerável. Em vez disso, Souma fortalece processos, integra novos recursos e evolui gradualmente — exatamente como ocorre em programas bem-sucedidos de modernização de mainframe.


O Que Existe de Diferente?

Poucos animes dedicam tanto tempo às consequências das decisões.

Nesta temporada:

  • não existem soluções mágicas;

  • política importa;

  • economia importa;

  • logística importa;

  • diplomacia importa;

  • planejamento importa.

É um anime onde inteligência supera força bruta.


Impacto Cultural

A segunda parte consolidou a reputação da série como uma das principais referências do subgênero "kingdom building" ou "nation building", voltado à construção e administração de reinos. Embora tenha recebido críticas pelo ritmo mais lento e pelo grande volume de diálogos políticos, foi elogiada por mostrar liderança, economia e administração pública como elementos centrais da narrativa, algo incomum entre os isekais contemporâneos.


O Que Pode Ensinar para Profissionais de Tecnologia

Para quem trabalha com IBM Mainframe, DevOps ou arquitetura corporativa, a segunda temporada apresenta lições valiosas:

  • Modernização é contínua.

  • Governança evita o caos.

  • Especialistas são ativos estratégicos.

  • Documentação reduz riscos.

  • Processos são tão importantes quanto tecnologia.

  • Escalabilidade exige planejamento.

  • Disponibilidade nasce da disciplina operacional.

  • Liderança é coordenar talentos, não centralizar decisões.


Classificação Bellacosa Mainframe

CritérioNota
História⭐⭐⭐⭐⭐ (9,6/10)
Construção do Mundo⭐⭐⭐⭐⭐ (9,8/10)
Estratégia⭐⭐⭐⭐⭐ (10/10)
Política⭐⭐⭐⭐⭐ (10/10)
Economia⭐⭐⭐⭐⭐ (10/10)
Desenvolvimento dos Personagens⭐⭐⭐⭐☆ (9,0/10)
Ação⭐⭐⭐☆☆ (7,5/10)
Gestão e Liderança⭐⭐⭐⭐⭐ (10/10)
Reassistir⭐⭐⭐⭐⭐ (9,5/10)

Nota Final Bellacosa Mainframe: 9,6/10


Conclusão

Se a primeira temporada ensina como recuperar um sistema legado, a segunda mostra como operar uma plataforma crítica em escala nacional.

A maior batalha de Kazuya Souma não é contra monstros, mas contra a complexidade inerente à gestão de pessoas, instituições e recursos. É uma metáfora poderosa para qualquer profissional de tecnologia que já precisou manter um ambiente crítico funcionando sem interrupções.

No universo Bellacosa Mainframe, a mensagem é clara: construir é um projeto; sustentar é uma disciplina. Assim como no IBM Z, o verdadeiro sucesso não está em mudanças espetaculares, mas na capacidade de evoluir continuamente sem comprometer a estabilidade. É essa visão de longo prazo que faz de Genjitsu Shugi Yuusha no Oukoku Saikenki um dos isekais mais singulares e intelectualmente estimulantes da última década.


quarta-feira, 30 de junho de 2021

Genjitsu Shugi Yuusha no Oukoku Saikenki : Quando o Herói Descobre que Governar um Reino é Mais Difícil que Derrotar um Dragão

 

Bellacosa Mainframe apresenta Genjitsu Shugi Yuusha no Oukoku Saikenki

☕ Um Café no Bellacosa Mainframe

Genjitsu Shugi Yuusha no Oukoku Saikenki

Quando o Herói Descobre que Governar um Reino é Mais Difícil que Derrotar um Dragão

"Existem animes onde o protagonista vence porque é o mais forte. E existem animes onde ele vence porque sabe administrar orçamento, logística, recursos humanos e planejamento estratégico. Este pertence ao segundo grupo."


Ficha Técnica

ItemInformação
Título Original現実主義勇者の王国再建記 (Genjitsu Shugi Yuusha no Oukoku Saikenki)
Título InternacionalHow a Realist Hero Rebuilt the Kingdom
AutorDojyomaru
IlustradorFuyuyuki
Light Novel25 de maio de 2016
Web Novel2014
EstúdioJ.C.Staff
DiretorTakashi Watanabe
Anime3 de julho de 2021
Episódios26 (2 partes)
Duração~24 minutos
GêneroIsekai, Fantasia, Política, Estratégia, Romance, Administração, Aventura
Classificação14 anos

Introdução

A maioria dos isekais segue praticamente a mesma fórmula.

Um estudante japonês morre.

Reencarna.

Recebe poderes absurdos.

Derrota o Rei Demônio.

Constrói um harém.

Fim.

Genjitsu Shugi Yuusha no Oukoku Saikenki quebra completamente essa lógica.

O protagonista não ganha uma espada lendária.

Não aprende magia suprema.

Não derrota ninguém nos primeiros episódios.

Ele faz algo muito mais perigoso.

Assume um governo quebrado.


Sinopse

Kazuya Souma é convocado para outro mundo para ser o lendário Herói.

Mas o reino não precisa exatamente de um guerreiro.

Precisa de um administrador.

Depois de analisar as contas públicas, as reservas de alimentos, as dívidas e os problemas políticos, o próprio rei conclui que Souma seria mais útil governando do que lutando.

Ele abdica.

Entrega a coroa.

Entrega sua filha em casamento.

E desaparece.

Agora um estudante universitário precisa administrar um país inteiro utilizando apenas conhecimento, lógica e planejamento. (J-Novel Club)


O Estúdio J.C.Staff

A J.C.Staff é conhecida por adaptar obras onde diálogos e desenvolvimento de personagens são tão importantes quanto a ação.

Entre seus trabalhos mais conhecidos estão:

  • Food Wars!

  • Toradora!

  • A Certain Magical Index

  • One Punch Man (2ª temporada)

  • Is It Wrong to Try to Pick Up Girls in a Dungeon?

Neste anime, o estúdio optou por privilegiar:

  • conversas políticas;

  • reuniões de gabinete;

  • diplomacia;

  • desenvolvimento econômico.

A animação não impressiona pelo espetáculo visual, mas serve muito bem ao foco narrativo. (Wikipedia)


A História

O Reino de Elfrieden enfrenta praticamente todas as crises possíveis:

  • dívida pública;

  • escassez de alimentos;

  • burocracia;

  • corrupção;

  • baixa produtividade;

  • conflitos militares;

  • pressão internacional;

  • nobres descontentes.

Enquanto todos esperam que o herói resolva isso derrotando monstros...

Souma pergunta:

"Onde estão os relatórios financeiros?"

Esse simples momento resume toda a obra.


Os Personagens

Kazuya Souma

O protagonista.

Não é um guerreiro.

É um administrador.

Seu maior poder é tomar decisões racionais.


Liscia Elfrieden

A princesa.

Inicialmente desconfia das decisões de Souma.

Depois torna-se sua maior aliada.

Representa a tradição aprendendo a conviver com inovação.


Hakuya Kwonmin

O estrategista.

Extremamente inteligente.

Praticamente o "Chief of Staff" do reino.

É impossível não lembrar de Zhuge Liang ou de um arquiteto corporativo experiente.


Aisha Udgard

General.

Leal.

Honesta.

Representa a força militar subordinada ao planejamento.


Juna Doma

Cantora.

Diplomata.

Agente de inteligência.

Uma personagem muito mais estratégica do que aparenta.


Roroa Amidonia

Provavelmente uma das personagens mais inteligentes da série.

Sua especialidade é economia.

Ela entende algo que poucos governantes entendem:

dinheiro é uma ferramenta política.


O Grande Diferencial

Este anime não é sobre magia.

É sobre gestão.

Em vez de perguntar:

"Como derrotar o dragão?"

Pergunta:

"Como alimentar cem mil pessoas?"

Em vez de:

"Como evoluir de nível?"

Pergunta:

"Como aumentar a arrecadação sem destruir a economia?"

Essa simples mudança transforma completamente a experiência.


As Aventuras

Embora pareça um anime político, há várias frentes de conflito:

  • guerras;

  • rebeliões internas;

  • negociações diplomáticas;

  • crises alimentares;

  • espionagem;

  • sucessão política;

  • alianças internacionais;

  • expansão territorial;

  • reformas administrativas.

Cada "aventuras" é menos uma jornada física e mais um desafio de governança, onde uma decisão equivocada pode custar milhares de vidas.


As Mensagens Ocultas

1. O verdadeiro herói resolve problemas.

Nem sempre usando espada.

Às vezes usando planilhas.


2. Liderança é formar equipes.

Souma nunca tenta fazer tudo sozinho.

Ele procura especialistas.

Como um bom CIO.


3. Talento é o maior recurso de um país.

Uma das primeiras ações do protagonista é realizar um enorme processo seletivo.

Isso lembra muito recrutamento corporativo.


4. Informação vale mais que força.

Antes de agir...

Ele coleta dados.

Depois decide.

É praticamente Business Intelligence medieval.


5. A economia vence guerras.

Sem recursos...

Não existe exército.

Sem alimentos...

Não existe reino.


6. Governar exige sacrificar popularidade.

Nem toda decisão correta é popular.

Essa talvez seja a maior lição da série.


A Filosofia do Anime

Embora seja um isekai, a inspiração vem de pensadores como:

  • Maquiavel

  • Sun Tzu

  • Adam Smith

  • Peter Drucker

  • Max Weber

O protagonista pensa como um administrador moderno inserido em uma monarquia medieval.


O Paralelo com IBM Mainframe

É aqui que o anime se torna surpreendentemente familiar para quem trabalha com IBM Z.

Imagine que Elfrieden é um grande banco.

Souma assume como novo CIO.

O reino possui:

  • aplicações legadas;

  • processos antigos;

  • infraestrutura crítica;

  • baixa produtividade;

  • usuários reclamando;

  • orçamento limitado.

O que ele faz?

Não reescreve tudo do zero.

Moderniza gradualmente.

Exatamente como ocorre no IBM Mainframe.

Trocar tudo seria um desastre.

Melhorar continuamente gera estabilidade.

Essa filosofia lembra diretamente ambientes z/OS:

  • mudanças controladas;

  • gestão de risco;

  • continuidade do negócio;

  • decisões baseadas em métricas;

  • evolução incremental.


O Que Existe de Diferente?

Enquanto outros isekais recompensam força...

Este recompensa competência.

Enquanto outros mostram batalhas...

Este mostra reuniões.

Enquanto outros valorizam magia...

Este valoriza conhecimento.

Enquanto outros apresentam um herói invencível...

Este apresenta um gestor eficiente.


Impacto Cultural

Embora não tenha alcançado a popularidade de gigantes como Re:Zero, Overlord ou Mushoku Tensei, a obra conquistou um público fiel justamente por oferecer uma abordagem incomum: um isekai centrado em administração, política e economia. Tornou-se referência quando fãs procuram histórias de "nation building", inspirando discussões sobre liderança, gestão pública e estratégia, além de destacar que inteligência pode ser tão decisiva quanto poder de combate. (Wikipedia)


Classificação Bellacosa Mainframe

CritérioNota
História⭐⭐⭐⭐⭐ (9,5/10)
Construção do Mundo⭐⭐⭐⭐⭐ (9,5/10)
Estratégia⭐⭐⭐⭐⭐ (10/10)
Política⭐⭐⭐⭐⭐ (10/10)
Personagens⭐⭐⭐⭐☆ (8,8/10)
Ação⭐⭐⭐☆☆ (7,0/10)
Administração⭐⭐⭐⭐⭐ (10/10)
Reassistir⭐⭐⭐⭐⭐ (9,2/10)

Nota Final Bellacosa Mainframe: 9,4/10


Conclusão

Genjitsu Shugi Yuusha no Oukoku Saikenki demonstra que a verdadeira força de um líder não está em uma espada lendária, mas na capacidade de compreender sistemas complexos, reunir pessoas talentosas e tomar decisões difíceis com visão de longo prazo. É um isekai sobre engenharia de organizações, onde governar um reino se parece muito mais com administrar um ambiente IBM Z do que com derrotar monstros.

Para quem vive o mundo do mainframe, a mensagem soa familiar: os maiores heróis raramente aparecem no campo de batalha; eles estão nos bastidores garantindo que sistemas críticos continuem funcionando, evoluindo e sustentando milhões de pessoas todos os dias.

sábado, 28 de novembro de 2020

Buzzwords sem Mistérios

 

Bellacosa Mainframe e o buzzwords sem misterios

☕ Um Café no Bellacosa Mainframe

Buzzwords sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender Por Que Algumas Palavras Parecem Revolucionárias, Mas Muitas Vezes São Apenas Marketing com Roupa de Tecnologia

Existe uma cena que se repete há décadas dentro da informática.

Uma nova tecnologia aparece.

Logo depois surge uma enxurrada de apresentações, palestras, artigos, webinars e vendedores dizendo que ela vai mudar tudo.

Quem não aprender imediatamente ficará para trás.

Poucos meses depois, praticamente toda empresa começa a repetir exatamente as mesmas palavras.

Cloud.

Big Data.

Data Lake.

Blockchain.

DevOps.

Microservices.

AI-First.

Agentic AI.

Platform Engineering.

Zero Trust.

Observability.

Digital Transformation.

Parece que, de repente, todo mundo passou a falar o mesmo idioma.

Mas existe um detalhe curioso.

Nem sempre essas palavras significam aquilo que parecem significar.

Na verdade, muitas delas pertencem a uma categoria muito conhecida dentro da indústria de tecnologia.

As famosas Buzzwords.

Para quem está começando no universo COBOL e Mainframe isso pode ser extremamente confuso.

O iniciante costuma pensar:

"Será que preciso aprender tudo isso?"

Na maioria das vezes...

Não.

Primeiro é preciso entender o que realmente é uma Buzzword.

Como ela nasce.

Por que empresas adoram utilizá-la.

E principalmente como separar inovação verdadeira de puro marketing.

Pegue sua caneca de café.

Hoje vamos estudar uma palavra que, curiosamente, descreve milhares de outras palavras.


O que significa Buzzword?

Buzzword pode ser traduzida como:

palavra da moda

ou

expressão da moda

ou ainda

termo que gera entusiasmo.

A palavra é formada por duas partes:

Buzz
= zumbido, burburinho, falatório.

Word
= palavra.

Literalmente:

"palavra que faz barulho."

É exatamente isso.

Uma Buzzword é uma palavra que gera enorme repercussão, muitas vezes muito maior do que seu significado técnico.

Ela chama atenção.

Ela vende.

Ela impressiona.

Ela cria expectativa.

Nem sempre ela explica alguma coisa.


A origem da palavra Buzz

A palavra "buzz" existe há centenas de anos na língua inglesa.

Originalmente descrevia o som produzido por:

  • abelhas

  • moscas

  • insetos

Depois passou a representar qualquer murmúrio coletivo.

Como uma sala cheia de pessoas conversando.

Daí surgiu a ideia de:

"todo mundo está falando disso."

É exatamente daí que nasce a Buzzword.


Quando surgiu a expressão Buzzword?

Os linguistas apontam que buzzword começou a aparecer em ambientes corporativos e acadêmicos durante a primeira metade do século XX.

Os registros impressos mais antigos conhecidos aparecem por volta da década de 1940, embora o uso tenha se popularizado principalmente nos anos 1960 e 1970, quando jornais e revistas passaram a utilizar o termo para criticar jargões administrativos e tecnológicos.

Na década de 1980, com a explosão da informática corporativa, "buzzword" tornou-se parte do vocabulário de profissionais de TI, consultorias e universidades.

Curiosamente, foi justamente a indústria da computação que ajudou a transformar a palavra em um fenômeno mundial.


Antes das Buzzwords modernas

Cada época teve suas palavras mágicas.

Década de 1960

  • Automation

  • Electronic Data Processing

Década de 1970

  • Time Sharing

  • Distributed Computing

Década de 1980

  • Expert Systems

  • Artificial Intelligence (na primeira onda)

Década de 1990

  • Client Server

  • Multimedia

  • Information Superhighway

Anos 2000

  • SOA

  • Web 2.0

  • e-Business

2010

  • Cloud

  • Big Data

  • IoT

  • Blockchain

2020

  • Generative AI

  • LLM

  • Agentic AI

  • AI Factory

  • Digital Twin

  • Platform Engineering

Perceba que algumas realmente revolucionaram a tecnologia.

Outras praticamente desapareceram.


Buzzword não significa mentira

Esse é um erro muito comum.

Nem toda Buzzword é falsa.

Na verdade:

Uma Buzzword pode representar:

  • uma tecnologia revolucionária;

  • uma ideia excelente;

  • um conceito importante;

  • uma inovação legítima.

O problema acontece quando a palavra é usada sem conteúdo.


O melhor exemplo

Imagine um restaurante.

Você pergunta:

"O que tem de almoço?"

O garçom responde:

"Nossa cozinha trabalha com gastronomia experiencial de alta performance orientada por inovação disruptiva."

Você continua sem saber se existe arroz.

Nem feijão.

Nem carne.

A Buzzword fez muito barulho.

Mas informou quase nada.


O mundo corporativo adora Buzzwords

Porque elas vendem.

Imagine dois anúncios.

Primeiro:

"Software para controlar estoque."

Segundo:

"Plataforma inteligente baseada em IA Generativa com arquitetura cloud-native orientada por microsserviços."

Qual chama mais atenção?

Mesmo que ambos façam exatamente a mesma coisa.


O Mainframe também possui Buzzwords

E muitas.

Veja algumas.

Cloud Mainframe

Hybrid Cloud

Digital Transformation

AI on IBM Z

Modernization

API Economy

Hyperautomation

Open Banking

Observability

Self-Healing Systems

Nem todas são exagero.

Algumas representam mudanças reais.

Outras são apenas novos nomes para ideias antigas.


Easter Egg

O Mainframe talvez seja o computador que mais sofreu com Buzzwords.

Desde os anos 1980 ouvimos frases como:

"O Mainframe morreu."

"O futuro é totalmente distribuído."

"Agora tudo será cliente-servidor."

"Cloud substituirá IBM Z."

Décadas depois...

Os maiores bancos do planeta continuam processando bilhões de transações diárias em mainframes.

A tecnologia mudou.

O discurso mudou.

Mas o IBM Z continua executando a parte mais crítica de muitos negócios.

Às vezes a Buzzword envelhece antes da tecnologia que prometia substituir.


Um exemplo para um programador COBOL

Imagine duas reuniões.

Primeira reunião.

"Precisamos criar um programa COBOL que leia um VSAM e grave no Db2."

Todo mundo entende.

Segunda reunião.

"Precisamos implementar uma arquitetura orientada à transformação digital utilizando pipelines inteligentes baseados em IA Generativa."

O desenvolvedor pergunta:

"Tá... mas o programa faz o quê?"

Silêncio.


Buzzword pode esconder falta de conhecimento

Este é um fenômeno psicológico interessante.

Quanto menos alguém domina um assunto...

Maior tende a ser o uso de palavras impressionantes.

Especialistas normalmente fazem o contrário.

Eles simplificam.

Albert Einstein costumava defender que, se você não consegue explicar algo de forma simples, provavelmente ainda não o compreendeu profundamente.

No mundo do software, isso aparece todos os dias.


Como reconhecer uma Buzzword perigosa

Existem alguns sinais clássicos.

Primeiro.

Ninguém consegue definir exatamente o significado.

Segundo.

Cada pessoa explica de um jeito.

Terceiro.

Ela resolve absolutamente todos os problemas.

Quarto.

Todo fornecedor diz possuir aquilo.

Quinto.

Quem questiona parece estar "atrasado".

Quando esses cinco sinais aparecem juntos...

Vale investigar melhor.


O perigo para quem está aprendendo

O programador iniciante acredita que precisa decorar centenas de palavras.

Isso gera ansiedade.

Na prática, seu chefe provavelmente perguntará:

"Consegue alterar esse programa COBOL?"

Não:

"Você domina arquiteturas hiperconvergentes orientadas por ecossistemas cognitivos?"


O COBOL ensina uma grande lição

COBOL sempre valorizou nomes claros.

READ.

WRITE.

MOVE.

ADD.

SUBTRACT.

OPEN.

CLOSE.

STOP RUN.

Não existe glamour.

Existe clareza.

Essa simplicidade ajudou milhares de sistemas a sobreviverem por décadas.


Por que empresas continuam usando Buzzwords?

Existem várias razões.

Marketing.

Vendas.

Captação de investimentos.

Reposicionamento de marca.

Atrair talentos.

Criar sensação de inovação.

Nem sempre isso é negativo.

Uma Buzzword pode facilitar a divulgação de uma ideia complexa.

O problema surge quando ela substitui a engenharia.


A diferença entre conceito e Buzzword

Veja um exemplo.

Conceito:

Virtualização.

Buzzword:

Everything-as-a-Service.

Conceito:

Container.

Buzzword:

Cloud Native Revolution.

Conceito:

API REST.

Buzzword:

API Economy.

A tecnologia existe.

O nome comercial cresce muito além dela.


Como sobreviver às Buzzwords

Um bom profissional faz algumas perguntas.

O que realmente isso resolve?

Quais problemas elimina?

Como funciona internamente?

Quais limitações possui?

Qual empresa já utiliza isso?

Existe documentação técnica?

Existe padrão aberto?

Qual ganho mensurável?

Se ninguém consegue responder...

Talvez exista apenas marketing.


Buzzwords que sobreviveram

Nem todas desaparecem.

Internet.

Cloud Computing.

Virtualização.

Containers.

Machine Learning.

DevOps.

Observabilidade.

Essas começaram como palavras da moda.

Depois provaram seu valor.

Hoje fazem parte da engenharia de software.


Buzzwords que perderam força

Outras ficaram pelo caminho.

Information Superhighway.

Cyber Café.

Web 2.0.

Multimedia Revolution.

Office Automation.

Expert Systems.

Não desapareceram completamente.

Mas deixaram de dominar as conversas.


A IA também criou novas Buzzwords

Nos últimos anos surgiram dezenas.

Prompt Engineering.

AI Agent.

Copilot.

Reasoning Models.

Agentic AI.

Synthetic Data.

Foundation Models.

Nem todas permanecerão por décadas.

Mas algumas certamente entrarão para a história da computação.


O grande aprendizado para um Padawan COBOL

Quando ouvir uma palavra nova...

Não pergunte primeiro:

"Como faço isso?"

Pergunte:

"O que exatamente isso significa?"

Depois:

"Qual problema ela resolve?"

Por fim:

"Como isso funciona tecnicamente?"

Essas três perguntas eliminam boa parte do marketing.


Curiosidade histórica

Há um paralelo interessante entre Buzzwords e modismos da programação.

Nas décadas de 1970 e 1980, diversas empresas trocavam o nome de produtos existentes apenas para parecerem modernos. Um sistema de "processamento de dados" virava "plataforma de informação". Um terminal "inteligente" podia ser apenas um terminal comum com novo folheto de vendas.

Mudava o nome.

O código permanecia praticamente igual.


Um conselho de veterano

No Mainframe existe um ditado não escrito.

"Antes de acreditar na apresentação do PowerPoint, leia a documentação técnica."

A apresentação mostra a promessa.

A documentação mostra a realidade.

O código mostra a verdade.


Conclusão

Buzzwords sempre existirão.

Enquanto houver inovação, haverá novas palavras para descrevê-la.

Enquanto houver marketing, algumas dessas palavras serão exageradas.

Enquanto houver tecnologia, surgirão novos modismos.

Mas o bom engenheiro de software não se impressiona apenas com nomes bonitos.

Ele procura entender princípios, arquitetura, limitações e resultados concretos.

É exatamente por isso que um programador COBOL continua sendo tão valorizado.

Ele aprendeu, desde cedo, que computadores não executam discursos inspiradores.

Eles executam instruções precisas.

No fim das contas, um sistema bancário não processa milhões de transações por segundo porque alguém escreveu um relatório cheio de Buzzwords.

Ele funciona porque milhares de profissionais, durante décadas, escreveram código claro, consistente, testado e confiável.

E esse talvez seja o maior ensinamento deste café no Bellacosa Mainframe.

As Buzzwords passam.

As boas ideias permanecem.

O marketing muda a embalagem.

A engenharia muda o mundo.


quarta-feira, 13 de maio de 2020

O Fator Ônibus Rules : O Dia em que um Programador COBOL Descobriu que o Maior Risco do Mainframe Não Era um ABEND... Era uma Pessoa Só

 

Bellacosa Mainframe e o fator onibus rules em engenharia de software

☕ Um Café no Bellacosa Mainframe

O Fator Ônibus Rules sem Mistérios

O Dia em que um Programador COBOL Descobriu que o Maior Risco do Mainframe Não Era um ABEND... Era uma Pessoa Só

"Computadores não guardam conhecimento. Pessoas guardam. O problema começa quando apenas uma pessoa sabe como tudo funciona."


Introdução — O Incidente na USS Enterprise

Imagine que a USS Enterprise esteja explorando um setor desconhecido da galáxia.

O Capitão Kirk está em uma missão diplomática.

Spock foi capturado pelos romulanos.

Scotty está preso na casa de máquinas tentando impedir uma explosão no núcleo de dobra.

McCoy está operando um tripulante.

Sulu está pilotando uma nave auxiliar.

Chekov perdeu comunicação.

Quem sabe operar toda a Enterprise?

Se apenas Scotty conhece o funcionamento do motor de dobra...

...a missão inteira depende dele.

No desenvolvimento de software acontece exatamente a mesma coisa.

Existe um conceito bastante conhecido na Engenharia de Software chamado Bus Factor (Fator Ônibus).

É uma métrica extremamente simples.

E extremamente assustadora.


O que é o Bus Factor?

Bus Factor mede:

Quantas pessoas podem deixar um projeto antes que ele deixe de funcionar.

Ou, na definição clássica:

Quantas pessoas precisariam ser atropeladas por um ônibus para que o projeto ficasse inviável.

Apesar do nome parecer humor negro, o objetivo nunca foi falar de acidentes.

Hoje muitas empresas preferem nomes como:

  • Lottery Factor

  • Truck Factor

  • Beer Truck Factor

  • Departure Factor

A ideia é a mesma.

Se apenas uma pessoa conhece todo o sistema...

Bus Factor = 1

Se cinco pessoas dominam tudo...

Bus Factor = 5

Quanto maior o número...

mais saudável é o projeto.


A origem do termo

O conceito apareceu informalmente nos anos 1990 em equipes de desenvolvimento.

Depois foi bastante difundido por comunidades Open Source.

Grandes projetos como:

  • Linux

  • Apache

  • PostgreSQL

  • Kubernetes

passaram a discutir continuamente como aumentar seu Bus Factor.

Hoje empresas como Google, Microsoft, IBM, Amazon e Meta utilizam práticas justamente para evitar esse risco.


Por que isso acontece?

Porque conhecimento técnico é caro.

E conhecimento acumulado durante anos é mais caro ainda.

Imagine um sistema bancário COBOL criado em 1987.

Foram feitas:

  • milhares de correções

  • centenas de integrações

  • dezenas de migrações

Mas apenas João conhece:

  • o motivo daquele IF estranho

  • porque existe aquele PERFORM GO TO

  • porque aquele arquivo VSAM não pode ser reorganizado na sexta-feira

Sem João...

ninguém entende.


O verdadeiro patrimônio não é o código

Muitos pensam:

"O código está no Git."

Não.

O código é apenas uma fotografia.

O conhecimento está na cabeça das pessoas.

Por exemplo.

Imagine este trecho:

IF CODIGO = 98
    MOVE "N" TO PROCESSAR
END-IF

Todo mundo consegue ler.

Mas somente um programador sabe que:

"98 significa agência incorporada antes da fusão de 1999."

Isso nunca foi documentado.


O Bus Factor no Mainframe

Mainframe possui uma característica curiosa.

Sistemas vivem por décadas.

Enquanto aplicações Web costumam durar poucos anos...

há programas COBOL executando desde os anos 80.

Isso cria um fenômeno interessante.

Os programadores mudam.

O sistema permanece.

Quem sobrevive?

O conhecimento.


O Programador Lendário

Toda empresa possui um.

Normalmente conhecido por frases como:

"Pergunta para o Carlos."

ou

"Só a Maria sabe."

ou

"Não mexe nisso."

ou

"Esse módulo é do Roberto."

Quando alguém fala isso...

o Bus Factor acabou de aparecer.


Um caso clássico

Imagine um programa COBOL de 250 mil linhas.

Existe um JOB chamado:

PGM=FECHAMES

Todos sabem executá-lo.

Ninguém sabe como funciona.

Quando aparece erro...

esperam José voltar das férias.

Isso significa:

Bus Factor = 1


Como identificar um Bus Factor baixo?

Existem sinais muito claros.

Sempre chamam a mesma pessoa

"Fulano resolve."

Isso é risco.


Férias geram pânico

A equipe evita liberar férias.

Outro alerta.


Ninguém revisa aquele código

Porque ninguém entende.


Documentação inexistente

Tudo está "na memória".


Medo de alterar

Frases como:

"Melhor não mexer."

indicam conhecimento concentrado.


O impacto nos projetos

Um Bus Factor baixo provoca:

  • atrasos

  • retrabalho

  • bugs

  • decisões lentas

  • dependência

  • burnout

E principalmente:

medo.


Burnout técnico

O especialista nunca descansa.

Nunca tira férias.

Nunca muda de área.

Nunca cresce.

Porque virou gargalo.

Ele deixa de ser desenvolvedor.

Passa a ser suporte permanente.


O paradoxo

Muitos profissionais acreditam:

"Quanto menos gente souber, mais indispensável eu fico."

Na realidade acontece o contrário.

Empresas modernas promovem quem compartilha conhecimento.

Porque líderes multiplicam.

Guardiões escondem.


O Bus Factor no COBOL

Imagine um sistema composto por:

800 programas COBOL

120 CICS

300 JCL

90 PROC

60 COPYBOOK

15 VSAM

120 tabelas DB2

Apenas um analista conhece:

  • arquitetura

  • fluxo

  • dependências

Esse sistema possui Bus Factor baixíssimo.


Como aumentar o Bus Factor?

1. Documentação viva

Não basta Word esquecido.

Documentação precisa acompanhar o código.


2. Code Review

Todo código passa por outra pessoa.

Assim o conhecimento circula.


3. Pair Programming

Duas pessoas desenvolvendo juntas.

Muito comum em Extreme Programming.


4. Rotação de equipes

Hoje você mantém cobrança.

Amanhã cartões.

Depois investimentos.

Conhecimento distribuído.


5. Treinamentos internos

Mini workshops.

Lightning Talks.

Brown Bag Sessions.

Lunch & Learn.


6. Diagramas

Fluxos ajudam mais do que textos enormes.


7. Wiki

Confluence.

GitHub Wiki.

Markdown.

Obsidian.

Qualquer coisa melhor que memória humana.


8. Comentários úteis

Não explique COBOL.

Explique regra de negócio.

Ruim:

MOVE X TO Y

Bom:

* Conta especial criada após Resolução BACEN 2451

O papel dos COPYBOOKS

No Mainframe, COPYBOOKS também espalham conhecimento.

Padronizam:

  • layouts

  • mensagens

  • estruturas

  • contratos

Isso reduz dependências.


A importância dos testes

Testes também documentam.

Um bom teste responde:

"O que esse programa deveria fazer?"


Integração com IA

Hoje IA ajuda muito.

Ela pode:

  • explicar COBOL

  • gerar documentação

  • criar diagramas

  • resumir programas

Mas atenção.

Ela aprende com o código disponível.

Se o conhecimento nunca foi registrado...

nem a IA consegue descobrir.


Bus Factor e sucessão

Toda empresa deveria perguntar:

"Se João sair amanhã, conseguimos continuar?"

Se a resposta for "não"...

o problema já existe.


Curiosidade

Algumas empresas medem oficialmente:

  • percentual de conhecimento compartilhado

  • quantidade de revisores

  • cobertura de documentação

Tudo isso influencia o Bus Factor.


Um exemplo divertido

Imagine o motor de dobra da Enterprise.

Scotty conhece:

  • manutenção

  • peças

  • ajustes

  • gambiarra klingon

Se Scotty aposentar...

a nave para.

Kirk então decide:

  • treinar Geordi (sim, ele ainda nem nasceu nesta linha temporal!)

  • criar manuais

  • registrar procedimentos

Bus Factor aumenta.


Erros mais comuns

Heroísmo

"O sistema depende de mim."

Não deveria.


Falta de documentação

Erro clássico.


Não ensinar

Conhecimento escondido envelhece.


Medo de perder espaço

Na prática ocorre o contrário.

Quem ensina cresce.


Sistemas sem arquitetura

Tudo funciona.

Ninguém entende.


O que um Padawan COBOL deve aprender?

Nunca seja apenas executor.

Entenda:

  • negócio

  • arquitetura

  • fluxo

  • integração

  • histórico

Quanto mais contexto...

mais valor você gera.


Outros termos curiosos da Engenharia de Software

O Bus Factor faz parte de uma enorme coleção de conceitos curiosos usados por arquitetos de software.

1. Technical Debt (Dívida Técnica)

Atalhos tomados hoje que gerarão custo no futuro.


2. Yak Shaving

Resolver dezenas de problemas irrelevantes antes do verdadeiro.


3. Bike Shedding

Horas discutindo detalhes pequenos.

Exemplo:

"A cor do botão."

Enquanto ninguém fala da arquitetura.


4. Golden Hammer

Usar sempre a mesma tecnologia.

"Para tudo usamos Java."

Mesmo quando não faz sentido.


5. Cargo Cult Programming

Copiar código sem entender.

Muito comum na internet.


6. Spaghetti Code

Código totalmente desorganizado.


7. Lasagna Code

Camadas demais.

Tudo depende de tudo.


8. Big Ball of Mud

Sistema gigantesco sem arquitetura definida.

Muito comum em sistemas antigos.


9. God Object

Objeto que faz absolutamente tudo.


10. Lava Flow

Código antigo que ninguém remove.

Porque ninguém sabe se ainda é usado.


11. Boiling Frog

Problemas pequenos acumulam lentamente.

Quando percebem...

o sistema virou caos.


12. Death March Project

Projeto impossível desde o início.

Prazo irreal.

Equipe pequena.

Escopo gigante.


13. Brooks's Law

Do clássico The Mythical Man-Month:

"Adicionar pessoas a um projeto atrasado o atrasará ainda mais."

Porque novos membros precisam aprender.


14. Conway's Law

O software reflete a estrutura organizacional.

Departamentos separados criam sistemas separados.


15. Murphy's Law

Tudo que pode falhar...

falhará.

Por isso existem testes.


16. KISS

Keep It Simple.

Soluções simples sobrevivem mais.


17. YAGNI

You Aren't Gonna Need It.

Não implemente funcionalidades imaginárias.


18. DRY

Don't Repeat Yourself.

Evite duplicação.


19. SOLID

Cinco princípios para software sustentável.


20. Boy Scout Rule

"Deixe o código um pouco melhor do que encontrou."

Uma pequena melhoria por vez transforma um sistema inteiro ao longo dos anos.


O grande ensinamento

O verdadeiro objetivo do Bus Factor não é medir acidentes.

É medir resiliência organizacional.

Em um ambiente Mainframe, onde sistemas podem sobreviver por 30, 40 ou até 50 anos, o ativo mais valioso não é o servidor IBM Z, nem o Db2, nem o CICS, nem o código COBOL. É o conhecimento coletivo da equipe.

Quando apenas uma pessoa conhece um módulo crítico, cria-se um ponto único de falha tão perigoso quanto um disco sem redundância ou um banco de dados sem backup. Por outro lado, quando o conhecimento é compartilhado por meio de documentação, revisões de código, mentorias, treinamentos, programação em pares e rotação de responsabilidades, o sistema torna-se mais robusto e a equipe evolui em conjunto.

Para um Programador COBOL Padawan, a maior lição é esta: não aspire ser insubstituível; aspire ser inesquecível. O profissional que ensina, documenta, orienta e forma novos especialistas deixa um legado muito maior do que aquele que guarda segredos técnicos. Assim como na Frota Estelar, uma nave não depende de um único oficial para cumprir sua missão. Ela depende de uma tripulação preparada, colaborativa e capaz de assumir o comando quando necessário.

No fim das contas, o melhor indicador de maturidade de uma equipe não é quantas pessoas sabem tudo, mas quantas conseguem continuar navegando com segurança quando qualquer membro precisa se afastar. Esse é o verdadeiro espírito do Bus Factor: transformar conhecimento individual em patrimônio coletivo, garantindo que a missão continue, independentemente de quem esteja na ponte de comando.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...