O mapa do parque

Levantamento do parque corporativo inteiro: o que cada aplicação faz, com quem ela fala e quem depende dela.

O problema

Responder tecnicamente por um parque grande de aplicações sem que exista um lugar que diga o que cada uma faz. O conhecimento existia, distribuído na cabeça das pessoas, e saía pela porta a cada mudança de time.

Decisão de arquitetura depende de saber o custo de mudar. “Posso alterar este contrato?” e “o que quebra se eu desligar isto?” não têm resposta sem saber quem consome, e sem isso ou se decide no palpite, ou não se decide.

A documentação escrita à mão não resolvia: envelhece na primeira semana, ninguém confia, e quando ninguém confia ninguém atualiza.

O que eu construí

• Varredura automatizada do parque, extraindo de cada repositório o que a aplicação faz, em que stack, com que banco, que integrações declara e quem a consome
• Organização por time e por área de negócio, com a costura entre as áreas explícita, que é onde mora o risco
• Ficha por aplicação com a regra de negócio lida do código, não do que alguém lembra
• Catálogo dos sistemas externos com que o parque conversa, e de quem fala com cada um
• Grafo navegável, com filtro para os nós que ligam tudo em tudo: autenticação e log conectam a todos e destroem a leitura

O que sustenta o mapa

Gerado a partir da fonte. O que é extraído do código pode ser reextraído; o que é escrito à mão apodrece. Documentação regenerável é a única que sobrevive a um parque desse tamanho.

Registrar a data de apuração e admitir o que está velho. Cada ficha diz quando foi apurada. Um mapa que finge estar sempre atualizado é pior que um mapa que diz “isto aqui é de março”.

Documentar a integração que só aparece no código. O valor não está no que o arquivo de configuração revela. Está no gatilho reativo, no bypass ativo em produção, no acoplamento que ninguém lembrava. São essas descobertas que mudam decisão.

De levantamento a base viva

O mapa começou como uma varredura: rodar, gerar, ter o retrato. O problema óbvio é que retrato envelhece, e um mapa em que ninguém confia ninguém consulta.

Hoje a varredura e a atualização acontecem sozinhas, e o mapa deixou de ser um documento para virar uma base de conhecimento consultável, inclusive pelos agentes com que eu trabalho, como descrito em Engenharia com IA. Quando eu preciso saber quem consome um contrato antes de mudá-lo, a resposta vem da base, não de uma varredura que eu lembro de disparar.

Foi essa mudança que transformou o mapa de entregável em infraestrutura. Enquanto atualizar dependia de alguém decidir atualizar, ele estava sempre um pouco errado, e “um pouco errado” é suficiente para as pessoas voltarem a perguntar umas às outras.

Resultado

O mapa é a base de como eu respondo pelo portfólio de sistemas, e foi o que permitiu separar com precisão três coisas que antes se confundiam numa só: o que está na minha área de atuação, o que está sob a minha responsabilidade técnica direta, e o que tem código escrito por mim.

O limite

O mapa enxerga integração declarada em código e configuração. Não enxerga acoplamento por banco compartilhado que não aparece em lugar nenhum, nem combinado informal entre times, e essa é uma lacuna estrutural, não um atraso de apuração: nenhuma varredura resolve.