Translate

Mostrar mensagens com a etiqueta low-code. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta low-code. Mostrar todas as mensagens

segunda-feira, 4 de maio de 2026

No-Code : O Que Todo Programador COBOL Precisa Saber Sobre a Revolução do Desenvolvimento Sem Programação

 

Bellacosa Mainframe e o no-code na stack mainframe

☕ Um Café no Bellacosa Mainframe

No-Code

O Que Todo Programador COBOL Precisa Saber Sobre a Revolução do Desenvolvimento Sem Programação

Você Não Está Sendo Substituído. Está Descobrindo Outra Forma de Construir Software.

"Toda década promete eliminar os programadores. Primeiro vieram os geradores de código. Depois os CASE Tools. Em seguida o RAD. Agora é o No-Code. Curiosamente, todas essas tecnologias continuam precisando de bons engenheiros de software."


Introdução

Quem trabalha com IBM Mainframe já ouviu inúmeras previsões durante a carreira.

"COBOL vai acabar."

"O Mainframe será substituído."

"Agora qualquer pessoa poderá criar sistemas."

Quase cinquenta anos depois dessas previsões, os maiores bancos do planeta continuam processando bilhões de transações em COBOL.

Agora surgiu uma nova promessa.

No-Code.

Segundo muitos anúncios de marketing, basta arrastar alguns blocos na tela e qualquer pessoa cria aplicações empresariais.

Será?

Como quase tudo na engenharia de software, a resposta é mais interessante do que parece.

Para um desenvolvedor COBOL, entender No-Code não significa abandonar décadas de conhecimento.

Significa compreender onde essa tecnologia realmente faz sentido.


O que é No-Code?

No-Code é uma abordagem de desenvolvimento onde aplicações são criadas utilizando componentes gráficos, configurações e regras visuais, praticamente sem escrever código tradicional.

Em vez de escrever:

IF SALDO > LIMITE
    MOVE "NEGADO" TO STATUS
END-IF

o desenvolvedor conecta dois blocos:

Saldo >
        \
         > Decisão
        /
Limite >

e define:

Sim → Negar operação

Não → Aprovar

A lógica continua existindo.

A diferença é apenas a forma de representá-la.


O princípio do No-Code

Todo software possui quatro elementos fundamentais:

  • Interface

  • Regras

  • Dados

  • Integrações

No-Code tenta transformar todos esses elementos em componentes reutilizáveis.

Em vez de programar:

Tela
↓

Código

↓

Banco

↓

API

o desenvolvedor monta:

Tela
↓

Blocos

↓

Fluxos

↓

Publicar

A origem do No-Code

Na realidade, No-Code não é novidade.

Ele apenas ganhou um novo nome.

Sua história começa muito antes da Internet.

Década de 1970

Mainframes já possuíam ferramentas declarativas.

CICS BMS

IMS MFS

ISPF Panels

Mapas de tela.

Você descrevia uma tela.

O sistema gerava a interface.

Isso já era uma forma de desenvolvimento declarativo.


Década de 1980

Surgiram os famosos CASE Tools.

Entre eles:

  • Texas Instruments IEF

  • AD/Cycle

  • COOL:Gen

  • Excelerator

  • CA Gen

Essas ferramentas prometiam:

"Desenhe o sistema."

"O software será gerado automaticamente."

Muito parecido com o discurso atual.


Década de 1990

Vieram:

  • Delphi

  • Visual Basic

  • PowerBuilder

  • Oracle Forms

Os componentes eram arrastados para formulários.

Pouco código.

Muito RAD (Rapid Application Development).


Década de 2000

Aplicações Web.

Frameworks.

CMS.

WordPress.

Joomla.

Drupal.

Muitos sites passaram a ser construídos sem programação.


Década de 2010

Cloud.

SaaS.

APIs REST.

Microserviços.

As plataformas começaram a conectar tudo.


Década de 2020

Explosão do verdadeiro No-Code.

Agora existem plataformas completas.

Aplicativos.

Workflows.

IA.

Bots.

Dashboards.

Integrações.

Tudo criado visualmente.


A diferença entre No-Code e Low-Code

Muita gente confunde.

No-Code

Destinado principalmente para usuários de negócio.

Exemplo:

Criar formulário

↓

Criar fluxo

↓

Publicar

Sem programação.


Low-Code

Destinado a desenvolvedores.

Permite código quando necessário.

Exemplo:

Fluxo visual

↓

Componente personalizado

↓

API

↓

Script

↓

Deploy

É muito mais poderoso.


Por que o No-Code cresceu tanto?

Porque o mercado possui um problema enorme.

Faltam desenvolvedores.

Empresas precisam entregar software rapidamente.

Nem toda aplicação exige uma equipe de engenharia.

Imagine criar:

  • formulário interno

  • cadastro

  • workflow de aprovação

  • pesquisa de satisfação

  • controle de férias

Não faz sentido desenvolver tudo em Java.

Nem em COBOL.

Nem em C#.

Uma ferramenta No-Code resolve em poucas horas.


Como funciona internamente?

Esse é um ponto importante.

No-Code não elimina programação.

Ele apenas esconde a programação.

Quando você cria:

Botão

↓

Enviar Email

a plataforma gera algo semelhante a:

HTML

CSS

JavaScript

API

Banco

Autenticação

Logs

Infraestrutura

Ou seja...

Alguém escreveu milhares de linhas de código para que você não precise escrevê-las.


As principais características

Uma plataforma No-Code normalmente possui:

Editor visual

Banco de dados

Autenticação

Controle de usuários

Integração com APIs

Dashboards

Automações

Relatórios

Workflow

Notificações

Segurança

Deploy automático


Principais metodologias

Embora cada fabricante possua sua implementação, quase todas seguem os mesmos conceitos.

Model Driven Development

Primeiro modela.

Depois gera.


Visual Programming

Fluxogramas.

Conexões.

Eventos.


Event Driven

Quando algo acontece...

Executa outra ação.

Cliente cadastrado

↓

Enviar Email

↓

Criar Pedido

↓

Registrar Log

↓

Atualizar CRM

Workflow Automation

Automação baseada em processos.

Muito utilizada em empresas.


Business Process Management (BPM)

Fluxos corporativos.

Aprovações.

Assinaturas.

Validações.

Integrações.


Domain Driven Modeling

A aplicação representa o negócio.

Não a tecnologia.


Vantagens

Desenvolvimento extremamente rápido

Horas.

Não meses.


Menor custo inicial

Poucos desenvolvedores.


Interface pronta

Layouts modernos.


Integração simples

Microsoft

Google

SAP

Salesforce

IBM

Oracle

Tudo via conectores.


Facilidade para prototipação

Ideal para MVP.


Atualizações automáticas

O fornecedor cuida da infraestrutura.


Baixa curva de aprendizado

Analistas conseguem construir aplicações simples.


Desvantagens

Agora vem a parte que o marketing raramente comenta.


Dependência do fornecedor

Seu sistema passa a depender totalmente da plataforma.


Vendor Lock-in

Trocar de ferramenta pode significar reconstruir tudo.


Limitações

Quando surge uma necessidade muito específica...

A plataforma pode simplesmente não permitir.


Performance

Nem sempre é ideal.

Algumas plataformas geram muito código desnecessário.


Escalabilidade

Funciona bem para centenas.

Nem sempre para milhões de usuários.


Licenciamento

Pode ficar caro.

Muito caro.

Especialmente conforme o número de usuários cresce.


Performance

Aqui existe um mito.

"No-Code é lento."

Nem sempre.

Depende da arquitetura.

Uma boa plataforma pode gerar aplicações excelentes.

Outra pode gerar aplicações enormes.

Tudo depende da qualidade do motor interno.


Segurança

Outro ponto crítico.

Toda plataforma precisa oferecer:

Autenticação

Criptografia

Auditoria

Controle de acesso

LGPD

Logs

Versionamento

Backup

Governança

Sem isso, ela dificilmente será aceita em ambientes corporativos.


Como desenvolver uma aplicação No-Code

Vamos imaginar um pequeno sistema de solicitação de férias.

Passo 1

Definir o processo.

Funcionário

↓

Solicita férias

↓

Gestor aprova

↓

RH confirma

↓

Sistema encerra

Passo 2

Criar entidades.

Funcionário

Departamento

Solicitação

Período

Gestor


Passo 3

Criar formulários.

Cadastro.

Consulta.

Aprovação.


Passo 4

Criar regras.

Se gestor aprovar...

Enviar ao RH.

Caso contrário...

Rejeitar.


Passo 5

Criar notificações.

Email.

Teams.

Slack.

WhatsApp.


Passo 6

Criar dashboards.

Solicitações abertas.

Pendentes.

Concluídas.

Tempo médio.


Passo 7

Publicar.

Sem compilação tradicional.


Boas práticas

Sempre modelar o processo primeiro.

Evitar criar fluxos gigantes.

Documentar regras.

Versionar alterações.

Controlar permissões.

Criar ambientes separados.

Testar integrações.

Monitorar desempenho.

Ter plano de contingência.


Os principais riscos

Criar aplicações sem arquitetura.

Duplicar regras.

Ausência de documentação.

Dependência da plataforma.

Integrações mal definidas.

Falta de testes.

Crescimento descontrolado.

Shadow IT.


Oportunidades para o programador COBOL

Aqui está o ponto mais importante deste artigo.

No-Code não compete com COBOL.

Ele complementa.

Imagine este cenário.

Cliente

↓

Portal Web

↓

Power Apps

↓

Power Automate

↓

API REST

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

DB2

Quem executa a lógica crítica?

COBOL.

Quem apenas apresenta uma interface bonita?

No-Code.


O papel do Mainframe

O Mainframe continua sendo responsável por:

Transações financeiras.

Processamento batch.

Contabilidade.

Pagamentos.

Cartões.

PIX.

Previdência.

Folha.

Seguros.

Toda essa lógica permanece exatamente onde sempre esteve.


O papel do No-Code

Construir rapidamente:

Painéis administrativos.

Dashboards.

Consultas.

Workflows.

Aprovações.

Aplicativos internos.

Portais.


A integração perfeita

Hoje, uma arquitetura moderna costuma ser assim:

Usuário
      │
      ▼
Power Apps / Mendix / OutSystems
      │
      ▼
REST API
      │
      ▼
IBM z/OS Connect
      │
      ▼
CICS
      │
      ▼
Programa COBOL
      │
      ▼
DB2 / VSAM / IMS

Perceba que o COBOL não desaparece.

Ele ganha uma nova camada de apresentação.


Principais plataformas No-Code

Entre as mais conhecidas estão:

  • Microsoft Power Apps

  • Microsoft Power Automate

  • Mendix (Siemens)

  • OutSystems

  • AppSheet (Google)

  • Bubble

  • Glide

  • Zoho Creator

  • Airtable

  • Retool

  • ServiceNow App Engine

  • Salesforce Lightning Platform

  • Oracle APEX (frequentemente classificado como Low-Code)

  • IBM watsonx Orchestrate (automação e IA)

  • IBM Business Automation Workflow

Cada uma possui foco diferente: aplicativos corporativos, automação de processos, portais, integração ou desenvolvimento empresarial.


Onde o No-Code NÃO funciona bem?

Há cenários em que o desenvolvimento tradicional continua sendo a melhor escolha:

  • Sistemas bancários de alta criticidade.

  • Motores de processamento em tempo real.

  • Aplicações com requisitos extremos de desempenho.

  • Sistemas embarcados.

  • Softwares que exigem controle detalhado de memória ou hardware.

  • Algoritmos científicos complexos.

  • Grandes motores de processamento batch.

Nesses casos, linguagens como COBOL, Java, C/C++, PL/I ou Assembler continuam sendo mais adequadas.


O futuro do No-Code

A próxima evolução já começou.

Ela combina:

  • No-Code

  • Low-Code

  • Inteligência Artificial Generativa

  • Agentes de IA

  • Automação inteligente

  • APIs

  • RPA

  • Event-Driven Architecture

Em vez de apenas montar telas, o desenvolvedor descreve um processo em linguagem natural, e a plataforma gera boa parte da aplicação. Ainda assim, alguém precisa revisar arquitetura, segurança, integração, testes e governança.


O impacto no ambiente Mainframe

Para o profissional de IBM Z, o maior impacto não é técnico, mas estratégico.

As equipes de negócio querem entregar soluções mais rápido. O Mainframe continua sendo o sistema de registro (System of Record), enquanto plataformas No-Code aceleram a criação de experiências digitais.

Isso aumenta a importância de tecnologias como:

  • IBM z/OS Connect

  • APIs REST

  • OpenAPI

  • IBM MQ

  • Kafka

  • CICS Web Services

  • Db2 Services

  • OAuth e OpenID Connect

  • Arquiteturas orientadas a eventos

O programador COBOL deixa de ser apenas um desenvolvedor de programas batch e online para atuar como um engenheiro de serviços corporativos.


O Novo Perfil do Programador COBOL

O profissional mais valorizado nos próximos anos provavelmente será aquele que combina:

  • COBOL moderno

  • CICS

  • Db2

  • JCL

  • APIs REST

  • JSON

  • Git

  • DevOps

  • Segurança

  • Integração com plataformas Low-Code e No-Code

  • Arquitetura de sistemas

Ele não precisará construir cada tela manualmente. Em vez disso, projetará serviços confiáveis, escaláveis e seguros que poderão ser consumidos por aplicativos web, mobile, IA e plataformas No-Code.


Conclusão

No-Code não representa o fim da programação.

Representa uma mudança de foco.

Assim como os compiladores não eliminaram os programadores Assembly, e as linguagens de alto nível não eliminaram a engenharia de software, as plataformas No-Code não eliminam a necessidade de profissionais experientes.

Elas reduzem o esforço em tarefas repetitivas e aceleram a construção de aplicações simples, mas continuam dependentes de boas decisões de arquitetura, integração, segurança e governança.

No universo IBM Mainframe, essa realidade é ainda mais evidente. O COBOL permanece executando a lógica de negócios que movimenta bancos, seguradoras, governos e grandes empresas. O No-Code entra como uma camada de produtividade e experiência do usuário, consumindo serviços expostos pelo Mainframe por meio de APIs.

O futuro não será uma disputa entre COBOL e No-Code.

Será uma colaboração entre ambos.

O desenvolvedor que compreender essa integração deixará de enxergar o No-Code como ameaça e passará a utilizá-lo como mais uma ferramenta para entregar valor ao negócio.

Porque, no fim das contas, software nunca foi apenas escrever código.

Sempre foi resolver problemas. E essa continua sendo a missão de qualquer engenheiro de software — seja escrevendo milhares de linhas em COBOL, seja conectando componentes visuais que, por trás da interface, ainda dependem da mesma disciplina, do mesmo raciocínio lógico e da mesma engenharia que sustentam os sistemas mais importantes do mundo há décadas.

sexta-feira, 30 de maio de 2025

CASE Tools - Muito Além da Geração de Código: A Tecnologia que Mudou a Engenharia de Software para Sempre

 

Bellacosa Mainframe e os primeiros passos em Case Tools

☕ Um Café no Bellacosa Mainframe

CASE Tools

Muito Além da Geração de Código: A Tecnologia que Mudou a Engenharia de Software para Sempre

"As CASE Tools nunca tiveram como objetivo substituir programadores. Elas nasceram para transformar programação em Engenharia de Software. Quarenta anos depois, continuam influenciando praticamente todas as ferramentas modernas, da UML à Inteligência Artificial."


Introdução

Quando alguém fala em CASE Tools, é comum ouvir a resposta:

"Isso é tecnologia antiga."

Na realidade, poucas afirmações estão tão distantes da verdade.

As CASE Tools podem até não aparecer mais nas manchetes, mas seus conceitos continuam presentes em praticamente todas as plataformas modernas de desenvolvimento.

Se você utiliza:

  • UML;

  • Enterprise Architect;

  • IBM Application Discovery;

  • IBM Developer for z/OS;

  • GitHub Copilot;

  • IBM watsonx Code Assistant;

  • Low-Code;

  • No-Code;

  • DevOps;

  • Model Driven Engineering;

você está, direta ou indiretamente, utilizando ideias que nasceram há mais de quatro décadas.

Para quem trabalha com IBM Mainframe, compreender CASE Tools significa entender a origem da engenharia que permitiu a bancos, seguradoras e governos manterem sistemas críticos funcionando por décadas.


Afinal, o que são CASE Tools?

CASE significa:

Computer-Aided Software Engineering

ou

Engenharia de Software Assistida por Computador.

O objetivo nunca foi substituir programadores.

O objetivo sempre foi automatizar tarefas repetitivas da Engenharia de Software.

Em vez de começar escrevendo código, a ideia era começar criando modelos.

A partir desses modelos, as ferramentas poderiam gerar:

  • programas COBOL;

  • tabelas DB2;

  • layouts VSAM;

  • telas CICS;

  • documentação;

  • diagramas;

  • dicionários de dados;

  • especificações técnicas.

O código passava a ser consequência do projeto, não seu ponto de partida.


Por que elas surgiram?

Durante as décadas de 1970 e 1980 a indústria enfrentou a chamada Crise do Software.

Os computadores evoluíam rapidamente, mas os sistemas tornavam-se cada vez maiores e mais difíceis de manter.

Projetos atrasavam.

Custos aumentavam.

A documentação ficava desatualizada.

Mudanças simples provocavam erros inesperados.

As CASE Tools surgiram para trazer disciplina, padronização, rastreabilidade e reutilização ao desenvolvimento de software.


O grande diferencial

A maior inovação das CASE Tools não foi a geração automática de código.

Foi a criação de um repositório de conhecimento.

Nele eram armazenados:

  • processos;

  • entidades;

  • regras de negócio;

  • relacionamentos;

  • programas;

  • tabelas;

  • dependências;

  • documentação.

Hoje chamamos isso de metadados.

Na época, era uma revolução.


O papel no IBM Mainframe

Foi no Mainframe que as CASE Tools demonstraram todo o seu potencial.

Imagine uma instituição financeira com:

  • milhões de clientes;

  • milhares de transações CICS;

  • centenas de bancos DB2;

  • milhares de arquivos VSAM;

  • milhões de linhas de COBOL.

Sem uma visão integrada, compreender o impacto de uma simples alteração seria praticamente impossível.

As CASE Tools permitiram analisar dependências, gerar documentação, identificar impactos e padronizar o desenvolvimento, tornando viável a evolução contínua desses sistemas.


Elas desapareceram?

Não.

Mudaram de nome.

Os princípios continuam presentes em tecnologias modernas como:

  • UML;

  • Model Driven Development (MDD);

  • Model Driven Engineering (MDE);

  • Domain-Driven Design (DDD);

  • Low-Code;

  • No-Code;

  • DevOps;

  • Infrastructure as Code;

  • Inteligência Artificial aplicada ao desenvolvimento.

A engenharia baseada em modelos continua mais viva do que nunca.


O que isso significa para o programador COBOL?

Significa que escrever código já não é suficiente.

O profissional moderno precisa compreender:

  • arquitetura;

  • modelagem;

  • regras de negócio;

  • engenharia reversa;

  • análise de impacto;

  • documentação automática;

  • integração entre sistemas;

  • automação.

Quem domina esses conceitos consegue evoluir sistemas complexos com muito mais segurança.


Esta série completa

Para explorar esse universo em profundidade, preparamos uma série especial dividida em quatro artigos.

📘 Parte 1 — A origem das CASE Tools

Conheça a história da Crise do Software, o nascimento da Engenharia de Software, os primeiros CASE Tools e como surgiu a ideia de modelar sistemas antes de escrever código.

Você entenderá por que essa tecnologia foi considerada revolucionária e como ela mudou a forma de construir aplicações corporativas.

https://eljefemidnightlunch.blogspot.com/2025/01/case-tools-tecnologia-que-tentou.html


📗 Parte 2 — Upper CASE, Lower CASE e Integrated CASE

Descubra como funcionavam as diferentes categorias de CASE Tools.

Entenda conceitos como:

  • Upper CASE;

  • Lower CASE;

  • I-CASE;

  • Forward Engineering;

  • Reverse Engineering;

  • Round Trip Engineering;

  • Repositórios;

  • Dicionários de Dados;

  • Metodologias clássicas de Engenharia de Software.

É a base conceitual que influenciou praticamente todas as ferramentas modernas.

https://eljefemidnightlunch.blogspot.com/2025/02/case-tools-upper-case-lower-case-i-case.html


📙 Parte 3 — CASE Tools no IBM Mainframe

Veja como bancos, seguradoras e órgãos governamentais utilizaram CASE Tools para administrar enormes ambientes COBOL.

Conheça a relação dessas ferramentas com:

  • COBOL;

  • CICS;

  • DB2;

  • IMS;

  • VSAM;

  • JCL;

  • IBM Application Discovery (ADDI);

  • IBM Developer for z/OS;

  • CA Gen;

  • Enterprise Architect;

  • PowerDesigner.

Uma leitura indispensável para quem trabalha com IBM Z.

https://eljefemidnightlunch.blogspot.com/2025/03/case-tools-case-tools-no-ibm-mainframe.html


📕 Parte 4 — Das CASE Tools à Inteligência Artificial

Entenda por que Low-Code, No-Code, MDD, MDE, DDD, DevOps e Inteligência Artificial representam uma evolução natural dos princípios introduzidos pelas CASE Tools.

Descubra como ferramentas como o IBM watsonx Code Assistant e assistentes baseados em IA continuam seguindo a mesma filosofia: automatizar tarefas repetitivas para que os engenheiros concentrem seus esforços na solução dos problemas de negócio.

https://eljefemidnightlunch.blogspot.com/2025/04/case-tools-das-case-tools-inteligencia.html


O maior legado das CASE Tools

Talvez a maior contribuição das CASE Tools tenha sido mudar a forma como enxergamos o desenvolvimento de software.

Elas mostraram que sistemas complexos não sobrevivem por décadas apenas porque utilizam uma boa linguagem de programação.

Eles sobrevivem porque foram construídos sobre princípios sólidos de engenharia.

Modelagem.

Padronização.

Rastreabilidade.

Reutilização.

Documentação.

Governança.

Esses conceitos permanecem essenciais, independentemente da linguagem, da plataforma ou da tecnologia utilizada.


Conclusão

A história das CASE Tools é, na verdade, a história da própria Engenharia de Software moderna.

O nome pode ter desaparecido das apresentações comerciais, mas suas ideias continuam presentes em praticamente todas as tecnologias atuais.

Quando utilizamos UML, geramos APIs automaticamente, criamos pipelines DevOps, fazemos engenharia reversa de aplicações COBOL ou pedimos que uma Inteligência Artificial produza código, estamos ampliando um conceito que nasceu há mais de quarenta anos.

Para o profissional de IBM Mainframe, conhecer CASE Tools não significa estudar uma tecnologia do passado.

Significa compreender por que os sistemas que movimentam bancos, seguradoras, bolsas de valores e governos continuam evoluindo com segurança após décadas de operação.

A tecnologia muda.

As ferramentas mudam.

As linguagens mudam.

Mas a Engenharia de Software continua sendo o verdadeiro diferencial.

"Quem aprende apenas uma linguagem de programação constrói aplicações. Quem compreende Engenharia de Software constrói sistemas capazes de atravessar gerações. Esse sempre foi o legado das CASE Tools."

 

segunda-feira, 28 de abril de 2025

CASE Tools Das CASE Tools à Inteligência Artificial – Parte IV

 

Bellacosa Mainframe apresenta o case tools parte iv

☕ Um Café no Bellacosa Mainframe

CASE Tools – Parte 4

Das CASE Tools à Inteligência Artificial

Como Low-Code, No-Code, Model Driven Engineering e IA São Apenas a Próxima Evolução da Mesma Ideia

"Toda geração acredita ter inventado uma nova forma de desenvolver software. A história mostra algo diferente: as ferramentas mudam, mas a engenharia continua sendo o verdadeiro diferencial."


Introdução

Chegamos ao último capítulo desta série sobre CASE Tools.

Ao longo dos artigos anteriores vimos como nasceu a Engenharia de Software moderna, conhecemos Upper CASE, Lower CASE e Integrated CASE e entendemos por que bancos, seguradoras e governos adotaram essas ferramentas para construir alguns dos sistemas mais confiáveis do mundo.

Mas uma pergunta permanece.

Se as CASE Tools eram tão revolucionárias, por que praticamente ninguém fala delas hoje?

A resposta é simples.

Elas nunca desapareceram.

Apenas mudaram de nome.

As ideias que surgiram nos anos 80 continuam presentes em praticamente todas as tecnologias modernas de desenvolvimento de software.

Quando alguém utiliza uma plataforma Low-Code, desenha um diagrama UML, cria um pipeline DevOps, gera uma API automaticamente ou pede para uma Inteligência Artificial escrever código, está utilizando conceitos que nasceram com as CASE Tools.

A tecnologia mudou.

Os princípios continuam exatamente os mesmos.


O fim das CASE Tools?

Durante a década de 1990 muitas empresas começaram a afirmar que as CASE Tools haviam fracassado.

Em parte isso era verdade.

Diversos produtos desapareceram.

Outros foram comprados.

Alguns mudaram completamente de estratégia.

Mas o motivo não foi a inutilidade da tecnologia.

Foi sua complexidade.


Imagine uma ferramenta que exigia:

  • meses de treinamento;

  • especialistas dedicados;

  • servidores caros;

  • processos extremamente rígidos;

  • equipes enormes de analistas.

Esse modelo funcionava muito bem para um banco com cinco mil desenvolvedores.

Mas não para uma empresa com vinte programadores.

Enquanto isso, o mercado começava a exigir velocidade.

Nasciam a Internet comercial, o desenvolvimento Web e novos modelos de negócio.

O software precisava evoluir em semanas, não em anos.


A chegada da Orientação a Objetos

Na mesma época surgia outro movimento importante.

A Orientação a Objetos.

Ferramentas como:

  • Rational Rose

  • Together

  • Select Enterprise

  • Enterprise Architect

passaram a utilizar UML.

Os enormes diagramas estruturados das CASE Tools começaram a dar lugar aos diagramas orientados a objetos.

Mas observe.

Ainda eram modelos.

Ainda existia documentação.

Ainda existia engenharia.

Mudou apenas a linguagem utilizada para representar os sistemas.


UML: uma CASE Tool disfarçada

Muita gente acredita que UML substituiu CASE.

Na realidade, UML tornou-se uma evolução natural.

Observe.

Antes.

DFD

↓

Modelo

↓

Código

Depois.

UML

↓

Modelo

↓

Código

O conceito permaneceu.

Modelar primeiro.

Implementar depois.


Model Driven Development (MDD)

No final dos anos 90 surgiu um conceito extremamente interessante.

Model Driven Development.

Ou simplesmente

MDD.

A ideia era simples.

O modelo deixa de ser apenas documentação.

Ele passa a ser o elemento principal do projeto.

O código torna-se um produto derivado.

Veja.

Modelo

↓

Transformação

↓

Código

↓

Sistema

Não parece familiar?

É exatamente a filosofia das CASE Tools.


Model Driven Engineering (MDE)

Depois surgiu um conceito ainda mais amplo.

Model Driven Engineering.

Agora não apenas o software.

Toda a engenharia passa a girar em torno dos modelos.

Os modelos passam a representar:

  • processos;

  • infraestrutura;

  • segurança;

  • bancos de dados;

  • APIs;

  • microsserviços;

  • eventos;

  • integrações.

Hoje diversas empresas trabalham exatamente assim.


Domain Driven Design (DDD)

Outro conceito importante.

Eric Evans publicou em 2003 o livro Domain-Driven Design.

Muitos acreditam que ele não possui relação com CASE.

Na realidade possui várias.

O DDD afirma que o mais importante não é o código.

É compreender profundamente o negócio.

Era exatamente isso que os analistas das CASE Tools já defendiam décadas antes.


Low-Code

Agora chegamos a uma tecnologia bastante conhecida.

Low-Code.

O nome sugere:

Pouco código.

Mas não significa ausência de programação.

Significa automatizar tarefas repetitivas.

Imagine construir um cadastro.

Em vez de escrever centenas de linhas.

Você desenha.

A ferramenta gera:

  • telas;

  • banco;

  • APIs;

  • validações;

  • documentação.

Parece familiar?

Sim.

É exatamente o que uma CASE Tool fazia.


No-Code

O No-Code leva essa ideia ainda mais longe.

O usuário de negócio pode criar aplicações utilizando componentes visuais.

Fluxos.

Formulários.

Integrações.

Regras.

Tudo configurado visualmente.

O código existe.

Mas fica escondido.

Mais uma vez.

A filosofia continua a mesma.


BPM

Outra evolução importante.

Business Process Management.

Ferramentas como:

  • IBM BPM

  • Camunda

  • Bizagi

  • Appian

permitem desenhar processos.

Depois executá-los automaticamente.

Observe.

Primeiro o modelo.

Depois a execução.

Mais uma herança das CASE Tools.


APIs e OpenAPI

Hoje criamos APIs utilizando especificações.

Por exemplo.

Cliente

↓

GET

↓

POST

↓

PUT

A partir dessa especificação diversas ferramentas geram:

  • documentação;

  • SDKs;

  • código;

  • testes.

É exatamente o conceito de geração automática.


DevOps

Existe uma dúvida muito comum.

DevOps substituiu CASE?

Não.

CASE responde:

Como construir?

DevOps responde:

Como entregar?

Observe.

CASE

↓

Código

↓

Git

↓

Pipeline

↓

Deploy

↓

Produção

São tecnologias complementares.


Infrastructure as Code

Outro exemplo.

Hoje descrevemos servidores usando arquivos.

Terraform.

Ansible.

CloudFormation.

Depois.

Tudo é criado automaticamente.

Em vez de desenhar programas.

Agora modelamos infraestrutura.

É engenharia dirigida por modelos novamente.


Kubernetes

Mesmo Kubernetes utiliza essa filosofia.

Descrevemos um ambiente.

O orquestrador cria tudo.

Deployment

↓

Pods

↓

Services

↓

Volumes

Primeiro descrevemos.

Depois a plataforma constrói.


GitHub Copilot

Agora chegamos ao assunto do momento.

A Inteligência Artificial.

Quando você escreve:

"Crie um programa COBOL para consultar saldo."

O Copilot gera código.

Mas observe.

Ele não conhece toda a empresa.

Não conhece todas as regras.

Não conhece todas as integrações.

Ele apenas produz uma sugestão.


ChatGPT

O mesmo ocorre aqui.

Uma IA pode ajudar a criar:

  • programas;

  • documentação;

  • testes;

  • SQL;

  • JCL;

  • APIs.

Mas ainda depende do engenheiro para validar:

  • arquitetura;

  • desempenho;

  • segurança;

  • conformidade;

  • regras de negócio.

A IA acelera.

O engenheiro decide.


IA + CASE

Agora imagine unir os dois mundos.

Uma CASE Tool conhece:

  • arquitetura;

  • banco;

  • programas;

  • dependências;

  • documentação.

A IA conhece:

  • linguagem natural;

  • geração de código;

  • testes;

  • documentação.

Resultado.

Uma combinação extremamente poderosa.


Imagine um banco.

O analista escreve.

Adicionar PIX Internacional.

A plataforma consulta o repositório CASE.

Descobre:

  • programas afetados;

  • tabelas;

  • APIs;

  • batchs;

  • CICS;

  • MQ.

Depois.

A IA sugere:

  • alterações COBOL;

  • SQL;

  • documentação;

  • testes.

Esse provavelmente será o futuro da Engenharia de Software.


O impacto no IBM Mainframe

O Mainframe talvez seja a plataforma que mais ganhará com essa evolução.

Por quê?

Porque seus sistemas possuem enorme conhecimento acumulado.

Décadas de regras de negócio.

Milhões de linhas COBOL.

Milhares de programas.

Sem documentação adequada.

A IA trabalha melhor quando possui contexto.

As antigas CASE Tools fornecem exatamente esse contexto.


IBM Application Discovery

Ferramentas como IBM ADDI caminham exatamente nessa direção.

Primeiro.

Entender o sistema.

Depois.

Permitir modernização.

Isso reduz riscos enormes.


IBM watsonx Code Assistant

Outro exemplo.

O IBM watsonx Code Assistant for Z utiliza IA para auxiliar na modernização de aplicações COBOL.

Mas ele não trabalha isoladamente.

Quanto maior o conhecimento sobre o sistema — dependências, modelos, documentação e arquitetura — melhores tendem a ser as recomendações produzidas.

Mais uma vez, percebemos a importância dos princípios introduzidos pelas CASE Tools.


O papel do programador COBOL

Existe uma preocupação comum.

"A IA vai substituir o programador?"

A história das CASE Tools responde essa pergunta.

Durante quarenta anos ouvimos:

  • geradores de código acabarão com os programadores;

  • 4GL eliminarão COBOL;

  • RAD substituirá desenvolvimento tradicional;

  • CASE automatizará tudo;

  • Low-Code eliminará engenheiros.

Nada disso aconteceu.

O que mudou foi o perfil do profissional.

Hoje vale mais quem entende:

  • negócio;

  • arquitetura;

  • integração;

  • segurança;

  • desempenho;

  • governança.

O código tornou-se apenas uma parte da engenharia.


As habilidades do futuro

O desenvolvedor COBOL moderno precisa ampliar seu conjunto de competências.

Além da linguagem, é importante dominar:

  • Modelagem de sistemas;

  • UML e BPMN;

  • APIs REST;

  • JSON e XML;

  • SQL e modelagem de dados;

  • Engenharia reversa;

  • Análise de impacto;

  • Git e DevOps;

  • Cloud híbrida;

  • Inteligência Artificial aplicada ao desenvolvimento;

  • Automação de testes;

  • Documentação viva.

Essas habilidades não substituem o COBOL.

Elas potencializam seu valor.


O futuro não será escrito apenas em código

Estamos entrando em uma era em que o software será construído a partir de vários elementos.

Diagramas.

Modelos.

Prompts.

Documentação.

Metadados.

IA.

Código.

Todos convivendo.

Quem compreender somente programação verá apenas uma parte do processo.

Quem compreender Engenharia de Software enxergará o sistema completo.


O maior legado das CASE Tools

Talvez o maior ensinamento das CASE Tools não tenha sido gerar código.

Foi mostrar que software é conhecimento organizado.

Programas mudam.

Linguagens mudam.

Frameworks desaparecem.

Mas o conhecimento do negócio permanece.

É justamente esse conhecimento que bancos conseguem preservar durante quarenta ou cinquenta anos.

Não por acaso, muitas regras escritas em COBOL nos anos 80 continuam processando bilhões de transações diariamente.

O segredo nunca foi apenas a linguagem.

Foi a engenharia que permitiu manter esses sistemas compreensíveis e evolutivos.


Conclusão

Ao longo desta série vimos que as CASE Tools não pertencem apenas à história da computação. Elas continuam presentes, ainda que sob novos nomes e novas interfaces.

Upper CASE transformou a análise de requisitos em uma disciplina estruturada.

Lower CASE automatizou a implementação e reduziu tarefas repetitivas.

Integrated CASE mostrou que todo o ciclo de vida do software poderia compartilhar um único repositório de conhecimento.

Depois vieram UML, MDD, MDE, DDD, Low-Code, No-Code, DevOps, Infrastructure as Code e, finalmente, a Inteligência Artificial. Todas essas abordagens carregam, em maior ou menor grau, a mesma ideia fundamental: o conhecimento deve ser capturado, organizado, reutilizado e automatizado sempre que possível.

Para quem trabalha com IBM Mainframe e COBOL, essa conclusão é especialmente importante. Os sistemas que sustentam bancos, seguradoras e governos não sobreviveram por décadas apenas porque foram escritos em uma linguagem robusta. Eles sobreviveram porque foram construídos com disciplina, arquitetura e engenharia.

A Inteligência Artificial certamente mudará a forma como produzimos software. Mas ela não elimina a necessidade de compreender processos, regras de negócio, impactos e dependências. Pelo contrário: quanto melhor estruturado estiver esse conhecimento, melhores serão os resultados obtidos com a IA.

As CASE Tools nos ensinaram que a verdadeira riqueza de um sistema não está em suas linhas de código, mas no conhecimento que elas representam. Essa lição continua tão atual hoje quanto era há quarenta anos.

"A Inteligência Artificial pode escrever milhares de linhas de código em poucos segundos. Mas somente a Engenharia de Software transforma esse código em sistemas capazes de durar décadas. Essa sempre foi a missão das CASE Tools. Continua sendo a missão dos engenheiros de software."

 

quarta-feira, 17 de abril de 2024

RAD (Rapid Application Development) - A Metodologia que Mudou a Engenharia de Software e Continua Transformando o IBM Mainframe

 

Bellacosa Mainframe e RAD rapid application development

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

A Metodologia que Mudou a Engenharia de Software e Continua Transformando o IBM Mainframe

Você não está estudando apenas uma metodologia criada nos anos 90. Está entendendo a origem de grande parte das práticas modernas de desenvolvimento de software.

"O Mainframe nunca foi lento. Lento sempre foi o processo de desenvolvimento ao seu redor."


Introdução

Quando alguém fala em desenvolvimento ágil, Scrum, DevOps, Low-Code, No-Code ou Inteligência Artificial, normalmente imagina que essas tecnologias surgiram praticamente do nada.

Na realidade, muitas dessas ideias nasceram décadas antes.

Entre elas está o RAD (Rapid Application Development), metodologia criada para reduzir o tempo entre uma necessidade do negócio e a entrega de software funcionando.

Seu princípio continua extremamente atual.

Não desenvolver mais rápido.

Aprender mais rápido.

Para quem trabalha com COBOL e IBM Mainframe, compreender o RAD significa entender que velocidade nunca dependeu apenas da linguagem de programação. Ela depende principalmente da organização do trabalho, da automação, da participação do usuário e da capacidade de evoluir continuamente.

Esta série apresenta o RAD sob a ótica do profissional IBM Z, mostrando que seus princípios continuam mais vivos do que nunca.


O que você aprenderá nesta série

Ao longo dos três capítulos veremos:

  • a origem do RAD;

  • por que ele revolucionou a Engenharia de Software;

  • como implementar RAD na prática;

  • metodologias derivadas;

  • ferramentas clássicas e modernas;

  • integração com Low-Code, DevOps e IA;

  • aplicação em COBOL, CICS, DB2, IMS e IBM Z;

  • oportunidades profissionais para desenvolvedores Mainframe.


Capítulo 1 — O que é RAD e por que ele revolucionou o desenvolvimento de software

Resumo

O primeiro capítulo apresenta a história do Rapid Application Development, criado por James Martin em 1991.

Mostra o cenário da época, dominado pelo modelo Cascata (Waterfall), em que projetos levavam anos para serem concluídos e frequentemente chegavam ao usuário já desatualizados.

Também explica os quatro pilares do RAD:

  • desenvolvimento iterativo;

  • prototipação;

  • participação constante do usuário;

  • equipes pequenas e multidisciplinares.

O capítulo compara RAD com Waterfall e demonstra como suas ideias influenciaram praticamente todas as metodologias modernas.

Leia o capítulo completo:

👉 RAD (Rapid Application Development) – Parte 1: O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia que Ensinou o Mundo a Desenvolver Software Rapidamente

https://eljefemidnightlunch.blogspot.com/2024/01/rad-rapid-application-development-o-que.html


Capítulo 2 — Como implementar RAD na prática

Resumo

Depois de entender os conceitos fundamentais, chega o momento de colocar o RAD em funcionamento.

Este capítulo apresenta um roteiro completo de implementação.

Você aprenderá:

  • como dividir projetos em pequenas entregas;

  • como montar equipes enxutas;

  • como construir protótipos;

  • como utilizar MVP (Minimum Viable Product);

  • como medir resultados;

  • indicadores de sucesso;

  • governança;

  • segurança;

  • documentação enxuta.

Também apresenta as metodologias influenciadas pelo RAD:

  • Scrum;

  • Extreme Programming (XP);

  • Lean Software Development;

  • DevOps;

  • Agile.

Além disso, faz um panorama das principais ferramentas RAD da história, como PowerBuilder, Delphi, Oracle Forms e GeneXus, chegando às plataformas atuais como Mendix, OutSystems, Power Apps, Oracle APEX e soluções baseadas em Inteligência Artificial.

Leia o capítulo completo:

👉 RAD (Rapid Application Development) – Parte 2: Como Implementar RAD na Prática, Principais Metodologias, Ferramentas e o Papel da Inteligência Artificial

https://eljefemidnightlunch.blogspot.com/2024/02/rad-rapid-application-development-como.html


Capítulo 3 — RAD no IBM Mainframe

Resumo

O terceiro capítulo aproxima definitivamente o RAD do universo IBM Z.

Mostra que o Mainframe nunca foi incompatível com desenvolvimento rápido.

Na verdade, muitos bancos já aplicavam práticas semelhantes ao RAD antes mesmo da popularização do Agile.

Entre os assuntos abordados estão:

  • RAD aplicado ao COBOL;

  • modularização;

  • COPYBOOKs;

  • reutilização;

  • APIs REST;

  • z/OS Connect;

  • CICS;

  • DB2;

  • IMS;

  • VSAM;

  • Git;

  • DevOps;

  • CI/CD;

  • testes automatizados;

  • observabilidade;

  • Inteligência Artificial aplicada ao código legado.

O capítulo também discute o futuro do desenvolvimento Mainframe e mostra como a combinação entre COBOL, IA e automação cria novas oportunidades para profissionais especializados em IBM Z.

Leia o capítulo completo:

👉 RAD (Rapid Application Development) – Parte 3: RAD no IBM Mainframe: Como Aplicar Desenvolvimento Rápido em COBOL sem Perder a Confiabilidade do IBM Z

https://eljefemidnightlunch.blogspot.com/2024/03/rad-rapid-application-development-rad.html


As principais lições da série

Ao final da leitura, fica evidente que o RAD nunca foi apenas uma metodologia para acelerar projetos.

Ele representa uma mudança de mentalidade.

Seus princípios continuam presentes em praticamente todas as práticas modernas de Engenharia de Software:

  • entregas incrementais;

  • feedback contínuo;

  • automação;

  • integração contínua;

  • testes automatizados;

  • prototipação;

  • foco no usuário;

  • redução de desperdícios;

  • melhoria contínua.

No ambiente IBM Mainframe, esses conceitos tornaram-se ainda mais relevantes graças à integração com APIs, Git, DevOps, z/OS Connect e Inteligência Artificial.

O desenvolvedor COBOL moderno não precisa abandonar décadas de conhecimento.

Precisa ampliar sua caixa de ferramentas.

Quanto mais automatizado for o processo, menor será o tempo entre uma ideia de negócio e sua implementação.

Esse sempre foi o verdadeiro objetivo do RAD.

Trinta anos depois, continua sendo uma das maiores lições da Engenharia de Software.


Próximas leituras recomendadas

Se você gostou desta série, acompanhe também os artigos do ☕ Um Café no Bellacosa Mainframe sobre:

  • DevOps para IBM Mainframe;

  • Low-Code para Programadores COBOL;

  • No-Code e Modernização;

  • Arquitetura Transformer para Mainframe;

  • Engenharia de Dados para Desenvolvedores COBOL;

  • CASE Tools;

  • APIs REST no IBM Z;

  • Inteligência Artificial aplicada ao COBOL;

  • Git e CI/CD no z/OS;

  • Modernização de aplicações IBM Z.

Esse artigo funciona como uma página pilar (Pillar Page) para SEO, concentrando a autoridade do tema RAD e distribuindo links para os três capítulos da série.


sexta-feira, 23 de fevereiro de 2024

RAD (Rapid Application Development) — Como Implementar RAD na Prática, Principais Metodologias, Ferramentas - Parte II

 

Bellacosa Mainframe apresenta o rad parte ii

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

Parte II — Como Implementar RAD na Prática, Principais Metodologias, Ferramentas e o Papel da Inteligência Artificial

"Desenvolver rapidamente nunca significou programar rapidamente. Significou aprender rapidamente."


Recapitulando

Na primeira parte desta série vimos que o RAD nasceu como resposta a um problema que ainda existe.

Empresas mudam rapidamente.

Os negócios mudam rapidamente.

Os clientes mudam rapidamente.

O software precisa acompanhar esse ritmo.

James Martin percebeu isso no início dos anos 90, muito antes de ouvirmos falar de Scrum, DevOps, Cloud Computing ou Inteligência Artificial.

Mas existe uma pergunta ainda mais importante.

Como colocar RAD em prática?

É exatamente isso que veremos agora.

Porque conhecer a teoria é relativamente simples.

O verdadeiro desafio está em transformar uma equipe tradicional em uma equipe capaz de entregar software continuamente.


A filosofia do RAD

Antes de falar de ferramentas precisamos compreender uma característica importante.

RAD não é uma ferramenta.

RAD não é uma linguagem.

RAD não é um framework.

RAD é uma filosofia de desenvolvimento.

Essa diferença muda tudo.

Uma empresa pode utilizar Java.

Outra COBOL.

Outra Python.

Outra C#.

Outra JavaScript.

Todas podem aplicar RAD.

O que muda não é a tecnologia.

É a maneira como ela é utilizada.


O primeiro passo: definir um problema pequeno

O maior erro cometido por equipes iniciantes é querer desenvolver todo o sistema de uma única vez.

RAD faz exatamente o contrário.

Começa pequeno.

Muito pequeno.

Imagine um banco.

Ao invés de desenvolver todo o Internet Banking...

Começa apenas pela consulta de saldo.

Depois extrato.

Depois PIX.

Depois investimentos.

Depois cartões.

Cada funcionalidade nasce praticamente como um pequeno projeto.

Essa abordagem reduz riscos.

Se algo der errado...

O prejuízo é pequeno.


Segundo passo: montar uma equipe enxuta

RAD funciona melhor quando existe pouca burocracia.

Normalmente encontramos equipes compostas por:

  • Analista de Negócios

  • Usuário-chave

  • Desenvolvedor

  • Especialista em Banco de Dados

  • Testador

  • Arquiteto

Não significa que grandes empresas trabalhem apenas com seis pessoas.

Significa que cada módulo possui autonomia.

Quanto menor a cadeia de aprovação...

Maior a velocidade.


Terceiro passo: envolver o usuário desde o primeiro dia

Este talvez seja o segredo mais importante.

No desenvolvimento tradicional o usuário aparece em três momentos.

Levantamento.

Homologação.

Produção.

No RAD ele participa praticamente todos os dias.

Imagine um gerente de crédito.

Na segunda-feira ele vê uma tela.

Na terça sugere mudanças.

Na quarta recebe uma nova versão.

Na quinta encontra outro detalhe.

Na sexta aprova.

Foram cinco dias.

Não cinco meses.


Quarto passo: criar um protótipo

Muitos desenvolvedores acreditam que um protótipo precisa funcionar.

Nem sempre.

Às vezes basta desenhar as telas.

Hoje existem dezenas de ferramentas para isso.

Figma.

Balsamiq.

Adobe XD.

Draw.io.

PowerPoint.

Até papel e caneta funcionam.

O objetivo não é impressionar.

É descobrir rapidamente se a ideia faz sentido.


Quinto passo: construir um MVP

Outro conceito herdado pelo desenvolvimento moderno.

MVP significa:

Minimum Viable Product

Ou Produto Mínimo Viável.

É a menor versão possível capaz de gerar valor.

Não significa software incompleto.

Significa software focado.

Imagine um sistema de empréstimos.

Ao invés de desenvolver quarenta funcionalidades...

Construa apenas cinco.

Se resolverem o problema principal...

O MVP cumpriu seu papel.


Sexto passo: validar rapidamente

Depois do MVP vem o momento mais importante.

Mostrar ao usuário.

Sem apresentações longas.

Sem centenas de slides.

Sem documentos enormes.

Coloque o sistema na frente dele.

Observe.

Escute.

Anote.

Melhore.

Repita.

Esse ciclo acontece inúmeras vezes.


Sétimo passo: melhorar continuamente

RAD nunca considera o software terminado.

Sempre existe espaço para melhorias.

Esse conceito influenciou diretamente o DevOps.

A aplicação evolui continuamente.

Pequenas melhorias.

Pequenos ajustes.

Pequenas correções.

Pequenas entregas.

O resultado costuma ser muito superior a uma única entrega gigantesca.


Como medir se o RAD está funcionando?

Toda metodologia precisa de indicadores.

Caso contrário ela vira opinião.

Algumas métricas importantes são:

Tempo até a primeira entrega

Quanto tempo levou para o usuário ver algo funcionando?

Dias?

Semanas?

Meses?

Quanto menor esse tempo...

Melhor.


Tempo de resposta às mudanças

Quanto tempo leva para alterar uma regra?

Horas?

Dias?

Semanas?

Se pequenas alterações exigem meses...

O processo ainda é pesado.


Número de retrabalhos

Se o usuário rejeita constantemente o software...

Algo está errado.

RAD busca reduzir retrabalho através do feedback constante.


Satisfação do usuário

Talvez seja o indicador mais importante.

Software existe para resolver problemas.

Não para produzir documentação.


As metodologias que herdaram conceitos do RAD

Embora o RAD seja uma metodologia própria, diversos movimentos posteriores incorporaram suas ideias.

Scrum

Sprint.

Incrementos.

Revisões.

Backlog.

Todos esses conceitos possuem enorme afinidade com RAD.

A principal diferença é que Scrum adicionou uma estrutura mais formal para gerenciamento.


Extreme Programming (XP)

XP talvez seja a metodologia que mais herdou conceitos do RAD.

Ela enfatiza:

  • feedback constante;

  • integração contínua;

  • programação em pares;

  • testes automatizados;

  • pequenas entregas.

Na prática, XP leva o RAD para um nível técnico ainda maior.


Lean Software Development

O Lean nasceu inspirado no Sistema Toyota.

Seu foco é eliminar desperdícios.

Curiosamente...

RAD também fazia exatamente isso.

Ambos valorizam aquilo que gera valor ao cliente.


DevOps

Muitos imaginam que DevOps trata apenas de infraestrutura.

Não.

DevOps também reduz o tempo entre desenvolver e colocar em produção.

Essa busca pela velocidade é um dos princípios centrais do RAD.


Agile

Podemos dizer que o RAD foi um dos grandes precursores do movimento ágil.

Nem todos concordam com essa afirmação.

Mas basta observar os princípios.

Feedback rápido.

Cliente presente.

Entregas frequentes.

Iterações.

Tudo isso já aparecia no RAD.


Ferramentas clássicas do RAD

Nos anos 90 existia uma verdadeira explosão de ferramentas RAD.

Algumas desapareceram.

Outras evoluíram.

Outras continuam presentes.

Entre elas:

PowerBuilder

Uma das maiores referências da época.

Construía aplicações corporativas rapidamente.


Oracle Forms

Durante muitos anos dominou aplicações empresariais.

Principalmente no ambiente Oracle.


Visual Basic

Talvez o maior símbolo do RAD para plataformas Windows.

Arrastar componentes.

Criar telas.

Conectar banco.

Gerar aplicações em poucas horas.


Delphi

Um dos ambientes RAD mais famosos da história.

Compilação extremamente rápida.

Excelente desempenho.

Grande produtividade.

Até hoje possui uma comunidade fiel.


GeneXus

Muito conhecido na América Latina.

Gera aplicações automaticamente para diversas plataformas.

Utilizado inclusive em grandes instituições financeiras.


Magic xpa

Ferramenta RAD voltada ao ambiente corporativo.

Muito utilizada em integração de sistemas.


Ferramentas modernas

O conceito continua vivo.

Mudaram apenas os nomes.

Hoje encontramos:

Microsoft Power Apps

Google AppSheet

OutSystems

Mendix

ServiceNow App Engine

Salesforce Lightning

Oracle APEX

Retool

FlutterFlow

Bubble

Appian

Zoho Creator

Todas seguem praticamente a mesma ideia.

Construir rapidamente.

Validar rapidamente.

Entregar rapidamente.


RAD e Low-Code

É impossível falar de RAD sem mencionar Low-Code.

Na prática...

Low-Code tornou o RAD muito mais poderoso.

Imagine criar uma tela.

Conectar um banco.

Criar APIs.

Publicar na nuvem.

Tudo isso praticamente sem escrever código.

O RAD encontrou no Low-Code um parceiro natural.


RAD e No-Code

O No-Code leva esse conceito ainda mais longe.

Usuários de negócio conseguem construir soluções simples.

Sem depender completamente da TI.

Isso acelera protótipos.

Validações.

Experimentos.

Naturalmente, sistemas críticos ainda exigem desenvolvimento profissional.

Especialmente no Mainframe.


Inteligência Artificial e RAD

Talvez este seja o maior salto desde os anos 90.

Hoje a IA consegue:

Gerar código.

Criar documentação.

Escrever testes.

Produzir APIs.

Criar consultas SQL.

Explicar código legado.

Converter linguagens.

Criar protótipos.

Documentar regras de negócio.

Isso reduz drasticamente o tempo de desenvolvimento.

Mas existe um detalhe importante.

A IA acelera.

Ela não substitui engenharia.

Alguém continua precisando tomar decisões arquiteturais.


Performance no RAD

Existe outro mito bastante conhecido.

"Software desenvolvido rapidamente é lento."

Não necessariamente.

Performance depende muito mais da arquitetura.

Uma aplicação construída em RAD pode apresentar excelente desempenho quando possui:

  • arquitetura bem definida;

  • banco de dados otimizado;

  • índices corretos;

  • consultas eficientes;

  • cache adequado;

  • testes de carga;

  • monitoramento constante.

O problema não está na velocidade do desenvolvimento.

Está na ausência de engenharia.


Governança

Projetos RAD também precisam de controle.

Sem governança surge o caos.

Algumas práticas recomendadas:

Versionamento no Git.

Code Review.

Integração Contínua.

Pipeline automatizado.

Testes automatizados.

Documentação mínima.

Monitoramento.

Catálogo de APIs.

Padronização de componentes.


Segurança

Outro erro comum.

"Ainda é protótipo."

Quantos incidentes começaram exatamente assim?

Mesmo durante prototipação devemos considerar:

Autenticação.

Autorização.

Criptografia.

Proteção de dados.

LGPD.

Auditoria.

Logs.

Quanto antes a segurança entrar no projeto...

Menor o custo.


Quando RAD não é a melhor escolha?

Existem situações em que outras abordagens podem ser mais adequadas.

Por exemplo:

Projetos militares.

Sistemas embarcados extremamente críticos.

Software aeroespacial.

Equipamentos médicos.

Aplicações certificadas.

Ambientes altamente regulados.

Nesses casos o custo da documentação extensa pode ser menor que o risco de falhas.

Mesmo assim, muitos princípios do RAD continuam sendo utilizados durante prototipação e validação.


O erro mais comum

Muitos gestores acreditam que RAD significa fazer tudo mais rápido.

Na realidade significa aprender mais rápido.

Existe uma enorme diferença.

Velocidade sem aprendizado produz retrabalho.

Aprendizado contínuo produz velocidade.

Essa talvez seja a maior lição deixada por James Martin.


O que um programador COBOL pode aproveitar hoje?

Mesmo trabalhando exclusivamente com IBM Z, praticamente todos os conceitos desta parte podem ser aplicados.

Você pode criar protótipos de telas antes de desenvolver transações CICS.

Pode validar regras de negócio com usuários antes de alterar programas COBOL.

Pode utilizar APIs simuladas para testar integrações.

Pode automatizar builds, testes e deploys em pipelines DevOps.

Pode expor programas COBOL como serviços REST por meio do z/OS Connect e receber feedback em ciclos curtos.

Pode utilizar Inteligência Artificial para documentar código legado, sugerir refatorações e acelerar a criação de testes.

O ambiente mudou muito desde 1991, mas o objetivo continua exatamente o mesmo: reduzir a distância entre a necessidade do negócio e a entrega de uma solução funcional.

No próximo café entraremos definitivamente no universo IBM Mainframe. Veremos como aplicar RAD em aplicações COBOL, CICS, IMS, DB2, VSAM e z/OS, como integrar essa metodologia com DevOps, Git, APIs, z/OS Connect, testes automatizados e modernização, além de entender por que o RAD continua extremamente relevante na era do IBM Z e da Inteligência Artificial.


quarta-feira, 24 de janeiro de 2024

RAD (Rapid Application Development) - O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia RAD Parte I

 

Bellacosa Mainframe apresenta a rapid application development parte i

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia que Ensinou o Mundo a Desenvolver Software Rapidamente

Você Não Está Descobrindo uma Ideia Nova. Está Descobrindo uma Tecnologia que Influenciou Quase Tudo o Que Veio Depois.

"Toda geração acredita que inventou uma forma mais rápida de desenvolver software. Poucos percebem que muitas dessas ideias nasceram há mais de trinta anos. O RAD foi uma delas."


Introdução

Quem começou a trabalhar com desenvolvimento de software nos anos 80 e 90 certamente ouviu falar de uma promessa bastante ousada.

"Vamos desenvolver sistemas em poucos meses."

Naquela época isso parecia impossível.

O desenvolvimento tradicional era lento.

Primeiro vinha o levantamento de requisitos.

Depois a documentação.

Depois o projeto.

Depois a programação.

Depois os testes.

Depois a homologação.

E finalmente... meses ou anos depois... o usuário via o sistema funcionando.

Não era raro um projeto durar dois ou três anos.

O problema?

Quando finalmente ficava pronto, o negócio já havia mudado.

As regras eram outras.

As necessidades eram diferentes.

E boa parte do software já nascia desatualizada.

Foi justamente para resolver esse problema que surgiu o Rapid Application Development, mais conhecido como RAD.

Muitos desenvolvedores mais jovens imaginam que desenvolvimento rápido começou com Agile, Scrum, DevOps, Low-Code ou Inteligência Artificial.

Na verdade, todos esses movimentos herdaram conceitos que o RAD apresentou décadas antes.

Para quem trabalha com COBOL, isso é especialmente interessante.

Durante muito tempo criou-se o mito de que Mainframe significa desenvolvimento lento.

Na prática, diversos bancos brasileiros entregavam sistemas críticos em velocidade impressionante utilizando conceitos extremamente próximos do RAD, mesmo antes de adotarem oficialmente essa metodologia.

O segredo nunca foi apenas a linguagem.

O segredo sempre foi o processo.


O cenário antes do RAD

Para entender o RAD precisamos voltar aos anos 1980.

A informática corporativa vivia um momento curioso.

Os computadores estavam ficando mais poderosos.

As empresas dependiam cada vez mais dos sistemas.

Mas o desenvolvimento continuava extremamente burocrático.

O modelo dominante era o famoso Waterfall, ou Cascata.

Sua lógica era simples.

Primeiro termina uma fase.

Depois começa a próxima.

Jamais volte atrás.

Na teoria fazia sentido.

Na prática...

Nem tanto.

Imagine desenvolver um sistema bancário durante dezoito meses.

Durante esse período:

  • novas leis aparecem;

  • novos produtos financeiros surgem;

  • a inflação muda;

  • concorrentes inovam;

  • clientes mudam de comportamento.

Quando o software finalmente chega à produção...

Ele resolve um problema que talvez nem exista mais.

Era uma época em que modificar requisitos era quase um pecado.

Qualquer alteração significava:

  • alterar documentos;

  • alterar diagramas;

  • alterar especificações;

  • alterar programas;

  • alterar testes.

Tudo isso custava muito dinheiro.

Foi nesse ambiente que algumas pessoas começaram a fazer uma pergunta aparentemente simples.

"E se desenvolvêssemos junto com o usuário?"

Essa pergunta mudaria a história da Engenharia de Software.


O nascimento do RAD

O principal responsável pela popularização do RAD foi James Martin.

Image

Image

Image

James Martin era um dos maiores especialistas em Engenharia de Software da época.

Consultor.

Autor.

Pesquisador.

Visionário.

Em 1991 publicou um livro que se tornaria referência mundial:

Rapid Application Development.

Naquele momento ele propôs algo bastante diferente.

Ao invés de gastar meses planejando cada detalhe do sistema...

Construa uma primeira versão.

Mostre ao usuário.

Receba feedback.

Melhore.

Repita.

Hoje isso parece absolutamente normal.

Na época era revolucionário.

Martin defendia que o software não deveria nascer perfeito.

Deveria nascer útil.

Existe uma enorme diferença entre essas duas ideias.


O grande problema que o RAD resolveu

Imagine um gerente de banco.

Ele pede um sistema.

Durante meses responde entrevistas.

Participa de reuniões.

Assina documentos.

Depois desaparece.

Um ano depois recebe o software.

Ao abrir a aplicação percebe algo curioso.

"Não era exatamente isso que eu queria."

Essa frase custava milhões de dólares.

Não porque os programadores eram ruins.

Mas porque pessoas têm dificuldade em imaginar um sistema apenas olhando documentação.

Quando veem uma tela funcionando...

Tudo muda.

Elas descobrem novas necessidades.

Percebem erros.

Lembram regras esquecidas.

Propõem melhorias.

O RAD transformou essa descoberta em metodologia.

Em vez de lutar contra mudanças...

Passe a utilizá-las como parte natural do desenvolvimento.


O princípio mais importante do RAD

Se fosse necessário resumir o RAD em apenas uma frase, seria esta:

O usuário entende melhor um sistema funcionando do que um documento descrevendo esse sistema.

Esse conceito parece óbvio hoje.

Mas revolucionou a forma de desenvolver software.

Em vez de produzir centenas de páginas de documentação...

Construa rapidamente um protótipo.

Mesmo incompleto.

Mesmo simples.

Mesmo temporário.

Porque um protótipo gera discussões muito mais produtivas do que um documento.

É muito mais fácil dizer:

"Esse botão deveria estar aqui."

Do que imaginar onde ele deveria ficar lendo uma especificação técnica.


O que significa "Rapid"

Muita gente interpreta o nome errado.

Rapid não significa:

"Programar correndo."

Nem:

"Escrever código sem qualidade."

Nem:

"Ignorar documentação."

Nem:

"Fazer gambiarra."

Rapid significa reduzir desperdícios.

Eliminar atividades que não agregam valor.

Descobrir erros cedo.

Corrigir rapidamente.

Automatizar tarefas repetitivas.

Construir somente aquilo que realmente será utilizado.

Em outras palavras...

Ser rápido porque o processo ficou melhor.

Não porque os programadores trabalham mais horas.


Os quatro pilares do RAD

Embora existam diversas interpretações, praticamente todas compartilham quatro fundamentos.

1. Desenvolvimento iterativo

Ao invés de entregar tudo no final...

Entregue pequenas partes continuamente.

Cada versão adiciona funcionalidades.

Cada ciclo reduz riscos.

Cada entrega aproxima o produto da necessidade real.

Esse conceito mais tarde inspiraria boa parte do Agile.


2. Prototipação

O protótipo é talvez a característica mais conhecida do RAD.

Ele não precisa ser bonito.

Nem completo.

Seu objetivo é validar ideias.

Quanto antes o usuário interagir...

Melhor.

Hoje fazemos isso com wireframes.

Mockups.

Aplicações Low-Code.

Ferramentas de UX.

Nos anos 90 isso já existia, apenas com tecnologias diferentes.


3. Participação intensa do usuário

No RAD o cliente deixa de ser apenas aprovador.

Ele participa continuamente.

Isso reduz um problema clássico.

Desenvolver exatamente aquilo que ninguém precisava.

Quanto mais próximo estiver o usuário...

Maior a chance de sucesso.


4. Times pequenos e multidisciplinares

Equipes enormes costumam gerar burocracia.

RAD prefere grupos pequenos.

Com autonomia.

Decisão rápida.

Comunicação simples.

Responsabilidade compartilhada.

Décadas depois...

Scrum repetiria praticamente o mesmo conceito.


O ciclo de vida do RAD

Embora existam variações, normalmente encontramos quatro grandes fases.

Planejamento

Define objetivos.

Escopo inicial.

Equipe.

Restrições.

Não tenta prever absolutamente tudo.

Planeja apenas o suficiente para começar.


Design colaborativo

Usuários e desenvolvedores trabalham juntos.

Modelam processos.

Criam protótipos.

Validam telas.

Ajustam regras.

É uma fase extremamente dinâmica.


Construção rápida

Os desenvolvedores começam imediatamente.

Ferramentas de geração automática.

Componentes reutilizáveis.

Bibliotecas.

Frameworks.

Tudo é utilizado para acelerar o trabalho.


Transição

Depois das validações...

O sistema entra em produção.

Mas o ciclo continua.

Novas versões aparecem.

Novos ajustes são realizados.

O software evolui continuamente.


RAD e Engenharia de Software

Existe um mito curioso.

Algumas pessoas acreditam que RAD significa abandonar Engenharia de Software.

Na verdade ocorre exatamente o contrário.

O RAD depende fortemente de boas práticas.

Arquitetura.

Modelagem.

Reutilização.

Padronização.

Automação.

Sem isso...

O desenvolvimento rápido se transforma rapidamente em caos.

Quanto maior a velocidade...

Maior deve ser a disciplina.


RAD versus Waterfall

A comparação mais comum é entre RAD e Cascata.

WaterfallRAD
Planejamento extensoPlanejamento suficiente
Documentação pesadaProtótipos
Entrega únicaEntregas frequentes
Mudanças carasMudanças esperadas
Usuário distanteUsuário presente
Descobre erros tardeDescobre erros cedo

Nenhum modelo é perfeito.

Projetos extremamente regulados ainda utilizam Cascata.

Projetos inovadores normalmente preferem abordagens iterativas.


O RAD influenciou quase tudo

É curioso observar quantas metodologias modernas possuem DNA do RAD.

Scrum utiliza iterações.

Kanban utiliza fluxo contínuo.

Lean elimina desperdícios.

XP incentiva feedback constante.

DevOps aproxima desenvolvimento e operação.

Low-Code acelera construção.

No-Code reduz codificação.

IA Generativa cria protótipos em minutos.

Nenhuma dessas ideias nasceu isoladamente.

Todas beberam, em maior ou menor grau, da mesma fonte: a busca por ciclos curtos de entrega e validação.


Vantagens do RAD

Para o negócio, os benefícios são claros:

  • redução do tempo de entrega;

  • menor custo de mudanças;

  • maior participação do cliente;

  • melhor alinhamento com o negócio;

  • menor risco de desenvolver funcionalidades desnecessárias;

  • maior satisfação dos usuários;

  • retorno mais rápido do investimento;

  • possibilidade de corrigir erros antes que se tornem caros.

Para os desenvolvedores, o ganho também é significativo.

Ver o sistema funcionando cedo aumenta a motivação da equipe.

O feedback deixa de ser uma surpresa no final do projeto e passa a orientar o trabalho desde o primeiro ciclo.


Desvantagens e limitações

Nenhuma metodologia resolve todos os problemas.

O RAD também possui limitações.

Projetos gigantescos, envolvendo centenas de equipes e forte dependência regulatória, podem exigir maior formalismo.

Além disso, o sucesso depende da disponibilidade do usuário.

Se o cliente não participa, o principal benefício do RAD desaparece.

Outro ponto crítico é a arquitetura.

A pressa para entregar não pode comprometer a qualidade estrutural da solução.

Sem uma boa arquitetura, cada nova iteração aumenta a dívida técnica.


Mitos sobre o RAD

Ao longo dos anos, alguns equívocos se tornaram comuns.

"RAD é programar sem planejamento."
Não. O planejamento existe, mas é adaptativo.

"RAD elimina documentação."
Não. Ele elimina documentação desnecessária.

"RAD serve apenas para sistemas pequenos."
Não. Grandes organizações o utilizam, desde que combinado com boa governança.

"RAD gera software de baixa qualidade."
Também não. Quando bem aplicado, tende a produzir software mais aderente às necessidades do negócio justamente porque recebe feedback constante.


O que um programador COBOL deve aprender com o RAD?

Talvez a maior lição do RAD seja esta:

A velocidade de um projeto não depende apenas da linguagem.

COBOL continua processando bilhões de transações diariamente com confiabilidade incomparável.

O desafio moderno não é substituir COBOL, mas reduzir o tempo entre uma ideia de negócio e sua implementação em produção.

É aí que entram os princípios do RAD.

Prototipação.

Integração contínua.

Automação de testes.

Reutilização de componentes.

Participação ativa do usuário.

Entrega incremental.

Esses conceitos funcionam tão bem em aplicações web quanto em ambientes IBM Z.

Um programa COBOL que expõe serviços por meio do z/OS Connect, integra APIs REST, participa de pipelines DevOps e recebe feedback frequente do negócio está muito mais próximo do espírito do RAD do que muitos sistemas escritos com tecnologias consideradas "modernas".

No fim, o RAD nunca foi sobre velocidade pela velocidade.

Sempre foi sobre reduzir desperdícios, aprender mais cedo e entregar valor continuamente.

Essa ideia nasceu há mais de três décadas, atravessou gerações de linguagens, frameworks e plataformas, e continua moldando a forma como construímos software.

No próximo café, veremos como colocar o RAD em prática: metodologias, ferramentas clássicas e modernas, métricas, governança, performance, integração com Low-Code, IA e um passo a passo completo para implementar RAD com sucesso — inclusive em ambientes IBM Mainframe.


quarta-feira, 29 de novembro de 2023

Low-Code: O Que Todo Programador COBOL Precisa Saber Você Não Está Sendo Substituído.

 

Bellacosa Mainframe e o low-code para o mundo mainframe

☕ Um Café no Bellacosa Mainframe

Low-Code: O Que Todo Programador COBOL Precisa Saber

Você Não Está Sendo Substituído. Está Ganhando Mais uma Ferramenta para Construir Soluções.

"Toda geração acredita que encontrou a tecnologia que acabará com o desenvolvimento tradicional. Até descobrir que software continua sendo engenharia."


Introdução

Durante décadas ouvimos promessas parecidas.

Primeiro foi o CASE.

Depois vieram os geradores automáticos.

Em seguida os Frameworks.

Logo apareceram os CMS.

Depois os ERPs prometendo eliminar programação.

Mais tarde surgiram as plataformas BPM.

Então veio o No-Code.

Agora o assunto da vez é o Low-Code.

Sempre aparece alguém dizendo:

"Agora ninguém mais precisará programar."

O curioso é que o número de desenvolvedores no mundo nunca foi tão grande.

Por quê?

Porque a demanda por software cresce mais rápido do que qualquer tecnologia consegue simplificar.

Para quem trabalha com IBM Z, COBOL, CICS, DB2 e z/OS, entender Low-Code não significa abandonar décadas de experiência.

Significa entender onde essa tecnologia realmente funciona.

E onde ela não funciona.


O que é Low-Code?

Low-Code é uma abordagem de desenvolvimento baseada em componentes visuais.

Em vez de escrever milhares de linhas de código manualmente, o desenvolvedor monta aplicações através de:

  • componentes prontos

  • fluxos visuais

  • formulários

  • regras de negócio

  • integrações

  • conectores

  • workflows

A plataforma gera automaticamente boa parte do código.

Isso não significa ausência de programação.

Normalmente existe código.

Muito código.

Só que parte dele é gerado automaticamente.

Por isso o nome:

Low-Code

e não

No-Code.


A diferença entre Low-Code e No-Code

Embora muita gente use como sinônimos, são conceitos diferentes.

No-Code

Destinado para usuários de negócio.

Exemplos:

  • RH

  • Marketing

  • Financeiro

  • Comercial

O objetivo é permitir criar aplicações sem escrever código.


Low-Code

Voltado para desenvolvedores.

Permite:

  • escrever código quando necessário

  • criar componentes próprios

  • consumir APIs

  • acessar bancos

  • integrar sistemas

  • customizar regras

Ou seja:

continua sendo engenharia de software.


Como surgiu o Low-Code?

Na verdade, a ideia é muito mais antiga do que parece.

Se voltarmos aos anos 80 veremos ferramentas como:

  • PowerBuilder

  • Delphi

  • Visual Basic

  • Oracle Forms

  • IBM VisualAge

  • Gupta SQLWindows

Todas possuíam:

  • drag-and-drop

  • componentes visuais

  • geração automática de código

Hoje chamaríamos isso de Low-Code.

A diferença é que atualmente as plataformas são orientadas para:

  • Cloud

  • APIs

  • Mobile

  • Microsserviços

  • Containers

  • IA

Ou seja,

o conceito é antigo.

A infraestrutura mudou.


Linha do tempo

Década de 1980

Programação visual.

CASE.

Geradores de código.

RAD (Rapid Application Development).


Década de 1990

Visual Basic.

Delphi.

PowerBuilder.

Oracle Forms.

Lotus Notes.


Década de 2000

SOA.

BPM.

Workflow.

Ferramentas corporativas.


Década de 2010

Cloud.

Mobile.

APIs REST.

Low-Code moderno.


Década de 2020

IA Generativa.

Copilots.

Modelagem automática.

Assistentes inteligentes.

Low-Code + IA.


O objetivo nunca foi eliminar programadores

Essa é talvez a maior confusão.

Imagine um arquiteto.

Hoje existem softwares que desenham plantas automaticamente.

Isso eliminou arquitetos?

Não.

Apenas aumentou sua produtividade.

O mesmo ocorre aqui.

Low-Code automatiza tarefas repetitivas.

Quem continua decidindo arquitetura é o desenvolvedor.


Como funciona internamente?

Quase todas as plataformas seguem a mesma arquitetura.

Usuário

↓

Designer Visual

↓

Modelo da Aplicação

↓

Gerador de Código

↓

Compilação

↓

Banco

↓

Servidor

↓

Aplicação Executando

O desenvolvedor manipula um modelo.

A plataforma transforma esse modelo em código.


Quais problemas o Low-Code resolve?

Principalmente:

  • desenvolvimento lento

  • escassez de desenvolvedores

  • excesso de sistemas internos

  • necessidade de digitalização

  • automação de processos

  • criação rápida de protótipos

Imagine um departamento de RH precisando aprovar férias.

Não faz sentido iniciar um projeto de 8 meses.

Uma plataforma Low-Code resolve isso em dias.


Onde o Low-Code é excelente?

Sistemas internos

  • RH

  • Compras

  • Financeiro

  • Aprovação


Dashboards

Indicadores.

KPIs.

Relatórios.


Formulários

Cadastro.

Pesquisa.

Solicitações.


Workflow

Fluxos de aprovação.


Aplicativos móveis

Aplicações simples.


Portais

Intranet.

Extranet.

Atendimento.


Onde ele não é indicado?

Nem tudo deve ser feito em Low-Code.

Exemplos:

  • motores bancários

  • processamento de cartões

  • compensação financeira

  • sistemas de bolsa

  • processamento em massa

  • compiladores

  • sistemas operacionais

  • bancos de dados

  • kernels

Nesses casos,

o controle fino importa.


Performance

Uma pergunta comum.

Low-Code é lento?

Resposta:

Depende.

Um formulário simples?

Praticamente igual.

Um workflow?

Excelente.

Mas aplicações extremamente críticas normalmente exigem código especializado.

Por quê?

Porque uma plataforma genérica precisa atender milhares de cenários.

Código manual pode ser otimizado especificamente.


O impacto na arquitetura

Antes:

Cliente

↓

Aplicação

↓

Banco

Hoje:

Cliente

↓

Portal Low-Code

↓

API

↓

Microsserviços

↓

Mainframe

↓

DB2

Perceba algo importante.

O Mainframe continua existindo.

Ele apenas deixa de conversar diretamente com o usuário.


Low-Code e APIs

Aqui está o ponto de encontro com IBM Z.

O Low-Code praticamente vive de APIs.

Quem fornece essas APIs?

Frequentemente:

  • COBOL

  • CICS

  • IMS

  • DB2

  • MQ

  • z/OS Connect

Ou seja,

o Mainframe passa a ser o motor.

O Low-Code apenas cria a interface.


O papel do COBOL muda?

Sim.

Mas não desaparece.

Antes:

COBOL fazia:

  • tela

  • regra

  • banco

Hoje:

COBOL concentra-se em:

  • regra de negócio

  • segurança

  • consistência

  • transações

Enquanto o Low-Code faz:

  • telas

  • formulários

  • dashboards

  • workflow

É uma separação saudável.


Principais vantagens

Desenvolvimento rápido

Dias em vez de meses.


Menos código repetitivo

CRUD praticamente automático.


Padronização

Todas as aplicações seguem o mesmo modelo.


Facilidade de manutenção

Mudanças visuais são simples.


Integração

APIs.

SOAP.

REST.

MQ.

SQL.

LDAP.

OAuth.


Reutilização

Componentes podem ser usados diversas vezes.


Os riscos

Nem tudo são flores.

Vendor Lock-in

Talvez seja o maior problema.

Sua aplicação depende da plataforma.

Trocar depois pode ser caro.


Código gerado

Nem sempre é elegante.

Às vezes gera excesso de processamento.


Limitações

Quando surge algo muito específico,

a plataforma pode não suportar.


Licenciamento

Grandes plataformas costumam ser caras.


Performance

Em aplicações extremamente críticas,

código especializado costuma vencer.


As boas práticas

Modele antes

Não saia criando telas.

Desenhe processos.


Use APIs

Nunca acesse diretamente sistemas legados.


Centralize regras

A regra deve permanecer no backend.

Nunca na interface.


Versione

Mesmo sendo visual.

Use Git.


Automatize testes

Aplicações visuais também precisam de testes.


Documente integrações

Principalmente contratos REST.


Passo a passo para criar uma aplicação Low-Code

1. Entenda o processo

Mapeie:

  • entradas

  • saídas

  • aprovações


2. Modele dados

Clientes.

Pedidos.

Produtos.

Usuários.


3. Crie formulários

Cadastro.

Consulta.

Pesquisa.


4. Configure regras

Quem pode aprovar?

Quem pode editar?


5. Integre APIs

REST.

SOAP.

MQ.

Banco.


6. Teste

Validação.

Carga.

Segurança.


7. Publique

Cloud.

On-premises.

Containers.


8. Monitore

Logs.

Performance.

Auditoria.


Principais metodologias utilizadas

Agile

Scrum.

Kanban.

Sprints curtas.


DevOps

CI/CD.

Deploy automático.


Domain Driven Design

Separação por domínio.


BPM

Modelagem de processos.


BPMN

Fluxos de negócio.


Design Thinking

Descoberta do problema.


UX

Experiência do usuário.


API First

Tudo começa pela API.


As principais plataformas Low-Code

O mercado amadureceu muito nos últimos anos e hoje existem dezenas de plataformas. Algumas são focadas em pequenas empresas; outras suportam ambientes corporativos gigantescos, incluindo integração com IBM Z.

Microsoft Power Apps

Talvez seja a plataforma mais conhecida atualmente.

Pontos fortes:

  • integração com Microsoft 365

  • SharePoint

  • Dynamics

  • Azure

  • Power Automate

  • Dataverse

Muito usada em departamentos internos.


Mendix

Uma das líderes mundiais.

Hoje pertence à Siemens.

Muito forte em aplicações corporativas complexas.

Possui excelentes recursos para integração com APIs REST e SOAP.


OutSystems

Bastante conhecida entre bancos, seguradoras e grandes empresas.

Possui:

  • desenvolvimento web

  • mobile

  • DevOps integrado

  • monitoramento

  • escalabilidade

É uma das plataformas mais maduras do mercado.


Appian

Extremamente forte em:

  • BPM

  • Workflow

  • Automação

  • Processos empresariais

Muito utilizada em governos e instituições financeiras.


Salesforce Platform

Voltada para aplicações em torno do ecossistema Salesforce.

Excelente quando toda a empresa já utiliza CRM Salesforce.


ServiceNow

Originalmente voltada para ITSM.

Hoje permite desenvolver inúmeras aplicações corporativas.


Oracle APEX

Muito respeitada entre desenvolvedores Oracle.

Rápida.

Estável.

Excelente para aplicações baseadas em banco Oracle.


IBM Business Automation Workflow

A IBM também investe nesse segmento.

Especialmente para processos corporativos.

Integra naturalmente com:

  • IBM MQ

  • CICS

  • DB2

  • IBM Z


Low-Code e Inteligência Artificial

A IA acelerou ainda mais esse mercado.

Hoje diversas plataformas conseguem:

  • criar formulários automaticamente

  • gerar consultas SQL

  • sugerir telas

  • criar APIs

  • escrever validações

  • documentar aplicações

Mas existe um detalhe.

A IA produz software.

Quem produz arquitetura continua sendo o engenheiro.


O impacto no ambiente Mainframe

Agora chegamos ao ponto mais importante para quem trabalha com COBOL.

Existe um mito recorrente:

"Se a empresa adotar Low-Code, o Mainframe desaparecerá."

Na prática acontece exatamente o contrário.

Quanto mais empresas investem em transformação digital, mais precisam acessar os sistemas que realmente armazenam os dados de negócio. Em bancos, seguradoras, operadoras de saúde, companhias aéreas e órgãos públicos, esses dados continuam majoritariamente em aplicações COBOL executando no IBM Z.

O Low-Code normalmente não substitui esse núcleo. Ele cria uma camada de experiência para o usuário.

Uma arquitetura moderna costuma seguir este fluxo:

Aplicativo Web ou Mobile
        │
        ▼
Plataforma Low-Code
        │
        ▼
API Gateway
        │
        ▼
z/OS Connect / API REST
        │
        ▼
CICS / IMS / MQ
        │
        ▼
Programas COBOL
        │
        ▼
DB2 / VSAM / IMS DB

Nesse cenário, o COBOL deixa de cuidar da interface gráfica e concentra seus esforços onde ele sempre foi excepcional:

  • regras de negócio;

  • integridade transacional;

  • processamento de alto volume;

  • consistência de dados;

  • disponibilidade contínua.

Enquanto isso, a plataforma Low-Code entrega:

  • formulários modernos;

  • portais web;

  • aplicativos móveis;

  • dashboards;

  • fluxos de aprovação;

  • integrações com serviços externos.

Essa separação de responsabilidades reduz o acoplamento e facilita a evolução dos sistemas.

Novas responsabilidades para o desenvolvedor COBOL

O profissional de Mainframe tende a atuar menos como "programador de telas" e mais como especialista em serviços.

Isso significa dominar conceitos como:

  • APIs REST;

  • JSON;

  • OpenAPI/Swagger;

  • OAuth e autenticação;

  • mensageria com IBM MQ;

  • integração via z/OS Connect;

  • versionamento de contratos;

  • observabilidade e monitoramento.

O conhecimento do negócio continua sendo o maior diferencial. Uma plataforma Low-Code pode gerar uma interface em minutos, mas não conhece as regras de crédito, tributação, previdência, seguros ou compensação bancária que estão consolidadas em décadas de código COBOL.

Oportunidades profissionais

Para quem trabalha com IBM Z, o crescimento do Low-Code abre novas possibilidades:

  • atuar como arquiteto de integração;

  • expor aplicações COBOL como APIs;

  • modernizar sistemas legados sem reescrevê-los;

  • integrar Mainframe com nuvem e aplicações móveis;

  • liderar iniciativas de transformação digital.

Em vez de competir com o Low-Code, o desenvolvedor COBOL pode tornar-se a peça central que conecta o legado confiável às novas interfaces de negócio.

Conclusão

Low-Code não é uma moda passageira nem a solução para todos os problemas. É mais uma etapa da evolução da engenharia de software.

Assim como o Delphi acelerou o desenvolvimento desktop, o Visual Basic simplificou aplicações Windows e os frameworks web reduziram código repetitivo, as plataformas Low-Code automatizam tarefas de baixo valor para que os desenvolvedores concentrem seu tempo naquilo que realmente importa: arquitetura, regras de negócio, segurança, integração e desempenho.

Para o profissional de Mainframe, a mensagem é especialmente positiva. O IBM Z continua sendo o ambiente onde executam algumas das aplicações mais críticas do planeta. O que muda é a forma como essas aplicações são consumidas. Em vez de telas verdes acessadas diretamente, elas passam a atender portais, aplicativos móveis e plataformas Low-Code por meio de APIs e serviços.

O futuro não será de COBOL ou Low-Code.

Será de COBOL com Low-Code, APIs, IA, DevOps e integração em nuvem, formando um ecossistema onde cada tecnologia desempenha o papel para o qual foi projetada.

No fim, a tecnologia muda, as interfaces evoluem e as ferramentas se renovam. Mas um princípio permanece inalterado desde os primeiros dias da computação: software crítico continua dependendo de boa engenharia. E essa continua sendo a principal especialidade de quem desenvolve soluções para o IBM Z.