Imagine que mañana, a las 8:00 a. m., un sistema crítico del Estado deja de funcionar. No un sistema “secundario”, sino el sistema: el que soporta trámites, pagos, procesos sensibles, atención a millones de personas. No hay margen de error. No hay ventana de mantenimiento suficiente. No hay botón de pause.
Para muchos CIOs y líderes de TI del sector público, esa presión no es hipotética. Es cotidiana.
Sistemas legacy —algunos con más de 20 o 30 años— siguen sosteniendo la operación del Estado. Funcionan, sí. Pero cada línea de código heredado, cada integración improvisada y cada dependencia rígida va acumulando una deuda silenciosa.
Una deuda que no aparece en el balance financiero, pero que se cobra con intereses altos: lentitud, riesgo operativo y experiencia ciudadana deteriorada.
Modernizar parece urgente. Pero apagar el sistema no es una opción.
El error que sigue costando millones
Durante años, la modernización tecnológica en el sector público se planteó como un acto heroico: “Reemplacemos todo. Empecemos de cero.” El famoso Big Bang.
La promesa era seductora: arquitectura limpia, tecnología moderna, menos parches. La realidad fue distinta. Proyectos que se extendieron por años, presupuestos desbordados, resistencia interna y, en muchos casos, sistemas nuevos que nunca lograron reemplazar completamente al anterior.
Hoy sabemos que el problema no era la intención, sino el enfoque. Reescribir todo de una vez no solo es riesgoso: es innecesario.
Cuando modernizar deja de ser destruir
En los últimos años, algo empezó a cambiar. No por moda, sino por supervivencia operativa.
Las organizaciones que lograron avanzar entendieron una verdad clave: no se trata de matar el sistema legacy, sino de dejar de depender de él.
Aquí entra la Arquitectura Evolutiva y, en particular, una estrategia tan simple como poderosa: el Strangler Fig Pattern (Patrón de la Higuera Estranguladora).
La metáfora es clara. Una higuera crece alrededor de un árbol viejo. No lo derriba de inmediato. Lo rodea, lo reemplaza poco a poco, hasta que el árbol original deja de ser necesario.
Aplicado a tecnología, el enfoque es similar: nuevas funcionalidades modernas se construyen alrededor del sistema monolítico existente. Estas nuevas capas interceptan gradualmente las llamadas, asumen responsabilidades específicas y reducen, paso a paso, la dependencia del núcleo antiguo.
El sistema sigue operando. El ciudadano no percibe interrupciones. La modernización avanza.
Claves estratégicas para el líder de TI público
Pero aquí aparece un punto crítico que muchas veces se subestima.
Más allá del patrón técnico, son las decisiones estructurales las que realmente marcan la diferencia entre un intento de modernización y una transformación sostenible.
– Desacoplamiento: Reducir la dependencia directa de bases de datos monolíticas es el primer paso para ganar flexibilidad, escalabilidad y seguridad. Cuando los sistemas dejan de estar atados a un único núcleo rígido, el cambio deja de ser traumático y se vuelve posible.
– Contenerización: Mover lo que ya funciona a entornos modernos permite reducir costos de infraestructura de forma inmediata, sin esperar años a un reemplazo total. No todo debe reescribirse para empezar a generar eficiencias reales.
– Cultura y gobernanza: La modernización no es solo código. Implica pasar de una lógica de “mantener lo que hay” a una de entrega continua de valor, con equipos empoderados, reglas claras y decisiones basadas en impacto ciudadano, no solo en urgencias operativas.
Sin este cambio cultural, incluso la mejor arquitectura termina estancada.
El verdadero cambio no es técnico
Hasta aquí, todo suena razonable. Pero hay una verdad incómoda que los líderes de TI conocen bien: Los proyectos no fallan por la tecnología… fallan porque la organización no estaba preparada para evolucionar con ella.
Modernizar sistemas críticos exige gobernanza, visión de largo plazo y la capacidad de avanzar sin poner en riesgo la operación diaria. Exige aceptar que el cambio no ocurre en un gran evento, sino en decisiones constantes, bien alineadas y sostenidas en el tiempo.
La deuda técnica también se paga hacia afuera
En el Estado, la deuda técnica no es un problema interno. Se manifiesta en filas, reprocesos, tiempos de espera y frustración ciudadana. Cada sistema que no evoluciona termina condicionando políticas, limitando servicios y ralentizando decisiones. Por eso, hablar de modernización no es solo hablar de TI. Es hablar de confianza institucional.
La buena noticia es que no necesitamos detener el tren para mejorarlo. Necesitamos ingeniería inteligente, visión estratégica y una hoja de ruta que permita modernizar en movimiento. Eso es lo que diferencia a las organizaciones que sobreviven de las que realmente avanzan.
Una reflexión final para líderes de TI
La pregunta ya no es si hay que modernizar. Tampoco es qué tecnología usar.
La pregunta clave es: ¿cómo reducir la deuda técnica sin poner en riesgo el servicio al ciudadano?
Ahí es donde la estrategia importa más que la herramienta.
Si su entidad está evaluando cómo abordar la deuda técnica sin interrumpir operaciones críticas, en Softmanagement acompañamos procesos de modernización progresiva diseñados para entornos donde “apagar el sistema” no es una opción.
Conversemos desde la estrategia: jbeltran@softmanagement.com.co