🏯 Quando o programador COBOL descobriu que TI não serve apenas para executar a estratégia — ela também pode mudar o futuro da empresa

 

☕ Um Café no Bellacosa Mainframe

🏯 A KUZUNOHA COMPANY E A DUNGEON DO PLANEJAMENTO ESTRATÉGICO

Quando o programador COBOL descobriu que TI não serve apenas para executar a estratégia — ela também pode mudar o futuro da empresa

Matriz BCG, Cachorros, Vacas Leiteiras, Estrelas, Pontos de Interrogação, estratégia da informação, arquitetura, sistemas legados, mainframe, COBOL, CICS, APIs, dados, inovação — e o dia em que Makoto Misumi descobriu que administrar a Kuzunoha Company era muito mais complicado do que derrotar monstros.

---

🎬 PRÓLOGO — MAKOTO ABRE UMA EMPRESA

Imagine nosso jovem programador COBOL atravessando mais um portal.

Depois de enfrentar JCL, arquivos VSAM, transações CICS, Db2, APIs e aquele inevitável SOC7 das 03:17 da madrugada, ele aparece em outro mundo.

À sua frente está Makoto Misumi.

Ao lado dele, Tomoe observa tudo com aquele sorriso de quem provavelmente já sabe que alguma coisa vai dar errado.

Mio pergunta se aquilo é comestível.

Shiki está examinando uma pilha de relatórios.

E atrás deles existe uma placa:

KUZUNOHA COMPANY

Makoto olha para nosso programador e pergunta:

— Você entende de planejamento estratégico?

O COBOLzeiro responde:

— Sei fazer PERFORM UNTIL.

Makoto pensa alguns segundos.

— Serve.

Bem-vindo ao estranho mundo do Planejamento Estratégico de Tecnologia da Informação.

E nossa primeira descoberta será importante:

Programar corretamente aquilo que a empresa não deveria estar fazendo continua sendo desperdício.

---

🏪 CAPÍTULO 1 — A KUZUNOHA COMPANY TEM UM PROBLEMA

Quando pensamos em informática, normalmente começamos pela tecnologia.

COBOL.

Java.

Python.

Banco de dados.

Cloud.

Mainframe.

APIs.

Mas uma empresa não compra tecnologia simplesmente porque tecnologia existe.

Pelo menos não deveria.

Uma empresa possui objetivos.

Quer vender.

Reduzir custos.

Ganhar clientes.

Entrar em mercados.

Criar produtos.

Evitar concorrentes.

Aumentar produtividade.

Reduzir riscos.

E a tecnologia deve participar dessas decisões.

Imagine que a Kuzunoha Company tenha quatro produtos:

Poções tradicionais
Armas mágicas
Cristais de comunicação
Pergaminhos experimentais de teletransporte

Makoto dispõe de apenas 10.000 moedas para investir.

Onde colocar o dinheiro?

Dividir igualmente parece democrático:

2.500 → Poções
2.500 → Armas
2.500 → Cristais
2.500 → Teletransporte

Mas talvez seja uma decisão terrível.

Um produto pode estar morrendo.

Outro pode gerar praticamente todo o lucro.

Outro está crescendo violentamente.

E outro talvez seja a próxima revolução comercial — ou um completo fracasso.

Precisamos conhecer nosso portfólio.

É aqui que surge nossa primeira ferramenta.

---

🐄 CAPÍTULO 2 — MAKOTO ENCONTRA QUATRO CRIATURAS ESTRANHAS

A clássica Matriz BCG, associada ao Boston Consulting Group, tornou-se uma das ferramentas mais conhecidas para análise de portfólio.

Ela utiliza duas grandes dimensões:

                 CRESCIMENTO DO MERCADO
                         ALTO
                          ▲
                          │
             ❓           │          ⭐
       INTERROGAÇÃO       │       ESTRELA
                          │
──────────────────────────┼────────────────────►
                          │
             🐕           │          🐄
         CACHORRO         │    VACA LEITEIRA
                          │
                        BAIXO

          BAIXA ← PARTICIPAÇÃO → ALTA

Os nomes parecem saídos de um anime estranho.

Mas existe lógica por trás deles.

Temos:

🐕 Cachorro: pouca participação e baixo crescimento.

🐄 Vaca Leiteira: forte posição em mercado relativamente maduro.

⭐ Estrela: forte posição e mercado em crescimento.

❓ Ponto de Interrogação: posição ainda pequena em mercado promissor.

E aqui faremos uma pequena magia.

Vamos aplicar essa ideia aos sistemas de informação.

---

🐕 CAPÍTULO 3 — O CACHORRO QUE NINGUÉM TEM CORAGEM DE DESLIGAR

Tomoe encontra um sistema antigo da Kuzunoha Company.

Ele controla encomendas de um produto que praticamente ninguém compra.

Existem 14 usuários.

São processadas 120 operações por dia.

A empresa pretende abandonar aquele mercado.

Nosso COBOLzeiro imediatamente propõe:

— Vamos modernizar!

Makoto pergunta:

— Por quê?

Silêncio.

Essa talvez seja uma das perguntas mais importantes da arquitetura corporativa.

Por quê?

O sistema pode perfeitamente funcionar.

Talvez seja estável.

Talvez tenha excelente código.

Mas se o negócio que ele suporta está desaparecendo, investir milhões em sua modernização pode ser desperdício.

A estratégia poderia ser:

Sistema legado
     ↓
manutenção corretiva
     ↓
segurança
     ↓
backup
     ↓
documentação
     ↓
mínimo investimento
     ↓
descomissionamento

Observe algo importante.

Cachorro não significa necessariamente software ruim.

Significa baixo valor estratégico futuro dentro daquele contexto.

Um maravilhoso programa COBOL pode ser Cachorro.

Um péssimo programa Java também.

Tecnologia não determina automaticamente o quadrante.

---

🐄 CAPÍTULO 4 — MIO ENCONTRA A VACA QUE PRODUZ DINHEIRO

No porão da Kuzunoha Company existe outro sistema.

É velho.

Muito velho.

Tela verde.

COBOL.

CICS.

Db2.

Mio olha horrorizada:

— Makoto-sama! Isso é antigo!

Shiki examina os números.

O sistema processa milhões de transações.

Está disponível 24 horas.

Praticamente toda a receita da empresa passa por ele.

Makoto responde:

— Então não toque nele sem saber exatamente o que está fazendo.

Encontramos uma Vaca Leiteira.

No contexto empresarial, é aquilo que possui posição consolidada e produz resultados consistentes em um mercado que já não apresenta crescimento explosivo.

Imagine:

              CORE COBOL
                  │
                  ▼
                CICS
                  │
                  ▼
                 Db2
                  │
          milhões de operações
                  │
                  ▼
              $$$$$$$$

Aqui existe uma armadilha.

Administradores podem pensar:

"Já funciona. Então não precisamos gastar dinheiro."

Durante algum tempo funciona.

Depois aparece:

subinvestimento
      ↓
dívida técnica
      ↓
versões antigas
      ↓
menos especialistas
      ↓
documentação deteriorada
      ↓
dependências desconhecidas
      ↓
fragilidade operacional

Até chegar aquela madrugada especial.

03:17.

Sim, padawan.

Você encontrou o easter egg.

O telefone toca.

A Vaca Leiteira parou.

E naquele momento ninguém quer saber se o programa possui 35 anos.

Querem saber:

"QUANDO VOLTA?"

---

🛡️ CAPÍTULO 5 — VACA LEITEIRA PRECISA DE INVESTIMENTO DEFENSIVO

Extrair produtividade não significa abandonar manutenção.

Uma aplicação crítica precisa receber investimento defensivo.

No universo mainframe isso pode significar:

COBOL antigo
      ↓
upgrade do compilador
      ↓
testes de regressão
      ↓
otimização

Também pode envolver:

• atualização de CICS;

• manutenção de Db2;

• RACF;

• automação operacional;

• observabilidade;

• Capacity Planning;

• backup;

• Disaster Recovery;

• documentação;

• testes automatizados;

• atualização de interfaces;

• treinamento.

Talvez nenhuma dessas iniciativas produza um botão novo para o cliente.

Mesmo assim elas protegem milhões.

Essa distinção é fundamental para o iniciante:

manutenção não é ausência de inovação.

Às vezes a decisão tecnologicamente mais inteligente é garantir que aquilo que funciona continue funcionando.

---

⭐ CAPÍTULO 6 — TOMOE ENCONTRA UMA ESTRELA

Agora surge um novo produto da Kuzunoha Company.

As vendas crescem rapidamente.

Clientes adoram.

Novos mercados aparecem.

Concorrentes começam a copiar.

Temos uma Estrela.

Aqui a estratégia muda.

É necessário:

INVESTIR
   ↓
ESCALAR
   ↓
INOVAR
   ↓
MELHORAR
   ↓
CONQUISTAR MERCADO

Agora faz sentido discutir:

• novas funcionalidades;

• automação;

• APIs;

• escalabilidade;

• novos canais;

• integração;

• observabilidade;

• analytics;

• segurança;

• experiência do cliente.

E encontramos uma mudança fundamental na relação entre negócio e TI.

Durante décadas imaginamos:

NEGÓCIO
   ↓
define estratégia
   ↓
TI
   ↓
implementa

Mas isso é incompleto.

Também pode acontecer:

TECNOLOGIA
     ↓
nova possibilidade
     ↓
novo produto
     ↓
novo mercado
     ↓
NOVA ESTRATÉGIA

A tecnologia não apenas executa estratégia.

Ela pode criar possibilidades estratégicas que anteriormente não existiam.

---

❓ CAPÍTULO 7 — SHIKI ENCONTRA UMA CAIXA QUE NINGUÉM SABE PARA QUE SERVE

No laboratório existe um protótipo.

Poucos clientes utilizam.

Ele ainda não gera dinheiro significativo.

Mas existe enorme potencial.

Bem-vindo ao Ponto de Interrogação.

Aqui encontramos tecnologias e produtos cujo futuro permanece incerto.

No mundo atual poderíamos encontrar, dependendo do contexto empresarial:

IA generativa
Agentes de IA
novos canais digitais
novas plataformas
novos produtos de dados
automação inteligente

Makoto não deveria apostar toda a Kuzunoha Company nisso.

Mas ignorar completamente a oportunidade também pode ser perigoso.

Portanto:

HIPÓTESE
   ↓
PROTÓTIPO
   ↓
PoC
   ↓
MVP
   ↓
CLIENTES
   ↓
MÉTRICAS
   ↓
┌─────────────┐
│ FUNCIONOU?  │
└─────────────┘
  │         │
 SIM       NÃO
  │         │
  ▼         ▼
INVESTIR   REVER

Isso é experimentação estratégica.

Não sabemos se existe uma Estrela escondida ali.

Precisamos descobrir gastando uma quantidade controlada de recursos.

---

🧪 CAPÍTULO 8 — O PROGRAMADOR COBOL APRENDE A NÃO CONFUNDIR PoC COM PRODUÇÃO

Essa é uma lição preciosa.

PoC — Proof of Concept responde:

É tecnicamente possível?

MVP — Minimum Viable Product tenta responder algo diferente:

Existe valor suficiente para usuários reais?

E produção pergunta:

Conseguimos operar isso continuamente, com segurança, desempenho, suporte e governança?

São três problemas diferentes.

Algo pode funcionar lindamente num notebook e tornar-se um desastre quando precisa atender 10 milhões de clientes.

Nosso programador COBOL deveria perguntar:

Qual volume?

Quantas transações?

Qual disponibilidade?

Qual SLA?

Qual RTO?

Qual RPO?

Qual segurança?

Quem monitora?

Quem suporta?

Como fazemos rollback?

Makoto sorri.

Nosso padawan está aprendendo.

---

🤝 CAPÍTULO 9 — MAKOTO COLOCA MARKETING E TI NA MESMA MESA

O material original traz uma observação extraordinariamente importante:

A análise estratégica deveria envolver tanto quem conhece a tecnologia quanto quem conhece o mercado.

Parece óbvio atualmente.

Historicamente não foi.

Durante muito tempo existiu algo semelhante a:

MARKETING
   │
   ▼
REQUISITOS
   │
   ▼
INFORMÁTICA
   │
   ▼
SISTEMA

TI recebia pedidos.

Mas planejamento estratégico exige diálogo:

          MERCADO
             │
             ▼
MARKETING ◄──────► TI
     │              │
     └──────┬───────┘
            ▼
         PRODUTO
            │
            ▼
        ESTRATÉGIA

Marketing pode dizer:

"Queremos atender 5 milhões de clientes."

TI precisa perguntar:

"Nossa arquitetura suporta?"

TI pode dizer:

"Agora conseguimos expor determinadas funções através de APIs."

Marketing pode responder:

"Então talvez exista um produto que ainda não imaginávamos."

Isso é colaboração estratégica.

---

💍 CAPÍTULO 10 — O CASAMENTO ENTRE ESTRATÉGIA DA ORGANIZAÇÃO E ESTRATÉGIA DA INFORMAÇÃO

Makoto coloca dois pergaminhos sobre a mesa.

No primeiro:

ESTRATÉGIA EMPRESARIAL

No segundo:

ESTRATÉGIA DA INFORMAÇÃO

Eles precisam conversar.

Suponha que a empresa queira triplicar vendas.

Excelente.

Mas atualmente temos:

1.000 TPS

e a campanha pode produzir:

10.000 TPS

Temos capacidade?

Rede?

CPU?

I/O?

Db2?

CICS?

MQ?

Storage?

Licenciamento?

Observabilidade?

Disaster Recovery?

A estratégia comercial acaba produzindo requisitos técnicos.

E os limites técnicos também podem limitar a estratégia comercial.

Esse casamento é conhecido modernamente através de discussões sobre alinhamento entre negócio e TI.

---

💳 CAPÍTULO 11 — QUANDO TECNOLOGIA MUDA O PRODUTO

Um exemplo histórico citado no material é o cartão magnético nos bancos.

Parece banal hoje.

Não era.

Antes:

CLIENTE
   ↓
AGÊNCIA
   ↓
FUNCIONÁRIO
   ↓
SISTEMA

Depois:

CLIENTE
   ↓
ATM
   ↓
REDE
   ↓
HOST

Hoje:

CLIENTE
   ↓
SMARTPHONE
   ↓
INTERNET
   ↓
API GATEWAY
   ↓
SERVIÇOS
   ↓
CICS / IMS / Db2

Perceba algo maravilhoso.

O canal pode mudar completamente enquanto determinadas funções centrais permanecem.

Isso nos ensina:

Modernização não significa obrigatoriamente substituição.

Podemos modernizar interfaces, integração, automação e observabilidade sem reescrever irresponsavelmente o coração transacional.

---

🧱 CAPÍTULO 12 — TECNOLOGIA COMO BARREIRA DE ENTRADA

Outro conceito poderoso é utilizar TI para dificultar a entrada de concorrentes.

Um exemplo histórico clássico envolve sistemas de reservas aéreas, como o SABRE.

Quando tecnologia conecta:

COMPANHIA
     ↕
SISTEMA
     ↕
AGÊNCIAS
     ↕
CLIENTES

ela deixa de ser simples ferramenta administrativa.

Torna-se parte do ecossistema competitivo.

Hoje vemos algo semelhante em:

• marketplaces;

• meios de pagamento;

• plataformas;

• ecossistemas de APIs;

• cloud;

• redes de parceiros.

Quanto mais integrado estiver determinado ecossistema, maior pode ser o custo de substituição.

A TI criou um moat, um fosso em volta do castelo.

Tomoe aprova essa metáfora.

---

📊 CAPÍTULO 13 — CONHECER O CLIENTE

O antigo exemplo da mala direta parece quase arqueológico.

A empresa selecionava clientes com maior probabilidade de responder.

Hoje faríamos:

CRM
 ↓
Data Lake / Warehouse
 ↓
Analytics
 ↓
Machine Learning
 ↓
Segmentação
 ↓
Campanha
 ↓
Conversão
 ↓
Feedback

Mudamos tremendamente as ferramentas.

Mas a pergunta permanece:

Para quem devemos oferecer determinado produto?

A antiga mala direta tornou-se:

• recomendação personalizada;

• segmentação comportamental;

• campanhas digitais;

• Customer 360;

• marketing automation;

• modelos preditivos.

Informação virou matéria-prima estratégica.

---

💰 CAPÍTULO 14 — QUANDO A INFORMAÇÃO VIRA PRODUTO

Existe outra possibilidade.

Uma empresa executa seu negócio e, como consequência, produz dados.

OPERAÇÃO
   ↓
DADOS
   ↓
ORGANIZAÇÃO
   ↓
INFORMAÇÃO
   ↓
ANÁLISE
   ↓
NOVO PRODUTO

Isso é monetização de dados.

Mas existe uma diferença gigantesca entre o passado e nosso mundo atual.

Hoje precisamos considerar:

• privacidade;

• consentimento;

• finalidade;

• segurança;

• governança;

• legislação como a LGPD.

O fato de uma empresa possuir tecnicamente acesso a um dado não significa automaticamente que possa utilizá-lo de qualquer maneira.

Governança também é estratégia.

---

🏗️ CAPÍTULO 15 — MAKOTO DESCOBRE QUE EXISTEM DUAS VELOCIDADES

Chegamos a uma das partes mais interessantes do planejamento.

A empresa precisa pensar simultaneamente em:

longo prazo e curto prazo.

Imagine a Kuzunoha Company construindo uma cidade.

Precisamos de:

estradas
água
energia
armazéns
segurança

Esses investimentos não podem ser refeitos toda semana.

São infraestrutura.

Mas amanhã aparece uma oportunidade comercial inesperada.

Precisamos reagir rapidamente.

Portanto:

             ORGANIZAÇÃO
                  │
        ┌─────────┴─────────┐
        │                   │
        ▼                   ▼
   FUNDAÇÃO             RESPOSTA
   LONGO PRAZO          CURTO PRAZO
        │                   │
   arquitetura             MVP
   dados                   PoC
   redes                automação
   segurança           experimento
   plataforma           oportunidade

Uma organização saudável precisa das duas.

---

🏛️ CAPÍTULO 16 — ARQUITETURA É DECIDIR O QUE SERÁ DIFÍCIL MUDAR

Essa definição vale ouro.

Arquitetura não é simplesmente desenhar caixinhas bonitas.

É tomar decisões estruturais.

Em mainframe isso aparece de forma extraordinária.

Imagine que em 1987 alguém definiu:

01 CUSTOMER-RECORD.
   05 CUSTOMER-ID PIC X(10).

Trinta anos depois esse identificador pode aparecer em:

COPYBOOK
   ↓
COBOL
   ↓
VSAM
   ↓
CICS
   ↓
Db2
   ↓
MQ
   ↓
API
   ↓
JSON
   ↓
MOBILE

A decisão aparentemente minúscula tornou-se parte da arquitetura empresarial.

É por isso que sistemas antigos carregam história organizacional codificada.

O código não contém apenas algoritmos.

Contém decisões de negócios tomadas por pessoas que talvez já tenham se aposentado.

---

⚡ CAPÍTULO 17 — DESENVOLVIMENTO OPORTUNISTA

O material utiliza uma expressão deliciosa:

desenvolvimento oportunista.

A organização precisa aproveitar oportunidades rapidamente.

Hoje utilizaríamos termos como:

• Agile;

• DevOps;

• MVP;

• prototipação;

• Low Code;

• automação;

• feature flags.

Mas existe um problema.

Rapidez sem arquitetura produz:

SOLUÇÃO RÁPIDA
      ↓
outra solução rápida
      ↓
mais uma
      ↓
integração improvisada
      ↓
dependências
      ↓
dívida técnica
      ↓
🔥

Arquitetura sem velocidade também produz problema:

REUNIÃO
 ↓
COMITÊ
 ↓
ARQUITETURA
 ↓
NOVO COMITÊ
 ↓
DOCUMENTO
 ↓
REVISÃO
 ↓
18 MESES
 ↓
concorrente lançou há um ano

Precisamos equilibrar as duas forças.

---

🖥️ CAPÍTULO 18 — A MATRIZ BCG ENTRA NO DATACENTER

Agora Makoto manda classificar aplicações.

Poderíamos obter:

Aplicação	Classificação	Estratégia
sistema em retirada	🐕 Cachorro	manter e descomissionar
core COBOL/CICS	🐄 Vaca Leiteira	proteger e otimizar
plataforma digital crescente	⭐ Estrela	investir e escalar
agente de IA experimental	❓ Interrogação	testar e medir

Mas cuidado!

Nunca faça:

COBOL = CACHORRO
JAVA = ESTRELA
IA = ESTRELA
MAINFRAME = VELHO
CLOUD = MODERNO

Isso é pensamento superficial.

Uma aplicação COBOL pode estar no centro de uma Estrela.

Imagine:

APP MOBILE
     ↓
REST API
     ↓
z/OS Connect
     ↓
CICS
     ↓
COBOL
     ↓
Db2

Para o cliente parece um serviço moderníssimo.

No coração encontramos COBOL processando a transação.

E está tudo bem.

---

🔄 CAPÍTULO 19 — OS QUADRANTES NÃO SÃO PRISÕES

Produtos mudam.

Normalmente imaginamos:

❓ INTERROGAÇÃO
       ↓
      ⭐
   ESTRELA
       ↓
      🐄
 VACA LEITEIRA
       ↓
      🐕
   CACHORRO

Mas isso não é inevitável.

Uma Interrogação pode fracassar.

Uma Estrela pode desaparecer.

Uma Vaca Leiteira pode ser reinventada.

Essa última possibilidade é particularmente interessante para mainframe.

Imagine:

CORE CONSOLIDADO
      🐄
       │
       + APIs
       + novos canais
       + analytics
       + automação
       + integração
       ↓
NOVOS PRODUTOS
       ↓
       ⭐

Você não precisou destruir o core.

Transformou-o em plataforma.

---

☠️ CAPÍTULO 20 — A QUINTA CRIATURA QUE NÃO EXISTIA NA MATRIZ

Shiki percebe um problema.

Existe um sistema que:

• não vende nada;

• não cresce;

• não aparece para clientes;

• não gera receita diretamente.

Makoto pergunta:

— Então podemos desligá-lo?

Shiki fica pálido.

— Não.

— Por quê?

— Porque tudo depende dele.

Aqui encontramos uma limitação importante da análise simplificada.

Sistemas tecnológicos possuem uma dimensão adicional:

CRITICIDADE OPERACIONAL.

Um serviço pode não produzir receita diretamente e ainda ser absolutamente essencial.

Por isso uma análise moderna deveria considerar:

VALOR ATUAL
     ×
POTENCIAL FUTURO
     ×
CRITICIDADE
     ×
RISCO
     ×
CUSTO
     ×
DÍVIDA TÉCNICA

Agora nossa análise começa a ficar realmente interessante.

---

🧭 CAPÍTULO 21 — PASSO A PASSO PARA ANALISAR UM SISTEMA

Nosso programador COBOL finalmente recebe sua missão.

Pegue uma aplicação real.

Primeiro, descubra o negócio.

Pergunte:

O que esse sistema faz?

Depois:

Quem utiliza?

Depois:

Quanto valor ele produz?

Depois:

O mercado relacionado cresce ou diminui?

Depois:

Qual é sua criticidade?

Depois:

Quanto custa mantê-lo?

Depois:

Qual é sua dívida técnica?

Depois:

Existe substituto?

Depois:

O que acontece se ele ficar quatro horas indisponível?

Agora documente:

SISTEMA: AUTORIZAÇÃO DE CARTÕES

Tecnologia:
COBOL / CICS / Db2

Volume:
8.000 TPS

Criticidade:
ALTÍSSIMA

Crescimento:
MODERADO

Receita relacionada:
ALTÍSSIMA

Dívida técnica:
MÉDIA

Estratégia:
PROTEGER + MODERNIZAR INTERFACES

Percebeu?

Agora estamos fazendo planejamento.

Não estamos simplesmente perguntando:

"Qual linguagem ele usa?"

---

🧙 CAPÍTULO 22 — MAKOTO ENSINA A DIFERENÇA ENTRE TECNOLOGIA E ESTRATÉGIA

Nosso COBOLzeiro finalmente compreende.

COBOL é tecnologia.

CICS é tecnologia.

Db2 é tecnologia.

Java é tecnologia.

Cloud é tecnologia.

IA é tecnologia.

Nenhuma delas constitui estratégia isoladamente.

Estratégia responde perguntas diferentes:

Onde queremos chegar?

Que mercado queremos atender?

Qual vantagem queremos construir?

Onde vale investir?

Onde devemos parar de investir?

Que riscos aceitamos?

Que capacidades precisamos possuir?

Só então perguntamos:

Qual tecnologia ajuda a executar isso?

Esse detalhe separa arquitetura tecnológica de coleção de buzzwords.

---

☕ EPÍLOGO — O PROGRAMADOR COBOL SAI DA LOJA

Anoitece em Tsige.

A Kuzunoha Company fecha suas portas.

Mio procura alguma coisa para comer.

Tomoe provavelmente está tramando alguma aventura.

Shiki guarda os relatórios.

Makoto chama nosso jovem programador antes que ele vá embora.

— O que você aprendeu hoje?

O padawan responde:

— Que eu não deveria perguntar primeiro se um sistema é velho.

Makoto sorri.

— Continue.

— Preciso perguntar qual problema ele resolve, quanto valor produz, qual sua importância, quanto custa, qual seu futuro e o que acontece quando ele para.

— Muito melhor.

Nosso programador olha novamente para aquele velho programa COBOL.

Ontem enxergava:

IF WS-SALDO >= WS-VALOR
    PERFORM 3000-AUTORIZAR
ELSE
    PERFORM 4000-NEGAR
END-IF.

Hoje enxerga:

ESTRATÉGIA
    ↓
MERCADO
    ↓
PRODUTO
    ↓
PROCESSO
    ↓
INFORMAÇÃO
    ↓
SISTEMA
    ↓
ARQUITETURA
    ↓
CICS
    ↓
COBOL
    ↓
Db2

Mas então percebe algo ainda mais importante.

A seta também pode subir:

COBOL
   ↓
CICS
   ↓
API
   ↓
NOVA CAPACIDADE
   ↓
NOVO PRODUTO
   ↓
NOVO MERCADO
   ↓
NOVA ESTRATÉGIA

E finalmente compreende a verdadeira lição daquela dungeon.

Durante décadas repetimos:

"A informática deve estar alinhada à estratégia do negócio."

Correto.

Mas incompleto.

Porque quando informação, software e conectividade passam a constituir parte do próprio produto, a tecnologia deixa de ocupar apenas a oficina nos fundos da empresa.

Ela entra na sala onde o mapa do reino está aberto sobre a mesa.

E talvez a maior lição da Kuzunoha Company seja justamente essa:

Não modernize porque algo é antigo. Não substitua porque algo não está na moda. Não preserve simplesmente porque ainda funciona. Descubra primeiro qual papel aquilo desempenha no reino.

O velho programa COBOL pode ser um Cachorro aguardando aposentadoria.

Pode ser uma Vaca Leiteira produzindo milhões.

Pode estar escondido no coração de uma Estrela.

Ou pode ser a infraestrutura invisível sem a qual todas as outras criaturas simplesmente morrem.

Quando você aprende a enxergar essa diferença, deixa de ser apenas alguém que escreve IF, MOVE e PERFORM.

Começa a entender por que aquele código existe.

E esse é um dos primeiros passos para deixar de ser somente programador e começar a pensar como analista, arquiteto e estrategista.

No fundo do relatório de Shiki, entretanto, havia uma pequena observação:

************************************************************
*  TODO: DESCOBRIR QUEM CRIOU ESTA ROTINA EM 1987         *
*  NINGUÉM SABE COMO FUNCIONA.                             *
*  NÃO APAGAR.                                             *
*                                                          *
*  ÚLTIMO INCIDENTE: 03:17                                 *
************************************************************

Tomoe olhou para Makoto.

Makoto olhou para o programador COBOL.

O programador olhou para o código.

Mio perguntou:

— Posso comer o servidor?

E assim começou a próxima War Room da Kuzunoha Company.

Continua...