Bellacosa Mainframe apresenta o zos connect

☕ Um Café no Bellacosa Mainframe

The Mentalist, COBOL e o Caso da API que Sabia Demais

🧠 z/OS Connect, REST, JSON, OpenAPI, CICS, IMS, Db2, SAF, RACF, SMF, WLM e o estranho caso em que Patrick Jane olhou para uma COMMAREA, sorriu e disse: “O problema nunca foi o COBOL. Foi quem tentou falar diretamente com ele.”

Imagine a cena.

Você acaba de entrar em uma sala de operações de um grande banco.

De um lado, desenvolvedores jovens discutem APIs, JSON, Kubernetes, microsserviços, OAuth, OpenAPI e gateways.

Do outro, um veterano de mainframe olha para uma tela verde onde aparece alguma coisa assim:

01 DFHCOMMAREA.
   05 CUSTOMER-ID        PIC 9(10).
   05 CUSTOMER-NAME      PIC X(40).
   05 ACCOUNT-BALANCE    PIC S9(11)V99 COMP-3.
   05 CUSTOMER-STATUS    PIC X(01).

No meio da sala está você, programador COBOL iniciante, tentando descobrir como esses dois mundos vão conversar.

Então entra Patrick Jane.

Ele olha para o código.

Olha para o diagrama da API.

Olha novamente para o código.

Sorri.

E pergunta:

— Por que vocês estão tentando ensinar o aplicativo móvel a entender COMP-3?

Silêncio.

O arquiteto cloud cruza os braços.

O programador CICS olha para o teto.

Jane continua:

— E por que estão tentando ensinar o programa COBOL a entender JSON?

Mais silêncio.

Finalmente ele pega uma caneta e escreve no quadro:

APP
 |
REST / JSON
 |
z/OS Connect
 |
CICS
 |
COBOL

E conclui:

— O truque não é fazer um mundo se tornar o outro. O truque é colocar alguém no meio que fale os dois idiomas.

Bem-vindo ao z/OS Connect.

E não, ele não é apenas “um conversor de JSON para COBOL”.

Essa definição seria tão incompleta quanto dizer que Sherlock Holmes era apenas um homem que usava lupa.

🔎 Cena do crime: dois mundos que não deveriam conhecer os detalhes um do outro

Comecemos pelo problema original.

Durante décadas, sistemas corporativos foram construídos sobre IBM Z utilizando tecnologias como:

COBOL;
CICS;
IMS;
Db2;
VSAM;
IBM MQ;
PL/I;
batch;
programas tradicionais de negócio.

Esses sistemas podem executar funções essenciais como:

consultar conta
autorizar pagamento
calcular seguro
registrar pedido
validar limite
atualizar estoque
consultar cliente
processar financiamento

A aplicação moderna, porém, pensa diferente.

Um aplicativo mobile quer fazer algo como:

GET /customers/1234567890

e receber:

{
  "customerId": 1234567890,
  "name": "JOAO DA SILVA",
  "balance": 15234.87,
  "status": "ACTIVE"
}

Parece simples.

Mas atrás dessa pequena chamada pode existir um programa COBOL que trabalha com:

PIC X
PIC 9
COMP
COMP-3
SIGN
REDEFINES
OCCURS
EBCDIC
COMMAREA
CHANNEL
CONTAINER

A pergunta verdadeira, portanto, não é:

“Como chamar um COBOL por REST?”

A pergunta correta é:

“Como criar uma fronteira estável entre consumidores modernos e ativos z/OS sem obrigar nenhum dos lados a conhecer detalhes desnecessários do outro?”

Essa é a investigação.

🧠 Primeira pista: o ativo de negócio

Documentações frequentemente usam o termo z/OS asset.

Para quem está começando, isso pode parecer algum arquivo misterioso armazenado no sistema.

Não necessariamente.

Um asset pode representar uma capacidade de negócio executada pelo ambiente z/OS.

Por exemplo:

Transação CICS
     |
     v
Programa COBOL
     |
     v
Db2
     |
     v
"Consultar cliente"

O ativo importante não é apenas o programa.

É o que ele sabe fazer.

Imagine um programa escrito há 25 anos que contém todas as regras para cálculo de prêmio de seguro.

Talvez o código seja antigo.

Mas as regras contidas ali representam décadas de conhecimento corporativo.

Patrick Jane provavelmente observaria:

— Você está olhando para código velho. Eu estou olhando para memória institucional.

E essa diferença muda tudo.

Modernização não significa obrigatoriamente eliminar o legado.

Às vezes significa tornar o legado acessível por interfaces modernas.

🚪 z/OS Connect como recepção do hotel

Existe uma analogia que gosto muito.

Imagine que o mainframe seja um hotel enorme.

Dentro dele existem departamentos falando linguagens próprias:

CICS
IMS
COBOL
Db2
VSAM
MQ
EBCDIC
COMP-3

Chega um cliente falando:

HTTP
REST
JSON
OpenAPI

Seria absurdo obrigar o hóspede a entrar na cozinha e perguntar:

— Onde deixo minha COMMAREA?

Da mesma maneira seria estranho mandar o cozinheiro estudar OAuth apenas para preparar o prato.

Você coloca uma recepção no meio.

CLIENTE
   |
   v
REST / JSON
   |
   v
z/OS Connect
   |
   +------ CICS
   |
   +------ IMS
   |
   +------ outros ativos

O cliente fala o idioma externo.

A aplicação z/OS fala seu idioma interno.

O z/OS Connect faz a mediação.

🎯 Service Provider: quando o mundo chama o mainframe

O primeiro modelo importante é o Service Provider, também chamado, conceitualmente, de fluxo inbound.

O tráfego vem de fora para dentro:

Aplicação
   |
HTTP / REST
   |
   v
z/OS Connect
   |
   v
CICS / IMS / aplicação z/OS

Imagine um aplicativo bancário solicitando saldo.

O aplicativo envia:

GET /accounts/1234567890/balance

Para ele, a coisa termina aí.

Mas internamente o caminho pode acabar em algo como:

CICS transaction = BAL1
program = BALANCE
layout = COBOL copybook
dados = EBCDIC / binário
saldo = COMP-3

O consumidor não precisa saber nada disso.

Essa é uma das características mais importantes de uma boa arquitetura: esconder detalhes de implementação atrás de um contrato.

🕵️ Patrick Jane encontra a primeira mentira: API e serviço não são a mesma coisa

Aqui muitos iniciantes tropeçam.

Um serviço de backend e uma API não são necessariamente a mesma coisa.

Considere uma aplicação COBOL que oferece uma função:

CUSTOMER-INQUIRY

Internamente isso pode ser tratado como um serviço.

Mas externamente talvez desejemos disponibilizar:

GET /customers/{id}

ou:

GET /customers/{id}/accounts

ou ainda:

GET /customers/{id}/balance

A API representa aquilo que desejamos oferecer ao consumidor.

O serviço representa aquilo que sabemos acionar internamente.

Podemos visualizar:

API
 |
 +--- GET /customers/{id}
 |
 +--- GET /customers/{id}/accounts
 |
 +--- GET /customers/{id}/balance
              |
              v
        serviço backend
              |
              v
             CICS
              |
              v
            COBOL

Esse desacoplamento é ouro.

Porque amanhã a implementação pode mudar sem necessariamente alterar o contrato externo.

🧬 O mistério do COMP-3 desaparecido

Chegamos ao coração técnico da história.

Suponha que o COBOL possua:

01 CUSTOMER-DATA.
   05 CUSTOMER-ID      PIC 9(08).
   05 CUSTOMER-NAME    PIC X(30).
   05 BALANCE          PIC S9(9)V99 COMP-3.

Enquanto o cliente espera:

{
  "customerId": 12345678,
  "customerName": "MARIA SILVA",
  "balance": 850.75
}

Esses dois mundos usam representações completamente diferentes.

COBOL entende conceitos como:

PIC
USAGE
COMP
COMP-3
SIGN
OCCURS
REDEFINES

JSON entende basicamente:

string
number
boolean
array
object
null

Alguém precisa transformar um modelo no outro.

Conceitualmente:

JSON
 |
 v
mapping
 |
 v
estrutura esperada pelo backend
 |
 v
COBOL

Na volta:

COBOL
 |
 v
estrutura interna
 |
 v
mapping
 |
 v
JSON

Para um COBOLzeiro, podemos brincar dizendo que é um tipo de:

SORT FIELDS=COPY diplomático entre civilizações de dados.

Só que aqui não estamos reorganizando registros.

Estamos traduzindo modelos de representação.

☕ Curiosidade de CPD: o COBOL talvez nunca saiba que existe JSON

Essa ideia merece atenção.

Um programa COBOL escrito antes da popularização da web pode continuar executando sua lógica normalmente.

Ele recebe uma estrutura.

Processa.

Devolve outra estrutura.

Pronto.

Do ponto de vista dele:

entrada
processamento
saída

Nada mudou.

Enquanto do lado externo temos:

HTTPS
REST
JSON
OpenAPI
API Gateway

Você acabou de criar uma arquitetura moderna ao redor de uma aplicação que talvez tenha começado sua carreira quando ninguém ainda dizia “cloud-native”.

Isso é encapsulamento em escala empresarial.

🛡️ SAF e RACF: Patrick Jane não confia em ninguém sem investigar

Agora chegamos à segurança.

O z/OS possui um conceito importantíssimo chamado SAF — System Authorization Facility.

SAF funciona como uma interface através da qual componentes do z/OS podem pedir verificações de segurança.

Um produto como RACF pode estar por trás dessa interface.

Simplificando:

z/OS Connect
    |
    v
   SAF
    |
    v
  RACF

Imagine que alguém chegue dizendo:

— Sou o usuário ABC123.

Autenticação pergunta:

Quem é você?

Autorização pergunta:

Você pode fazer isso?

Essa diferença parece pequena, mas é gigantesca.

Uma identidade autenticada pode não possuir autorização para chamar determinado recurso.

É semelhante ao prédio da polícia em The Mentalist.

Você pode possuir crachá para entrar no edifício.

Isso não significa que pode abrir qualquer sala de evidências.

📜 SMF: toda boa investigação precisa de registros

Agora aparece uma das integrações mais poderosas do ecossistema z/OS: SMF — System Management Facilities.

O mainframe possui longa tradição em registrar atividades operacionais.

SMF pode alimentar processos associados a:

auditoria
performance
capacity planning
chargeback
investigação
segurança
estatísticas

Quando APIs começam a acessar sistemas centrais, você quer responder perguntas como:

Quem chamou?
Quando chamou?
Qual recurso?
Quanto demorou?
Qual foi o resultado?

Imagine um incidente às 03:17.

Um investigador pergunta:

— Quem consultou essa conta?

Você não quer ouvir:

— Talvez aquele microsserviço azul que estava naquele container que morreu ontem.

Você quer rastreabilidade.

É aqui que a cultura mainframe mostra uma virtude antiga: registrar o que aconteceu é tão importante quanto fazer acontecer.

⚙️ WLM: nem todas as requisições merecem tratamento igual

Outro elemento importante é WLM — Workload Manager.

No mundo simplificado de APIs podemos imaginar:

requisição = requisição

Mas produção não funciona assim.

Uma consulta simples pode ter importância menor que uma autorização financeira urgente.

Considere:

GET /marketing/catalog

versus:

POST /payments/authorize

Talvez ambos sejam APIs.

Mas não necessariamente devem receber a mesma prioridade operacional.

O WLM existe justamente no universo z/OS para tratar workloads de acordo com metas e importância.

Isso é fascinante porque mostra que APIs modernas podem entrar em um ambiente que há décadas já trabalha com conceitos sofisticados de gerenciamento de carga.

🧱 Liberty: a base que fala HTTP naturalmente

O z/OS Connect utiliza tecnologia associada ao Liberty, oferecendo uma base moderna para aplicações Java, HTTP e serviços REST.

Para um programador COBOL podemos pensar assim:

Liberty
   |
runtime moderno
   |
HTTP / REST / segurança
   |
z/OS Connect

É importante porque o mainframe não precisa fingir que HTTP é uma COMMAREA.

Existe uma camada apropriada para lidar com tecnologias web.

Cada componente trabalha no terreno em que é mais competente.

Isso é arquitetura saudável.

🌍 API Gateway: o porteiro antes da recepção

Existe ainda outra peça que costuma aparecer na arquitetura:

CLIENT
   |
   v
API Gateway
   |
   v
z/OS Connect
   |
   v
CICS
   |
   v
COBOL

Não confunda API Gateway com z/OS Connect.

Um gateway frequentemente cuida de questões como:

rate limiting
throttling
quotas
API keys
analytics
policies
versionamento
developer portal
controle de consumidores

O z/OS Connect está mais próximo da integração com os ativos z/OS.

Podemos imaginar:

API Gateway
    =
porteiro do condomínio

z/OS Connect
    =
recepção que sabe para onde encaminhar

Ambos são importantes, mas têm papéis diferentes.

🚨 A armadilha da metralhadora REST

Aqui vai uma história que deveria assustar qualquer sysprog.

Suponha que alguém desenvolva:

setInterval(getBalance, 10);

Parabéns.

Você acaba de transformar um aplicativo em uma metralhadora REST apontada diretamente para o CICS.

Uma transação que antes recebia 500 chamadas por minuto pode começar a receber:

Mobile
Web
Bots
Parceiros
Microsserviços
Aplicações internas
        |
        v
       API
        |
        v
      CICS

e saltar para:

25.000 chamadas por minuto

Publicar uma API muda o perfil do workload.

Portanto entram questões como:

throttling
rate limiting
timeout
capacity planning
WLM
CICS MXT
CPU
zIIP
Db2 locks
pool de conexões
caching
SLA

A API pode tornar um recurso mais acessível.

E exatamente por isso pode torná-lo muito mais solicitado.

🔄 API Requester: quando o COBOL decide sair de casa

Até agora falamos do mundo chamando o mainframe.

Mas existe o movimento contrário.

O API Requester permite que aplicações z/OS consumam APIs REST externas.

O fluxo passa a ser:

COBOL
 |
 v
z/OS Connect
 |
 v
REST API
 |
 v
Cloud / SaaS / serviço externo

Isso é uma mudança conceitual enorme.

Imagine um programa COBOL que precisa consultar uma cotação de moeda.

Sua estrutura pode ser:

01 CURRENCY-REQUEST.
   05 FROM-CURRENCY PIC X(03).
   05 TO-CURRENCY   PIC X(03).
   05 AMOUNT        PIC 9(09)V99.

Enquanto o serviço externo recebe:

{
  "from": "USD",
  "to": "BRL",
  "amount": 100
}

O fluxo conceitual:

COBOL data
   |
   v
mapping
   |
   v
JSON
   |
   v
REST API
   |
   v
JSON response
   |
   v
mapping
   |
   v
COBOL data

Portanto o z/OS Connect não serve apenas para fazer:

REST -> MAINFRAME

Também pode permitir:

MAINFRAME -> REST

🌉 O mainframe deixa de ser uma ilha

Juntando os dois movimentos:

                z/OS Connect
                     |
         +-----------+-----------+
         |                       |
      Provider                Requester
         |                       |
   REST -> z/OS              z/OS -> REST

Imagine:

APP MOBILE
   |
   v
API Gateway
   |
   v
z/OS Connect
   |
   v
CICS
   |
   v
COBOL

Durante o processamento, aquele COBOL pode precisar consultar uma API externa antifraude:

COBOL
   |
   v
z/OS Connect Requester
   |
   v
API antifraude
   |
   v
Cloud

Agora temos uma arquitetura genuinamente híbrida:

Mobile
   |
REST
   |
IBM Z
   |
COBOL
   |
REST
   |
Cloud

O mainframe continua sendo o sistema central.

Mas participa de um ecossistema moderno.

📐 OpenAPI: o contrato que impede testemunhas de mudar a história

Uma API moderna precisa de um contrato claro.

É aqui que entra OpenAPI.

Algo conceitualmente assim:

paths:
  /customers/{customerId}:
    get:
      operationId: getCustomer

Isso pode descrever:

URI
método HTTP
parâmetros
request
response
tipos
status codes

O contrato OpenAPI pode ser usado por ferramentas para:

documentação
geração de clientes
testes
validação
automação
DevOps

Patrick Jane provavelmente observaria:

— Em investigações, pessoas mudam versões. Em APIs, contratos existem para impedir isso.

Se hoje a API retorna:

{
  "balance": 100.00
}

e amanhã alguém simplesmente muda para:

{
  "currentBalance": 100.00
}

pode quebrar consumidores.

Por isso API não é apenas interface.

É contrato de produção.

🗃️ SAR e AAR: pegadas de uma geração anterior

Quem pesquisa z/OS Connect inevitavelmente encontra termos como:

SAR
Service Archive

AAR
API Archive

Eles aparecem em materiais históricos de versões anteriores do produto.

Isso merece cuidado.

A tecnologia evoluiu.

Hoje existe uma orientação muito mais forte para abordagens baseadas em OpenAPI e tooling moderno.

Portanto, ao estudar, adote uma regra que todo veterano de mainframe aprende cedo:

Antes de acreditar em uma documentação, descubra para qual versão ela foi escrita.

Essa regra economiza semanas de sofrimento.

Mainframe possui excelente retrocompatibilidade.

Documentação da internet, nem sempre.

🔧 DevOps entra na investigação

APIs não deveriam ser tratadas como arquivos criados artesanalmente e esquecidos em produção.

Uma abordagem moderna pode ter:

Git
 |
 v
OpenAPI
 |
 v
Build
 |
 v
Validation
 |
 v
Tests
 |
 v
Package
 |
 v
Deploy
 |
 v
z/OS Connect

Agora imagine um commit:

commit:
"alterando resposta da API"

Isso pode disparar:

lint
validation
test
build
deployment

O IBM Z passa a participar do mesmo ciclo de engenharia observado no restante da organização.

Não significa abandonar controles tradicionais.

Significa integrá-los.

🧪 Passo a passo mental para construir uma API

Suponha que você precise expor uma consulta de cliente existente no CICS.

Passo 1 — descubra o verdadeiro ativo

Não comece pela API.

Pergunte:

Qual transação?
Qual programa?
Qual entrada?
Qual saída?
Onde estão os dados?

Talvez descubra:

TRN = CUST
PGM = CUSTINQ
DB  = Db2

Passo 2 — entenda o layout COBOL

Exemplo:

01 REQUEST.
   05 CUSTOMER-ID PIC 9(10).

01 RESPONSE.
   05 NAME        PIC X(40).
   05 STATUS      PIC X.

Passo 3 — pense como consumidor

O consumidor não quer saber sobre PIC 9(10).

Ele quer:

GET /customers/1234567890

Passo 4 — defina o contrato

Resposta:

{
  "customerId": "1234567890",
  "name": "JOAO DA SILVA",
  "status": "ACTIVE"
}

Passo 5 — defina o mapping

Agora ligue:

customerId
     |
     v
CUSTOMER-ID

NAME
 |
 v
name

Passo 6 — defina segurança

Pergunte:

Quem pode chamar?
Como será autenticado?
Qual recurso SAF?
Quais grupos RACF?

Passo 7 — pense em observabilidade

Pergunte:

O que será registrado?
SMF?
Logs?
Tempo de resposta?
Erros?

Passo 8 — pense em carga

Pergunte:

Quantas chamadas?
Qual pico?
Qual SLA?
É necessário throttling?

Passo 9 — teste erro, não apenas sucesso

Teste:

cliente inexistente
dados inválidos
backend indisponível
timeout
usuário não autorizado
CICS congestionado
Db2 indisponível

A API perfeita em PowerPoint costuma morrer no primeiro HTTP 500.

🧠 Dica de Mentalista: observe aquilo que ninguém está perguntando

Em projetos de integração, todos perguntam:

“A API funciona?”

Pergunte também:

“O que acontece se ela funcionar demais?”

Esse é um dos segredos arquiteturais mais importantes.

Uma API bem-sucedida pode multiplicar chamadas.

Imagine antes:

Sistema A
   |
500 chamadas/hora

Depois:

Sistema A
Sistema B
Sistema C
Mobile
Parceiros
Bots
Analytics
       |
       v
50.000 chamadas/hora

O backend continua sendo o mesmo.

Isso significa que API design também precisa envolver:

capacity
performance
security
governance
resiliência

💣 Easter egg: o Red John das APIs

Toda série policial precisa de um vilão recorrente.

No mundo das APIs, ele atende por vários nomes:

acoplamento
falta de controle
ausência de versionamento
payload mal desenhado
autorização excessiva
timeout inexistente
retry infinito

Mas existe um especialmente perigoso:

expor diretamente a implementação interna.

Imagine uma API assim:

POST /executeTransaction/BAL1/program/BALANCE

Isso é quase entregar ao cliente o mapa da casa inteira.

Melhor expor intenção de negócio:

GET /accounts/{id}/balance

A API deveria dizer:

“o que o negócio oferece”

e não:

“como meu CICS está montado”.

Patrick Jane chamaria isso de linguagem corporal arquitetural.

Quando uma API começa a revelar demais sobre o backend, alguma coisa está errada.

🏚️ APIficar não é modernizar automaticamente

Outro erro comum:

legacy ruim
   |
REST
   |
legacy moderno

Não.

Você pode ter:

API linda
   |
   v
COBOL gigantesco
   |
   v
47 CALLs
   |
   v
12 tabelas Db2
   |
   v
3 arquivos VSAM
   |
   v
regra que ninguém entende desde 1997

O z/OS Connect resolve integração.

Ele não resolve automaticamente:

código ruim
acoplamento
débito técnico
modelagem inadequada
problemas de performance
regras incompreensíveis

API não é água benta arquitetural.

🧭 O erro do iniciante: pensar em tecnologia antes do negócio

O programador iniciante geralmente pergunta:

“Como faço o JSON?”

O arquiteto experiente pergunta:

“Qual capacidade estamos oferecendo?”

Essa mudança mental é importante.

Em vez de começar:

REST
JSON
OpenAPI

comece:

negócio
 |
capacidade
 |
contrato
 |
integração

Depois escolha a tecnologia.

Porque uma API excelente para uma operação mal definida continuará sendo uma API mal desenhada.

🎩 Curiosidade: o mainframe já fazia “serviços” antes da palavra ficar elegante

Existe uma ironia histórica deliciosa.

Durante décadas, aplicações mainframe já separavam responsabilidades usando:

CALL
LINK
XCTL
MQ
transações
programas reutilizáveis
copybooks
interfaces

Hoje chamamos muitos conceitos de:

service
API
contract
interface

É claro que as tecnologias são diferentes.

Mas a ideia de criar fronteiras entre componentes não nasceu com REST.

O veterano COBOL pode aprender uma coisa importante:

Você não está entrando em um universo completamente alienígena.

Muito do raciocínio arquitetural você já conhece.

Os nomes mudaram.

Os protocolos mudaram.

Os princípios continuam surpreendentemente familiares.

☕ A cena final

Depois de horas olhando diagramas, Patrick Jane pega sua xícara de chá.

O veterano COBOL pergunta:

— Então o z/OS Connect moderniza o mainframe?

Jane faz aquela expressão irritantemente tranquila.

— Não exatamente.

— Então ele substitui COBOL?

— Não.

— Converte JSON?

— Também.

— Então o que ele realmente faz?

Jane aponta para o quadro.

MUNDO MODERNO
REST / JSON / OpenAPI
        |
        v
   z/OS Connect
        |
        v
MUNDO IBM Z
CICS / IMS / COBOL

E responde:

— Ele permite que dois mundos colaborem sem obrigar nenhum deles a fingir que é o outro.

Essa é a chave.

O COBOL não precisa virar JavaScript.

O aplicativo mobile não precisa entender COMMAREA.

O desenvolvedor cloud não precisa saber onde está o programa CICS.

O programa CICS não precisa saber que foi chamado por um smartphone.

Cada camada conhece apenas aquilo que precisa conhecer.

E isso, no fim das contas, é arquitetura.

🧠 O mapa mental definitivo

Se você está começando com z/OS Connect, grave este desenho:

                    CONSUMIDORES
             Mobile / Web / Cloud
                       |
                       v
                 API Gateway
                       |
                       v
                 z/OS Connect
                       |
        +--------------+--------------+
        |              |              |
       CICS           IMS          outros
        |              |
      COBOL          COBOL
        |
      Db2 / VSAM

No fluxo contrário:

COBOL
   |
   v
z/OS Connect Requester
   |
   v
REST API externa
   |
   v
Cloud / SaaS

E ao redor disso pense sempre em:

OpenAPI
Security
SAF
RACF
SMF
WLM
DevOps
Observability
API Management
Performance
Governance

🎯 Conclusão: observe o que está escondido atrás da API

O grande valor do z/OS Connect não é simplesmente “colocar REST na frente do COBOL”.

É criar uma fronteira arquitetural controlada.

De um lado:

HTTP
REST
JSON
OpenAPI
Cloud
Mobile
Web

Do outro:

COBOL
CICS
IMS
Db2
z/OS

No meio:

contrato
mapeamento
segurança
governança
observabilidade
integração

E aqui está talvez a lição mais importante para quem está começando.

Não despreze a aplicação antiga porque ela não fala JSON.

Ela pode carregar quarenta anos de conhecimento corporativo.

Também não force a aplicação moderna a aprender detalhes de mainframe que não lhe dizem respeito.

Coloque uma fronteira correta entre os dois mundos.

É para isso que arquiteturas de integração existem.

E quando alguém na reunião disser:

— Precisamos substituir COBOL porque o aplicativo mobile precisa usar REST...

Você pode sorrir discretamente, tomar um gole de café e pensar como Patrick Jane:

“Interessante. O suspeito parece culpado demais.”

Talvez COBOL não seja o problema.

Talvez a verdadeira pista esteja justamente na camada que faltava entre ele e o resto do mundo.

☕🧠🖥️

Easter egg final: se você chegou até aqui procurando Red John, talvez ele esteja escondido no único endpoint em produção que ninguém documentou, não possui throttling, aceita qualquer usuário autenticado e chama uma transação CICS que ninguém ousa alterar desde 1998.

Nesse caso, esqueça Patrick Jane.

Chame o sysprog.

Translate

quinta-feira, 7 de dezembro de 2023