Cuatro sistemas que nunca se hablaron,
conectados en un solo portal.
Un patrón frecuente en gobiernos locales: cuatro o más sistemas catastrales heredados que registran la misma realidad territorial, sin punto único de consulta. Así abordaríamos el problema — sin reemplazar lo que funciona.
El catastro existe cuatro veces. Ninguna es la verdad.
En muchas alcaldías, cuatro secretarías registran la misma realidad territorial: catastro tiene una base, hacienda otra, planeación una tercera, obras públicas una cuarta. Cada una construida en una era distinta, con tecnologías incompatibles, sin sincronización.
El costo se traslada al ciudadano: cuando solicita información sobre un predio, un funcionario tiene que consultar manualmente cada fuente, reconciliar diferencias y emitir un informe. Lo que debería ser una consulta toma semanas.
Reemplazar los sistemas suele ser inviable: cada uno tiene usuarios, procesos y dependencias institucionales propias. La solución tiene que convivir con lo existente, no destruirlo.
Una capa de integración, no un reemplazo.
El patrón que aplicaríamos: diseñar una capa intermedia que se conecte a los sistemas existentes, reconcilie sus datos con reglas de prioridad documentadas y exponga una única API. Los sistemas heredados siguen operando como siempre.
Las cuatro fases típicas que proponemos:
1. Discovery. Mapeo de las fuentes, entrevistas con usuarios
de cada secretaría, audit técnico, identificación de campos canónicos y reglas
de conflicto.
2. Capa de integración. Conectores por sistema, modelo de datos
canónico en PostGIS, reglas de reconciliación documentadas y auditables.
3. Portal ciudadano. Frontend ligero, mapa con barrios oficiales,
búsqueda por cédula, NIT o referencia catastral.
4. API abierta. Documentación OpenAPI, rate limits, autenticación
opcional. Datos abiertos para investigadores y desarrolladores.
Tiempos típicos por fase dependen del estado de las fuentes y el alcance acordado.
Un solo portal. Cuatro sistemas intactos detrás.
Al cierre, el municipio tiene: un portal ciudadano que responde en segundos, una API documentada que sirve a investigadores y desarrolladores, un modelo de datos canónico defensible, y los sistemas legacy operando como siempre — sin migración, sin reemplazo.
Las reglas de reconciliación quedan documentadas y auditables: cuando dos sistemas reportan datos distintos para el mismo predio, se sabe por qué se eligió uno sobre el otro.
Y el equipo del municipio puede mantener todo sin nosotros — el código y el modelo son legibles y heredables.
Tecnologías maduras, código mantenible.
Stack consolidado: nada experimental, todo documentado y con ecosistema fuerte. El equipo del municipio puede mantenerlo sin nosotros.
¿Sistemas heredados que no conversan?
Escríbenos.
Cuéntanos el contexto y los sistemas involucrados — respondemos con preguntas, no con propuesta cerrada.