Migración Legacy a SOA

La principal problemática radica en la obsolescencia tecnológica de los sistemas legacy. Estos sistemas, a menudo basados en tecnologías como Visual Basic o Delphi, se vuelven difíciles de mantener y actualizar debido a la creciente escasez de profesionales con experiencia en estas plataformas antiguas. El avance tecnológico provoca que la disponibilidad de personal capacitado en sistemas legacy disminuya, incrementando los riesgos y costos asociados a su mantenimiento. La dificultad para integrar estos sistemas con nuevas tecnologías y arquitecturas modernas representa un obstáculo significativo para la evolución de las empresas, limitando su capacidad de adaptarse a los cambios en el mercado y las nuevas demandas de los negocios. Esta situación se agrava por la falta de documentación adecuada, donde el código fuente a menudo contiene la única descripción de las reglas de negocio, complicando su comprensión y mantenimiento. La cita de TIOBE 2017 refuerza la idea de la disminución en el uso de lenguajes de programación más antiguos, reflejo directo de la dificultad para encontrar personal cualificado para su gestión y mantenimiento.

El mantenimiento de sistemas legacy suele resultar extremadamente costoso debido a su complejidad y a la falta de documentación adecuada. El código a menudo se encuentra disperso y mal estructurado, lo que dificulta la comprensión y la realización de modificaciones. A esto se suma el problema de la deuda técnica, definida por Seaman (2011) como "artefactos inmaduros, incompletos o inadecuados que causan mayores costos y menor calidad a largo plazo." Esta deuda técnica se acumula con el tiempo y genera importantes dificultades para la evolución y la modernización del sistema. La inversión inicial en el desarrollo de estos sistemas, a menudo realizada hace años, no debe interpretarse como una justificación para su perpetuación. La migración o adaptación es inevitable para mantener la competitividad de la organización, y este proceso resulta menos costoso que la reconstrucción completa del sistema. Las herramientas de inspección automatizadas se mencionan como una posible solución para analizar el código y evaluar la extensión de la deuda técnica existente, siendo SonarQube un ejemplo de herramienta disponible para este fin.

Los sistemas legacy, aunque funcionales, a menudo no se integran fácilmente con las nuevas aplicaciones y tecnologías. Para mantener la competitividad en el mercado actual, es esencial poder integrar estos sistemas con plataformas modernas, como aplicaciones web y móviles. Esta integración permite la actualización tecnológica sin perder la funcionalidad vital proporcionada por los sistemas legacy. La falta de esta integración limita la escalabilidad y la capacidad de respuesta a los cambios en los requerimientos de negocio, aumentando los riesgos en las operaciones de la organización. Para integrar sistemas legacy en un entorno de aplicaciones moderno es necesario adaptar las partes del software con funcionalidades requeridas, involucrando la conformación de equipos de trabajo y la correcta gestión de este proceso (Rodríguez 2001). Este proceso de integración debe ser cuidadosamente planificado y ejecutado para minimizar riesgos y asegurar el éxito. La gestión eficaz del ciclo de vida del sistema es clave para evitar contratiempos y asegurar la calidad del resultado final.

El documento revisa las soluciones clásicas para abordar sistemas legacy, citando a Rodríguez (2001). Estas soluciones incluyen: el rediseño completo del sistema utilizando una nueva tecnología, una estrategia que implica un esfuerzo significativo y una alta inversión de tiempo y recursos; el wrapping, que consiste en crear una nueva interfaz para un componente del sistema legacy, mejorando su accesibilidad desde otras aplicaciones, sin modificar la base del sistema; y la migración o transformación, un enfoque que implica el traslado del sistema legacy a un nuevo entorno o plataforma más flexible, manteniendo la funcionalidad y los datos originales. La elección del método dependerá de varios factores, incluyendo la complejidad del sistema legacy, los recursos disponibles y los objetivos de la migración. El texto destaca la importancia de considerar la relación costo-tiempo entre la migración de un módulo y su reimplementación completa, favoreciendo la primera opción en términos de eficiencia.

Se analiza el ciclo de vida de los sistemas legacy, destacando que su duración puede extenderse por décadas. A lo largo del tiempo, estos sistemas sufren modificaciones, adiciones y eliminaciones de funcionalidades, lo que lleva a una acumulación de lógica y reglas de negocio que desestabilizan el sistema original. Sommerville (2005) señala que esta situación genera malas prácticas en el mantenimiento, incluso hasta el punto de que algunas funcionalidades se vuelven inaccesibles fuera del código fuente legacy. Este proceso evolutivo y acumulativo genera complejidad y riesgo, incrementando el costo de mantenimiento y disminuyendo la capacidad de adaptación a las nuevas necesidades. La reticencia a reemplazarlos por sistemas modernos, debido a su papel crítico en las operaciones, prolonga la vida útil del sistema legacy hasta que las restricciones tecnológicas impiden su funcionamiento adecuado. Llegado este punto, se requiere una solución que garantice la continuidad de los servicios.

Para representar las etapas de la reingeniería de sistemas, se utiliza el modelo en herradura (Kazman 1998). Este modelo destaca los diferentes niveles de abstracción que se atraviesan durante el proceso. Se inicia con un alto nivel de abstracción, que se mantiene en una segunda fase, para luego disminuir en la última etapa, donde se materializa la solución. Este modelo visual facilita la comprensión de la complejidad del proceso, mostrando cómo se pasa de una representación abstracta del sistema a una implementación concreta. La aplicación de este modelo permite gestionar y controlar los distintos niveles de detalle involucrados en la reingeniería, facilitando la planificación y la ejecución de cada una de las etapas. La simplicidad del modelo facilita su comprensión y lo convierte en una herramienta útil para la planificación y seguimiento del proceso de migración.

El documento analiza los desafíos en la implementación de arquitecturas orientadas a servicios (SOA), citando a Holley (2004). La complejidad de los entornos de sistemas de información, con la necesidad de reutilizar en lugar de reemplazar sistemas, junto con la rápida aparición de nuevos modelos de negocio y el crecimiento mediante fusiones y adquisiciones, genera la necesidad de integración y absorción de diversas aplicaciones e infraestructuras. La existencia de soluciones punto a punto añade complejidad, requiriendo la gestión de entornos heterogéneos en cuanto a hardware, sistemas operativos, lenguajes y tipos de datos. En resumen, la implementación de SOA supone un reto que requiere la gestión de gran complejidad y la capacidad para integrar diversas tecnologías existentes.

El documento presenta las arquitecturas orientadas a servicios (SOA) como una solución para la modernización de sistemas legacy. Se define SOA como un modelo de programación y arquitectura que permite diseñar sistemas de software que ofrecen servicios a otras aplicaciones a través de interfaces publicadas y descubiertas, accesibles a través de una red. Se destaca el uso de Web Services como pilar fundamental de SOA, definidos por Holley (2004) como un conjunto de protocolos que permiten la publicación, descubrimiento y uso de servicios de manera neutral y estandarizada. El World Wide Web Consortium (W3C), citado por Wilkes (2004), ofrece una definición más concisa: "Componente capaz de realizar una tarea". La adopción de SOA permite la creación de sistemas más robustos y flexibles, reduciendo los costes y riesgos de implementación al minimizar la necesidad de desarrollo de código nuevo y permitir la reutilización de componentes existentes. Un servicio en un contexto de negocio podría ser una transacción simple (obtener cuota de stock) o una compleja (calendario de entregas), o servicios de sistema (autenticación de usuario).

Se distingue entre servicios y componentes en el contexto de SOA. Si bien los componentes son la mejor forma de implementar servicios, una aplicación basada en componentes no es necesariamente una aplicación orientada a servicios. La diferencia reside en que SOA implica una capa adicional de abstracción, con mayor granularidad y ubicada más cerca del consumidor de la aplicación (Suarez, 2006). Un servicio se define como una unidad de procesamiento de granularidad gruesa, que consume y produce objetos pasados por valor. Implementada sobre una colección de componentes que colaboran para entregar la funcionalidad de negocio; los componentes son de granularidad más baja. Un servicio mapea una funcionalidad del negocio, mientras que un componente mapea las entidades del negocio y las reglas que las operan. La clave de SOA radica en la interfaz, que define los parámetros y el resultado, independientemente de la tecnología utilizada, permitiendo la gestión y manejo de servicios de forma independiente.

Se destacan las ventajas de SOA, incluyendo la reducción de código, costes y la mejora en la estandarización. El Software Quality Assurance (SQA) disminuye al haber menos código para documentar, y la documentación de la empresa ya existe para los servicios SOA. Sin embargo, también se mencionan desventajas. SOA depende de XML y comunicaciones de red, aumentando el tiempo de transacción y la necesidad de hardware adicional. Además, la dependencia entre servicios puede generar fallos en cascada: si un servicio falla, todas las aplicaciones que lo utilizan también lo harán, lo que hace que las empresas sean reacias a adoptar esta solución. En resumen, SOA ofrece beneficios en términos de eficiencia y reutilización de código, pero plantea desafíos en cuanto a escalabilidad, rendimiento y gestión de dependencias.

El proceso de migración se divide en etapas claramente definidas. Inicia con un diagnóstico de factibilidad para evaluar el potencial de migración del sistema legacy. Una vez confirmado este potencial, se definen casos de prueba pre-migratorios para validar posteriormente el proceso. A continuación, se trabaja sobre los orígenes de datos, generalmente bases de datos relacionales (DBMS), pero con la posibilidad de ampliarlo a otros tipos de orígenes, como archivos o motores NoSQL. Luego, con la base de datos preparada, se centra en la generación automática de código para la arquitectura orientada a servicios (SOA). Una vez disponible la arquitectura SOA, se trabaja sobre el código fuente legacy para integrarlo con la nueva arquitectura. Finalmente, se utiliza mecanismos automatizados para validar si la migración cumple con las expectativas, contrastándolo con los casos de uso pre-migratorios. Se destaca la importancia de justificar el proyecto, incluyendo metas, objetivos, alcance y limitaciones de la migración. El conocimiento del sistema legacy de partida es fundamental: si es caja negra (sin código fuente), caja blanca (con código fuente), o mixto, así como la identificación de sus orígenes de datos y tecnologías.

El proceso comienza trabajando sobre los orígenes de datos del sistema legacy. Si bien se centra en bases de datos relacionales (DBMS), se plantea como trabajo futuro ([TF-1]) la migración de tecnologías más antiguas, como archivos, hacia DBMS o nuevas tecnologías no relacionales (NoSQL). Para sistemas de “caja negra” (sin acceso al código fuente), se deben analizar las entradas, salidas y respuestas del sistema. En cambio, para sistemas de “caja blanca” (con acceso al código fuente), se puede aplicar la ingeniería inversa para descomponer el sistema en funciones y datos. Este análisis permite dividir la aplicación según el tipo de función y alinearlas con las metas del negocio, identificando servicios candidatos que no se generen automáticamente. El enfoque se orienta a entornos RAD, que normalmente usan SQL como origen de datos.

Esta etapa se centra en la migración del código legacy, que suele estar desarrollado bajo esquemas monolíticos con artefactos fuertemente acoplados. El documento se enfoca en plataformas legacy generadas con entornos RAD de los años noventa. Se considera el patrón MVC para implementar sistemas con interfaces de usuario, destacando su importancia para la facilidad de mantenimiento, reutilización del código y separación de conceptos (Burbeck, 1992). La etapa final del proceso implica la validación, utilizando herramientas automatizadas, de que ningún circuito del sistema legacy migrado ha sido alterado. Esto se realiza usando el plan de pruebas definido al comienzo, centrándose en las pruebas de interfaz de usuario (UI) con herramientas automatizadas. Se busca automatizar el plan diseñado sobre pruebas de interfaz de usuario mediante herramientas especializadas, como las pruebas de UI codificadas (CUIT).

Se detallan problemáticas que se deben tener en cuenta durante el proceso: la aplicación legacy es monolítica, con la capa de presentación, almacenamiento persistente y lógica de negocios entrelazadas. La generación automática de la arquitectura orientada a servicios (SOA) ayuda a separar responsabilidades, pero requiere extraer y encapsular la lógica de negocios del sistema legacy e integrarlo con la arquitectura SOA. Se busca preservar el valor de las aplicaciones legacy, transponiendo el código a una nueva plataforma sin añadir errores. Otro problema es que el código es el único lugar donde se documentan las reglas de la empresa, y estas están dispersas y no son comprendidas por nadie. Se propone la minería de código para separar código según su responsabilidad y aplicar refactoring para separar responsabilidades por capas. Finalmente, se considera la deuda técnica (Seaman, 2011), utilizando herramientas de inspección automatizadas (ej. SonarQube) para detectarla y mitigarla. El proceso se describe como incremental e iterativo.

El caso de estudio se centra en Inmosoft, un sistema empresarial que atiende a más de cien clientes, con cientos de usuarios concurrentes. A pesar de su consolidación en el mercado, Inmosoft presenta limitaciones tecnológicas debido a su antigüedad. El objetivo de la migración es permitir la integración con otras aplicaciones y extender funcionalidades imposibles o difíciles de lograr con tecnologías obsoletas. Se busca una migración a tecnologías modernas orientadas a servicios, que permita la integración con aplicaciones modernas (aplicaciones móviles o web), manteniendo el activo legacy encapsulado en capas de negocios. La migración también se justifica por la pérdida de conocimiento y experiencia en tecnologías legacy por parte del personal, lo que representa un riesgo. Se busca un proceso simple, claro, y con un margen de error mínimo. Inmosoft se describe como un sistema de caja blanca, con código fuente accesible (Borland Delphi 6), base de datos SQL Server 2000, y amplio conocimiento del dominio de la aplicación. El enfoque se basa en la aplicación del proceso de migración de forma incremental e iterativa, utilizando releases periódicos para migrar módulos de forma individual.

Para ejemplificar el proceso de migración, se utiliza el módulo de altas, bajas y modificaciones de personas (ABM de Personas) de Inmosoft. El enfoque es actualizar el entorno de desarrollo legacy a uno moderno compatible con el código legacy y las arquitecturas SOA. Se utiliza la metodología de pruebas automatizadas de interfaz de usuario (UI) para garantizar que la migración no altere las interfaces existentes, priorizando la compatibilidad con los usuarios finales. Se muestra el proceso de automatización de un caso de prueba para este módulo, incluyendo la validación del formato CUIT y la verificación de campos obligatorios como el IVA, usando herramientas como Visual Studio y su generador de pruebas CUIT (UI Automation VS). Esto permite una validación post-migración eficiente, asegurando la funcionalidad del sistema sin afectar la experiencia del usuario.

Para la migración, se describe la actualización del entorno de desarrollo. Se detalla la tabla 7 (no incluida en el fragmento) que especifica las tecnologías origen y destino involucradas en la migración de Inmosoft. La idea es modernizar el entorno de desarrollo del sistema legacy, buscando compatibilidad tanto con el código legado como con las arquitecturas SOA. Se busca una migración de las tecnologías origen (Borland Delphi 6, SQL Server 2000) hacia tecnologías modernas Web o Mobile, apoyándose en un proceso de migración que pueda replicarse en otras tecnologías. La integración de la app móvil, desarrollada como parte del caso de estudio, resalta la escalabilidad y simplicidad de integrar nuevas tecnologías con la arquitectura SOA resultante de la migración. Se enfatiza que la app móvil no se encarga del acceso a datos ni de implementar la lógica de negocio, sino que consume los servicios de la nueva arquitectura.