Translate

quinta-feira, 3 de maio de 2007

O que é Downsize?

 

Bellacosa Mainframe o que é downsize

O que é Downsize?

Imagine que uma empresa possui um enorme IBM Mainframe responsável por processar sua folha de pagamento.

Um fornecedor promete:

"Vocês podem substituir todo esse Mainframe por dezenas de servidores menores, gastando menos."

A empresa aceita.

Os programas COBOL são convertidos.

Os dados são migrados.

Os servidores UNIX, Windows ou Linux passam a executar aquilo que antes era feito pelo IBM Z.

Esse processo ficou conhecido como Downsizing.

Durante as décadas de 1980 e principalmente 1990, ele foi considerado por muitos como o "futuro da informática". Entretanto, a experiência mostrou que a realidade era muito mais complexa.


Definição simples

Downsize (ou Downsizing) é a estratégia de substituir um computador de grande porte, normalmente um Mainframe, por servidores menores distribuídos.

Em outras palavras:

É a migração de uma arquitetura centralizada para outra baseada em servidores menores.


Origem da palavra

A palavra inglesa Downsizing significa literalmente:

"Reduzir de tamanho".

Na informática, ela passou a representar a troca de um grande computador por vários computadores menores.


Uma analogia simples

Imagine uma grande usina hidrelétrica.

Ela fornece energia para uma cidade inteira.

Agora imagine desligar essa usina e substituí-la por centenas de pequenos geradores espalhados pela cidade.

Funciona?

Pode funcionar.

Mas será necessário coordenar:

  • combustível;

  • manutenção;

  • sincronização;

  • distribuição;

  • monitoramento.

É exatamente esse desafio que ocorre no Downsizing.


Como funciona?

Antes:

Usuários

↓

IBM Mainframe

↓

COBOL

↓

Db2

↓

Processamento

Depois:

Usuários

↓

Load Balancer

↓

Servidor 1

Servidor 2

Servidor 3

Servidor 4

↓

Banco de Dados

O processamento deixa de ser centralizado.


Por que surgiu?

Na década de 1990, vários fatores incentivaram essa estratégia:

  • servidores ficaram mais baratos;

  • processadores Intel evoluíram rapidamente;

  • UNIX e Windows Server ganharam espaço;

  • arquitetura cliente-servidor tornou-se popular;

  • acreditava-se que Mainframes desapareceriam.

Na época, muitos chegaram a prever o "fim do Mainframe".

Essa previsão não se confirmou.


O objetivo

As empresas esperavam:

  • reduzir custos;

  • comprar hardware mais barato;

  • usar tecnologias abertas;

  • contratar mais profissionais;

  • aumentar a flexibilidade.

Na teoria parecia uma excelente ideia.


O que aconteceu?

Em muitos projetos ocorreram problemas como:

  • custo de migração muito alto;

  • reescrita de milhões de linhas COBOL;

  • perda de regras de negócio;

  • desempenho inferior;

  • aumento da complexidade;

  • maior indisponibilidade;

  • crescimento dos custos operacionais.

Diversas organizações perceberam que o custo total de propriedade (TCO) não caiu como esperado.


Exemplo bancário

Imagine um sistema que processa:

  • cartões;

  • PIX;

  • TED;

  • folha de pagamento;

  • investimentos.

No Mainframe:

  • tudo ocorre no mesmo ambiente;

  • segurança centralizada;

  • backup unificado;

  • alta disponibilidade.

Após o Downsizing:

  • dezenas ou centenas de servidores;

  • diversos bancos de dados;

  • múltiplos sistemas operacionais;

  • replicação;

  • sincronização;

  • monitoramento distribuído.

A arquitetura pode ganhar flexibilidade, mas também aumenta a quantidade de componentes a administrar.


Downsize x Modernização

Muita gente confunde.

Downsizing

Troca completamente a plataforma.

IBM Z

↓

Linux

Modernização

Mantém o Mainframe.

Integra novas tecnologias.

Aplicativo

↓

API

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

Db2

Hoje a modernização é muito mais comum do que um downsizing completo.


Vantagens

Quando bem planejado, o Downsizing pode oferecer:

  • maior liberdade tecnológica;

  • facilidade para utilizar plataformas abertas;

  • ampla oferta de profissionais;

  • escalabilidade horizontal;

  • integração simplificada com determinadas soluções.


Desvantagens

Também existem desafios importantes:

  • migração complexa;

  • alto custo do projeto;

  • risco de interrupções;

  • necessidade de reescrever aplicações;

  • aumento da administração da infraestrutura;

  • perda de desempenho em cargas altamente transacionais.


O papel do COBOL

Um erro comum foi imaginar que bastava converter programas COBOL para outra linguagem.

Na prática, o código era apenas parte do problema.

O maior desafio era preservar décadas de regras de negócio incorporadas às aplicações.


Curiosidades

1. O Downsizing foi um dos maiores movimentos da história da TI

Entre os anos 1990 e o início dos anos 2000, milhares de empresas iniciaram projetos para substituir grandes computadores por servidores distribuídos.


2. Nem todos os projetos foram bem-sucedidos

Algumas migrações reduziram custos e aumentaram a flexibilidade. Outras enfrentaram atrasos, estouros de orçamento e perda de desempenho, tornando-se casos estudados em engenharia de software e gestão de projetos.


3. O Mainframe não desapareceu

Ao contrário das previsões da época, o IBM Z continua sendo amplamente utilizado em bancos, seguradoras, governos e grandes empresas para cargas críticas.


4. Hoje fala-se mais em modernização do que em Downsizing

A tendência atual é integrar Mainframes com APIs REST, microsserviços, containers, nuvem híbrida e Inteligência Artificial, preservando as aplicações críticas que já funcionam bem.


Erros comuns de iniciantes

"Downsize significa apenas comprar um computador menor"

Não.

Ele envolve mudanças de arquitetura, software, infraestrutura, banco de dados, processos e, muitas vezes, reescrita de aplicações.


"Todo sistema deve passar por Downsizing"

Também não.

A decisão depende de fatores como custo, desempenho, riscos, requisitos regulatórios e estratégia da empresa.


"Downsizing é o oposto de Mainframe"

Não exatamente.

Ele é uma estratégia de migração. Muitas organizações mantêm uma arquitetura híbrida, em que Mainframes convivem com servidores distribuídos e serviços em nuvem.


Quando estudar Downsizing?

Depois de aprender:

  1. Arquitetura Mainframe.

  2. Sistemas Legados.

  3. Engenharia de Software.

  4. COBOL.

  5. CICS.

  6. Db2.

  7. APIs REST.

  8. Computação Distribuída.

  9. Arquiteturas Híbridas.

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

Esse conhecimento ajuda a compreender por que tantas empresas optam por preservar seus sistemas centrais enquanto evoluem gradualmente a arquitetura.


Downsizing x Rightsizing x Modernização

Hoje é comum distinguir três estratégias:

  • Downsizing: migração de um grande computador para servidores menores.

  • Rightsizing: escolher a plataforma mais adequada para cada carga de trabalho, sem a obrigação de abandonar o Mainframe.

  • Modernização: manter os sistemas legados e integrá-los a tecnologias atuais, como APIs, nuvem híbrida e IA.

Muitas organizações adotam uma combinação dessas abordagens, mantendo no IBM Z as aplicações críticas e distribuindo outras cargas para plataformas diferentes.


Conclusão

O Downsizing marcou uma importante fase da evolução da tecnologia da informação, impulsionando a adoção de arquiteturas cliente-servidor e plataformas distribuídas. Embora tenha trazido benefícios em determinados cenários, também revelou que substituir um Mainframe envolve muito mais do que trocar hardware: significa migrar regras de negócio, processos, integrações e décadas de conhecimento acumulado.

Hoje, em vez de substituir completamente os sistemas centrais, a maioria das grandes empresas prefere estratégias de modernização e arquiteturas híbridas, aproveitando a confiabilidade do IBM Z enquanto incorpora APIs, microsserviços, computação em nuvem e Inteligência Artificial. Assim, o Mainframe continua desempenhando um papel essencial nas operações mais críticas do mundo corporativo.

quarta-feira, 2 de maio de 2007

O que é Software Legado?

 

Bellacosa Mainframe o que é software legado

O que é Software Legado?

Imagine entrar em um banco e descobrir que o sistema responsável por movimentar bilhões de reais diariamente começou a ser desenvolvido na década de 1980.

Ele continua funcionando.

Continua recebendo novas funcionalidades.

Continua sendo atualizado.

Continua extremamente confiável.

Esse é um exemplo clássico de software legado.

Ao contrário do que muitas pessoas imaginam, um sistema legado não é necessariamente velho, ruim ou ultrapassado. Em muitos casos, ele representa o coração da operação de grandes empresas.

No universo Mainframe, praticamente todas as grandes instituições financeiras, seguradoras, companhias aéreas, operadoras de telecomunicações e órgãos governamentais convivem diariamente com sistemas legados.


Definição simples

Um software legado é um sistema que continua sendo utilizado por uma organização porque ainda atende às necessidades do negócio, mesmo tendo sido desenvolvido com tecnologias, arquiteturas ou práticas de outra época.

Em outras palavras:

Software legado é um sistema que continua gerando valor para o negócio, independentemente de sua idade.


Uma analogia simples

Imagine uma locomotiva construída há cinquenta anos.

Ela recebe:

  • novos motores;

  • novos sistemas de freio;

  • pintura moderna;

  • equipamentos eletrônicos.

Ela continua antiga?

Sim.

Ela continua útil?

Também.

O mesmo acontece com muitos sistemas Mainframe.


O que caracteriza um Software Legado?

Nem todo sistema antigo é legado.

Normalmente ele possui algumas características:

  • muitos anos de operação;

  • importância crítica para a empresa;

  • milhares ou milhões de usuários;

  • documentação parcial;

  • diversas manutenções ao longo do tempo;

  • integração com outros sistemas;

  • alto custo de substituição.


Exemplo em um banco

Imagine um sistema COBOL criado em 1989.

Ele controla:

  • contas correntes;

  • pagamentos;

  • TED;

  • PIX;

  • cartões;

  • empréstimos.

Durante décadas foram adicionadas novas funcionalidades.

Hoje ele conversa com:

  • APIs REST;

  • aplicativos móveis;

  • Internet Banking;

  • Open Finance;

  • serviços em nuvem.

Mesmo moderno em vários aspectos, sua base continua sendo um software legado.


Como um software se torna legado?

O processo normalmente acontece assim:

Sistema Novo

↓

Entrou em Produção

↓

Recebe Atualizações

↓

Recebe Novas Funções

↓

Integra Novos Sistemas

↓

Passam 10, 20 ou 30 anos

↓

Software Legado

Ser legado é consequência do tempo e da continuidade do uso, não um defeito.


Software legado não significa software abandonado

Esse é um dos maiores mitos.

Existem sistemas COBOL que recebem atualizações diariamente.

Novos programas.

Novas APIs.

Novas telas.

Novas integrações.

Novos bancos de dados.

Mesmo assim continuam sendo considerados legados.


Exemplos de Software Legado

Em grandes empresas encontramos sistemas como:

  • processamento bancário;

  • folha de pagamento;

  • previdência;

  • arrecadação de impostos;

  • seguros;

  • reservas aéreas;

  • faturamento;

  • controle industrial;

  • telecomunicações.

Todos podem possuir décadas de evolução contínua.


No Mainframe

Os sistemas legados costumam utilizar tecnologias como:

  • COBOL;

  • PL/I;

  • Assembler;

  • CICS;

  • IMS;

  • Db2;

  • VSAM;

  • JCL;

  • MQ;

  • z/OS.

Hoje muitos deles também utilizam:

  • APIs REST;

  • JSON;

  • Java;

  • Python;

  • Kafka;

  • containers;

  • nuvem híbrida.


Por que não substituir tudo?

Essa pergunta aparece frequentemente.

A resposta é simples:

Porque normalmente é muito mais caro e arriscado.

Imagine substituir um sistema que:

  • possui 40 milhões de linhas COBOL;

  • processa bilhões de transações por dia;

  • está em produção há 35 anos;

  • atende milhões de clientes.

A migração pode levar muitos anos e envolver riscos elevados.


Vantagens dos sistemas legados

Estabilidade

Foram testados durante anos em produção.


Confiabilidade

Processam milhões de transações diariamente.


Regras de negócio maduras

Grande parte do conhecimento da empresa está implementada nesses sistemas.


Alto desempenho

Mainframes IBM Z conseguem processar enormes volumes de dados com baixa latência e alta disponibilidade.


Segurança

Possuem mecanismos robustos de autenticação, auditoria e controle de acesso.


Desafios

Nem tudo são vantagens.

Os desafios incluem:

  • documentação incompleta;

  • profissionais experientes se aposentando;

  • código muito extenso;

  • integração com tecnologias modernas;

  • dificuldade para encontrar especialistas.


Modernização

Em vez de substituir tudo, muitas empresas optam por modernizar.

Exemplos:

Aplicativo

↓

API REST

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

Db2

O usuário enxerga um aplicativo moderno.

O processamento continua sendo realizado pelo sistema legado.


Curiosidades

1. A maioria das transações financeiras passa por sistemas legados

Grande parte das operações bancárias, cartões de crédito, transferências e seguros ainda é processada por aplicações desenvolvidas há muitos anos e continuamente evoluídas.


2. "Legado" não significa obsoleto

Um software pode ser legado e, ao mesmo tempo, utilizar APIs, microsserviços, DevOps e computação em nuvem.


3. Muitos sistemas nunca foram reescritos

Eles evoluíram continuamente por décadas, incorporando novas tecnologias sem perder a base original.


4. IBM Z é especialista em executar software legado

Uma das maiores forças da plataforma IBM Z é manter compatibilidade com aplicações desenvolvidas décadas atrás, permitindo que elas convivam com tecnologias modernas.


Erros comuns de iniciantes

"Software legado é software ruim"

Não.

Existem sistemas legados extremamente bem projetados e mantidos.


"Todo software antigo deve ser reescrito"

Nem sempre.

Muitas reescritas fracassam porque tentam reproduzir décadas de regras de negócio acumuladas.


"Legado impede inovação"

Também não.

Hoje é comum integrar sistemas COBOL com APIs REST, aplicações Java, Python, microsserviços, Open Finance e soluções de Inteligência Artificial.


Quando estudar Software Legado?

Depois de aprender:

  1. Lógica de Programação.

  2. Engenharia de Software.

  3. Requisitos.

  4. Análise Funcional.

  5. Arquitetura de Software.

  6. COBOL.

  7. CICS.

  8. Db2.

  9. APIs REST.

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

Assim você compreenderá por que tantos sistemas permanecem ativos por décadas e como evoluí-los sem comprometer a operação do negócio.


Legado x Modernização

Um dos maiores equívocos é imaginar que a única alternativa para um software legado seja descartá-lo. Na prática, a estratégia mais comum é a modernização incremental: preservar o que funciona bem, melhorar gradualmente a arquitetura, expor novas APIs, automatizar testes, adotar DevOps e integrar o sistema a tecnologias atuais.

Essa abordagem reduz riscos, protege o conhecimento acumulado e permite que a empresa continue inovando sem interromper operações críticas.


Conclusão

O software legado é um sistema que permanece em uso porque continua sendo essencial para o negócio. Sua idade não determina sua qualidade; o que realmente importa é sua capacidade de entregar valor, processar operações com segurança e evoluir ao longo do tempo.

No universo IBM Mainframe, os sistemas legados representam décadas de conhecimento de negócio, estabilidade e confiabilidade. Em vez de serem vistos como um obstáculo, eles são frequentemente a base sobre a qual novas tecnologias — como APIs REST, aplicações móveis, computação em nuvem e Inteligência Artificial — são construídas. Saber compreender, manter e modernizar software legado é uma das habilidades mais valiosas para um Analista ou Programador Mainframe.

terça-feira, 1 de maio de 2007

O que é Dívida Técnica?

 

Bellacosa Mainframe o que é divida tecnica

O que é Dívida Técnica?

Imagine que um banco precisa colocar uma nova funcionalidade em produção até sexta-feira.

O sistema precisa permitir que um cliente solicite um novo tipo de empréstimo.

A equipe percebe que, para fazer tudo corretamente, seriam necessárias três semanas de trabalho.

Mas a diretoria responde:

"Façam funcionar até sexta. Depois melhoramos."

Os desenvolvedores então criam uma solução provisória.

Ela funciona.

Os testes passam.

O cliente fica satisfeito.

Porém...

O código ficou mais difícil de entender, existem duplicações, alguns padrões foram ignorados e a documentação não foi atualizada.

Essa diferença entre o ideal e o que realmente foi entregue é chamada de Dívida Técnica.


Definição simples

A Dívida Técnica é o custo futuro causado por decisões técnicas tomadas para entregar uma solução mais rapidamente ou com menos qualidade do que o ideal.

Assim como uma dívida financeira, ela pode ser útil em situações específicas, mas gera "juros" se não for paga.

Em outras palavras:

É um atalho que economiza tempo hoje, mas aumenta o trabalho amanhã.


Por que o nome "dívida"?

A comparação foi criada pelo programador Ward Cunningham, um dos autores do Manifesto Ágil.

A ideia é simples:

  • Você "pega emprestado" tempo hoje.

  • Entrega mais rápido.

  • Depois precisa "pagar" essa dívida corrigindo o código.

Quanto mais tempo passa, maiores são os "juros".


Uma analogia simples

Imagine comprar uma casa.

Você pode:

  • construir uma fundação sólida;

  • usar bons materiais;

  • fazer tudo corretamente.

Ou pode:

  • economizar no concreto;

  • usar materiais mais baratos;

  • terminar rapidamente.

A casa ficará pronta.

Mas anos depois surgirão:

  • rachaduras;

  • infiltrações;

  • reformas caras.

No software acontece exatamente o mesmo.


Como surge a Dívida Técnica?

Ela aparece quando fazemos escolhas como:

  • copiar código em vez de reutilizá-lo;

  • ignorar testes automatizados;

  • deixar documentação para depois;

  • não remover código antigo;

  • usar soluções provisórias como definitivas;

  • adiar refatorações;

  • aceitar más práticas por causa do prazo.


Exemplo em COBOL

Imagine um programa de cálculo de juros.

Em vez de criar uma rotina reutilizável, o programador copia o mesmo código para dez programas diferentes.

Hoje parece mais rápido.

Daqui a seis meses, quando a regra mudar, será necessário alterar os dez programas.

Isso é Dívida Técnica.


Outro exemplo

Uma tabela Db2 precisa ser reorganizada.

Como o ambiente está estável, ninguém executa o REORG.

Meses depois:

  • consultas ficam lentas;

  • índices crescem;

  • jobs aumentam de duração.

A manutenção adiada gerou uma dívida operacional que afeta o desempenho.


Exemplo no CICS

Uma transação recebe milhares de acessos.

Para atender ao prazo:

  • não foi feita análise de performance;

  • nenhuma otimização foi realizada;

  • o programa faz leituras repetidas no Db2.

Funciona.

Mas o consumo de CPU cresce diariamente.

Mais uma dívida técnica.


Como ela cresce?

Imagine este ciclo:

Prazo apertado

↓

Solução rápida

↓

Entrega

↓

Código difícil

↓

Mais manutenção

↓

Mais tempo gasto

↓

Nova solução rápida

↓

Mais dívida

Esse ciclo pode durar anos se a dívida nunca for tratada.


Principais tipos de Dívida Técnica

1. Código

  • duplicação;

  • complexidade excessiva;

  • nomes confusos;

  • falta de modularização.


2. Arquitetura

  • integração mal planejada;

  • dependências desnecessárias;

  • excesso de acoplamento.


3. Banco de Dados

  • índices inadequados;

  • tabelas mal modeladas;

  • ausência de normalização;

  • consultas ineficientes.


4. Infraestrutura

  • versões antigas;

  • bibliotecas desatualizadas;

  • servidores sem atualização;

  • configurações improvisadas.


5. Documentação

  • fluxogramas inexistentes;

  • requisitos desatualizados;

  • diagramas incompletos.


6. Testes

  • pouca cobertura;

  • testes manuais excessivos;

  • ausência de testes automatizados.


No Mainframe

A Dívida Técnica pode aparecer em:

  • programas COBOL gigantes com dezenas de milhares de linhas;

  • JCLs duplicados;

  • PROC repetidas;

  • VSAM mal estruturado;

  • SQL ineficiente;

  • índices Db2 inadequados;

  • transações CICS muito pesadas;

  • documentação antiga;

  • rotinas sem comentários;

  • interfaces MQ improvisadas.


Sinais de alerta

Alguns sintomas indicam que a dívida técnica está crescendo:

  • cada alteração demora mais;

  • surgem muitos defeitos após mudanças;

  • ninguém entende o código;

  • apenas um especialista consegue manter o sistema;

  • a documentação está desatualizada;

  • o desempenho piora constantemente;

  • há medo de modificar programas antigos.


Como reduzir a Dívida Técnica?

Refatoração

Melhorar o código sem alterar seu comportamento.


Documentação

Atualizar:

  • requisitos;

  • fluxogramas;

  • diagramas;

  • manuais.


Testes

Criar testes automatizados para reduzir riscos.


Revisão de Código

Outro desenvolvedor analisa o código antes da entrega, identificando problemas e oportunidades de melhoria.


Padronização

Adotar convenções de nomenclatura, arquitetura e desenvolvimento para evitar soluções diferentes para o mesmo problema.


Manutenção preventiva

Reservar tempo em cada projeto para corrigir problemas antigos, em vez de apenas adicionar novas funcionalidades.


Dívida Técnica é sempre ruim?

Não.

Em algumas situações, ela é uma decisão consciente.

Por exemplo:

  • corrigir rapidamente uma falha crítica em produção;

  • atender uma exigência legal com prazo curto;

  • restaurar um serviço essencial após uma indisponibilidade.

Nesses casos, a equipe assume a dívida sabendo que ela será tratada posteriormente.

O problema surge quando ela é esquecida.


Curiosidades

1. Todo sistema possui alguma Dívida Técnica

Mesmo aplicações muito bem desenvolvidas acumulam pequenas dívidas ao longo dos anos.


2. Sistemas Mainframe podem carregar décadas de dívida

É comum encontrar aplicações COBOL criadas nos anos 1980 que receberam centenas de alterações sem uma refatoração completa.


3. Dívida Técnica também afeta infraestrutura

Ela não está apenas no código. Ambientes, automações, documentação e processos também podem acumular dívida.


4. IA ajuda a identificar Dívidas Técnicas

Ferramentas modernas conseguem detectar duplicação de código, funções muito complexas, SQL ineficiente e oportunidades de refatoração.


Erros comuns de iniciantes

"Código antigo é automaticamente Dívida Técnica"

Não.

Um programa COBOL de 30 anos pode ser extremamente bem escrito, documentado e de fácil manutenção.

A idade do código não determina sua qualidade.


"Toda solução rápida é ruim"

Também não.

Uma solução emergencial pode ser a escolha correta, desde que exista um plano para revisá-la depois.


"Só programadores criam Dívida Técnica"

Não.

Analistas, arquitetos, gestores e até decisões de negócio podem contribuir para seu surgimento ao impor prazos irrealistas ou adiar investimentos.


Quando estudar Dívida Técnica?

Depois de aprender:

  1. Lógica de Programação.

  2. Engenharia de Software.

  3. Requisitos.

  4. Análise Funcional.

  5. Arquitetura de Software.

  6. COBOL.

  7. CICS.

  8. Db2.

  9. DevOps e Integração Contínua.

Esse conhecimento ajuda a equilibrar velocidade de entrega e qualidade, evitando que pequenas concessões se transformem em grandes problemas no futuro.


Conclusão

A Dívida Técnica representa o custo futuro gerado por decisões que priorizam rapidez em detrimento da qualidade ideal do software. Em ambientes Mainframe, onde aplicações COBOL, CICS, Db2 e JCL permanecem em produção por décadas, administrar essa dívida é essencial para garantir sistemas estáveis, seguros e de fácil manutenção.

Uma equipe madura não busca eliminar toda dívida técnica, mas sim identificá-la, documentá-la, priorizá-la e reduzi-la continuamente. Assim como uma dívida financeira pode ser administrada com responsabilidade, a dívida técnica também pode ser controlada para que o sistema continue evoluindo sem comprometer a confiabilidade do negócio.

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