Técnicas de modernización de sistemas legados

Los sistemas legados, o sistemas heredados, son sistemas desarrollados con tecnologías antiguas que ya no pueden actualizarse por limitaciones técnicas. También porque el propio desarrollo no es adaptable a nuevos requisitos o tecnologías actuales. La modernización de estos sistemas es una tarea complicada. Casi nunca es viable reemplazarlos de una sola vez, ya que habitualmente se trata de sistemas muy grandes de los que dependen las empresas. Por eso se suele optar por un reemplazo gradual, lo que implica detectar los servicios a sustituir y el reto de integrar los nuevos desarrollos en el flujo de trabajo actual. Dicho de otra forma, se suele optar por la vía evolutiva, en vez de por la vía revolucionaria, a la hora de cambiar el software.

Dado que los sistemas legados suelen ser piezas monolíticas de software, también suele ser necesario que el proyecto no solo tenga en cuenta qué interesa desarrollar en primer lugar. También la dificultad que entraña que el nuevo software se integre en el antiguo. Habitualmente, el desarrollo del nuevo sistema también encarece el mantenimiento del software legado. Esto se debe a que a la corrección de fallos habitual se suman las modificaciones para ir desechando unos módulos en favor de nuevos sistemas externos.

¿Cómo modernizar sistemas legados?

Existen numerosas técnicas para llevar a cabo un proceso de sustitución de sistemas legados, pero el primer paso siempre es determinar qué es necesario actualizar. Algunas de estas técnicas son:

• Architecture Driven Modernization (ADM)

Esta técnica está muy centrada en el análisis funcional del software heredado. Está relacionada con el concepto de ingeniería inversa y es un muy buen enfoque cuando no se dispone de documentación útil del sistema legado o, incluso, no tenemos acceso al código. Dispone de muchos estándares y metodologías para adquirir conocimiento sobre el sistema, ya que se basa en la obtención de un Metamodelo de Descubrimiento de Conocimientos (KDM).

• Enfoque empresarial de Gartner

Esta consultora propuso su propio método. Este está basado en el concepto de Análisis de Cartera de Aplicaciones (APA). En este análisis se valoran seis factores o requisitos. Tres de ellos son de tipo empresarial: adaptación al negocio, valor para el negocio y agilidad. Los otros tres son de tipo tecnológico: coste, complejidad y riesgo. Cuando no se cumplen los requisitos para una aplicación es el momento de llevar a cabo la actualización.

• Model Driven Engineering (MDE)

Es un método basado en el desarrollo de modelos conceptuales, basados en dominios más que en criterios técnicos. Es decir, en el área de experiencia de todas las partes implicadas en la aplicación. En particular, el de los usuarios que trabajan con ellas. A partir de esos modelos puedes desarrollar el software para dar respuesta a las necesidades de estos. Hay dos arquitecturas que responden al enfoque MDE: Model Driven Architecture (MDA), que está desarrollada por el OMG (Object Management Group) y diversos proyectos de Eclipse (la fundación que desarrolla el popular IDE de desarrollo) que están orientados a la visualización de modelos de alto nivel.

• Renaissance

Otro enfoque interesante es este framework, definido por investigadores de la Universidad de Lancaster. Una de sus ventajas es proporcionar un método iterativo que valora los sistemas legados desde varias perspectivas: técnicas, comerciales y organizativas. La lectura del documento que explica el método Renaissance es de lectura casi obligada para cualquier organización que afronte la necesidad de migrar sistemas legados. El documento identifica muchas de las dificultades y necesidades que aparecen cuando es preciso modernizar software.

• Estrategia WMU (Warrants, Maintenance, Update)

Es otra estrategia muy interesante, ya que su enfoque es distinto del de las anteriores, basadas sobre todo en criterios técnicos y de negocio. En el caso de WMU, el foco se pone en la satisfacción del cliente. Esto implica recopilar mucha información de un tipo diferente a la de otros enfoques. Así, podrás optar por hacer encuestas de satisfacción con los sistemas actuales o valorar el número y tipo de incidencias. También revisar las necesidades de los usuarios que el software actual no cubre y no puede llegar a cubrir. Ya sea por limitaciones técnicas o porque resultaría excesivamente costoso. A partir de ahí puedes establecer reglas para determinar qué aplicaciones, o partes, se siguen manteniendo y cuáles se reemplazan por nuevas aplicaciones.

Los sistemas legados son siempre una fuente de problemas. Lo son incluso los que en su día fueron diseñados con las mejores técnicas y desarrollados con las herramientas más avanzadas. El mantenimiento que se ha llevado a cabo a lo largo de los años siempre está limitado por las capacidades del sistema heredado, por lo que nuevas tecnologías han sido descartadas. Además, las adaptaciones se han hecho sobre un diseño ya existente que, por bueno que fuese en su día, no podía prever muchas de las nuevas necesidades.

¿Cuánto se tarda en modernizar los sistemas legados?

Todo el software tiene un ciclo de vida limitado en el tiempo. Pero hay aplicaciones que necesitan reemplazarse a los pocos años de su desarrollo para evitar la obsolescencia tecnológica. Por ejemplo, como una web corporativa. También hay otras que duran décadas. Un buen ejemplo de esto son las aplicaciones en COBOL de los bancos y algunas administraciones públicas. Por ese motivo, es básico reconocer qué limitaciones estamos padeciendo, establecer criterios o “red flags” que nos indican cuándo debemos iniciar el proceso de renovación y planificarlo con antelación suficiente. De esta manera, podrás hacer que el reemplazo sea tan gradual como el negocio lo permita.

Este tipo de procesos suele llevar años. Y, ¿qué sucede cuando este termina? Algunos proyectos entrarán en una fase de mantenimiento prolongada. Otros tendrán un tiempo de vida más corto. Si la compañía utiliza muchas herramientas de software, es más que probable que la renovación de aplicaciones sea continua.

Las buenas noticias son que, tanto para las nuevas aplicaciones que incorpores como para las que vayas renovando, actualmente se puede diseñar software mucho más modular y basado en servicios o microservicios. Así se simplifica mucho su sustitución cuando llega el momento de hacerlo. Es buen momento para analizar las dificultades que hemos experimentado y prever que, el software que hoy es nuevo, será un sistema legado eventualmente. Por eso es importante documentar, analizar y desarrollar un código de calidad. Pero también abordar con cuidado la renovación de sistemas legados, así que ¡planifica cuidadosamente su sustitución!