En muchas entidades públicas existen sistemas construidos hace diez, quince o veinte años que todavía permiten consultar información, registrar actuaciones y completar las funciones para las que fueron creados, por eso puede parecer innecesario modernizarlos mientras continúen encendiendo y no presenten una falla grave, aunque el verdadero problema de la obsolescencia no comienza cuando el software deja de funcionar, sino cuando la entidad necesita cambiar y descubre que cada nueva norma, integración, servicio o aumento de usuarios exige meses de trabajo, soluciones provisionales y riesgos que nadie quiere asumir.
Pensemos en una plataforma creada cuando la entidad recibía documentos por pocos canales y atendía una carga mucho menor, con el tiempo aparecen nuevas dependencias, trámites digitales, firmas electrónicas, servicios en línea, intercambio de información con otras instituciones y ciudadanos que esperan consultar el estado de sus solicitudes sin desplazarse, mientras el sistema original continúa operando gracias a ajustes pequeños, hojas de cálculo, correos paralelos y el conocimiento de dos o tres personas que saben dónde tocar sin romperlo, de modo que la tecnología parece seguir funcionando, aunque la operación real ya ocurre alrededor de ella.
Aquí aparece una diferencia importante entre un sistema antiguo y un sistema obsoleto, porque un software con años puede continuar siendo seguro, mantenible y capaz de integrarse, mientras uno más reciente puede volverse una carga si depende de tecnologías difíciles de encontrar, no permite extraer información, concentra demasiadas funciones en una sola pieza o exige especialistas que la entidad ya no puede contratar, ya que elegir tecnología también significa elegir una comunidad, una oferta futura de talento y la posibilidad de que otras personas puedan mantenerla cuando quienes la construyeron ya no estén.
Modernizar tampoco significa reemplazar de una vez todo aquello que funciona, porque una migración completa puede detener servicios esenciales, perder conocimiento acumulado y convertir una mejora necesaria en un proyecto imposible de terminar, por eso suele ser más razonable identificar primero las partes que producen mayor dependencia, separar los datos de las aplicaciones, crear integraciones controladas, renovar componentes por etapas y construir una arquitectura donde cada nueva capacidad pueda incorporarse sin intervenir todo el sistema, entendiendo que incluso una plataforma exitosa necesita reconstruir infraestructura, monitoreo, procesos y núcleo tecnológico cuando el crecimiento supera aquello para lo que fue diseñada.
La obsolescencia casi nunca llega como un apagón repentino, normalmente se presenta como pequeños retrasos, tareas manuales, cambios que siempre se aplazan, dificultades para integrar una nueva herramienta y decisiones que dependen de la única persona que todavía entiende el sistema, por eso esperar hasta que la plataforma falle no es ahorrar recursos, sino acumular una deuda que la siguiente administración tendrá que pagar con menos tiempo y mayor riesgo, de manera que la pregunta no debería ser únicamente si el sistema todavía funciona, sino si puede acompañar con seguridad a la entidad que necesitaremos dentro de los próximos años.
Pregunta para conversar: ¿Tu sistema sigue siendo útil porque funciona o porque todavía puede cambiar sin poner en riesgo la operación?
