ASNA White Paper
Libérese del Synon en su IBM i
Dirigir un negocio hoy en día con una aplicación en pantalla verde de hace 25 años es una aventura peligrosa. (Consulte nuestro White Paper, La década crítica para el IBM i y el RPG, y sabrá de los peligros que le acechan). Este White Paper de ASNA analiza cómo puede escapar de la dependencia crítica de su antigua aplicación Synon y garantizar la continuidad del negocio al migrarla a C# y SQL Server en la plataforma .NET, implementándola opcionalmente en la nube de Azure.
Los años 80 fueron los inicios de las aplicaciones informáticas empresariales. Por entonces, muchos todavía usaban lápiz y papel para administrar sus negocios. La llegada del AS/400 trajo consigo una nueva computadora de uso generalizado y muchas empresas se dieron cuenta de que, con el software adecuado, el AS/400 podría sacarlos de la ardua tarea del mantenimiento manual de registros.
Cuando IBM anunció el AS/400 en 1988, proclamó con orgullo que había más de 1000 paquetes de software disponibles para su nueva computadora. Sin embargo, la singularidad de muchas empresas (o al menos la singularidad percibida) hacía que los paquetes estándar no pudieran satisfacer muchas necesidades específicas de software. Si usted estaba en el negocio de destilar whisky escocés, construir partes de aviones, recaudar impuestos sobre la propiedad en Valencia o cumplir con cualquiera de los cientos de otros nichos especializados, los programas estándar a menudo no resolvían su desafío. Necesitaba un software AS/400 "a medida"
El nacimiento de las aplicaciones empresariales
En los años 80, había muchas empresas con un nivel de informatización mínimo o nulo. El AS/400 fue fundamental en la modernización de muchas de estas empresas. A medida que modernizaban sus procesos comerciales, muchos se mostraron firmes en la necesidad de informatizar flujos de trabajo manuales específicos.
Si bien se vendía una gran cantidad de software estándar para el AS/400, en muchas empresas no había mucha mentalidad de adquirir software de ese tipo en los días felices del AS/400; a menudo prevalecía un enfoque más centrado en las necesidades, que dictaba un software personalizado.
Esta demanda de soluciones AS/400 a medida creó rápidamente muchos puestos de trabajo nuevos. Las empresas incorporaron personal a sus equipos de programación para crear su software personalizado. Sin embargo, los gerentes comerciales no tardaron mucho en darse cuenta de que desarrollar software comercial complejo es un trabajo arduo y lleva mucho tiempo. Para las grandes empresas con procesos complejos, había mucho trabajo por hacer. Esta necesidad de un software de alto nivel dio lugar a un nuevo concepto de programación que ayudó a las empresas desarrolladoras a crear software.
¡Desarrollo rápido y fácil!
La mayor parte del software AS/400 está escrito en RPG. Cuando se introdujo el AS/400, RPG se estaba desarrollando por completo como un lenguaje comercial y había pocas herramientas de desarrollo disponibles para él: escribir el software AS/400 se hacía principalmente a mano. Las herramientas CASE y los lenguajes 4GL surgieron para aliviar esta carencia en el desarrollo de aplicaciones. Su objetivo era acelerar el desarrollo de aplicaciones mediante la abstracción de los detalles complicados para permitir a los programadores centrarse más en lo que había que hacer en lugar de cómo se tenía que hacer.
Poco después de la aparición del AS/400, surgieron rápidamente varios productos CASE orientados a la empresa. Complejos y sofisticados, estos productos permitieron la creación de aplicaciones AS/400 completas. Estos productos estaban destinados a grandes empresas con necesidades críticas de aplicaciones y, como era de esperar, grandes presupuestos de desarrollo de aplicaciones. La inversión en estas herramientas podía ascender fácilmente a seis cifras.
El líder.
Synon/2, de Synon, Ltd en el Reino Unido, se convirtió rápidamente en el líder del mercado AS/400. Presentado en 1986, Synon/2 (que reemplazó un paquete simple de herramientas de programación para el S/38 llamado Synon/1), rápidamente se estableció como el líder. En 1997, Synon/2 para AS/400 se llamó Synon/2E. Adoptado y mejorado por IBM, Synon/2E se estableció mundialmente rápidamente y con una base de clientes fieles (y llena de efectivo). En 1997, se afirmaba que los ingresos de Synon eran de $80 millones con 6.000 clientes en todo el mundo.
Un detalle sobre el nombre
La familia de productos Synon ha tenido varios propietarios y, a lo largo de los años, se dividió en un par de productos diferentes (algunos de los cuales tenían como objetivo plataformas más allá del AS/400). El producto estrella fue Synon/2, que más tarde se denominó CA/2E. Cualquier referencia a "Synon" en este artículo se refiere a los productos Synon/2 CA/2E y su capacidad para generar RPG para el AS/400.
También el AS/400 ha tenido muchos nombres desde su presentación. Hoy se conoce como IBM i. Debido a que Synon es anterior al nombre "IBM i", usamos "AS/400" en contextos históricos, pero de lo contrario usamos el nombre actual, "IBM i".
Synon proporcionó herramientas para crear y mantener un repositorio específico de reglas de negocio y modelos de datos. Este repositorio se conoce como el "modelo" de Synon. Utilizando la biblioteca de Synon de 15 plantillas de programas predefinidos, el diagramador de acciones de Synon y su modelo de negocio, las aplicaciones se pueden crear e implementar rápidamente.
El código resultante de Synon fue RPG, que a su vez se envió al compilador RPG para crear objetos de programa AS/400. Este RPG generado era un código de solo salida, que no estaba destinado a ser cambiado o incluso visto por los programadores. Esta generación de RPG fue esencialmente transparente para el programador de Synon. Todos los cambios necesarios para una aplicación de Synon se realizaron en el modelo de Synon y se generó un nuevo RPG.
Para muchas empresas de AS/400, Synon era una herramienta crítica e importante. Permitió crear aplicaciones en meses con un pequeño equipo de programación. Este es un trabajo que normalmente costaría años a un equipo de programación, escribiendo el código a mano. Más de 25 años después de su creación, las aplicaciones basadas en Synon todavía están en uso en cientos de empresas que usan el AS/400 (ahora conocido como IBM i) en todo el mundo.
Qué beneficios tiene el desarrollo de aplicaciones basadas en Synon
Synon permitió la creación de innumerables aplicaciones y proporcionó un ROI sustancial para muchos desarrolladores de AS/400. Entre otros sus beneficios eran:
- Simplificando el desarrollo: Hay un viejo principio de programación que dice que los programadores pueden crear cientos de programas, pero solo crean una cantidad pequeña y fija de tipos de programas. Parte del éxito de Synon fue reproducir este principio con sus 15 plantillas de programas. Estas plantillas ayudaron a reducir los desafíos de casos especiales que debían resolverse a mano.
- Personalización de primera clase: Si bien el número fijo de plantillas de Synon resolvió muchos desafíos, las plantillas universales simplemente no pueden abordar todas las necesidades. Para superar las limitaciones impuestas por sus plantillas, el modelo de Synon se puede configurar con código RPG y CL personalizado, así como con la capacidad de integrar programas RPG y CL independientes (o existentes) creados manualmente. Las funciones de personalización de Synon lo diferenciaron de sus competidores y la mayoría de los desarrolladores de Synon las utilizaron mucho.
- Componentes genéricos fáciles y accesibles: Synon proporciona una biblioteca de funciones muy generales. Las rutinas de fecha, la programación de mensajes, registrar logs y muchas funciones que se necesitan comúnmente, están fácilmente disponibles y se usan con mucha frecuencia.
- Estándar y disciplinado: Las 15 plantillas de Synon impusieron modelos y estándares de programación predecibles. Esto facilitó el mantenimiento y los cambios del programa. El código escrito a mano es indisciplinado (y la mayoría del RPG escrito a mano es muy indisciplinado) es mucho más difícil de modificar que los patrones de plantilla predecibles de Synon.
- La integración con el AS/400: A diferencia de muchos otros generadores de programas, Synon apuntó exclusivamente al AS/400. Las aplicaciones de Synon aprovecharon expresiones y características únicas y específicas de AS/400 para producir aplicaciones de alto rendimiento y muy personalizadas.
Pero tiene un lado oscuro
Las principales preocupaciones si sigues usando Synon
- Los desarrolladores Synon están llegando a la jubilación. El uso de Synon requería un conjunto muy específico de habilidades de programación. Muchas empresas capacitaron y desarrollaron equipos de programación internos de Synon. Sin embargo, muchos de estos programadores están llegando ya a la edad de jubilación y, desde el declive de Synon, los programadores más jóvenes de Synon están desaparecidos.
- Limitados recursos externos. En el apogeo de la popularidad de Synon, había muchos recursos, desarrolladores y formación disponibles específicos de Synon. La mayoría de las empresas que ofrecían recursos de Synon se evaporaron o cambiaron de enfoque hace mucho tiempo y la ayuda que se puede encontrar hoy suele ser muy costosa.
- Synon no es RPG. Los programadores de RPG hoy son un recurso valioso, pero no tanto como los programadores de Synon. Aunque Synon produjo RPG, Synon nunca se centró en RPG; su RPG generado fue simplemente un paso intermedio e invisible, necesario para producir objetos de programa nativos a partir del modelo de Synon. Por lo tanto, incluso si una empresa puede encontrar programadores de RPG, no es probable que sepan más sobre Synon que los programadores de C# o Java.
- El código RPG generado por Synon no es un activo. Dado que Synon genera RPG, es razonable preguntarse "¿por qué no se puede mantener la aplicación a partir de ese RPG generado?" Ese RPG generado nunca fue pensado para la comprensión humana. Para los humanos, es un código arcano y desconcertante que carece de símbolos significativos: estaba destinado únicamente a enviarse al compilador RPG y, tal como está, no ofrece ayuda en mantener la vida de una aplicación Synon.
- La nube está llamando. Para muchas empresas, otra razón para reemplazar su antigua aplicación Synon es aprovechar la escalabilidad, la asequibilidad y la facilidad de la implementación en la nube basada en Azure. Migrar su aplicación Synon a C# en .NET y la base de datos IBM i DB2 a SQL Server abre esa posibilidad. ASNA Synon Escape puede apuntar fácilmente a una instancia de nube de Azure para una implementación y funcionamiento sin dolores de cabeza.
No solo es Synon, también es la plataforma.
Más allá de los problemas que una aplicación de 25 años, creada con un generador ahora casi extinto, impone a una empresa, se debe considerar la viabilidad del AS/400 como una plataforma empresarial del siglo XXI. Ahora conocida como IBM i, la plataforma de rango medio de IBM ha hecho un excelente trabajo al reinventarse mientras mantiene una alta fidelidad con aplicaciones muy antiguas.
El IBM i tiene muchos fans y no va a desaparecer pronto. Sin embargo, IBM i (y sus modelos predecesores) es una plataforma informática obsoleta con una interfaz de usuario de pantalla verde basada en caracteres nativos y una base de datos idiomática integrada. A pesar de las incursiones de PHP y Node, RPG sigue siendo el lenguaje principal de IBM i y la mayoría de las aplicaciones de IBM i todavía están fuertemente arraigadas en él. Las operaciones y la administración de RPG e IBM i no se enseñan en muchas universidades. Para muchos responsables de TI hoy en día, especialmente aquellos sin años de devoción a la plataforma de rango medio de IBM, mantener el IBM i es difícil de vender.
Atrapado en Synon
Las empresas que usan el IBM i y que utilizan aplicaciones Synon hoy en día tienen que tomar decisiones muy difíciles. La propuesta comercial única que ofrecen, los flujos de trabajo que los mantienen competitivos y muchas operaciones diarias dependen en gran medida de sus aplicaciones Synon. Para la mayoría de las empresas, avanzar sin ellos es inconcebible. El camino a seguir para estas empresas tiene solo cuatro alternativas:
- Reescribir. Esta es la alternativa que desean muchos responsables de TI, que los miembros de la junta a menudo piensan que es la mejor y que tiene el mayor atractivo emocional. ¿Quién no querría una aplicación nueva y brillante con todas las comodidades y capacidades modernas? Por desgracia, esta reescritura, a todos los efectos, debe ser desde cero. La documentación de la aplicación IBM i (Synon o no) es casi siempre inexistente y/o lamentablemente desactualizada. Por muy romántica que sea la idea de reescribir la aplicación, la realidad es que se necesita mucho tiempo (normalmente medido en años) y un presupuesto exorbitante para realizar el trabajo. Reescribir la aplicación es un juego de ganarle al reloj. ¿Puedes hacer la nueva aplicación antes de que caduque la aplicación anterior?
- Paquetes estándar. Evitar los paquetes estándar es la razón por la que muchas empresas comenzaron a usar Synon. La necesidad de una solución única, hecha a medida, tuvo una atracción mucho más fuerte que la de comprimir su negocio en un paquete estándar. En los 25 años desde eso probablemente nada ha cambiado. Es posible que pueda identificar y delegar tareas de propósito general como el libro mayor o las cuentas por pagar a estándares, pero esas tareas que permiten la singularidad de su negocio, su ventaja competitiva, generalmente no se pueden realizar con paquetes cerrados.
- No hacer nada. Este es uno de los favoritos de los responsables de TI que están contando los días hasta su jubilación. ¿Por qué abordar la tarea altamente visible de reemplazar una aplicación de 25 años cuando es más fácil pasar los próximos dos años soportando las hondas y flechas de una administración nerviosa? Pronto todo será problema de otra persona. Este punto de vista cínico puede ser ofensivo para algunos, pero considérelo con cuidado. No permita que su equipo de gestión se deje influir por un tomador de decisiones que tiene más habilidades para enmascarar problemas que para resolverlos.
- La migración. Una migración de aplicaciones transfiere una aplicación de una plataforma a otra. Si bien hay muchas tareas de descubrimiento e investigación, la migración de aplicaciones se reduce a analizadores de dominio específicos que traducen un idioma a otro. Por ejemplo, ASNA Monarch traduce RPG a C#. Sin embargo, las aplicaciones de Synon no están basadas en lenguajes, están basadas en modelos. Las migraciones tradicionales de idioma a idioma por sí solas no funcionan bien con Synon.
Abrimos el melón de las migraciones de Synon
Para muchas empresas, la necesidad de escapar del control de Synon es abrumadora y la migración es la única opción racional. Garantizar la persistencia de la inteligencia de la aplicación Synon para el futuro de la empresa es de suma importancia.
Synon presenta varios desafíos de migración de casos especiales. Quizás el mayor desafío es lo que alguna vez fue una gran fortaleza de Synon: sus capacidades de personalización de primera clase. La mayoría de las aplicaciones generadas por Synon son, en última instancia, una combinación de Synon puro basado en modelos y RPG y CL personalizados. Este RPG y CL personalizados existen integrados en el modelo Synon y en programas RPG externos (y escritos a mano).
Para escapar de Synon, la aplicación debe llevarse a un entorno nativo, ya sea en la plataforma IBM i o en alguna otra plataforma. Los proveedores de migración a menudo adoptan un enfoque ingenuo para resolver este rompecabezas. En algunos casos, el modelo se ignora, mientras que en otros se convierte en el único foco de la solución, ignorando los programas RPG y CL personalizados que admiten los programas generados. Existen principalmente cuatro formas de intentar una migración de Synon (como se muestra en la Figura 1 a continuación), pero solo una tiene sentido.
Los contenidos que indicamos a continuación asumen que la migración se dirige a una plataforma distinta al IBM i (algunas de las debilidades se reducen si la base de datos de la aplicación migrada permanece en el IBM i).
Migrar el modelo de Synon a un nuevo modelo y un nuevo generador. Estas herramientas intentan migrar el modelo de Synon a un nuevo modelo. El software más cercano a este enfoque es CA Plex (también conocido como Obsydian), que es el sucesor multiplataforma del Synon original. Las debilidades de este enfoque serían:
- La importación del modelo es imperfecta y se requiere trabajo manual para asegurar su fidelidad con el modelo anterior.
- El RPG personalizado o CL integrado en el modelo de Synon (y llamado mediante la operación EXCUSRPGM de Synon) debe reescribirse. Esta es una debilidad significativa.
- Todos los informes deben reescribirse o reemplazarse con una herramienta de BI.
- Las operaciones de IO en ficheros que funcionaban bien de forma nativa en IBM i pueden no ser eficientes con otro controlador de base de datos (es decir, JDBC) que utilice la plataforma de destino.
El mayor desafío con la opción anterior es su desprecio por las dependencias de Synon de los programas RPG y CL personalizados. Estas áreas personalizadas son cruciales para la aplicación y este enfoque no solo las deja atrás, sino que las deja atrapadas en otro generador.
Migrar el RPG generado a otro lenguage. Este enfoque traduce el RPG generado por Synon a otro idioma/plataforma. ASNA Monarch utiliza este enfoque y funciona muy bien para aplicaciones RPG escritas a mano. Sin embargo, este enfoque no funciona bien con RPG generado por Synon.
- Los programas generados son muy grandes con muchos segmentos de código repetidos en muchas partes del código fuente.
- El RPG generado por Synon no usó nombres significativos de campos y subrutinas (recuerde, este código estaba destinado a ser compilado, no leído por humanos). Mantener este código incomprensible es casi imposible.
-
Extraer las reglas comerciales y la lógica y reescribir la aplicación. Con este enfoque, las reglas comerciales y la lógica del modelo Synon se extraen (a través de un proceso manual) a una definición de modelo nueva y patentada. Luego, se produce un nuevo fuente de la aplicación, generalmente Java, a partir de este modelo.
Este enfoque no es más que una reescritura de la aplicación moderadamente asistida. Tiene todos los problemas de la migración basada en modelos n.º 1, pero carece de procesos completamente automatizados.
-
Refactorización basada en modelos del RPG generado. Este es el enfoque que adopta Synon Escape de ASNA. Creemos firmemente que el mejor enfoque para modernizar una aplicación IBM i basada en Synon se basa en una traducción guiada por modelos del código generado por Synon. Los beneficios de este modelo son:
- Los programas refactorizados se basan en un framework que consolida la funcionalidad común de las plantillas de Synon y su framework.
- La aplicación resultante es C# fácil de mantener, moderna y orientada a objetos. Las diferencias significativas entre el RPG generado original y este código refactorizado son:
- Se asignan nombres significativos de campos y subrutinas a los nombres incomprensibles de Synon.
- El código generado es más fácil de comprender y se presta a una refactorización más sencilla.
- El framework de C# tiene jerarquías de clases que implementan el código repetitivo de las funciones de Synon.
- Implementaciones fieles de las 15 plantillas originales de Synon.
- El RPG personalizado o CL se migra con ASNA Monarch directamente.
- Reemplaza el runtime de alta fidelidad para lenguajes de IBM i como grupos de activación, áreas de datos, QTEMP y colas de salida/trabajo.
Con ASNA Synon Escape, la antigua aplicación se expresa en un nuevo lenguaje de programación dirigido a una nueva plataforma. Toda la funcionalidad, incluidas las interfaces de usuario y los informes, son funcionalmente equivalentes a la aplicación original. El RPG y CL personalizados que se integraron con la antigua aplicación Synon también se migran directamente como C# moderno y se integran con la nueva aplicación.
Una migración de aplicaciones Synon preparada para el futuro debería:
- Tener alta fidelidad con todas las partes de la aplicación existente (incluidos los informes, las interfaces, las reglas comerciales y el acceso a la base de datos).
- Extraer el valor del modelo de Synon, pero también asegurar que la aplicación migrada se pueda mantener y entenderse sin él.
- No excluya ni ignore los RPG y CL personalizados que integran la "salsa secreta" de su negocio con la aplicación original.
- Potenciar la nueva aplicación en su nueva plataforma no solo para ejecutarla, sino para extenderla y mantenerla racionalmente con herramientas y técnicas estándar.
ASNA Synon Escape hace todo eso. ¡Y mucho más!
Synon Escape con más detalle
Synon Escape es el paquete de migración de aplicaciones específico de Synon de ASNA. Synon Escape comparte y usa muchos componentes de nuestra suite de migración original, ASNA Monarch. Monarch migra el RPG escrito a mano a C#. En los últimos años, hemos probado un par de enfoques para introducir a Monarch en la tarea de migrar aplicaciones de Synon. Sin embargo, estaba claro que Synon necesitaba algo muy específico y centrado en Synon.
Mediante un enfoque basado en modelos, Synon Escape migra las aplicaciones Synon2/Cool:2E/CA 2E a C#. Al acoplar las definiciones de lógica empresarial en el modelo de Synon con el RPG generado por Synon, Synon Escape crea una fuente de C# racional y mantenible. La mayoría de las migraciones de Synon no son solo migraciones de Synon. Son híbridos que necesitan migrar código CL y RPG personalizado generado por Synon. ASNA Monarch es un gran socio de Synon Escape, lo que permite a ASNA migrar de manera efectiva tanto el código relacionado con el modelo Synon de una aplicación con Synon Escape como su RPG y CL personalizados con ASNA Monarch.
Synon Escape comparte la consola de migración de Monarch, ASNA Cocoon, que se muestra a continuación en la Figura 2. Cocoon analiza el contenido de la biblioteca de IBM i para crear un repositorio de información de aplicaciones con referencias cruzadas.
Parte de la información que revela Cocoon es:
- Un inventario de los activos de la aplicación (es decir, archivos físicos y lógicos, áreas de datos, objetos de programa, fuentes de copia, archivos de impresora, miembros fuente)
- Gráficos de dependencia (qué objetos llaman a otros objetos)
- Objetos de programa antiguos y probablemente sin usar
- Utilidades en origen que se han perdido
Cocoon proporciona un gráfico de llamadas entre objetos de programa detallado, que se muestra a continuación en la Figura 3. Los grupos de programas se identifican para crear una hoja de ruta de migración detallada.
Los módulos específicos de Synon encajan en Cocoon para ayudar con el descubrimiento y la definición de modelos. El mapeo de campos de Synon Escape, que se muestra a continuación en la Figura 4a, es una de las formas en que Synon Escape crea C# mantenible. Estos nombres de campo significativos, derivados del modelo Synon, aumentan drásticamente la legibilidad y el mantenimiento del código.
El resultado de la asignación de nombres de campo de Synon Escape se muestra a continuación en la Figura 4b:
Para hacer el trabajo pesado de transformar el código, Synon Escape utiliza una variedad de "agentes de migración" como se muestra a continuación en la Figura 5:
- Agente de archivos de pantalla. Los archivos de pantalla se migran a páginas Razor de Microsoft ASP.NET. En tiempo de ejecución, estas páginas se representan como HTML 5.
- Agente de CL. El código CL se migra a C#.
- Agente de RPG. El código ILE RPG y RPG/400 se migra a C#.
- Agente de archivos de impresión. Los archivos de impresión se migran a su análogo en Windows. Estos recrean fielmente el archivo de impresión tal como existía en IBM i.
- Agente de archivos de mensajes. Los archivos de mensajes se migran a una representación basada en XML.
- Agente de datos y esquemas. La base de datos de IBM i se migra a SQL Server. Los archivos físicos se transforman en tablas SQL y los archivos lógicos se transforman en vistas SQL. Una vez migrado a SQL Server, todas sus funciones de inteligencia comercial se pueden usar en esta nueva base de datos.
A medida que el RPG generado por Synon se migra a C#, el código se refactoriza para eliminar sus redundancias intrínsecas. Un ejemplo de esta refactorización se muestra a continuación en la Figura 6:
Synon Escape crea páginas ASP.NET que se representan como páginas HTML 5. A continuación se muestra una pantalla de antes y después en la Figura 7. Con un paso posterior a la migración, estas nuevas pantallas podrían mejorarse aún más, tanto funcional como estéticamente.
Rompa sus cadenas con Synon
La necesidad de migrar su aplicación Synon va mucho más allá de ser un problema técnico. Encerrados dentro de esa aplicación están los procesos y flujos de trabajo personalizados sobre cómo su empresa ofrece su valor comercial único. Sin mantener esos procesos personalizados, es casi imposible mantener su negocio.
ASNA Synon Escape es una solución rica y profunda que permite escapar de las dependencias de Synon IBM i. Haber trasladado su aplicación Synon heredada (y sus dependencias RPG personalizadas) a C# no solo ofrece un salida, sino que abre esa aplicación a una comunidad de programadores más jóvenes (y mucho más disponibles). Una vez migrada a C# , las formas en que la aplicación puede mejorarse y ampliarse no tienen fin.
Synon Escape es la única herramienta con capacidad para proteger su negocio al mantener su aplicación heredada crítica para el futuro.
