Migración de Aplicaciones


"El Triunfo de la muerte" (Pieter Bruegel, mayormente conocido como "El Viejo")
La obra, del año 1562, representa a una Muerte entrando rampante en un caballo esquelético, tomando por sorpresa a ricos y pobres. Los unos en un banquete, los otros sobreviviendo en su miseria, pero ninguno de ellos pudiendo escapar del desenlace final que a todos nos espera
Esto vale también para el software y su vida útil, sea de la mejor calidad o de la otra


 Hoy  completamos el tercer Architect Forum en este año fiscal. Lo basamos en Procesos de Migración, y especialmente dentro de eso, en el impacto que sufren las arquitecturas de las aplicaciones

Con Alejandro Pacheco (arquitecto .NET de Microsoft Chile) abrimos la sesión comentando el momento en que a las aplicaciones les llega su hora. La crisis de la mantenibilidad se manifiesta cuando el presupuesto de TI es usado más para construir piezas de infraestructura de aplicación (frameworks u otras bibliotecas de bajo nivel) que para desarrollar lógica de negocio

Normalmente cuando el software entra en una fase de mantenimiento, las necesidades de negocio pueden empezar a crecer a una tasa mayor que la capacidad de innovación del equipo de mantenimiento. Para que la brecha entre la funcionalidad que el negocio requiere y la que la aplicación brinda no se haga exageradamente larga, los procesos de modernización procuran -mediante un esfuerzo extra- mejorar capacidades operacionales, funcionales, de performance y evolución

Este esfuerzo es más caro que el mantenimiento regular porque normalmente suele requerir, como vamos a ver, prácticas de reingeniería. Para colmo, a nivel tecnológico se ve menos atractivo que una sustitución completa de la aplicación porque no implica un cambio de paradigma o de plataforma de desarrollo. Aún así, en términos de negocio este enfoque es por lo general el más pragmático

Normalmente las estrategias incluyen

  • Retargeting: mecanismo no invasivo para el software desarrollado que sólo lo despliega en otro hardware y posiblemente otro software de base (cambio de servidor, o de sistema operativo, o de base de datos, etc pero sin impacto o con un muy acotado impacto en la aplicación)
  • Revamping: relanzamiento de la interfaz de usuario en una tecnología más moderna. Caso típico de los robots que generan la versión HTML de las pantallas verdes (los "mapas" o interfaces de usuario en ambientes CICS)
  • Componentes comerciales: tipicamente la compra de una biblioteca, framework o sistema completo de un tercero para cubrir un módulo o funcionalidad que hasta el momento era cubierta en líneas de código del sistema (por ende era responsabilidad del equipo mantenerlas alineadas a las necesidades del negocio)
  • Paradigm shift: reescritura de la aplicación o de partes sustanciales de la misma en un lenguaje o ambiente de programación de un paradigma más evolucionado que el inicial, a fin de recolectar los beneficios del mismo
  • Refactoring: transformación funcional con el objeto de modularizar mejor el código (estructura del programa y de los datos) en términos de mantenibilidad

Una forma inteligente de priorizar el portfolio de aplicaciones que están sufriendo la crisis de la mantenibilidad es aquella que considera Calidad Técnica versus Valor Aportado al Negocio. La siguiente tabla resume la forma de decidir en base a estas características

Una de las partes más dolorosas de la migración de código legado es la reconstrucción de la arquitectura inicial. Partamos por preguntarnos: la hubo acaso? Si la hubo, está documentada? Si lo está, es documentación fidedigna o fue la documentación inicial que luego fue quedando desactualizada y olvidada?

La arquitectura no queda explicitada en el código fuente. Peor aún, a veces nos puede tocar migrar aplicaciones donde tampoco tenemos código fuente sino que tenemos directamente los ejecutables. Para poder reconstruir la arquitectura es que se pone en práctica las tres "I": Interpretar (el significado semántico del código), Interactuar (con desarrolladores, arquitectos, usuarios, … los que estén disponibles, para confirmar y avanzar en la comprensión) e Iterar (las dos íes anteriores hasta donde dé). Afortunadamente existen herramientas que mediante la aplicación de heurísticas logran reconocer patrones en las aplicaciones y pueden llegar hasta cierto nivel de ingeniería reversa

Definir una arquitectura objetivo no es tan difícil hoy que las plataformas de ejecución más modernas como .NET o J2EE nos definen a grandes rasgos los blueprints (moldes) para desarrollar sistemas robustos en tres capas u orientados a servicios (ver post anterior)

Para transformar la vieja aplicación en la nueva hay que considerar tanto lógica como datos. Respecto de estos últimos, lo normal es que el viejo esquema de datos (esquema de tablas, etc) deba permanecer vivo un tiempo hasta tanto la vieja aplicación no salga del todo de producción. Para lograr esto existen estrategias como la replicación (mediante scripting, "extracción-transformación-carga" o ETL, y los triggers que comunmente las bases de datos implementan), o también las capas de acceso, que enmascaran de la nueva aplicación la forma en que la información es persistida

Como siempre suelo recomendar, al menos mi experiencia así me lo hizo concluir, un enfoque dirigido por el esquema de las viejas tablas (data-driven) que me condiciones los clases de entidades que voy a modelar es preferible por razones pragmáticas al enfoque opuesto: redefinir esquemas de tablas debido a que el modelo de clases de objetos de negocio se realizó desde cero sin considerar las viejas estructuras de información (object-driven). Este último enfoque es sin dudas el politicamente correcto… pero es difícil de llevar a la práctica cuando hay ya un esquema de tablas predefinido

En otro orden, y ahora sí, es factible que en la medida en que parte de la lógica es reemplazada, otra lógica legada deba quedar disponible. En este caso deberemos hacer interoperar la aplicación que está naciendo con la antigua. Sea en forma directa, a través de algún middleware orientado a mensajes (MOM) o en forma indirecta a través de un intermediario de servicios (service broker). En tanto que el primer mecanismo no es invasivo de la vieja aplicación, el segundo presenta la ventaja de ser menos acoplado en la nueva aplicación

Como consideraciones finales, poder dividir el proceso de migración en etapas acotadas favorece, tanto a usuarios como a desarrolladores, a entender el nuevo sistema en la medida en que el esfuerzo está más enfocado. Este es el esquema que generalmente proponen los métodos ágiles, aunque suelen ser criticados por cortoplacistas
También no se debe perder de vista el impacto en el equipo de la vieja aplicación. No nos olvidemos que la segunda "I" era "Interactuar". Con quién? Con los viejos desarrolladores. Si no está claro qué rol van a jugar en el proceso de migración ni hay planeado para ellos un programa de entrenamiento y participación en el nuevo sistema, va a ser inevitable la poca predisposición a colaborar

Las sesiones principales del evento fueron cubiertas por ArtInSoft y DTS Latin America Technology

ArtInSoft, de la mano de los costarricenses Federico Zoufaly (su CEO) y Marco Astúa, explicaron como sus trece años de presencia en el segmento de las herramientas de migración les ha permitido adquirir un expertise que hoy lo vuelcan en procesos de evaluación (assessment). Mediante heurísticas logran predecir esfuerzos (en horas/hombre, en dinero, y en otros órdenes) que el proceso de migración completo pueda consumir (hicieron una demo con una de las principales herramientas de migración que han creado: el migrador de código Visual Basic a Visual Basic .NET). Con esto, las soluciones de ArtInSoft claramente se enmarcan dentro de la estrategia de Paradigm Shift. Sin embargo ellos ofrecen también servicios de consultoría que permiten refinar los resultados de manera de sacar el máximo provecho a la plataforma objetivo (llamémoslo post-refactoring, una vez lograda la equivalencia funcional). ArtInSoft no está "casada" con Microsoft, si bien la empresa de Redmond es un accionista de esta compañía costarricence: otra tool muy conocida que han creado es un migrador de Informix 4GL a Java

Por el lado de DTS Latin America Technology, a través de Pedro Montero y Ernesto Carpio, hemos conocido una solución enmarcada dentro de una estrategia conjunta de retargeting y revamping. En términos generales, su producto Micro Focus Net Express permite migrar un ambiente mainframe (el que fuere, CICS, OS/400, …) a plataforma Windows Server sin mover ni un peón en el código. Archivos VSAM en formato EBCDIC terminan alimentando tablas SQL Server en forma transparente. La interfaz de usuario, por su parte, puede conservar un look and field similar al de las terminales 3270, o bien se pueden migrar en forma automática a ventanas gráficas de escritorio e incluso a HTML. El beneficio? Provocar un impacto alto en la experiencia de usuario con un mínimo o quizás ningún esfuerzo. COBOL y la plataforma CICS completa sobreviviendo en ambientes mid range actuales. Viejo es el viento y no por eso deja de soplar

Quiero agradecer publicamente a ArtInSoft y a DTS Latin America Technology por su participación en este evento, ayudándome a mostrar casos prácticos de herramientas de migración, y desearles que el mismo les genere buenas oportunidades

Quiero despedirme con una frase atribuída a Albert Einstein, que me ayuda a sintetizar por qué las plataformas tecnológicas de hoy puedan no resultar adecuadas para satisfacer los desafíos de mañana:

"Los problemas significativos que enfrentamos no pueden ser resueltos con el mismo nivel de pensamiento que teníamos cuando se nos presentaron" (Albert Einstein)

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

4 respuestas a Migración de Aplicaciones

  1. María dijo:

    Hola, solo una aclaración, estoy casi segura de que Pieter
    Brueghel y "El Bosco" eran artistas diferentes, aunque sus pinturas
    fueran similares. El nombre verdadero del Bosco era Hyeronimus Van
    Aeken. Un saludo.

  2. Diego dijo:

    Lo confirmé, MARIA, y es como vos decís. Te recontra agradezco que me hayas ayudado con esa respuesta

  3. matias dijo:

    Disculpame pero esa obra es de  Peter Brueghel. y te respondo con absoluta seguridad

  4. Diego dijo:

    Gracias Matías y Gracias María!!
     
    Gracias a los dos
     
    Toda la confusión partió de mí, chicos. Yo arranqué mal cuando metí este post allá por marzo/abril del 2006, porque estaba convencido de que "El Triunfo de la Muerte" era de El Bosco
     
    Entonces busqué data en Internet y encontré que, como aclara Matías, la pintura es de un tal Pieter Bruegel. De ahí que saqué como conclusión errónea que Pieter Bruegel era El Bosco. Y así lo reflejé en el post original
     
    Luego María me corrigió acertadamente que El Bosco no era Bruegel sino Hyeronimus Van Aeken y, cuando lo confirmé, concluí erroneamente una vez más de que "El Triunfo de la Muerte" había sido pintado pues por Hyeronimus Van Aeken (dado que no me sacaba de la cabeza que la pintura era de El Bosco!!)
     
    Confirmadísimo esta vez: la pintura definitivamente no es de El Bosco. Este post se debería llamar El Triunfo de Pieter Bruegel
     
     
     😀
     
    Un placer chicos, y nos seguimos comunicando

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s