Cuando una aplicación web funciona no significa que esté al día

Desarrollar y poner en producción una aplicación web no debería entenderse como el final de un proyecto tecnológico, sino como el inicio de una etapa de explotación que puede prolongarse durante muchos años. Durante ese periodo evolucionarán los lenguajes, frameworks, librerías, navegadores, sistemas operativos, infraestructuras y servicios externos con los que interactúa la aplicación.

Cuando esa evolución no se gestiona de forma periódica, puede producirse una situación engañosa: la aplicación continúa funcionando y, sin embargo, su deuda tecnológica aumenta silenciosamente. El problema suele hacerse visible cuando surge la necesidad de modificarla, integrarla con nuevos sistemas o adaptar su infraestructura y una actuación inicialmente sencilla obliga a abordar años de evolución tecnológica acumulada.

El funcionamiento diario no refleja necesariamente el estado tecnológico

Uno de los errores más habituales en la gestión de aplicaciones web consiste en utilizar su funcionamiento como principal indicador de su estado tecnológico. Mientras los usuarios puedan acceder, los procesos continúen ejecutándose y no existan incidencias evidentes, resulta comprensible considerar que no hay ninguna razón para intervenir.

Sin embargo, una aplicación no funciona de manera aislada. Forma parte de un ecosistema compuesto por múltiples elementos que evolucionan de forma independiente: lenguajes de programación, frameworks, librerías, bases de datos, sistemas operativos, servidores, navegadores, APIs, servicios de terceros y herramientas de desarrollo, entre otros.

Durante los primeros años, esa evolución externa puede no producir ningún efecto visible. La aplicación continúa haciendo exactamente aquello para lo que fue diseñada y, desde la perspectiva del usuario, nada parece haber cambiado. Desde el punto de vista tecnológico, en cambio, la situación puede ser muy distinta.

Algunos componentes habrán evolucionado hacia nuevas versiones, determinadas dependencias habrán modificado sus requisitos de compatibilidad y otras habrán llegado al final de su ciclo de mantenimiento. También pueden haber cambiado las prácticas recomendadas de desarrollo, despliegue y operación.

Nada de esto implica que la tecnología utilizada originalmente fuese una mala elección. La obsolescencia no es necesariamente consecuencia de una mala decisión tecnológica; es una consecuencia natural del paso del tiempo en un sector que evoluciona continuamente.

La diferencia reside en cómo se gestiona esa evolución.

Cinco años de estabilidad pueden convertirse en cinco años de evolución pendiente

En Aduxia nos encontramos en ocasiones con aplicaciones o webs que han permanecido durante varios años sin apenas modificaciones porque, sencillamente, no las necesitaban. Desde la perspectiva del negocio, esto puede interpretarse incluso como una señal positiva: la solución ha cumplido correctamente su cometido durante todo ese tiempo.

La dificultad aparece cuando, después de cuatro, cinco o más años, surge la necesidad de introducir una modificación aparentemente menor.

En ese momento ya no estamos trabajando únicamente sobre la aplicación que se desarrolló originalmente. Estamos trabajando sobre una aplicación que ha permanecido prácticamente estable mientras el ecosistema tecnológico del que depende ha continuado avanzando.

Antes de realizar el cambio solicitado puede ser necesario revisar dependencias, compatibilidades, entornos de ejecución, herramientas de construcción y despliegue, integraciones externas o componentes que ya no siguen el mismo ciclo de soporte que cuando se desarrolló el proyecto.

La complejidad de la intervención deja entonces de estar determinada exclusivamente por la funcionalidad solicitada. Parte del esfuerzo debe destinarse a recuperar la distancia tecnológica acumulada durante los años anteriores.

Este fenómeno puede producirse con independencia del lenguaje, framework o plataforma elegidos. Cualquier tecnología profesional tiene un ciclo de evolución y cualquier aplicación con una vida suficientemente larga necesita gestionar ese ciclo.

La deuda tecnológica permanece invisible hasta que necesitamos volver a intervenir

La deuda tecnológica presenta una característica especialmente relevante desde el punto de vista empresarial: durante mucho tiempo puede no generar ningún síntoma perceptible.

Una aplicación puede seguir funcionando mientras aumenta progresivamente la distancia entre sus componentes y las versiones actualmente mantenidas. Esta circunstancia permite aplazar decisiones porque no existe una incidencia concreta que obligue a actuar.

El problema aparece cuando cambia alguna de las condiciones que habían permitido mantener esa estabilidad.

Puede surgir una nueva necesidad de negocio, ser necesario incorporar una integración con otro sistema, cambiar el proveedor de infraestructura, adaptar un proceso, modificar una funcionalidad o evolucionar alguno de los servicios externos utilizados por la aplicación.

Es entonces cuando una organización puede descubrir que antes de abordar la necesidad que ha motivado la intervención debe resolver una serie de condicionantes tecnológicos que hasta ese momento permanecían ocultos.

Desde la perspectiva de gestión, esta es probablemente una de las principales razones para establecer revisiones periódicas: permiten detectar la evolución pendiente cuando todavía puede planificarse, en lugar de descubrirla cuando existe una necesidad de negocio que condiciona los plazos.

Actualizar no consiste en perseguir permanentemente la última versión

Mantener una aplicación tampoco significa incorporar cada nueva versión de una tecnología en cuanto aparece. Una estrategia de actualización indiscriminada puede introducir costes y riesgos innecesarios y, en determinadas circunstancias, ser tan poco recomendable como no actualizar nunca.

El objetivo debe ser diferente: conocer el estado tecnológico de la aplicación y tomar decisiones informadas sobre su evolución.

Esto implica revisar periódicamente los principales componentes, conocer sus ciclos de soporte, identificar dependencias que puedan convertirse en un condicionante futuro, comprobar la compatibilidad con la infraestructura y valorar qué actualizaciones son convenientes en función de la criticidad y características de cada solución.

En algunos casos será recomendable actualizar. En otros tendrá sentido esperar. También habrá componentes que puedan mantenerse durante años sin necesidad de intervención.

La diferencia fundamental es que la decisión sea consciente.

No actualizar durante un periodo determinado porque se ha evaluado el sistema y no existe una razón técnica o empresarial para hacerlo es una decisión perfectamente válida. Mantener una aplicación durante años sin conocer el estado de sus componentes es una situación completamente distinta.

La evolución progresiva reduce la distancia tecnológica

Una aplicación mantenida periódicamente permite distribuir su evolución a lo largo del tiempo. En lugar de enfrentarse a varios años de cambios tecnológicos acumulados, las intervenciones pueden realizarse de forma progresiva y controlada.

Esta diferencia es especialmente importante porque los componentes de una aplicación no evolucionan de forma independiente. Una actualización puede requerir otra versión del entorno de ejecución; esta, a su vez, puede afectar a determinadas librerías, y una nueva versión de estas puede exigir modificaciones en partes concretas del código.

Cuanto mayor sea el intervalo entre revisiones, mayor puede ser el número de dependencias que hayan evolucionado y más difícil resultará determinar inicialmente el alcance real de una actualización.

En proyectos que han permanecido muchos años sin mantenimiento, puede llegar incluso un momento en el que sea necesario evaluar si resulta más razonable actualizar determinados componentes, sustituir partes de la solución o plantear una modernización más profunda.

Ninguna de estas alternativas constituye por sí misma un problema. El problema aparece cuando la organización descubre esta situación precisamente en el momento en que necesita realizar urgentemente otro cambio.

Las webs corporativas también son activos tecnológicos

Esta reflexión no afecta únicamente a grandes aplicaciones de negocio, plataformas digitales o productos comercializados a terceros. También es aplicable a las webs corporativas.

Una web aparentemente sencilla puede incorporar un gestor de contenidos, frameworks de desarrollo, librerías, plugins, bases de datos, servicios de analítica, formularios, APIs, sistemas de envío de correo, integraciones comerciales o herramientas proporcionadas por terceros.

Desde la perspectiva del usuario, el resultado son páginas, contenidos y funcionalidades. Desde la perspectiva tecnológica, existe una aplicación formada por componentes que tienen sus propios ciclos de vida.

Esta distinción es importante porque las organizaciones suelen aplicar criterios diferentes a ambos tipos de activos. Mientras que una aplicación directamente relacionada con la actividad del negocio suele disponer de responsables y procesos de mantenimiento claramente identificados, una web corporativa puede permanecer durante años fuera de cualquier planificación tecnológica siempre que continúe siendo accesible.

Sin embargo, que una web tenga una finalidad principalmente informativa no elimina la necesidad de conocer el estado de la tecnología que la soporta.

El mantenimiento debe ser proporcional al valor y la criticidad de cada aplicación

No todas las aplicaciones requieren la misma frecuencia de revisión ni el mismo nivel de intervención. Establecer un mantenimiento adecuado exige tener en cuenta factores como la criticidad para el negocio, el volumen de usuarios, el número de integraciones, la complejidad tecnológica, la exposición pública, la velocidad de evolución de sus dependencias y el impacto que tendría una interrupción del servicio.

Una web corporativa relativamente sencilla puede necesitar únicamente revisiones periódicas y actuaciones puntuales. Una aplicación utilizada diariamente para procesos esenciales del negocio requerirá probablemente un seguimiento mucho más continuo. Un producto digital comercializado a clientes puede necesitar incorporar su evolución tecnológica al propio roadmap del producto.

Por tanto, no existe una periodicidad universal ni un conjunto de actualizaciones que pueda aplicarse de forma automática a cualquier proyecto.

Lo que sí debería existir es una estrategia de ciclo de vida.

Esta estrategia permite conocer qué tenemos actualmente, qué componentes requieren seguimiento, qué evolución podemos anticipar y qué actuaciones conviene planificar antes de que se conviertan en condicionantes para el negocio.

Mantener una aplicación es también mantener la capacidad de cambiarla

Con frecuencia se entiende el mantenimiento como una actividad destinada a garantizar que una aplicación siga funcionando. Es una definición correcta, pero incompleta.

Existe otra dimensión igualmente importante: mantener la capacidad de evolucionar la aplicación cuando el negocio lo necesite.

Una solución tecnológica aporta valor no solo porque resuelva correctamente las necesidades actuales, sino también porque pueda adaptarse razonablemente a las futuras.

Cuando una aplicación permanece durante muchos años al margen de cualquier estrategia de evolución, la organización puede conservar su funcionalidad actual y, al mismo tiempo, ir perdiendo progresivamente agilidad para modificarla.

Ese coste no aparece en ningún informe mientras no sea necesario realizar cambios. Sin embargo, cuando surge una nueva necesidad, puede manifestarse en forma de mayores plazos, más incertidumbre sobre el alcance de los trabajos, necesidad de actuaciones previas o inversiones que no estaban contempladas inicialmente.

Por eso el mantenimiento tecnológico no debería entenderse exclusivamente como un coste asociado al software existente. También es una forma de preservar opciones para el futuro.

Una pregunta que merece la pena hacerse periódicamente

No es necesario actualizar una aplicación simplemente porque haya transcurrido un determinado número de meses o porque exista una nueva versión de alguno de sus componentes.

Pero sí resulta razonable conocer periódicamente su situación.

¿Qué tecnologías y componentes forman actualmente nuestra aplicación? ¿Continúan dentro de ciclos de mantenimiento adecuados? ¿Existen dependencias que deberíamos vigilar? ¿Podríamos modificarla hoy con normalidad si surgiera una nueva necesidad? ¿Sabemos qué actuaciones tendremos que abordar durante los próximos años?

Si una organización puede responder a estas preguntas, está gestionando el ciclo de vida de su aplicación.

Si nunca se las ha planteado porque la aplicación lleva años funcionando correctamente, quizá el primer mantenimiento que necesita no sea una actualización.

Quizá sea simplemente una revisión que permita saber dónde está hoy y cuánto esfuerzo supondrá llevarla mañana hasta donde el negocio necesite.