 |
| Bellacosa Mainframe em um visao do dbb e zbuilder |
☕ DBB e zBuilder: Os Jedi Invisíveis da Modernização IBM Z
Quando a Galáxia Fala de IA, OpenShift e APIs, Mas Esquece Quem Realmente Constrói o Sabre de Luz
Por Vagner Bellacosa – Bellacosa Mainframe
Existe uma cena recorrente no universo da tecnologia corporativa contemporânea.
Um executivo sobe ao palco de um grande evento. Atrás dele aparecem imagens futuristas de nuvens híbridas, containers rodando em OpenShift, dashboards coloridos alimentados por Inteligência Artificial Generativa, modelos LLM analisando código COBOL e APIs REST conectando sistemas legados a aplicativos móveis.
A plateia aplaude.
Os fornecedores sorriem.
Os analistas produzem relatórios.
Os CIOs aprovam investimentos milionários.
E, em algum canto silencioso de um datacenter refrigerado, um desenvolvedor COBOL continua aguardando que alguém compile seu programa utilizando um processo criado quando Ronald Reagan ainda era presidente dos Estados Unidos.
Talvez seja exatamente aí que esteja um dos maiores paradoxos da modernização do Mainframe.
Todos querem modernizar aplicações.
Poucos querem modernizar a engenharia que produz essas aplicações.
E talvez seja por isso que IBM Dependency Based Build (DBB) e zBuilder continuem sendo duas das tecnologias mais importantes, poderosas e menos discutidas do ecossistema IBM Z.
A Modernização que o Mercado Enxerga
Quando falamos em transformação digital associada ao Mainframe, normalmente escutamos frases semelhantes a estas:
"Precisamos expor COBOL como APIs."
"Vamos colocar CICS atrás de um API Gateway."
"Devemos integrar IBM Z ao OpenShift."
"Precisamos utilizar IA Generativa para entender programas legados."
"Vamos migrar workloads para a nuvem híbrida."
Tudo isso possui valor.
Tudo isso representa avanços importantes.
Mas existe uma pergunta quase filosófica que raramente aparece nas apresentações corporativas.
Como essas aplicações são construídas hoje?
A resposta costuma ser desconfortável.
Em muitas organizações ainda encontramos processos semelhantes a este:
Desenvolvedor altera programa COBOL.
↓
Salva em um PDS.
↓
Executa compile manual.
↓
Submete JCL.
↓
Espera aprovação.
↓
Abre chamado.
↓
Aguarda CAB.
↓
Equipe operacional promove.
↓
Produção.
Se substituirmos COBOL por Java, Python ou Go, provavelmente qualquer desenvolvedor moderno consideraria esse fluxo algo retirado de um museu de informática.
No entanto, em centenas de empresas ao redor do mundo, essa ainda é a realidade operacional.
Enquanto equipes cloud utilizam GitHub Actions, GitLab Pipelines, ArgoCD, Tekton e GitOps, muitos ambientes z/OS permanecem dependentes de mecanismos desenvolvidos em uma época em que a palavra DevOps sequer existia.
O Mainframe Não Precisa Ser Modernizado. A Engenharia Sim.
Esta talvez seja a primeira provocação importante deste artigo.
O IBM Z já é extremamente moderno.
Executa Linux.
Possui aceleração para IA.
Executa containers.
Suporta APIs.
Possui criptografia embarcada.
Disponibiliza telemetria avançada.
Integra-se com Kubernetes.
Suporta OpenShift.
Conecta-se com praticamente qualquer ecossistema corporativo.
O problema raramente está na plataforma.
O problema está na forma como produzimos software para essa plataforma.
Em outras palavras:
Não basta transformar programas COBOL em APIs.
Precisamos transformar desenvolvedores Mainframe em engenheiros de software do século XXI.
IBM DBB: O Maven que Nasceu em z/OS
IBM Dependency Based Build surgiu justamente para resolver esse problema.
Muitas pessoas imaginam que DBB seja apenas um mecanismo de compilação.
Na prática, ele é muito mais do que isso.
DBB representa uma mudança conceitual profunda.
Historicamente, ambientes Mainframe trabalhavam com builds completos.
Alterou um copybook?
Compila tudo.
Mudou uma tabela?
Compila tudo.
Atualizou uma rotina compartilhada?
Compila tudo.
Imagine um banco contendo dois mil programas COBOL.
Um único COPY chamado CLIENTE é utilizado em mil e duzentos programas.
Uma alteração de dois bytes nesse copybook pode disparar uma compilação massiva.
Horas de processamento.
Centenas de datasets temporários.
JES2 congestionado.
Fila de builds aumentando.
DBB muda completamente essa lógica.
Ele constrói um grafo de dependências.
Algo semelhante ao que Maven, Gradle ou Bazel fazem há anos no mundo distribuído.
O DBB entende que:
CLIENTE
é utilizado por
COB001
COB017
COB105
COB221
COB998
Logo, apenas esses componentes precisam ser recompilados.
O ganho operacional pode ser gigantesco.
Horas podem transformar-se em minutos.
Dias podem transformar-se em horas.
O Encanamento que Ninguém Mostra no LinkedIn
Existe uma razão interessante para DBB receber relativamente pouca atenção.
Ferramentas de build são invisíveis.
Ninguém publica uma foto dizendo:
"Olhem meu maravilhoso sistema hidráulico."
As pessoas mostram a piscina.
Mostram a fachada.
Mostram o jardim.
DBB é o encanamento.
Sem ele, a casa não funciona.
Mas dificilmente aparece na propaganda.
Executivos não compram compiladores.
Executivos compram redução de risco.
Compram velocidade.
Compram governança.
Compram previsibilidade.
Compram auditoria.
Compram produtividade.
DBB entrega exatamente isso.
O Desafio do Groovy
Historicamente, muitas implementações DBB foram construídas utilizando Groovy.
Algo como:
buildProgram("COB001")
compile()
link()
package()
Para equipes acostumadas ao universo z/OS isso pode ser aceitável.
Mas estamos vivendo uma nova era.
A era do Platform Engineering.
E Platform Engineers respiram YAML.
Respiram GitOps.
Respiram Infrastructure as Code.
Respiram Kubernetes.
Respiram ArgoCD.
Respiram Tekton.
Respiram Ansible.
Respiram pipelines declarativos.
Nesse contexto, surge um novo protagonista.
zBuilder: O YAML Desperta na Força
Talvez zBuilder seja uma das iniciativas mais promissoras do ecossistema IBM Z atual.
Sua proposta é elegantemente simples.
Trocar imperatividade por declaratividade.
Trocar scripts complexos por descrições legíveis.
Ao invés de dezenas de linhas em Groovy, podemos imaginar algo semelhante a:
application:
name: BANKAPP
languages:
- COBOL
- PL1
- JCL
test:
zunit
deploy:
cics
Subitamente, o Mainframe começa a falar o mesmo idioma das equipes cloud.
E isso é muito poderoso.
Porque YAML tornou-se praticamente a língua franca da engenharia moderna.
Kubernetes utiliza YAML.
OpenShift utiliza YAML.
GitHub Actions utiliza YAML.
Ansible utiliza YAML.
ArgoCD utiliza YAML.
Crossplane utiliza YAML.
Tekton utiliza YAML.
Terraform possui sintaxe declarativa semelhante.
Platform Engineering gira em torno desse paradigma.
O Surgimento do GitOps Mainframe
Talvez este seja o próximo estágio evolutivo da engenharia IBM Z.
Durante décadas o repositório oficial era um PDS.
Hoje ele pode ser Git.
Antes:
PDS
↓
Compile
↓
Promotion
Agora:
Git
↓
Pull Request
↓
Review
↓
Pipeline
↓
Testes
↓
Security Scan
↓
Deploy
Exatamente igual ao mundo Java.
Exatamente igual ao mundo Python.
Exatamente igual ao universo Go.
Exatamente igual ao desenvolvimento cloud-native.
Isso reduz uma barreira psicológica importante.
O Mainframe deixa de parecer um ambiente exótico.
Passa a parecer apenas mais uma plataforma suportada pelo pipeline corporativo.
DevSecOps Não É Opcional
Durante muitos anos o Mainframe foi considerado seguro por definição.
E, de certa forma, ele realmente é.
RACF.
Criptografia.
Auditoria.
SMF.
Segurança robusta.
Porém, DevSecOps não trata apenas da segurança da plataforma.
Trata da segurança do ciclo de desenvolvimento.
Podemos imaginar pipelines semelhantes a:
Git
↓
DBB
↓
ZUnit
↓
SonarQube
↓
Checkmarx
↓
SBOM
↓
Artifact Repository
↓
Approval
↓
Deploy
Agora COBOL participa das mesmas políticas utilizadas pelo restante da organização.
Existe rastreabilidade.
Existe compliance.
Existe análise estática.
Existe assinatura digital.
Existe inventário de componentes.
Existe governança corporativa.
O Grande Equívoco da Modernização
Talvez o maior erro cometido por algumas organizações seja acreditar que modernização significa abandonar Mainframe.
Na prática, a maior parte dos projetos bem-sucedidos mostra exatamente o oposto.
Modernizar significa aumentar a capacidade de evolução do Mainframe.
Transformá-lo em uma plataforma capaz de competir pela atenção dos novos desenvolvedores.
Se um profissional de vinte e cinco anos consegue utilizar VS Code, GitHub, Pull Request, pipelines automatizados, Zowe, OpenShift e YAML para desenvolver COBOL, a experiência muda completamente.
Ele deixa de enxergar IBM Z como um fóssil tecnológico.
Passa a enxergá-lo como um backend extremamente robusto conectado a práticas modernas.
A Analogia dos Jedi
Talvez DBB e zBuilder possam ser comparados aos técnicos responsáveis por construir os sabres de luz dos Jedi.
Nos filmes, a atenção está sempre voltada para o duelo.
Para a batalha espacial.
Para os poderes da Força.
Pouco se fala sobre os artesãos que produziram as armas.
Mas sem eles não existiria batalha.
Não existiria Ordem Jedi.
Não existiria legado.
DBB e zBuilder desempenham papel semelhante.
Não aparecem em demonstrações de IA.
Não aparecem em apresentações sobre OpenShift.
Não aparecem em propagandas de APIs.
Mas tornam possível algo muito mais importante.
Permitem que a engenharia IBM Z participe plenamente do movimento DevSecOps corporativo.
Considerações Finais
A pergunta original permanece extremamente pertinente.
DBB e zBuilder ainda são subestimados?
Possivelmente sim.
Mas talvez isso esteja começando a mudar.
Estamos observando o surgimento de uma nova geração de profissionais que não deseja apenas integrar Mainframe à nuvem.
Deseja integrar Mainframe à cultura moderna de engenharia.
Quer Git.
Quer pipelines.
Quer automação.
Quer segurança contínua.
Quer observabilidade.
Quer experiência de desenvolvedor.
Quer Platform Engineering.
Quer GitOps.
Quer tratar COBOL exatamente como trata Java, Python ou Go.
Se esse movimento continuar crescendo, talvez daqui a dez anos olhemos para DBB e zBuilder da mesma forma que hoje observamos Git ou Kubernetes.
Ferramentas que inicialmente pareciam apenas componentes técnicos, mas que acabaram redefinindo completamente a maneira como organizações constroem software.
E talvez essa seja a verdadeira modernização do Mainframe.
Não trocar COBOL por outra linguagem.
Não mover aplicações para outro ambiente.
Mas transformar o IBM Z em algo que ele sempre teve potencial para ser:
Uma plataforma de engenharia contínua, capaz de unir a estabilidade de cinquenta anos de missão crítica com a velocidade, automação e governança exigidas pela próxima geração de sistemas corporativos.
Que a Força do Pipeline esteja com vocês.
