Un estudio reciente de Forrester (de septiembre de 2016) concluye que el 90% de los ejecutivos se encuentran con problemas a la hora de desarrollar aplicaciones para mainframe y ponerlas en producción. De hecho, el 57% de las nuevas iniciativas de negocio de las grandes compañías tienen que ver con un mainframe. Y los motivos para ello son varios: por un lado, el control que se tiene sobre un mainframe es muy superior al que se puede tener sobre tecnologías cloud; y por otro, hay miles de millones de líneas de código escritas para mainframe que están funcionando perfectamente, en un entorno controlado y estable, que no hay una necesidad inmediata de cambiar.

Por algo, una de las leyes de Murphy reza: “Si algo funciona, no lo toques”. Y así es en muchos casos. Los sistemas basados en mainframe son sólidos como rocas. Y no se trata necesariamente de anquilosamiento en el pasado por parte de la compañía o el departamento de TI, sino que el sistema les está ofreciendo el rendimiento y disponibilidad que necesitan, con una fiabilidad enorme. Así que ¿para qué cambiarlo? Y no hablemos de los billones de dólares que se han invertido en código y sistemas (y son billones españoles, con doce ceros). Sectores como banca, retail, aseguradoras o la industria son fieles al mainframe. Y no lo van a abandonar así como así.

Pero… y naturalmente hay un “pero”, gran parte de las herramientas, procesos y cultura que rodea a estas aplicaciones, en su mayoría con muchos años a sus espaldas, impide que las organizaciones sean capaces de proporcionar una buena experiencia de usuario o incluso un buen producto o servicio. E incluso si lo consiguen, el ciclo de desarrollo suele ser demasiado largo para la velocidad con la que todo evoluciona hoy.

Hacer que las metodologías Agile y DevOps formen parte del software empresarial legacy

Evolución, no revolución

Por otro lado, los lenguajes en los que están escritos esos miles de millones de líneas de mainframe son, por ejemplo, PL/1 y, sobre todo, Cobol. Y aunque Cobol suene a antiguo, lo cierto es que la última versión es de 2014. Y cada año se escriben unas 5 000 millones de nuevas líneas de Cobol.

Es evidente que a Cobol le queda mucha vida, pero la necesidad de mejorar y modernizar el código con las nuevas funcionalidades de las últimas generaciones del lenguaje es cada vez mayor. Un código que funciona es increíblemente valioso para la empresa, pero hay que mantenerlo al día. Y es aquí donde está el reto.

Las nuevas generaciones de desarrolladores, como los millennials, emplean métodos muy diferentes (como Agile y DevOps) a los que se utilizaron para crear el código en su momento. Por ese motivo es necesario encontrar la forma de aplicar estos nuevos paradigmas al mainframe en general, y a Cobol de forma específica, para permitir el relevo generacional de los responsables de las aplicaciones legacy de las compañías (que se están acercando a su edad de jubilación en muchos casos).

Pero, como ya hemos visto, el deshacerse del código Cobol y sustituirlo por algo más “moderno” no es viable. Así que el camino de la “revolución” nos está vedado y solo queda la “evolución” hacia un método más moderno, que ofrezca una interfaz y un uso conformes a las metodologías Agile y DevOps y que permita realizar iteraciones mucho más rápidas del código que si se empleara el típico método en cascada (waterfall) propio del desarrollo para sistemas legacy.

La alternativa de Compuware

En esta situación de relevo generacional, no solo de la tecnología sino también de las personas y los métodos que la mantienen, existen soluciones para trabajar con los mainframes de forma mucho más ágil y eficiente. Al integrar herramientas populares en el proceso (Eclipse, Jenkins, Splunk…) es posible que equipos especializados en mainframe puedan colaborar con otros que no lo estén. Incluso si trabajan en otras plataformas. Para ello, hemos dividido el ciclo de vida de DevOps en tareas discretas y, para cada una de ellas, ofrecemos una o varias soluciones:

• Análisis. Con la ayuda de ISPW se consigue un desarrollo de aplicaciones más colaborativo, así como un análisis de impacto para ver en qué lugar afectan los cambios propuestos. Con Topaz for Program Analysis se pueden visualizar programas de forma gráfica, para entender mejor cómo funcionan, incluso si no disponen de una documentación fiable.
• Edición. A través de Topaz for Enterprise Data y Topaz Workbench se puede editar cualquier tipo de base de datos, así como el código. Todo ello en una interfaz de Eclipse, familiar para la mayoría de los desarrolladores.
• Compilación. Un simple clic en ISPW compila y enlaza el código de forma apropiada para el sistema y con la posibilidad de compilar en entornos de prueba.
• Pruebas y depuración. Con diferentes elementos de Topaz se pueden automatizar las pruebas y controlar la calidad del código. Xpediter, por ejemplo, es un depurador para mainframe, en entorno Eclipse.
• Despliegue. Se puede realizar en múltiples entornos a la vez, para garantizar una mejor sincronización de la aplicación. Incluso permite el despliegue directamente desde la interfaz móvil.
• Monitorización y auditoría. Esta parte tan importante del ciclo de vida se realiza con soluciones como Strobe y otras, para garantizar tanto el rendimiento como la seguridad y la calidad de los datos.
• Diagnóstico y tuning. Aunque a nadie le gustan los fallos en un software, lo cierto es que ocurren. Con Topaz Workbench y otras soluciones se reúne la información necesaria para poder resolver el problema cuanto antes y, con Strobe, se localizan los procesos que consumen demasiada CPU o recursos para corregir esos defectos y mejorar el rendimiento general de la aplicación.

La agilidad que el negocio gana es significativa e insufla nueva vida a los mainframes

Conclusión

La propuesta es clara y, por el momento, carece de competencia: modernizar el desarrollo en Cobol y PL/1 para mainframe con herramientas actuales hasta un punto en que las metodologías Agile y DevOps formen parte intrínseca del proceso de creación o modificación del software empresarial legacy. Al utilizar estos mecanismos, es posible que desarrolladores jóvenes, no versados en los sistemas legacy ni en sus particularidades, puedan utilizar interfaces y herramientas que conocen, para interactuar con ellos sin problema y sin tener que recurrir al antiguo método del waterfalling.

La agilidad que el negocio gana con esto es significativa e insufla nueva vida a los mainframes, cuya muerte hace décadas que se anuncia, pero que se resisten a desaparecer. Y lo que les queda.