El dilema del cepo, ¿Cómo abordar la problemática del software Legacy huérfano? 

Como jefe de proyecto, gerente IT, CTO, etc… Es posible que a lo largo de tu vida profesional te hayas encontrado con el problema de tener que administrar y mantener una aplicación antigua de arquitectura monolítica que en muchos casos es clave para la continuidad del negocio. 

Vamos a dibujar un escenario en el que carecemos de los elementos más básicos: buena documentación, y por supuesto un soporte o en su defecto código fuente; ya no solo para aplicar el correctivo correspondiente, sino el evolutivo que puede surgir simplemente de la evolución de la legislación vigente o el propio negocio. 

Esto que parece una situación extrema se da de forma mucho más común de lo que podemos creer; PYMES de diferentes tamaños o grandes empresas incluso dependen de softwares muchas veces de gestión o incluso relacionados con la productividad que fueron desarrollados hace más de una década y que el soporte ha expirado, la empresa que lo mantenía ya no existía (incluso por jubilación en el caso de autónomos) y por supuesto la documentación es escasa o incluso nula. 

Cuando estos sistemas son de la primera década del 2000 o más antiguos incluso, muchas veces tienen además la problemática agregada de que las bases de datos que las soportan son enrevesados formatos propietarios inaccesibles fuera del propio sistema (una mala práctica realizada para proteger la propiedad intelectual que como se puede entender tiene serios riesgos para afectar a la continuidad del negocio). 

Para abordar un ejemplo de este tipo de situaciones, imaginemos un software monolítico de gestión (tipo ERP con integraciones en procesos claves para la compañía) de principios de la década del 2000, que fue desarrollado para la empresa X por un desarrollador autónomo a medida, durante diez años o más… (Este ejemplo como digo es mucho más común de lo que podemos pensar); hablamos de una arquitectura cliente/servidor, que no solo guarda datos clave para la compañía, sino que toda su lógica y función es imprescindible para realizar los procesos de la empresa. 

El sujeto o la empresa que lo desarrolló ya no están; el sistema lo mantiene un empleado que conoce más que el resto y sabe cuando y donde tiene que liberar espacio en disco o cuando tiene que resetear un determinado servicio windows en el PC que soporta el sistema, que está en un armario sin refrigerar en el despacho del director… ¿Os suena? 

Por supuesto, hay una jefa de contabilidad que hace copias de seguridad periódicas de forma metódica desde hace 20 años, copias que por otro lado, no sabe como restaurar (porque la última vez que algo terrible ocurrió sí había a alguien a quien llamar)… y esas copias solo se pueden leer por la BBDD propietaria de la que se sirve el sistema… ¿No os recuerda a la orquesta del Titanic? 

En las grandes empresas, pueden ocurrir cosas similares; el software clave para la continuidad del negocio fue desarrollado por el antiguo director IT, que se jubiló hace cinco años, subcontratando recursos en modalidad bodyshopping y que durante varios años fueron trabajando en el sistema hasta hacer algo Ad Hoc para la empresa; hasta ahora ha funcionado de maravilla. En este caso sí hay documentación e incluso código fuente, pero… El lenguaje de programación está en desuso y hay pocos profesionales que lo puedan mantener y una recompilación entera del sistema y colocar una nueva versión del mismo tirando de la BBDD original podría tener consecuencias impredecibles…  

Son solo algunos ejemplos…, pero podríamos buscar muchos más con ejemplos mucho más complejos y escenarios de todo tipo en múltiples sectores. Por desgracia las tecnologías modernas no se libran de estos problemas y llegará un momento que alguien deberá pasar por este calvario incluso con el software que ahora consideramos más TOP y que ha sido desarrollado con las mejores prácticas. 

Por comentar una única variante más de este problema; podemos imaginar una empresa propietaria de un gran software que vende a otros y que ha ido creciendo capa a capa durante décadas y llega un momento, con la rotación de personal normal, que los ingenieros originales no están y por supuesto no hay nadie que conozca el software al 100% en E2E y eso trae aparejados muchos problemas añadidos que no merece la pena enumerar por no eternizar el artículo. 

¿Existe una solución mágica a estos problemas? 

Desgraciadamente No. Quizás en veinte años una IA muy potente pueda usar técnicas de ingeniería inversa y aplicando una gran capacidad de lógica funcional pueda atacar estos problemas de una forma rápida y confiable, pero lo que es cierto es que a día de hoy, esto es pura especulación y ciencia ficción. 

Un Cepo, una trampa

La primera idea que nos puede venir a la cabeza sería la tentación de tratar de manipular el software, sondeando archivos, editando, probando. Esto casi siempre es una mala idea, al menos en un inicio. 

Por ser un poco metódicos deberemos recoger información mediante una auditoría y un estudio profundo del sistema; la sucesión lógica sería: 

• Revisión de contratos, y compromisos legales del sistema. 
• Inventario de documentación. 
• Entrevista a usuarios encargados de mantener y usar el sistema. 
• Inventario de código fuente y/o otros procedimientos de aplicación de parches correctivos y evolutivos. 
• Análisis de impactos y riesgos para la continuidad del negocio. 
• Planteamiento de medidas mitigadoras del riesgo. 
• Roadmap de trabajo. 

Mitigando el riesgo

Sí como resultado de nuestras pesquisas determinamos que es posible delegar el soporte en un proveedor cualificado y seguro que nos garantice la estabilidad del sistema y su posterior migración, ¡perfecto!. Ese es el Camino (Como diría el Mandaloriano); la decisión más conservadora casi siempre es la mejor. 

Sin embargo, es muy posible que esta solución o sea muy cara o simplemente no se pueda dar, porque no exista la alternativa, entonces, ¿Qué hacer? 

En primer lugar

Dentro de nuestro estudio y plan de mitigación de riesgos, deberemos reducir todas las situaciones de riesgo que puedan conllevar su colapso del sistema o de producirse, como restaurarlo rápidamente. 

En el ejemplo que hemos puesto anteriormente sería sencillo: Sacar al PC del despacho y ponerlo en una habitación con mejores medidas ambientales y de seguridad, así como hacer copias regulares del disco (no solo las que te provee el propio sistema); revisar si es posible replicar el sistema en una máquina más segura o incluso en un proveedor de housing confiable, garantizando las comunicaciones y el acceso cuando sea necesario. 

Todo ello, contribuirá a mantener la situación actual, pero no nos posibilitará crecer o adaptarnos a normativa o nuevas situaciones de negocio que se den… Sin embargo, esa noche, dormiremos a pierna suelta. 

Inmediatamente después

Siempre hay un empleado que lleva muchos años en la compañía y que tiene una Macro, o un destornillador (metafóricamente) para garantizar que determinado proceso de liquidación, etc… se termine de ejecutar correctamente, o con un agregado que hizo otro empleado (que casualmente ya no está en la empresa) que con eso se pudieron adaptar a no se que situación en no sé qué contexto… ¡Ese es el Camino! (Volvería a decir el Mandaloriano) 

Entonces, ¿Qué debemos hacer? 

Tomemos ese procedimiento de trabajo, documentemoslo y empecemos a preparar un plan para automatizarlo, pero cuidado, el siguiente CEPO podría ser que empezaramos a generar “setas” por toda la red de la empresa para reproducir y garantizar procesos humanos existentes, eso sería un grave error que podría conducir a una situación inmantenible aún peor. ¡No!, debemos empezar a diseñar un sistema de recubrimiento con suficientes garantías de continuidad. 

Como capas de cebolla

El nuevo sistema deberá tener un corazón propio y una lógica (idealmente basada en arquitectura de microservicios), que nos permita extenderlo completando o supliendo funciones del sistema Legacy de forma paulatina; de esta forma iremos poco a poco reduciendo la dependencia de la bomba explosiva que tenemos entre las manos y con el tiempo, sustituyendo módulos o funcionalidades completas hasta reducir a la mínima expresión la dependencia. 

Esta solución de capa de cebolla, no solo es aplicable a estas situaciones de Software Legacy, también podría ser aplicable a sistemas con licencias o rentas en la nube prohibitivamente caras cuyo mantenimiento nos implique una seria penalización para la economía de la empresa. 

Por supuesto el desarrollo del nuevo sistema deberá contemplarse desde el punto de vista de la aplicación de las mejores prácticas para no repetir situaciones del pasado, es por tanto básico, diseñarlo con un soporte confiable y robusto y buenos contratos asociados que nos protejan en el tiempo y no solo en dependencia del personal contratado. 

En Resumen

Aunque el artículo es un poco largo, la explicación está planteada a muy alto nivel, pero me sirve para ilustrar la idea; no luchar contra el monstruo, sino crear una cerca a su alrededor y que poco a poco, sea la cerca con la que interactúen los stakeholders externos e internamente, sea esta la encargada de mantener con vida al monstruo el tiempo suficiente hasta que consideremos que deja de ser necesario y ya no es un grave riesgo para la continuidad del negocio. 

Ese es el Camino 🙂