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 centenas 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 142 sistemas externos 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

Decisões que eu defendo

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, e foi o que permitiu declarar com precisão a diferença entre as 319 aplicações da minha área, as 128 sob responsabilidade técnica direta e os 108 repositórios com código meu.

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.

Ver também

Documentação e mapeamento de sistemas · Projetar antes de implementar · Engenharia com IA