Si la modernización de sistemas legacy en IBM i no se atiende de manera oportuna y proactiva, las compañías sólo estarán aplazando las actividades de modernización que eventualmente tendrán que hacer, y entre más tiempo pase, más complicado y costoso se vuelve.
El IBM i (AS400 – iSeries) ya tiene ciertas décadas de uso acumuladas en todo tipo de compañías; de todas las industrias y de todos los tamaños. Es muy común encontrarnos empresas con operaciones obsoletas (legacy o heredadas) en sus Sistemas IBM i. Esto sucede en parte por la rotación natural de personal en las compañías y la rápida evolución de tecnologías año con año.
Estas empresas se han mantenido operando de manera relativamente estable utilizando software e infraestructura obsoleta. Y lo han mantenido así porque se dejan regir por una idea peligrosa que es: “Si funciona, no lo toquen”. Sin embargo, con el paso de los años, las operaciones legacy se vuelven cada vez más inestables y costosas de mantener, llegando inevitablemente a un punto de inflexión en el que se tiene que decidir si esa tecnología obsoleta se moderniza o se remplaza.
En este artículo hablaremos sobre modernización, ya que reemplazar tecnología legacy del IBM i suele ser más costoso y complicado que modernizar, pero ese será tema para otro artículo. Por otro lado, la modernización toma ventaja y explota la inversión que se ha hecho a lo largo de décadas.
La modernización en el IBM i es un tema extenso que puede atacarse por varios frentes. No existe un ‘ABC de la modernización’ puesto que cada compañía tiene sus particularidades y circunstancias; no todas las operaciones de TI adolecen de lo mismo. Sin embargo, sí existen formas generalizadas para identificar las diferentes aristas de la modernización en el IBM i, y podrían categorizarse principalmente a 3 diferentes niveles: infraestructura, aplicaciones y bases de datos.
Hablar de infraestructura es en gran parte hablar sobre fierros y todos los medios en los que se ejecuta nuestra operación. Por un lado tenemos la parte del hardware donde vive nuestro IBM i, y por otro lado tenemos el sistema operativo como tal.
Tanto el hardware como el sistema operativo pueden convertirse en un dolor de cabeza si no se están actualizando constantemente. La evolución de ambos elementos debería ser progresivo, como actualizar el sistema operativo cada determinado tiempo, así como hacer un tech-refresh de nuestros equipos IBM POWER SYSTEMS.
Uno de los principales impedimentos para no actualizar infraestructura constantemente es por una cuestión de costos y malas planeaciones. Nosotros nos hemos topado con más de un par de casos en los que la empresa deja de renovar sus máquinas y sistema operativo porque están en un proyecto de transición hacia ‘nuevas tecnologías’.
Casos en los que la dirección exige la implementación de ERP’s como SAP u Oracle (que no corren en IBM i), los equipos de TI estiman proyectos de 3 años, pero terminan por abandonar el proyecto después de aplazarlo por 10 años. No es ninguna exageración, sustituir los IBM i no es cosa sencilla. Y en estas situaciones, nos encontramos con infraestructuras que no han sido actualizadas en 5 o 10 años.
Además de los dolores de cabeza de hacer saltos enormes entre equipos y OS viejos hacia nuevos, nos topamos con los problemas de pagar penalizaciones a IBM por no haber pagado nuestro mantenimiento (after license), si es el caso en el que ni siquiera se cubrieron los cargos de mantenimiento y soporte tanto de hardware como de software con IBM.
El punto más inmediato de modernización de infraestructura es la actualización de versión de sistema operativo. Hoy en día se recomienda tener nuestro OS en la penúltima versión disponible ya que se considera que podría ser más estable que la más reciente.
No actualizar la versión de OS nos puede poner en apuros al momento de necesitar actualizar software de terceros que ejecutamos de manera nativa en nuestro IBM i. Puede haber casos en la que la última versión de la solución no sea estable en nuestro OS viejo, y la última versión del software solucione problemas u ofrezca nuevas características.
Por otro lado, tener una versión vieja nos puede impedir implementar nuevas tecnologías para desarrollar en nuestro IBM i. Por ejemplo, realizar desarrollos con lenguajes como PHP, NodeJS, o Python, o utilizar una versión más reciente de estos lenguajes. También puede ser un impedimento para adoptar tecnologías de nube (cloud), y de eso hablaremos un poco en el siguiente punto.
La actualización de OS de manera progresiva no es tan complicada, pasar de una versión 7.2 hacia 7.3 o 7.4 es muchísimo menos complicado y arriesgado que saltar de una versión 5.2 hacia una 7.4. No dejar estancada nuestra versión de OS es un gran paso para evitar obsolescencia de infraestructura.
Todo el hardware en la que corre nuestro IBM i también es una parte fundamental de la infraestructura y no renovarla de forma periódica tiene implicaciones similares a las que explicamos en el punto anterior con el OS.
Sin embargo, fallas en las máquinas pueden ser aún más graves ya que pueden frenar por completo la operación del negocio si no contamos con alguna estrategia de HA o DRP. No es necesario explicar que entre más obsoleto sea el hardware, más probabilidades existen de que tenga alguna falla. En ocasiones, equipos POWER tan viejos no encuentran accesorios o refacciones en caso de que se les descomponga alguna, no la podrían conseguir con IBM, y sólo tendrían que confiar en encontrar alguna en el mercado de segunda mano. El cambio de máquinas en IBM lo denominan como “tech-refresh”, y lo recomendable es realizar uno cada 3 o 5 años.
En el caso de migrar nuestra operación a la nube, nos estaríamos olvidando de este problema por completo. Sin embargo, para migrar el IBM i a la nube es necesario tener versiones recientes de OS. Proveedores de nube como IBM Cloud o Microsoft Azure necesitan que tu OS esté al menos en la versión 7.2, si cuentas con una versión antigua tendrás que actualizar primero antes de considerar dar el salto a cloud. Aunque existen algunos proveedores de nube IBM i como Connectria, que ofrecen la posibilidad de utilizar OS más antiguos, pero lo recomendado es siempre estar en versiones recientes por lo explicado en el punto anterior.
Situaciones en las que aplicaciones del core de negocio fueron desarrolladas por personas que ya no están en la compañía, y no crearon documentación, son más comunes de lo que uno se podría imaginar. Por otro lado, las tecnologías populares al momento de implementar estas aplicaciones hoy ya están lejos de serlo, o incluso están en riesgo de desaparecer.
Es por tal motivo que existen operaciones que siguen trabajando con aplicaciones desarrolladas en COBOL y con bases de datos DDS (por decir un ejemplo).
El software obsoleto también ‘repele’ a las nuevas generaciones. Hoy en día difícilmente se encuentra talento joven que sepa desarrollar en RPG, trabajar en pantallas verdes tampoco es muy amigable que digamos. El riesgo de tener aplicaciones obsoletas también pone en riesgo el futuro de nuestra operación.
Como se mencionó, las nuevas generaciones difícilmente se interesarían en aprender un lenguaje de programación obsoleto. Principalmente porque las oportunidades laborales están en lenguajes más modernos y populares como Nodejs, o Python.
Modernizar el código fuente no es tarea fácil, ya que en la mayoría de las ocasiones implica refactorizar o volver a hacer aplicaciones pero con un lenguaje de programación más moderno. Lo cual puede llevar demasiado tiempo además de que exigiría bastante conocimiento sobre la aplicación que se busca volver a desarrollar.
Existen herramientas como ARCAD Software, que cuenta con módulos para modernizar el código fuente de aplicaciones desarrolladas en versiones antiguas de RPG, y las transforma en aplicaciones en RPG Free. Evidentemente, RPG Free tampoco es el lenguaje de programación más popular y moderno en el mercado, pero su gran ventaja es que su sintaxis es similar a la de Java; lo que reduciría las barreras de que nuevos programadores puedan tener una curva de aprendizaje menos complicada a comparación de aprender versiones anteriores de RPG (ej. I, II, III, etc.)
Las pantallas verdes son anticuadas, no es ninguna mentira. Por supuesto que hasta la fecha han sido bastante efectivas y parece que no hay necesidad de cambiarlas o renovarlas. Sin embargo, cuando tenemos un enfoque muy técnico creemos que las cosas sólo tienen que funcionar bien, lo que nos hace creer que no habría ningún impacto al remplazar pantallas verdes feas pero funcionales por unas ‘bellas’ interfaces web.
No es una cuestión de estética, es una cuestión de usabilidad.
A veces, como creadores y operadores de tecnología, se nos olvida que toda esta tecnología es utilizada por alguien; nuestros usuarios. No porque una pantalla verde ha cumplido bien su función significa que no pueda ser mejor en cuanto al uso que se le da. Una pantalla verde es una interacción limitada a textos y comandos. Con una interfaz gráfica es posible mejorar la usabilidad de nuestras aplicaciones:
Con aplicaciones como Profound UI, es posible convertir nuestras pantallas verdes hacia modernas interfaces web. Pero no debemos olvidarnos en ningún momento del usuario final. Lo peor de sustituir pantallas verdes con interfaces web, es que los usuarios finales no las utilicen y prefieran volver a las pantallas verdes en las que han trabajado por años. Para evitar que esto suceda es necesario involucrar conocimiento de experiencia de usuario (UX) e interfaz de usuario (UI) que puedan explotar al máximo las bondades de una interfaz web.
Los procesos de desarrollo son uno de los puntos más flacos en operaciones legacy. En ocasiones las compañías (por desconocimiento del sistema) deciden dejar de desarrollar en el IBM i, y mejor utilizar sistemas satelitales (Linux, Widows, etc.) para desarrollar aplicaciones que a fin de cuentas necesitan conectarse con las base de datos en el IBM i. Estos desarrollos satelitales suelen ser soluciones rápidas, pero a la larga se vuelven difíciles de gestionar además de impactar negativamente el rendimiento de los servidores.
Lo recomendado es que todas las aplicaciones que deban interactuar con las bases de datos en el IBM i, se desarrollen de forma nativa. Y la imposibilidad de poder desarrollar aplicaciones nativas de forma ágil termina afectando la productividad e incluso oportunidad de crecimiento del negocio. Ya que no se podría cumplir con las exigencias de la operación de la compañía por tener un sistema tan rígido.
La mejor forma de modernizar nuestros procesos de desarrollo en el IBM i es implementando la filosofía de desarrollo DevOps. De esta forma será posible estar desarrollando y liberando software de manera continua (CI/CD), cumpliendo y superando las expectativas del negocio al ofrecer sistemas flexibles y seguros. La adopción de herramientas open source tales como Jira, Github, Docker, Jenkins, etc. juegan un rol clave en este proceso. En este artículo te compartimos información detallada sobre DevOps y consejos útiles para implementarlo en el IBM i con ARCAD Software.
La capacidad de la base de datos DB2 es y seguirá siendo la principal ventaja de desarrollo de la plataforma IBM i, gracias a su reconocida confiabilidad, seguridad y escalabilidad.
El alto nivel de integración del motor de base de datos en el propio sistema operativo prácticamente elimina la necesidad de un administrador de base de datos en el IBM i, lo que ahorra costos de recursos. Y desde el punto de vista del rendimiento, las últimas versiones de DB2 para IBM i han superado recientemente a la tecnología SAP durante las pruebas comparativas.
Entonces, ¿cuál podría ser el problema del DB2? La respuesta está en las propias aplicaciones. Para aprovechar toda la potencia del motor del IBM i con bases de datos DB2, debemos modernizar nuestras bases de datos existentes migrando hacia un modelo relacional completo (transformar bases de datos DDS hacia DDL). De esta forma:
El módulo de ARCAD Transformer DB simplifica el proceso de reingeniería de bases de datos DDS hacia DDL (SQL), ahorrando potencialmente meses de trabajo en reingeniería.
Una de las formas más seguras y eficientes de trabajar con las bases de datos en el IBM i, es por medio de la utilización de API’s rest. De esta forma, es posible crear interconexiones seguras con aplicaciones satelitales sin vulnerar acceso a la información, además de afectaciones mínimas en el rendimiento (performance) de nuestros equipos POWER. En este video mostramos cómo realizamos una interfaz web en un servidor externo, que interactúa en tiempo real con la bases de datos en el IBM i. Estas API’s fueron creadas de forma sencilla con Profound API.
Como podemos ver, la modernización en el IBM i es un tema bastante extenso. En este artículo se procuró hablar de la gran mayoría de elementos a considerar, pero de una forma un poco superficial y no tan técnica. Sabemos que cada compañía tiene sus particularidades, en TIMWare te podemos apoyar a dimensionar y establecer alcances de proyectos de modernización a la medida de tu operación, somos partners y expertos en soluciones como ARCAD Software, y también ofrecemos hardware de IBM y servicios de nube (IBM Cloud). No dudes en contactarnos para cualquier duda o comentario.
