Néstor López: experiencia en la reingeniería de mainframes

En el segundo artículo de la serie “Experiencias de Graduados”, compartimos la experiencia del CC. Néstor López en la reingeniería de mainframes para el procesamiento de apuestas de juegos de azar en el Instituto Provincial de Lotería y Casinos de la Provincia de Buenos Aires, que comienza con una serie de reflexiones preliminares.

Reflexiones: ¿Por qué no divulgamos casos de éxito?

Hace unos meses, Patricia Bazán en su rol de directora de Willay envió un correo a algunos colegas informáticos en el que nos decía “… muchos de ustedes hacen a diario cosas que sería interesante trasmitir a nuestros graduados…”.

Me sentí halagado por la invitación e intenté conseguir que algunos compañeros con los que compartí proyectos interesantes me ayudaran en su divulgación a través de esta generosa invitación que había recibido. Mis intentos fueron en vano y eso me llevó a la pregunta que encabeza este apartado. Creo que en los ámbitos académicos las cosas son diferentes, pero me consta que en las empresas privadas y estatales se desarrollan proyectos de software interesantes que no se comunican. Será que estamos muy ocupados o simplemente que no nos gusta documentar, pero…

Más allá de invitar a todos los colegas a reflexionar sobre eso, me quedaban dos alternativas: elaborar algo por mi cuenta o quedar en deuda con Patricia. Hasta hoy hice esto último, pero sentí remordimientos y acá estoy tratando de divulgar algo que espero resulte interesantes a los lectores.

En el ejercicio de mi profesión, 36 años como “programador de computadoras” o “desarrollador de software” (como prefieran denominarme) pasé de utilizar los “mainframe” IBM a la “novedad” de las PC y luego a las redes basadas en UNIX y/o Windows; de programar en algunos lenguajes hoy en desuso, al mundo de los lenguajes orientados a objetos y los “frameworks” de la tecnología Web; de usar solo archivos planos a las bases de datos primitivas, las relacionales y ahora también las “NO SQL”. En fin, creo que me fui de tema, la idea no es contar mi historia, sino algún proyecto en que tuve la suerte de participar y que esas experiencias sirvan en algo a mis colegas ¡Allá vamos!

Haciendo una reingeniería de un mainframe

Tal vez será por mi experiencia acumulada o tal vez solo por cuestiones fortuitas, pero, en los últimos años, me tocó participar con distintos roles en varios proyectos de reingeniería de aplicaciones de “mainframe”.

Si se me permite un consejo para los más jóvenes: siempre busquen analogías entre las herramientas que vayan utilizando, aunque no resulten ser muy académicas. En mi caso, por ejemplo, encontré parecidos entre CICS y los servidores de aplicaciones Web o similitudes entre la forma en que maneja una sesión el núcleo Natural bajo CICS y la JVM de Java. Seguramente un alto porcentaje de los lectores tengan que “googlear” Natural o CICS para saber qué son esas cosas, pero pueden intentar sus propios paralelismos entre tecnologías que utilizaron (puede ser entre Java y Phyton o C++ y Rubi, o entre frameworks como Struts y Symfony).

Retomando mi relato, contaré una de esas reingenierías en la que me tocó participarS se trata del procesamiento de apuestas de juegos de azar en el Instituto Provincial de Lotería y Casinos (IPLC) de la Provincia de Buenos Aires. Como suele pasar con los sistemas en producción, la vorágine y los tiempos escasos para implementar nuevas funcionalidades, nos llevan a tomar ciertos “atajos”, desaconsejables pero inevitables. Esto es, al momento de comenzar con el proyecto de reingeniería, cada juego de azar comercializado por el IPLC, tenía sus propios programas escritos en lenguaje COBOL y ejecutando en un sistema operativo Z/OS 390 IBM (otras palabras para googlear para muchos). Las funciones que proveían estos eran muy similares, pero, –ahí viene el atajo-, ante cada juego nuevo que aparecía se tomaba como base alguno existente similar, se modificaba sólo lo necesario y… Listo. Creo que no hace falta que explique los trastornos derivados de esta operatoria para el mantenimiento de estos sistemas.

Ante la decisión de cambiar la plataforma operativa buscamos unificar todos los procesos en una sola aplicación. Comenzamos por diseñar un único modelo de datos en una base relacional y definir las actividades (tareas) que componían el “workflow” común al procesamiento de cada juego (ej.: aceptar las apuestas que se realizaron, determinar ganadoras y perdedoras según la reglamentación del juego, liquidar deudas y pagos para los agentes autorizados que los comercializan, generar los movimientos contables y administrativos necesarios, etc.).

No hay en todo lo antedicho ninguna idea genial ni desafío titánico que justifique tanta cháchara de mi parte, ya que llevar a cabo un desarrollo como este, sólo requiere que los participantes del proyecto tengan el “know how” del negocio y sepan aplicar metodologías conocidas del desarrollo de software. Es decir, lo que contaré en esta nota no pasa por brindar detalles del proyecto en cuanto a software, sino a divulgar ideas que creo son importantes para lograr que un proyecto de reingeniería llegue a buen puerto.

Creo (esto es discutible) que el principal obstáculo a vencer en la reingeniería de “mainframes” hacia otras plataformas es más “operativo” que de ingeniería de software. Las instalaciones que se basan en este tipo de arquitecturas se componen de áreas donde los empleados se especializan en tareas que no tendrán alguna función equiparable en la nueva plataforma. Para citar un ejemplo concreto, a pesar de existir software que permite automatizar los procesos por lote a ejecutar, generalmente las organizaciones cuentan con un grupo de gente que ejecuta las tareas referidas y verifica sus resultados. Como en todo cambio, es fundamental considerar el impacto laboral que producirá en la organización.

En nuestro caso, un grupo de operadores ejecutaban las tareas cada día, usando de forma eficiente las herramientas interactivas que proveía el sistema operativo (JCL y SDSF particularmente -sigo mencionando herramientas poco conocidas-) dándoles un cierto ordenamiento para los procesos y su control (mediante reportes), con la finalidad de anticipar errores. Las tareas (Jobs) que se ejecutaban tienen una relación directa con el programa de sorteos semanales de los juegos y los horarios comprometidos para su resolución. Como ejemplo: los premios a pagar deben estar determinados a lo sumo una hora después de finalizado cada sorteo de quiniela, todas las noches debe estar generada la información a enviar al banco para debitar y/o acreditar a cada concesionario en su cuenta lo que corresponda a recaudación y premios del día, etc. El orden entre las tareas de cada sorteo también es importante.

Ante este panorama nos propusimos que, más allá de la resolución del “qué se debe hacer” en cada juego, lo primordial erael “cómo facilitar la operatoria diaria”. Por eso primero nos abocamos a modelar el calendario de sorteos y las actividades involucradas en su procesamiento. Contar con información configurable de días y horarios de sorteos y actividades, la dependencia entre estas, etc, permitiría que la aplicación a construir pudiera brindar cierta “inteligencia” que guiara y facilitara la tarea del personal. Para citar algunos ejemplos de la información que íbamos a modelar:

• hay un número de sorteos diarios de quiniela en distintos horarios preestablecidos;
• hay otros juegos con uno o dos sorteos semanales;
• la tarea de recibir el archivo con las apuestas de quiniela que se aceptaron se debe llevar a cabo 15 minutos antes de realizarse cada sorteo, pero en juegos semanales (Quini-6 por ejemplo), esta misma tarea debe realizarse cada uno de los días previos al sorteo también;
• al finalizar un sorteo y ser ratificados los números favorecidos mediante un acta, se puede comenzar la tarea que determina apuestas ganadora y perdedoras. Esto sucede generalmente unos pocos minutos después de confeccionarse el acta, y, por supuesto, deben haberse recibido las apuestas en juego.

Todos estos datos fueron estructurados en un grupo de tablas de la base de datos al que denominamos “plantilla de eventos semanales”. La aplicación a partir de este “template” es capaz de generar los eventos futuros y sus actividades, así como brindar una “hoja de ruta” a los operadores encargados de ejecutar los procesos con cada actividad programada junto a botones operativos (ej.: ejecutar, ratificar, deshacer, etc.) que se habilitan dependiendo de su estado y el de sus tareas precedentes. Además, cuando la actividad produzca información de resultados, se puede visualizar el reporte generado para un control del proceso.

En resumen, luego de diseñar el “template” y el “motor” operativo de la aplicación, nos pudimos centrar en desarrollar el “qué”, o sea, las actividades en particular. Por ejemplo: no es igual determinar ganadores de la Quiniela, o el Loto, o los billetes de lotería, pero en todos los casos, resultan tickets ganadores y perdedores con atributos comunes a todos los juegos, sin importar su naturaleza.

Conclusiones

Unos meses después de comenzar con el desarrollo y teniendo una versión prototipo de la nueva aplicación, se convocó al personal que ejecutaba las tareas en el sistema a reemplazar para tener una primera evaluación.

Este fue el comentario de uno de ellos (casi textual): “es lo mismo que hacemos hoy pero más lindo”. El lector dirá que esto es sólo una anécdota, pero su valor es enorme porque demuestra que el camino elegido fue el correcto porque, en general, la gente se resiste a los cambios y más aún cuando este es muy grande.

Varios meses se emplearon para el diseño y casi un año para implantar la primera versión con un juego importante del IPLC (Quiniela Plus). A partir de ese hito (mediados de 2007), se fueron incorporando progresivamente el resto de los juegos On-Line (apuestas capturadas por las terminales operadas por la empresa Boldt S.A. antes y luego por Provincia.net) hasta 2010 y, en los años siguientes, se agregaron juegos de otro “tipo” (los denominamos pre-impresos, un ejemplo es el TeleKino, los de resolución inmediata o “raspaditas”, etc.).

Los juegos de azar cambian, ya sea para otorgar otros tipos de premios o aceptar variantes en su forma de apostar, etc. Esto ha requerido  adaptaciones, pero, en general, los costos de mantenimiento han sido bajos.

Por último, no quiero cerrar esta nota sin mencionar a quienes compartieron conmigo el desarrollo del proyecto: Martín Craviotto, Ezequiel Maceira, Pablo Grimaut, Germán Mahon, Juan Pedro Diez y Miguel Busso.