Translate

Mostrar mensagens com a etiqueta transformacao digital. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta transformacao digital. Mostrar todas as mensagens

sexta-feira, 5 de junho de 2026

☕💣 OPERADOR, TEM ALGUÉM NO TERMINAL! — O Dia em Que um Assistente de IA Pediu Acesso ao Seu Mainframe

 

Bellacosa Mainframe e o assistente de IA LLM RAG

☕💣 OPERADOR, TEM ALGUÉM NO TERMINAL! — O Dia em Que um Assistente de IA Pediu Acesso ao Seu Mainframe

"Primeiro ele responde perguntas. Depois organiza tarefas. Em seguida consulta sistemas. Quando você percebe, existe uma inteligência trabalhando ao seu lado 24 horas por dia."


🚀 Afinal, o que é um Assistente de IA?

Imagine um operador de computador que:

✅ Nunca dorme
✅ Nunca tira férias
✅ Nunca esquece um procedimento
✅ Aprende com documentação
✅ Conversa em linguagem natural

Um Assistente de Inteligência Artificial é um software capaz de compreender perguntas, interpretar contexto, acessar informações e executar tarefas para auxiliar pessoas em suas atividades.

Diferente de um chatbot tradicional, que segue roteiros pré-definidos, um assistente moderno utiliza modelos de linguagem (LLMs) para raciocinar sobre problemas e gerar respostas dinâmicas.

Na prática, ele pode:

  • Responder dúvidas técnicas

  • Gerar código

  • Criar documentos

  • Automatizar processos

  • Consultar bancos de dados

  • Executar fluxos de negócio

  • Integrar sistemas corporativos

  • Apoiar decisões operacionais

Pense nele como uma mistura de:

  • Analista de Sistemas

  • Operador

  • DBA

  • Documentador

  • Programador

  • Professor

Tudo em uma única interface.


🏛️ O Assistente de IA no Mundo Mainframe

Imagine um assistente treinado com:

  • JCL

  • COBOL

  • CICS

  • DB2

  • IMS

  • RACF

  • TSO/ISPF

  • JES2

  • z/OS

Você poderia perguntar:

"Por que este JOB deu ABEND S0C7?"

ou

"Monte um JCL para copiar um VSAM KSDS."

ou

"Explique a diferença entre EXEC CICS LINK e XCTL."

Em segundos ele produziria:

  • Explicações

  • Diagnósticos

  • Exemplos

  • Sugestões de correção

É como ter um especialista Bellacosa Mainframe disponível 24x7.


🔧 Como Construir um Assistente de IA?

Hoje existem vários caminhos.

Caminho 1 — O Mais Simples

Utilizar plataformas prontas:

  • GPTs personalizados

  • Assistants

  • Copilots

  • No-Code AI Builders

Você fornece:

  • Documentação

  • PDFs

  • Manuais

  • Procedimentos

E o assistente aprende aquele contexto.

Ideal para:

  • Empresas

  • Equipes de suporte

  • Times de treinamento


Caminho 2 — Assistente com Base de Conhecimento

Arquitetura típica:

Usuário
   │
   ▼
Assistente IA
   │
   ▼
Base de Conhecimento
   │
   ├── PDFs
   ├── Manuais
   ├── Wikis
   ├── Procedimentos
   └── Documentação Técnica

O modelo consulta documentos antes de responder.

Chamamos isso de:

RAG (Retrieval Augmented Generation)

É uma das arquiteturas mais populares atualmente.


Caminho 3 — Assistente Corporativo

Aqui a brincadeira fica séria.

Usuário
   │
   ▼
Assistente IA
   │
   ├── SAP
   ├── Mainframe
   ├── Banco de Dados
   ├── ServiceNow
   ├── Jira
   ├── APIs
   └── Sistemas Legados

O assistente deixa de apenas responder.

Ele passa a:

  • Consultar sistemas

  • Abrir chamados

  • Executar processos

  • Atualizar registros

Estamos entrando no território dos Agentes de IA.


🎯 O Que Eu Ganho Construindo Um?

Muito mais do que parece.

1. Produtividade

Tarefas que demoravam horas passam a levar minutos.


2. Documentação Viva

Em vez de procurar em centenas de PDFs:

CTRL+F
CTRL+F
CTRL+F
CTRL+F

Você simplesmente pergunta.


3. Treinamento Acelerado

Novatos aprendem mais rápido.

Um júnior pode consultar o assistente constantemente.


4. Preservação do Conhecimento

Quando especialistas se aposentam, muito conhecimento desaparece.

O assistente pode ajudar a preservar:

  • Procedimentos

  • Boas práticas

  • Lições aprendidas


5. Disponibilidade 24x7

Não importa:

  • Madrugada

  • Feriado

  • Final de semana

O assistente continua disponível.


⚠️ As Desvantagens

Nem tudo é magia.

Alucinações

O maior problema atual.

A IA pode responder com enorme confiança algo completamente errado.

Exemplo:

"Qual parâmetro resolve esse ABEND?"

Ela pode inventar uma solução inexistente.


Dependência Excessiva

Algumas pessoas param de pensar.

Começam a copiar respostas sem validar.

Isso é extremamente perigoso.


Custo

Modelos avançados podem gerar custos relevantes.

Especialmente em grandes empresas.


Segurança

Documentos enviados para modelos externos podem conter:

  • Dados sensíveis

  • Segredos corporativos

  • Informações confidenciais

Governança é obrigatória.


☠️ Os Caminhos Tenebrosos

Agora entramos na sala escura do datacenter.

Luzes piscando.

Ar-condicionado rugindo.

Alarmes ao fundo.


Caminho Tenebroso #1

Confiar Cegamente na IA

A IA não é uma autoridade.

Ela é uma ferramenta.

Quem assina a decisão continua sendo o humano.


Caminho Tenebroso #2

Alimentar a IA com Dados Incorretos

Existe uma regra antiga:

Garbage In
Garbage Out

Se o treinamento estiver errado:

As respostas estarão erradas.


Caminho Tenebroso #3

Expor Informações Sigilosas

Jamais envie para modelos públicos:

  • Senhas

  • Chaves de API

  • Dumps confidenciais

  • Dados de clientes

Uma única falha pode gerar consequências enormes.


Caminho Tenebroso #4

Automatizar Sem Controle

Um assistente que apenas responde é uma coisa.

Um assistente que executa comandos é outra completamente diferente.

Imagine:

DELETE PRODUCAO

executado automaticamente.

Nem preciso explicar o restante da história...


Caminho Tenebroso #5

Substituir Conhecimento Humano

O objetivo não é eliminar especialistas.

É amplificar sua capacidade.

O melhor cenário é:

Humano + IA

e não

Humano OU IA

🎓 O Futuro

Estamos caminhando para uma era onde cada profissional terá seu próprio assistente especializado.

Um desenvolvedor terá um assistente de programação.

Um médico terá um assistente clínico.

Um advogado terá um assistente jurídico.

E um profissional de Mainframe poderá ter algo como:

"Bellacosa Mainframe Assistant"

Capaz de explicar:

  • JES2

  • RACF

  • CICS

  • DB2

  • COBOL

  • JCL

  • z/OS

com exemplos, laboratórios e diagnósticos.


☕💣 Conclusão Bellacosa Mainframe

O assistente de IA não é o fim do operador.

Não é o fim do programador.

Não é o fim do analista.

Ele é uma nova camada de abstração, assim como:

  • Assembly evoluiu para COBOL

  • Cartões perfurados evoluíram para terminais

  • Terminais evoluíram para interfaces gráficas

  • Interfaces evoluíram para a Web

Agora estamos entrando na era da conversa.

A pergunta não é mais:

"Como faço isso?"

Mas sim:

"Como explico para a IA o que eu preciso?"

Quem dominar essa habilidade terá uma vantagem semelhante à de quem aprendeu internet nos anos 90 ou computação em nuvem nos anos 2000.

Porque, no fim das contas, o maior poder da IA não está em responder perguntas.

Está em transformar conhecimento em ação.

E isso, meu amigo operador, é algo que merece um café forte antes do próximo IPL. ☕🚀💣


quinta-feira, 4 de junho de 2026

A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS

 

Bellacosa Mainframe e o covid expondo problemas da divida tecnica

☕💣📋 A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS


O DIA EM QUE UM PROGRAMADOR COBOL JÚNIOR DESCOBRIU QUE O MAIOR BUG DO BANCO NÃO ESTAVA NO CÓDIGO

Imagine a seguinte situação.

Você acabou de entrar em um grande banco.

Recebe seu primeiro programa COBOL para manutenção.

Abre o membro no ISPF.

O programa possui:

  • 28.000 linhas

  • 134 COPYBOOKS

  • 742 parágrafos

  • Comentários da época do Plano Real

  • Um PERFORM THRU que ninguém entende

  • Um campo chamado WK-AREA1

  • Outro chamado WK-AREA2

  • Outro chamado WK-AREA3

E você pensa:

"Quem foi o maluco que escreveu isso?"

Então um analista veterano olha para você e responde:

— Eu.

E completa:

— Em 1998 aquilo era considerado moderno.

Nesse momento você acabou de conhecer um dos conceitos mais importantes da engenharia de software:

Dívida Técnica


O QUE É DÍVIDA TÉCNICA?

A melhor definição é simples.

Dívida técnica é quando uma decisão que economiza tempo hoje gera custos maiores amanhã.

Funciona exatamente como um empréstimo bancário.

Você pega dinheiro hoje.

Mas depois paga:

  • principal

  • juros

  • correção

  • multas

No software acontece a mesma coisa.

Você ganha velocidade agora.

Mas perde produtividade no futuro.


EXEMPLO COBOL CLÁSSICO

Imagine que em 1998 alguém criou:

IF AGENCIA = 1234
   MOVE 'SANTOS' TO CIDADE
END-IF

Parecia inofensivo.

Hoje existem:

  • 3.000 agências

  • dezenas de fusões

  • múltiplas marcas

Agora o código virou:

IF AGENCIA = 1234
...
ELSE IF AGENCIA = 2345
...
ELSE IF AGENCIA = 3456
...

O que era uma solução virou um problema.


COMO A DÍVIDA TÉCNICA NASCE?

Normalmente através de frases famosas.

Frase 1

"Depois a gente melhora."

Mentira.

Ninguém melhora.


Frase 2

"É só uma correção rápida."

Nunca é.


Frase 3

"O projeto fecha sexta-feira."

A dívida nasce quinta.


Frase 4

"Não mexe porque funciona."

O terror dos bancos.


OS TIPOS DE DÍVIDA TÉCNICA

1. Código

Programas difíceis de entender.

Exemplos:

  • GOTO excessivo

  • PERFORM THRU gigantes

  • variáveis sem significado

  • duplicação


2. Arquitetura

Problemas maiores.

Exemplos:

  • sistemas monolíticos

  • dependências excessivas

  • integrações frágeis


3. Dados

Muito comum em bancos.

Exemplos:

  • arquivos VSAM redundantes

  • tabelas DB2 duplicadas

  • dados inconsistentes


4. Processos

Pouco discutida.

Mas extremamente perigosa.

Exemplos:

  • deploy manual

  • testes manuais

  • documentação inexistente


COMO IDENTIFICAR DÍVIDA TÉCNICA?

Um júnior costuma perguntar:

"Como sei que existe dívida?"

Observe sintomas.


Sintoma 1

Mudanças simples levam semanas.


Sintoma 2

Toda alteração gera incidente.


Sintoma 3

Poucas pessoas entendem o sistema.


Sintoma 4

Ninguém quer mexer.


Sintoma 5

A frase mais perigosa:

"Esse programa é do fulano."

Quando o sistema tem dono humano, existe dívida.


MÉTRICAS IMPORTANTES

Agora entramos em uma área que diferencia profissionais comuns de profissionais de elite.

Você não gerencia aquilo que não mede.


1. COMPLEXIDADE CICLOMÁTICA

Criada por Thomas McCabe.

Mede quantos caminhos lógicos existem.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Complexidade = 2

Agora imagine 300 IFs.

O número explode.

Quanto maior:

  • mais difícil testar

  • mais difícil manter

  • maior risco

Meta saudável:

  • abaixo de 10 excelente

  • até 20 aceitável

  • acima de 30 perigoso


2. LINHAS DE CÓDIGO

LOC (Lines of Code)

Não mede qualidade.

Mas mede tamanho.

Programa COBOL:

  • 500 linhas → simples

  • 5.000 linhas → atenção

  • 20.000 linhas → investigação


3. DUPLICAÇÃO DE CÓDIGO

Quanto código está repetido?

Exemplo:

Mesma regra de cálculo em:

  • cadastro

  • empréstimo

  • cartão

  • investimentos

Quando muda uma regra:

quatro programas precisam mudar.


4. COBERTURA DE TESTES

Quanto do sistema é validado?

Métrica:

Cobertura = código testado / código total

Quanto maior, melhor.


5. TEMPO MÉDIO DE CORREÇÃO

MTTR

Mean Time To Repair.

Quanto tempo leva para corrigir problemas.

Quanto menor:

melhor maturidade.


6. DEFEITOS POR RELEASE

Muito utilizada em bancos.

Pergunta simples:

Quantos incidentes surgem após implantação?


FERRAMENTAS QUE AJUDAM

Vamos ao arsenal.


IBM APPLICATION DISCOVERY

Conhecida como AD.

Excelente para:

  • dependências

  • impacto

  • análise de código

Mostra relacionamentos invisíveis.


IBM APPLICATION DELIVERY FOUNDATION

Ajuda em:

  • DevOps

  • testes

  • integração


SONARQUBE

Uma das mais famosas.

Analisa:

  • complexidade

  • duplicação

  • vulnerabilidades

Possui suporte para COBOL.


TOPAZ

Muito utilizada em ambientes Compuware/BMC.

Excelente para:

  • visualização

  • debugging

  • análise


ENDEVOR

Ajuda no controle de versões.

Embora não seja ferramenta de dívida técnica, ajuda a evitar que ela cresça.


GIT

Sim.

Programadores COBOL modernos usam Git.

O mundo mudou.


COMO REDUZIR DÍVIDA TÉCNICA?

Agora chegamos à parte prática.


PASSO 1

MAPEAR

Nunca saia corrigindo.

Primeiro descubra:

  • onde está

  • quanto existe

  • qual impacto


PASSO 2

CLASSIFICAR

Separe em:

Alta prioridade

Afeta negócio.

Média prioridade

Afeta produtividade.

Baixa prioridade

Apenas estética.


PASSO 3

ATACAR O TOPO

Use a regra 80/20.

Normalmente:

20% dos programas geram 80% dos problemas.

Comece por eles.


PASSO 4

REFATORAR

Refatorar significa:

melhorar sem alterar comportamento.

Exemplo:

Antes

MOVE 'S' TO WS-FLAG1

Depois

MOVE 'S' TO WS-CLIENTE-ATIVO

Mesmo resultado.

Melhor compreensão.


PASSO 5

REMOVER DUPLICAÇÃO

Regra de ouro.

Se existe em cinco lugares.

Transforme em um.


PASSO 6

DOCUMENTAR

A documentação mais barata é aquela escrita hoje.

A mais cara é aquela que será escrita daqui cinco anos.


PASSO 7

CRIAR APIs

Aqui entra a modernização.

Não destrua o COBOL.

Encapsule.

Exemplo:

Mobile
   |
API
   |
CICS
   |
COBOL
   |
DB2

O COBOL continua funcionando.

Mas agora conversa com o mundo moderno.


O PAPEL DA CLOUD

Muitos profissionais acreditam:

"Cloud substitui Mainframe."

Não.

A realidade é:

Cloud complementa Mainframe.

O mercado está migrando para:

Mainframe + APIs + Cloud + IA

Não:

Mainframe versus Cloud

EASTER EGG DA INDÚSTRIA

Você sabia?

Grande parte dos sistemas bancários mais críticos do planeta possui código executando há décadas.

Alguns módulos possuem mais idade que muitos programadores que fazem manutenção neles.


CURIOSIDADE

Em muitos bancos existem programas COBOL executados diariamente há mais de 30 anos sem interrupção significativa.

Pouquíssimas tecnologias no mundo podem afirmar isso.


A REGRA DOS ESCOTEIROS

Uma das melhores técnicas contra dívida técnica.

Conhecida como:

Boy Scout Rule

"Deixe o código mais limpo do que encontrou."

Você corrige um bug.

Aproveite para:

  • melhorar nomes

  • remover comentários obsoletos

  • eliminar duplicações

Pequenas melhorias acumulam enormes resultados.


O ERRO QUE TODO JÚNIOR COMETE

Querer reescrever tudo.

Não faça isso.

Sistemas bancários existem para:

  • processar pagamentos

  • movimentar bilhões

  • atender clientes

Não para serem bonitos.

Primeiro entenda.

Depois melhore.

Por último modernize.


O CAMINHO DE EVOLUÇÃO PROFISSIONAL

Júnior:

"Como funciona?"

Pleno:

"Como melhorar?"

Sênior:

"Como evitar que o problema volte?"

Arquiteto:

"Como impedir que o problema exista?"


☕🦠💣 QUANDO A COVID FEZ O IPL DO PLANETA E REVELOU TODOS OS ABENDS ESCONDIDOS DOS BANCOS

Até 2020 muitos bancos acreditavam que estavam preparados para o futuro.

Possuíam:

  • Internet Banking

  • Aplicativos móveis

  • Chatbots

  • APIs

  • Transformação Digital nos PowerPoints

Então chegou a COVID.

E a realidade apareceu.


O TESTE DE STRESS QUE NINGUÉM PLANEJOU

Durante décadas os bancos planejavam crescimento gradual.

De repente aconteceu:

Milhões de clientes
tentando acessar
os sistemas ao mesmo tempo

O equivalente em mainframe seria:

100.000 jobs
entrando na fila
simultaneamente

O QUEBROU?

Curiosamente, muitas vezes não foi o COBOL.

Nem o CICS.

Nem o DB2.

Foi a camada moderna.

Por exemplo:

  • Portais Web

  • Gateways API

  • Aplicativos móveis

  • Centrais de atendimento

Os sistemas core continuavam funcionando.

Mas os canais de acesso colapsaram.


O DIA EM QUE O BANCO DESCOBRIU SUA DÍVIDA TÉCNICA

Muitas instituições descobriram:

  • Processos manuais escondidos

  • Dependência excessiva de funcionários específicos

  • Sistemas sem escalabilidade

  • Arquiteturas ultrapassadas

A pandemia funcionou como um scanner de vulnerabilidades em escala mundial.


☁️ A NUVEM NÃO É UMA MÁQUINA. É UMA ESTRATÉGIA.

Um dos maiores erros dos iniciantes é pensar:

Cloud = Servidor em outro lugar

Não.

Cloud é uma mudança de modelo operacional.


O QUE A NUVEM OFERECE?

Imagine que amanhã o banco precise processar:

10 vezes mais transações

No modelo tradicional:

  • Comprar servidores

  • Instalar servidores

  • Configurar servidores

Meses de trabalho.


NA NUVEM

Precisa de mais capacidade?

Adiciona.

Precisa de menos?

Remove.


A NUVEM REDUZ DÍVIDA TÉCNICA?

Resposta curta:

Não.


RESPOSTA LONGA

A nuvem não elimina dívida técnica.

Mas torna muito mais fácil combatê-la.

Exemplo:

Antes:

Sistema monolítico
30.000 programas

Depois:

Microserviços
APIs
Containers

Agora você consegue modernizar partes isoladas.


O PADRÃO QUE ESTÁ DOMINANDO OS BANCOS

O mercado financeiro está migrando para:

Cloud
    |
APIs
    |
Mainframe
    |
DB2

Não:

Cloud substituindo Mainframe

Mas:

Cloud consumindo Mainframe

Essa diferença é gigantesca.


O STRANGLER PATTERN

Um dos segredos da modernização bancária.

Ao invés de destruir:

Sistema COBOL

Você faz:

Nova API

Depois:

Novo serviço

Depois:

Novo canal digital

E o legado vai sendo cercado gradualmente.


👨‍💼 O PROBLEMA QUE NINGUÉM GOSTA DE DISCUTIR: RH

A parte mais interessante da entrevista da IBM talvez seja esta:

A maior dívida técnica não é financeira.

É humana.


O PROGRAMA COBOL QUE APOSENTOU O FUNCIONÁRIO

Imagine:

Programa:

PAGBOL01

Criado em:

1994

Quem entende?

Uma pessoa.


O DIA DO DESASTRE

Essa pessoa:

  • aposenta

  • muda de empresa

  • entra em férias

Pronto.

Agora existe um risco operacional.


O FATOR ÔNIBUS

Métrica famosa.

Pergunta:

Quantas pessoas precisam desaparecer para que o projeto pare?

Se a resposta for:

1

Você possui um problema grave.


O QUE OS JOVENS DESENVOLVEDORES PROCURAM?

A nova geração busca:

  • Git

  • APIs

  • DevOps

  • Cloud

  • Automação

  • CI/CD

Não necessariamente porque são modismos.

Mas porque aumentam produtividade.


O ERRO DOS GESTORES

Muitos acreditam:

"Os jovens não querem aprender COBOL."

Errado.

O que eles não querem é:

Trabalhar em caos.

Existe uma enorme diferença.


UM COBOL MODERNO É ATRAENTE

Imagine um ambiente com:

  • Git

  • VS Code

  • Zowe

  • APIs REST

  • Jenkins

  • SonarQube

E atrás disso:

COBOL
CICS
DB2

O profissional moderno trabalha feliz.


UM COBOL ANTIGO É REPELENTE

Agora imagine:

  • documentação inexistente

  • deploy manual

  • FTP

  • planilhas Excel

  • mudanças sem controle

O problema não é COBOL.

É a cultura.


O CUSTO INVISÍVEL DA DÍVIDA TÉCNICA

Os gestores normalmente medem:

  • hardware

  • software

  • licenças

Mas esquecem:

  • turnover

  • treinamento

  • conhecimento perdido

Esses custos podem superar os custos tecnológicos.


O CICLO VICIOSO

A dívida técnica cria:

Sistema ruim
      ↓
Pouca produtividade
      ↓
Mais pressão
      ↓
Mais atalhos
      ↓
Mais dívida técnica
      ↓
Mais pessoas saem
      ↓
Menos conhecimento
      ↓
Mais dívida técnica

É um círculo destrutivo.


O CICLO VIRTUOSO

A modernização cria:

Melhor arquitetura
       ↓
Mais produtividade
       ↓
Menos incidentes
       ↓
Mais inovação
       ↓
Mais satisfação
       ↓
Melhor retenção
       ↓
Mais conhecimento
       ↓
Menos dívida técnica

A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL JÚNIOR

Quando você ouvir a expressão:

"Precisamos migrar para a nuvem."

Não pense em servidores.

Pense em:

  • agilidade

  • automação

  • integração

  • APIs

  • escalabilidade

  • experiência do desenvolvedor

Quando ouvir:

"Precisamos reduzir dívida técnica."

Não pense apenas em código.

Pense em:

  • pessoas

  • conhecimento

  • processos

  • documentação

  • cultura

E quando ouvir:

"Precisamos modernizar o mainframe."

Lembre-se:

Os maiores bancos do mundo não estão abandonando COBOL.

Eles estão cercando COBOL com tecnologias modernas para que ele continue entregando valor pelos próximos 30 anos.


CONCLUSÃO

A maior lição sobre dívida técnica é surpreendente.

O problema raramente é COBOL.

O problema quase sempre é falta de gestão.

Um programa COBOL de 1985 pode ser extremamente moderno se possuir:

  • documentação

  • testes

  • APIs

  • observabilidade

  • versionamento

  • arquitetura bem definida

Da mesma forma, uma aplicação criada ontem pode nascer cheia de dívida técnica.

Lembre-se sempre:

Dívida técnica não é idade.

Dívida técnica é descuido acumulado.

E existe uma enorme diferença entre um sistema antigo e um sistema mal cuidado.

O programador COBOL que entender essa diferença deixa de ser apenas um mantenedor de código legado e passa a ser um verdadeiro engenheiro responsável por preservar, modernizar e evoluir alguns dos sistemas mais importantes do planeta.


quarta-feira, 30 de julho de 2025

Época de mudanças no Mainframe e a possível derrocada da BIG BLUE. Será?

 

Bellacosa Mainframe e as mudanças no Mundo Mainframe

Época de mudanças no Mainframe e a possível derrocada da BIG BLUE. Será?

4,424 followers


  • #Informática Básica
  • #Arquitetura de Sistemas
  • #Soft Skill

114 Anos da IBM!!! Hip Hip Hurra

Derrocada da IBM, quando executivos erram.

Uma historia cheia de idas e vindas

Salve jovem padawan, graças a positiva repercussão do artigo sobre Cobol, resolvi ir um pouco mais além e falar despretensiosamente sobre tendências e estratégias, que nos simples desenvolvedores devemos saber e aprender ao longo da carreira, lembrando que esta nao é um visão executiva afinal somos pequenos programadores a mercê do mercado, vivendo do salário e dependemos dos projetos.

Article content

Existe risco ao adotarmos uma tecnologia, um simples erro em nossa escolha na área de tecnologia, poderá significar o fracasso de nossas vidas profissionais e empregabilidade futura, como exemplo vide a quantidade de ex-programadores das dezenas de LPs que nao sobreviveram a prova TEMPO e hoje estão atuando em outras áreas profissionais.

Meu testemunho é um exemplo destas escolhas e caminhos, minha carreira de DEV (programador até pouco tempo atrás), iniciou-se no século passado, época que o Mainframe dominava o mundo dos computadores, a IBM era a empregadora dos sonhos, dona de uma carreira desafiadora, o estado da arte em IT, produzindo obras de arte em softwares e dominando a imprensa, conquistando corações. Todo jedi de cabecinha branca de hoje, com certeza um dia sonhou em ter um crachá da Big Blue e fazer parte da equipe Harlem Globetrotters dos computadores..

Article content

Naquela época todo Analista PROGRAMADOR aspirava trabalhar em um dos grandes laboratórios informáticos da IBM, ou melhor C.P.D. com maquinas fabulosas saídas de um cenário de filme HI, até hoje ainda sonho com unidade leitoras de fita magnética e robots manipulando cartridges para inicializar unidades de disco, e os leds acendendo e apagando em maquinas e seus terminais 3270 conectados por modens trocando dados.

Saiba que o modulo Drácula, muito em voga atualmente, nada mais é que um retorno às origens, uma singela homenagem das novas gerações as telas negras dos terminais com suas 24 linhas com 80 colunas de texto caps lock em fosforo verde.

Falando sobre o porquê da DERROCADA do Mainframe.

Article content

O prego no caixão do Mainfame/Cobol foi a mania do bug do milênio, onde milhares de empresas gastaram a rodo, sacos e mais sacos de recursos financeiros e humanos, para “consertar” o Bug Y2k, um problema originado nos anos 70 e perpetuados ao longo de décadas por programadores preguiçosos e usuários zelosos, nao sei se era, mas o consenso geral acreditava que 2 bytes a mais era muito dispendioso.

So sei que isso acabou enriquecendo consultorias inescrupulosas que jogavam mais e mais querosene no incêndio, com artigos catastróficos, assustadores e altamente criativos, criados para criar gerar  pânico nos stakeholders, originando um estouro de manada generalizado, que obrigava a necessidade de ações rápidas e impensadas.

Article content

Vendo com olhos experiente, essa mania acabou causando grandes danos à imagem dos Computadores e analistas programadores, derrubando a credibilidade e confiança do mercado em computação e softwares legados. Verdade seja dita, o preço foi pago com as centenas de diretores de informática mandados a guilhotina nos anos seguintes.

Mas isso não foi o pai de todos os males, a tempestade perfeita estava se formando no horizonte, para ajudar esse período confuso, ainda tivemos o colapsos no Sistema Financeiro Mundial, iniciados pela crise financeira de 2001, que apôs a derrocada do World Trade Center, adicionaram um pouco de caos, ao processo em curso do estouro da bolha das DotCom, empresas de internet, que prometiam lucros pornográficos, mas não tinham pé nem cabeça.

Para concluir o cenário de caos apocalíptico, fomos vítimas da crise do subprime de 2008 em que erros de Acadêmicos de prestigiosas Universidade em suas teorias de portfólio, aliada a gestores gananciosos e suas carteiras de investimentos com fraudes em processos estocásticos, definitivamente concluíram um ciclo econômico com a destruição dos mercados financeiros mundiais.

Article content

Estes eventos aleatórios que enterraram centenas de grandes empresas e conjuntamente a turbulência gerada no mercado laboral, foram responsáveis pela destruição dos postos de trabalhos, gerando desemprego a milhões de trabalhadores de do setor financeiro e da informática, no caso do IT pessoas altamente especializadas em Mainframe, que de um momento para outro, se viram sem chão.

Agora pare um pouco e pense nessas pessoas, muitos delas estando próximo da aposentadoria e acostumados a ter um padrão confortável de vida, que inesperadamente foram jogados para o desemprego e devido aos elevados salários recebidos na época áurea, tiveram grande dificuldade em se realocar e retornarem ao mercado laborativo, principalmente pela queda abrupta em novos projetos e falência de inúmeras pequenas softhouses, que empregavam terceirizados, quarteirizados e afins.

Um dia gostaria de ler um estudo ou artigo acadêmico que contabilizasse os milhões de linhas de código, que foram parar no fundo da lata de lixo da história empresarial, pensar em bom código que nunca chegaram ao potencial previsto, produtos únicos e inovadores, que não tiveram a chance de debutar e gerarem riquezas.

Migração dos sistemas legados.

Article content

Os gestores de IT estão desesperados com o rumo do mercado, com cortes frequentes de orçamento, com a perda de prestigio e diminuição do mercado, bem que tentaram reinventar a Roda, criando monstros informáticos e em consequência desta anomalia, acabaram destruindo ainda mais empregos, prova disso, basta perguntarmos aos inúmeros jedi renegados, que foram dispersados após o final da Guerra Subprime.

Neste turbulento momento histórico, com inúmeros jedi dispersados pelo mercado, coletaremos inúmeras histórias tragicômicas sobre migração de sistemas legados, erps vistosos mas incompletos e com aquisição de packages de software para migração que falharam catastroficamente, uma das mais recentes tragédias foi o TSB Bank com 300 milhões de libras esterlinas em multas e menos 80.000 clientes.

Por mais que as novas tecnologias e as linguagens de programação moderna atendam a parte de front-end, criando maravilhas do design UI e UX, o back-end continua a ser o lugar onde a magia realmente acontece, todas as regras do negócio e seus meandros, a inteligência de processos, a máquina de gerar lucros continua sendo os softwares antigos.

O big data existe ? Sua razão de ser principal é processar grandes quantidades de dados, bits e bytes na casa dos milhões, quiçá bilhões de registros, mas quando necessitamos de alta performance, segurança, continuidade, uso inteligente de recursos limitados, nisso a IBM ainda é a líder absoluta, por mais que surja o cloude computer, o custo de alocar mais maquinas (espaço, cpu e ram), acaba ultrapassando os custos com equipamento IBM Mainframe, o Azure e o AWS são jovens nesse mercado, somente o tempo dirá quem será o vencedor..

Onde a IBM errou, então?

Article content

Abandonando as pessoas, esse foi o erro, mas antes temos que agradecer a Linux Torvalds e a derrocada da Microsoft, calma ai, está pensando que surtei? Estou falando bobagens e fazendo-o perder tempo precioso? Calma, vamos por partes, que explicarei melhor.

A Microsoft nos anos 90 tomou de assalto o mundo da informática, abocanhando grande fatias de mercado da IBM, graças a pirataria de informática, em pouco tempo todos os trabalhadores do mundo foram treinados gratuitamente no pacote MS Office, dominando o Word, Excel , Access e Power Point, em detrimento do WordStar, Lotus, Dbase IV e similares.

Nesse meio do caminho existia um movimento barulhento, alimentado com famosas consultorias, que convidava executivos de informatica para jantares, viagens e passeios. Onde aproveitavam para catequizar e vender as boas novas dos Servers, dos celeiros com centenas de servidores, muito mais economicos que o Mainframe, era o inicio do Downsize e posteriormente o Rightsite.

Voltando a Microsoft madura e com mão de obra qualificada e treinada foi fácil, obrigar as empresas a comprarem as licenças e investir em treinamentos empresariais caríssimos e suas certificações, enquanto isso a IBM dormia, dificultando a reciclagem nos estudos e construindo uma muralha maior que a da China, cheia de barreiras de acesso a novos e jovens profissionais, mas também era o inicio de uma revolução silenciosa, nos bastidores insatisfeitos criavam uma via alternativa: surgia o Python, o Java e o Javascript, antes chamado Actionscript.

Um maxima jedi: "No People No Program", afinal toda linguagem de programação necessita sempre de reciclagem, sangue novo para inovar e criar novas formas de fazer, padawans aprendendo os fundamentos da linguagem e evoluindo com novos conhecimentos e técnicas, ao mesmo tempo repassando novos conhecimentos aos velhos jedis, numa via de mão dupla de aprimoramento continuo.

Onde Linux Torvalds entra nessa

Article content

História?

A Microsoft sendo uma cria da IBM, acabou herdando alguns vícios e mesmo a arrogância da BIG Blue, ao dominar o mercado da baixa plataforma, foi consumida pelo lado negro da força, e tornou-se uma ditadora suprema. Perpetuando os erros da IBM com cursos caríssimos e barreira de acesso a novos programadores. Criando uma geração de DEVs que odiavam a gigante de Redmond.

Após a morte do Clipper, o Visual Basic virou a linguagem do povo, mas era limitada, enquanto o C era complexo, difícil e pouco intuitivo, em pouco tempo a odiada MS, começou a ser hostilizada pelos DEVs do software livre e empresas concorrentes, que aproveitaram para imitar Brutus e apunhalar Caesar.

Article content

.

Com isso o jovem jedi Linux, seguindo o mesmo caminho do Gates e o CPM e Jobs nos IOS, mergulhou no Unix e criou seu Linux, porém sendo altamente inovativo, ele abriu a caixa preta e convidou a comunidade DEV e jovens universitários do mundo a participarem da festa e criarem suas próprias versões, compartilhando ideias e projetos na aldeia global interligada pela WEB e suas primordiais redes sociais IRC e ICQ.

Nessa onda de mudança do software aberto a Microsoft sentiu a dor, perdeu mercado, amargou perda financeiras e acabou sendo a empresa mais odiada pelo mundo dos programadores jedis, o JAVA e o Linux viraram os queridinhos e em menos de uma década dominaram o mercado de baixa plataforma.

Enquanto isso, a IBM altamente entrincheirada na Alta Plataforma, pouco mudou, mesmo vendo que a cada vez haviam menos DEVs treinados em Alta Plataforma, encarecendo a mão de obra e inviabilizando novos projetos, afinal quem se arriscaria a desenvolver um software onde não encontraria profissionais para darem sustentação ou manutenção evolutiva?

Para piorar o cenário da Big Blue, o advento dos ERPs tendo o SAP como seu maior expoente e a tentativa falhada do Navision da Microsoft criaram mais caos no turbulento e agitado mercado de IT, dividindo ainda mais os DEVS, seguindo a máxima dividir para reinar.

Veja que coisa agora tínhamos jedis em Mainframe, jedis em SAP, jedis em Microsoft e os jedis renegados em JAVA, sendo que muitos descontentes das outras tribos migraram para o JAVA enriquecendo esta linguagem, debugando, sugerindo inovações, evoluindo e criando novos padrões.

O império contra-ataca.

Article content

A Microsoft pressionada pelo mercado, acuada pela Google de um lado e no fronte das comunidades livres JAVA e sofrendo ataques sucessivos pelo IOS no altamente elitizado mercado de TOPs computers, perdendo o universo universitário para os squads Linux. Reinventou-se e escreveu um novo capítulo na história, diferentemente da IBM, que morosamente engatinha os primeiros passos, a reinvenção da MS deu um passo além, democratizou o acesso a informação e ofereceu um nova gama de serviços e oportunidades aos DEVs criando uma academia de padawans mundial.

O primeiro passo foi criar uma rede social (comprou e reformulou o Linkedin), segundo passo educar e difundir o conhecimento (comprou e reformulou o GitHUb) e terceiro passo cursos e formações gratuitas (abriu o código fonte de tudo e deu para o mercado), a cada dia vemos mais e mais DEVs tornando-se jedis Microsoft, a comunidade acadêmica utilizando maciçamente o Azure e o VS Code, abocanhando fatias de mercado da AWS da Amazon e o C Sharp debutando e conquistando fans.

A IBM assistindo todos estes eventos, entrou tardiamente nesta corrida, mas a lição foi aprendida, correndo contra o relógio, desenvolveu uma plataforma de ensino e divulgação do Mainframe, conhecida como projeto ZOWE e modestamente vem educando uma nova geração de jedis em Mainframe. Inclusive tentando atrair os descontentes do Linux / Java, visando reforçar suas linhas e criar novas estratégias.

Hoje temos o LinuxOne rodando em um Mainframe IBM Z e todas as linguagens que estavam fora do Mainframe, agora estão dentro convivendo em harmonia e complementando as diversas frentes.

Minha visão do Mundo IBM Mainframe.

Article content

Enquanto o ensino de PL/I e Cobol forem elitizados o Mainframe está condenado a morte e obsolência, pois o Peopleware é que dão vida ao sistema, sem eles não adianta ter os melhores e mais rápidos computadores do mundo, as linguagens mais performáticas, seguras e a prova de bugs estrupidos, se não há humanos para operar e criar novas soluções e venderem-nas para o mercado.

Acredito que as grandes consultoras de informática deveriam criar pools de treinamento usando plataformas existentes, indico a Digital Innovation One e criarem bootcamps de Mainframe, na tentativa de atrair jovens talentos para o mundo da Alta Plataforma e através dessa iniciativa darem sobrevida e quem sabe evoluir novos mercados criando um novo tempo.

Nelson Blecher e a morte do IBM

Article content

Passado s quase 30 anos do inspirador artigo e reportagem de Blecher sobre a morte da IBM, a BIG BLUE continua viva e ativa, apesar das cisões, perdas de mercados, diminuição de prestígios, continua vendendo e lucrando.

Seus algozes caíram um a um, Xerox quase sumiu, HP e Compac são sombras do que eram, SUN foi incorporada e as fabulosas e fantásticas DotCom, viraram estudos de caso, ilustrando o grande risco do efeito manada e os vieses dos investidores.

Para quem gosta de uma boa historia deixo os links de antigos artigos, muito obrigado Nelson Blecher, me inspirei neles para escrever estas linhas.

https://www1.folha.uol.com.br/fsp/1994/9/18/mais!/30.html

https://www1.folha.uol.com.br/fsp/1994/9/18/mais!/29.html

Conclusão

No artigo de hoje, jovem padawan fizemos um giro pelo Império, vimos como o mercado é mutável, como tecnologias e empresas surgem e somem, paradigmas computacionais caem por terra, antigos vilões se reciclam e viram heróis.

Mas por trás de todas as evoluções e involuções vemos a figura do SER HUMANO como agente de mudança, o trabalhador que precisa pagar o arroz feijão, que uma vez analista extinto, necessita se reinventar e adquirir novos conhecimentos, estudar novas tecnologias e procurar novos senhores feudais para defender.

Meu conselho a ti, jovem e iniciante padawan, estude, escolha a sua tecnologia preferida e torne-se um jedi, porem fique atento as ondas da evolução, prepara-se para migrar no tempo certo, não pare de estudar nunca, evolua, participe e defenda a sua LP preferida.

Espero ter ajudado ate o próximo artigo.

Article content
Article content

Mais momento jabá, para distrair, visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=C5olTn9Dczw

Bom curso a todos.

Article content

https://www.linkedin.com/in/vagnerbellacosa/

Article content

https://github.com/VagnerBellacosa/

Pode me dar uma ajudinha no YouTube?

Article content

https://www.youtube.com/user/vagnerbellacosa