Metodologia Waterfall, o que é, para que serve, virtudes e defeitos

Muitas linhas foram escritas, defensores e detratores, propagandistas de outras metodologias, coachs e consultores tentando vender seu peixe, pintando um monstro, atacando uma metodologia, que como tudo na vida, ela tem seus pros e contras.

Pontos de Função: um pouco sobre métricas. Parte I

Agora nossa agenda conta com 163 cursos gratuitos em diversas tecnologias, para animar ainda mais novos bootcamps e acelerações é muita notícia fantástica, hoje meu trabalho esta próximo do limiar, este é o artigo 99° escrito com muito carinho, uma retribuição a nossa comunidade por tanta coisa recebida, da minha parte venho enriquecer um pouco mais nosso Gruppen com velhas historias de mainframe, preparados? Agora é hora de voltar ao laptop e bora terminar de escrever sobre Ponto de Função. Leia na Integra

O que é J.A.D. - Joint Application Design?

Salve jovem padawan, inspirado no artigo anterior sobre como organizar uma boa reunião. Resolvi aproveitar o gancho e falar sobre uma técnica desenvolvida pelos engenheiros da IBM, nos idos anos 70, que vem passando por inúmeras melhorias ao longo dos anos, sempre visando atender as necessidades que a evoluções tecnológicas apresenta. Leia na Integra

Usando VARCHAR em COBOL

Ajudando enormemente no processamento de grandes áreas de memória e, ao mesmo tempo sendo prático e econômico, ao codificarmos temos que ter em mente, o custo de CPU, a alocação de espaço em disco e memória, afinal em tempos de processamento distribuído, cloude computer e uso indiscriminado de PDAs. Leia na Integra

🌃 O Salaryman como Símbolo da Solidão Moderna

 

🌃 O Salaryman como Símbolo da Solidão Moderna

No Japão, o homem médio veste terno preto e alma cinza.
O salaryman é o retrato da solidão que se aprendeu a disfarçar com rotina.
Ele acorda com o despertador, embarca em silêncio no trem lotado e atravessa a cidade com o olhar fixo no chão.
No meio da multidão, é invisível — e talvez seja esse o ponto.

---

💼 A máscara do dever

A vida do salaryman é uma performance social.
Sorrisos no horário comercial, submissão educada, lealdade ao grupo, gaman — a palavra japonesa para suportar sem reclamar.
Ele não pertence a si mesmo: pertence à empresa, ao cronograma, ao sistema.
A solidão surge não por falta de gente ao redor, mas por falta de espaço para existir como indivíduo.

Nos animes e mangás, essa solidão aparece em olhares cansados e jantares solitários.
Em “Shinya Shokudō”, o restaurante abre só à meia-noite — porque é quando o salaryman finalmente tem um momento para si.
Em “Aggretsuko”, a protagonista grita no karaokê o que jamais diria no escritório: o ódio, o tédio, o desespero de quem finge estar tudo bem.

---

🕯️ Solidão em massa

É um paradoxo moderno: nunca estivemos tão conectados, mas o salaryman vive isolado em meio à multidão.
O trem é uma metáfora perfeita — corpos próximos, almas distantes.
A cidade vibra em energia, mas o indivíduo se apaga.

A cultura japonesa chama isso de “kodoku” (孤独) — solidão profunda, a sensação de estar desconectado mesmo cercado de gente.
Nos anos 90, isso se tornou tema recorrente na arte e nos animes, reflexo de uma geração que viu o colapso da estabilidade econômica e o surgimento de uma nova forma de vazio.

---

🏙️ O silêncio da cidade grande

Os salarymen povoam os izakayas depois do expediente, copos de saquê entre mãos trêmulas.
Conversam sobre o tempo, riem forçado, voltam para casa tarde demais.
Muitos dormem nos bancos da estação. Alguns não voltam — e tornam-se jōhatsu, os evaporados, pessoas que desaparecem da própria vida.

A solidão urbana japonesa é uma epidemia silenciosa, e o salaryman é o seu rosto mais comum.
Ele não é vilão nem vítima — é o produto de uma sociedade que trocou intimidade por eficiência.

---

📺 O reflexo nos animes

Nos animes, o salaryman moderno carrega o peso simbólico do homem que perdeu o propósito, mas continua andando.
Ele não sonha em ser herói. Só quer suportar mais um dia.
A sua história raramente tem clímax — mas há uma beleza nisso: a resistência silenciosa, o cotidiano transformado em poesia mínima.

Obras como “Tokyo Godfathers”, “NHK ni Youkoso!” e “Paranoia Agent” exploram esse vazio com sutileza brutal — personagens quebrados tentando achar sentido em meio ao concreto e às luzes artificiais.

---

💔 O homem que ainda está lá

O salaryman é o homem comum de um mundo extraordinariamente cansado.
Ele carrega o Japão nas costas e o vazio no peito.
Sua solidão é a solidão de todos nós — o medo de parar e perceber que talvez não saibamos mais quem somos sem o trabalho, sem a rotina, sem o uniforme social.

Entre o som dos trilhos e o brilho dos néons, ele segue.
Calado, invisível, mas estranhamente poético.

Uma breve visão sobre Portugol para IBM Mainframe

Neste documento irei apresentar de forma sucinta e pratica os comandos em português estruturado para a resolução dos exercícios de Lógica de Programação. Serão apresentadas as sintaxes mais comuns e básicas para que o aluno iniciante consiga ler e interpretar os comandos antes de codifica-lo em COBOL. Leia na Integra

 

Bellacosa Mainframe e o problema do vendor lock-in

☕🚀 PADAWAN, O QUE É VENDOR LOCK-IN?

Imagine que você comprou uma cafeteira que só aceita cápsulas de uma única marca.

Enquanto tudo funciona, parece ótimo. Mas quando você descobre que as cápsulas são caras, difíceis de encontrar ou a empresa muda as regras, trocar de sistema vira um pesadelo.

Isso é Vendor Lock-In.

Definição Simples

Vendor Lock-In (aprisionamento ao fornecedor) é a situação em que uma empresa se torna tão dependente de uma tecnologia, produto ou fornecedor específico que mudar para outro se torna caro, complexo ou praticamente impossível.

Em outras palavras:

"Entrar foi fácil. Sair virou uma missão impossível."

---

Exemplo do Mundo Mainframe

Imagine um sistema COBOL rodando há 30 anos:

• Milhões de linhas de código

• JCLs personalizados

• CICS

• DB2

• RACF

• Ferramentas de monitoramento específicas

Tudo foi construído para funcionar perfeitamente naquele ambiente.

Migrar para outra plataforma exigiria:

• Reescrever aplicações

• Treinar equipes

• Alterar integrações

• Testar tudo novamente

O custo pode chegar a dezenas ou centenas de milhões de dólares.

Resultado?

A empresa fica "presa" ao fornecedor.

---

Exemplos Modernos

Cloud Computing

Uma empresa usa:

• AWS Lambda

• DynamoDB

• SQS

• Step Functions

Quanto mais utiliza serviços exclusivos da AWS, mais difícil fica migrar para:

• Azure

• Google Cloud

• Oracle Cloud

---

Banco de Dados

Aplicação criada usando recursos específicos do Oracle:

• PL/SQL

• Packages

• Procedures proprietárias

Migrar para PostgreSQL pode exigir anos de trabalho.

---

ERP

Uma empresa adota um ERP gigantesco.

Após anos:

• Processos foram customizados

• Integrações foram criadas

• Equipe foi treinada

Trocar de ERP pode ser mais caro que continuar usando o atual.

---

Como o Lock-In Acontece?

1. Tecnologia Proprietária

Somente aquele fornecedor possui a solução.

Exemplo:

• Linguagem exclusiva

• Banco de dados proprietário

• APIs fechadas

---

2. Dados Difíceis de Exportar

Os dados ficam presos.

Você até consegue sair...

Mas não consegue levar tudo junto.

---

3. Alto Custo de Migração

O sistema funciona tão bem que reescrevê-lo custa uma fortuna.

---

4. Falta de Conhecimento

A equipe só conhece aquela tecnologia.

Treinar todos em outra plataforma custa tempo e dinheiro.

---

Vendor Lock-In é Sempre Ruim?

Não.

Muitas vezes ele é uma consequência natural do sucesso.

Se um banco investiu bilhões em uma plataforma que funciona perfeitamente:

• Alta disponibilidade

• Segurança

• Performance

Talvez não faça sentido trocar.

Nesse caso, o lock-in é um risco controlado.

---

Como Reduzir o Vendor Lock-In?

Use Padrões Abertos

• REST

• JSON

• XML

• SQL padrão

---

Evite Recursos Exclusivos

Quanto mais código específico do fornecedor:

Mais difícil será sair depois.

---

Utilize Containers

• Docker

• Kubernetes

Facilitam mover aplicações entre ambientes.

---

Mantenha Documentação

Muitas empresas descobrem que não conseguem migrar porque ninguém sabe mais como o sistema funciona.

---

Curiosidade Histórica

O termo ganhou força nos anos 1980 e 1990, quando empresas começaram a depender fortemente de:

• IBM

• Oracle

• Microsoft

• SAP

Muitas organizações perceberam que o custo para trocar de fornecedor era maior do que o custo inicial da implementação.

---

☕ A Moral para o Padawan COBOL

Vendor Lock-In não significa que uma tecnologia é ruim.

Significa apenas que:

Quanto mais valor você constrói sobre uma plataforma, mais caro fica abandoná-la.

Isso vale para:

• Mainframe

• Cloud

• ERP

• Banco de Dados

• IA

• Ferramentas DevOps

Até mesmo linguagens modernas podem gerar lock-in.

A verdadeira arquitetura corporativa não busca eliminar completamente o Vendor Lock-In — isso é quase impossível. Ela busca entender, medir e controlar o nível de dependência do fornecedor, para que a empresa tenha opções quando precisar mudar de rumo. 🚀☕

Eastereggs

Sim. Embora o vendor lock-in nem sempre seja ruim, existem casos famosos em que a dependência excessiva de um fornecedor gerou enormes prejuízos, atrasos ou até fracassos de projetos.

☕🚀 1. O Caso Oracle e os Sistemas Legados Governamentais

Diversos governos ao redor do mundo construíram aplicações usando:

• Oracle Database

• Oracle Forms

• Oracle Reports

• PL/SQL

Após 15 ou 20 anos, descobriram que:

• Licenças ficaram muito caras

• Profissionais especializados eram raros

• Migração era extremamente complexa

Em alguns casos, o custo da migração ultrapassava o custo de continuar pagando as licenças.

Resultado:

Milhões gastos apenas para manter sistemas antigos funcionando.

---

☕🚀 2. O Drama do VMware após a Broadcom

Em 2023 a Broadcom adquiriu a VMware.

Muitas empresas possuíam:

• milhares de VMs

• automações

• processos

• treinamento

inteiramente dependentes do ecossistema VMware.

Após mudanças de licenciamento, diversas organizações relataram aumentos expressivos nos custos de renovação. Muitas iniciaram projetos emergenciais para migrar para:

• Hyper-V

• Proxmox

• Nutanix

• OpenShift Virtualization

O problema?

Anos de dependência tornaram a saída lenta e cara.

---

☕🚀 3. O Windows Phone

A Microsoft criou um ecossistema próprio.

Desenvolvedores precisavam:

• ferramentas específicas

• APIs específicas

• marketplace próprio

Quando a plataforma fracassou comercialmente:

• milhares de aplicativos perderam valor

• empresas tiveram que reescrever aplicações para Android e iOS

Foi um lock-in que terminou em um beco sem saída.

---

☕🚀 4. Salesforce Excessivamente Customizado

Muitas empresas adotaram Salesforce.

Depois de anos:

• workflows complexos

• Apex

• integrações proprietárias

ficaram profundamente acoplados.

Em alguns casos a organização descobriu que:

Trocar de CRM custaria mais do que continuar pagando o Salesforce.

O fornecedor virou praticamente parte da arquitetura da empresa.

---

☕🚀 5. SAP e os Projetos Bilionários

Existem empresas que investiram centenas de milhões de dólares em customizações SAP.

Anos depois:

• a versão ficou obsoleta

• o fabricante mudou a estratégia

• surgiu a necessidade de migrar para S/4HANA

Muitas organizações enfrentaram projetos enormes de conversão.

Algumas gastaram mais na migração do que no projeto original.

---

☕🚀 6. AWS e o "Cloud Shock"

Na década de 2010 muitas empresas migraram rapidamente para a AWS.

Utilizaram serviços exclusivos como:

• Lambda

• DynamoDB

• Aurora

• Step Functions

Anos depois perceberam que:

• custos cresceram

• negociar preços ficou difícil

• migrar para Azure ou GCP exigiria reescrever aplicações inteiras

Nasceu o movimento chamado:

Cloud Repatriation

Ou seja:

trazer sistemas de volta para datacenters próprios.

---

☕🚀 7. O Fracasso do Google App Engine Original

Nos primeiros anos, o Google App Engine exigia uma arquitetura bastante específica.

Muitas aplicações foram escritas para aquele modelo.

Quando as necessidades cresceram:

• migrar para outras clouds era complicado

• várias empresas reescreveram aplicações inteiras

Foi uma das razões para a popularização dos containers e Kubernetes.

---

☕🚀 8. Lotus Notes

Quem viveu os anos 90 e 2000 conhece.

Muitas empresas criaram:

• workflows

• aplicações

• bases documentais

inteiramente dentro do Lotus Notes.

Quando surgiu a necessidade de migrar:

• milhares de aplicações precisaram ser convertidas

• regras de negócio estavam escondidas nos bancos Notes

Alguns projetos levaram anos.

---

☕🚀 9. Mainframe: O Lock-In Mais Famoso (e Talvez o Mais Justificado)

Muitos executivos enxergam o Mainframe como exemplo clássico de lock-in.

Mas existe um detalhe interessante:

Os bancos normalmente permanecem porque:

• funciona

• é seguro

• é rápido

• processa bilhões de transações

Muitas tentativas de migração fracassaram porque o custo era gigantesco.

Um exemplo famoso foi o esforço de alguns bancos europeus e seguradoras que investiram centenas de milhões de euros em projetos de "saída do mainframe" e acabaram cancelando ou reduzindo o escopo após anos de trabalho.

O lock-in existia.

Mas o valor entregue pelo sistema também.

---

☕🚀 O Caso Mais Trágico: Quando o Fornecedor Morre

Existe algo ainda pior.

Imagine:

• software proprietário

• banco de dados proprietário

• fabricante pequeno

A empresa fecha as portas.

Agora você possui:

• sistema crítico

• sem suporte

• sem código-fonte

• sem atualização

Isso aconteceu inúmeras vezes com ERPs regionais, softwares hospitalares e sistemas industriais.

Nesse momento o vendor lock-in vira um risco existencial.

---

☕ A Grande Lição

O maior prejuízo não ocorre quando você compra uma tecnologia proprietária.

O maior prejuízo ocorre quando você constrói toda a sua estratégia acreditando que nunca precisará sair dela.

Os maiores desastres de TI costumam acontecer quando a organização descobre, tarde demais, que:

"Entrar levou seis meses. Sair levará seis anos e custará dez vezes mais." 🚀☕