Llegamos a ustedes gracias a:



Reportajes y análisis

El futuro de COBOL es ahora

[19/01/2021] A principios de la pandemia del coronavirus del 2020, el gobierno del estado de Nueva Jersey tenía una necesidad de personal de TI muy específica -y recibió mucha más publicidad que la que suelen recibir los movimientos de contratación. La recientemente aprobada Ley CARES había añadido 600 dólares a los pagos semanales por desempleo en todo el país, pero el arcaico software de desempleo de Nueva Jersey, escrito en COBOL, no podía incorporar el dinero extra sin reprogramar, y no había nadie en el personal capaz de hacer el trabajo.

El mencionado incidente significó echarle un vistazo público a un pequeño y sucio secreto dentro de TI, que hay miles de millones de líneas de código escritas en COBOL que aún ejecutan aplicaciones de misión crítica, pero que la gran ola de programadores entrenados en COBOL que escribieron todo ese código están envejeciendo fuera de la fuerza laboral. Esa historia no es nueva, escribimos sobre ello hace ocho años, y once años antes de eso.

Pero la era COBOL ha persistido hasta el día de hoy, y muchos sistemas heredados han seguido confundidos y sin saber bien qué hacer, solo parcialmente entendidos por las empresas que dependen de ellos, luego de que los costosos proyectos "big bang" para reemplazarlos fracasaran. Ahora muchos expertos están pensando en nuevas formas de enfocar el problema que presentan las aplicaciones COBOL y de desarrollar las habilidades necesarias para trabajar con ellas.

COBOL es más fácil (y más difícil) de lo que piensa

Uno de los problemas de la conversación en torno a la brecha de habilidades de COBOL es que a menudo asumimos la existencia de una raza distinta de persona conocida como "programador de COBOL", como si dicho lenguaje fuera algo tan diferente del resto del mundo de la programación como para necesitar su propia casta especializada. Pero ese no es el caso.

"COBOL es una pista falsa en todo este debate", señala Mark Cresswell, CEO de LzLabs. "Es solo una sintaxis para expresar las reglas de negocios. La mayoría de los programadores son políglotas. Puede tener una especialización o ser mejor en un lenguaje u otro, pero nunca se va a decir a sí mismo, 'Bueno, no voy a hacer C++ porque soy un programador de Java'. COBOL, como lenguaje, no es diferente de cualquier otro lenguaje, en realidad. Tiene su propia idiosincrasia, pero eso es algo que todos los lenguajes tienen.

Tengan en cuenta que el COBOL (que fue creado en la década de 1950) fue diseñado específicamente como una forma para que los no especialistas programen las computadoras que comenzaban a entrar en el mundo de los negocios. "El BOL es un lenguaje orientado a los negocios", señala Emad Georgy, CTO de Georgy Technology Leadership. "Está pensado para ser fácil de leer y de entender. Creo que hay un gran temor a su alrededor porque funciona con algunos sistemas de misión crítica, pero en realidad, como programador, es muy fácil de aprender".

COBOL no está construido alrededor de la programación orientada a objetos y carece de características heredadas, así que aquellos que se han dedicado a los sistemas modernos tendrán más facilidad para aprenderlo que una vieja mano de COBOL tratando de aprender Java o C++. (Aunque existen versiones "modernas" de COBOL orientadas a objetos, no se usan en los sistemas heredados donde realmente encontrarás COBOL de producción en estado salvaje).

En realidad, cuando hablamos de una "escasez de habilidades de COBOL", suele ser la abreviatura de algo más complicado. Podría, por ejemplo, descargar GnuCOBOL y empezar a retocar el código que se ejecutará en una máquina Linux familiar, pero eso no lo prepararía para la experiencia de trabajar con código COBOL de producción en su hábitat natural.

"Aprender COBOL es fácil, pero sus aplicaciones requieren una experiencia poco común con tecnología de legado, como los sistemas de bases de datos IMS y CICS de IBM", señala Michael Yurushkin, CTO y fundador de BroutonLab. "El principal desafío no es aprender el idioma, sino tener la experiencia en tecnología que tiene muchas décadas de antigüedad".

Cresswell de LzLabs destaca que el moderno conjunto de herramientas en las que han confiado los desarrolladores durante el último decenio, simplemente no se aplica a los entornos mainframe. "Si quiero compilar y probar un programa, no presiono la pequeña flecha verde de la barra de herramientas", indica, "sino que ejecuto una cosa llamada trabajo por lotes que hace una compilación y un enlace. Cuando se trata de configurar un entorno de prueba, no puedo simplemente hacer girar un contenedor en mi estación de trabajo para probar mis cambios. Tengo que hablar con los administradores de sistemas para configurar las particiones con subsistemas y configuraciones ocultas. Todo esto alarga el ciclo de desarrollo y es tan idiosincrásico que es muy difícil de entender para alguien que está acostumbrado a desarrollar a la velocidad de Internet en plataformas de nubes".

Y si se trata de una aplicación de larga duración y de misión crítica, desenredar la lógica del programa puede terminar siendo su principal desafío. "Todos estos sistemas han sido creados durante décadas", indica Ben Stevens, ingeniero principal y arquitecto de soluciones en Art+Logic, que trabajó durante años en agencias gubernamentales que dependían de COBOL. "Si no conoce esos detalles, conocer el lenguaje no va a servir de mucho. Terminará convirtiéndose en un proyecto de ingeniería inversa en el que usted hace las de arqueólogo. Incluso si conoce el lenguaje, es como si estuviera leyendo esos textos antiguos sin ningún contexto: "Ok, puedo traducir esto palabra por palabra, pero ¿qué significa?".

Desarrollando habilidades de COBOL dentro de la organización

Imagine que su organización tiene una base de código COBOL de misión crítica. ¿Cómo puede asegurarse de que tiene acceso a los conocimientos que necesita -en términos de programación y entornos mainframe, así como la lógica de negocios subyacente- para mantener el sistema en funcionamiento, al menos a corto plazo? Una estrategia es trabajar en el desarrollo de habilidades internamente. Eso no significa contratar programadores de COBOL recién salidos de la universidad (ya que no existen) ni retener a los barbas grises a tiempo completo cuando prefieren retirarse.

"Mi objetivo para mi equipo sería no enseñarles COBOL, sino mi sistema", sostiene Georgy. "El contexto es clave. Quiere que aprendan lo suficiente de COBOL, pero probablemente no hará ningún proyecto nuevo en COBOL, así que tiene que ser juicioso en cuanto al nivel de inversión".

Para ello, deberá emparejar a los desarrolladores internos interesados con los recursos que tenga a mano, con un enfoque láser en las necesidades particulares de su negocio. Esto puede implicar que los desarrolladores más antiguos que han trabajado en la aplicación en cuestión -tal vez todavía parte del personal, tal vez traídos de vuelta como contratistas- asesoren a los más jóvenes.

"Me gusta tener casos de uso muy específicos o problemas que estamos tratando de resolver con la capacitación", comenta Georgy. "Como, 'Miren, ustedes tres, van a trabajar con este profesional ya jubilado que va a venir y pasar unas horas cada semana. Nuestro objetivo para fin de mes es resolver este problema'".

Los desarrolladores tendrán que seguir una educación más general en COBOL y en programación en mainframe para complementar lo que aprenden sobre sus propios sistemas. IBM tiene un interés evidente en mantener una masa crítica de programadores COBOL en el mercado, y ofrece una gran variedad de recursos educativos, como los cursos gratuitos de programación COBOL y las certificaciones de programación en mainframe. Tomar estos cursos ocupará el tiempo del personal, pero puede que la inversión valga la pena.

"Nuestros clientes también necesitan recordar que mantener las aplicaciones de misión crítica que han sido optimizadas durante las últimas décadas requiere un mantenimiento", señala Barry Baker, vicepresidente de software en IBM Z. "Aunque puede ser fácil tomar atajos o pensar que se la puede pasar sin invertir en talento, eso es simplemente una receta para el desastre".

No tenga miedo de pedir ayuda

Sin embargo, puede que se encuentre en una situación en la que simplemente no tiene los recursos internos para hacer frente a su crisis COBOL. En esos casos, tal vez quiera recurrir a una consultoría externa que se especialice en trabajar con dichos sistemas. Pravin Vazirani es el vicepresidente de operaciones de Chetu, una empresa que hace precisamente eso, y las situaciones en las que se les pide ayuda suelen ser bastante graves.

"Ha habido muchos casos en los que el desarrollador principal de la plataforma heredada ya no está en la empresa", comenta Vazirani. "Y el mantenimiento del sistema lo hace un desarrollador que tiene un conocimiento limitado, pero la suficiente experiencia para ejecutar con éxito las aplicaciones COBOL. Esto sucede normalmente en lugares que están ejecutando plataformas heredadas con poca o ninguna documentación adecuada".

Vazirani cree que muchas organizaciones, especialmente las más pequeñas, ahorrarán a largo plazo utilizando terceras empresas especializadas como la suya. "La experiencia en desarrollo de COBOL no es tan común fuera de las empresas de desarrollo personalizadas, por lo que, en muchos sentidos, contratar a una empresa de desarrollo eficiente y de bajo costo puede ser más rentable para las empresas en lugar de contratar y cultivar el talento interno", indica. "Y es posible que muchas empresas estén buscando una transición fuera de sus aplicaciones COBOL en un futuro cercano o lejano, por lo que se haría más hincapié en la contratación de talento interno para hacer frente a las necesidades futuras de la empresa, mientras que un tercero se encarga del sistema actual".

Mirando hacia el futuro de COBOL

¿Y cómo es el futuro de las organizaciones que dependen de COBOL? Misu Tasnim, directora ejecutiva del servicio digital del Departamento de Salud y Servicios Humanos de los Estados Unidos, esbozó una respuesta. Ella es parte de un grupo que se ha enfocado en la migración de las agencias gubernamentales lejos de los sistemas mainframe anticuados, y su cliente actual es el Centro de Servicios de Medicare y Medicaid. Es una misión complicada: estos sistemas pueden ser un poco torpes, pero funcionan y un despliegue fallido podría ser desastroso. Los clientes gubernamentales (como muchos del sector privado) se ponen nerviosos ante los intentos de reemplazar sistemas anticuados de golpe.

Tasnim señala que "la forma en la que el gobierno se ha modernizado es poniendo un contrato de 100 millones de dólares por 10 años y contratar a una gran empresa, porque solo éstas saben cómo navegar por agencias de ese tamaño y complejidad, y tienen el personal para hacerlo. Lo que hacen es venir, quemar 100 millones de dólares y luego, una década más tarde, no tiene un sistema moderno".

En su lugar, el equipo de Tasnim está trabajando de forma incremental. "Hemos decidido que va a ser primero la API y la nube", señala, "pero no puede mover todo este monolito hacia la nube en un día". Algunos componentes del sistema se están convirtiendo a Java, mientras que otros todavía se ejecutan en la computadora central, y sin duda lo harán durante algún tiempo.

De hecho, prácticamente todos con los que hablamos para este artículo vieron alguna variación en esta técnica como el camino a seguir: la funcionalidad se desprenderá de los sistemas heredados pieza por pieza, con el código reescrito y el código COBOL corriendo en paralelo. Vivimos en un mundo de sistemas distribuidos, con microservicios en contenedores vagamente acoplados que se comunican a través de APIs, y las aplicaciones COBOL de la computadora central pueden participar en ese moderno ecosistema.

Muchas aplicaciones de COBOL ya lo hacen, con diversos grados de éxito. Steve Hassett, presidente de GT Software, un proveedor de herramientas de integración de mainframes, señala que muchas historias de horror que se escuchan sobre los fracasos de COBOL, como la situación de desempleo en Nueva Jersey, pueden en realidad tratarse de intentos de integrar mainframes con sistemas más modernos. "Cuando dicen que los sistemas están sobrecargados es probablemente atribuible a todas las conexiones con los otros sistemas que fueron diseñados para el 1% del volumen que estaban viendo", explica.

La compañía de Hassett es una de las muchas en la industria que buscan formas de hacer bien estas integraciones. "Acepte su sistema de mainframe COBOL heredado, entienda en qué es bueno y dele más de eso para hacer", indica Hassett. "No intente quitar las cosas en las que solo está haciendo el procesamiento de transacciones repetitivas y luego construir sus nuevas capacidades en la nube, aun conectándose a un sistema moderno basado en la nube". Si está tratando de hacer la contabilidad en un banco y hacer un seguimiento de los depósitos, puede hacerlo muy bien en COBOL. Si quiere iniciar un pago en tiempo real, probablemente necesite conectarse a un sistema externo". GT Software provee herramientas para ayudar a los clientes a hacer esas conexiones, usando un GUI de arrastrar y soltar.

Mark Cresswell de LzLabs aborda el problema desde un ángulo diferente. Han desarrollado una capa de virtualización que sirve como un "mainframe definido por software" y permite que el código COBOL se ejecute en un entorno Linux estándar. "El programa puede hacer llamadas a archivos usando una sintaxis de acceso a archivos mainframe", anota Cresswell. "Puede acceder a bases de datos relacionales usando una sintaxis de bases de datos relacionales de mainframe. Puede interactuar con entornos en línea usando la misma sintaxis que si se ejecutara en un mainframe. Pero debajo de las cubiertas solo está usando código abierto todo el tiempo, lo que significa que puede contenerlo y hacerlo fluir a través de un pipeline CI/CD de una manera estándar".

Contenerizar la aplicación es el primer paso para partir trozos de funcionalidad y reescribirlos con lenguajes más modernos, manteniendo algunos componentes como COBOL según sea necesario. De hecho, la tecnología de LzLabs le permite port over sobre binarios de sistemas mainframe -algo que a menudo es necesario para los sistemas heredados de larga duración. "Hay muchas empresas que no pueden encontrar de forma fiable su código fuente para estas aplicaciones, indica Cresswell. "Es como una caja negra. Pueden identificar que 30 o 40 aplicaciones dependen de él, así que tienen que tenerlo. No están muy seguros de lo que está haciendo".

El momento de aprender COBOL es ahora

Este es el futuro de COBOL. Estos sistemas no serán reemplazados en uno o dos años con algo brillante y nuevo, como resultado de un proyecto triunfante y transformador. Más bien, las aplicaciones COBOL se desvanecerán lentamente, con algunos componentes reemplazados, pero otros todavía zumbando durante años, ya sea en el hardware de la computadora central, o tal vez en entornos virtualizados.

Las empresas que dependen de las aplicaciones COBOL deben dejar de pretender que la era COBOL terminará en cualquier momento, y empezar a tomar decisiones para el futuro a corto y medio plazo. O bien necesitan presupuestar los servicios de consultoría externos que necesitarán, o empezar a desarrollar esas habilidades internas, identificando a los desarrolladores interesados en recibir capacitación/orientación sobre la lógica de negocio de los sistemas heredados y sumergirse en la estrafalaria sintaxis y el entorno operativo COBOL.

No todo el mundo estará interesado, pero para algunos desarrolladores COBOL representará un desafío intrigante.

"Aprender nuevos lenguajes de programación -y específicamente aprender lenguajes de programación que son significativamente diferentes de los que ya conoce- es una gran manera de exponerse a nuevas ideas y nuevas formas de pensar", sostiene Mike Loukides, vicepresidente de estrategia de contenido de O'Reilly Media. "Desde ese punto de vista, COBOL encaja perfectamente. Es diferente, se ve extraño, tiene un montón de ideas importantes sobre la computación financiera embebidas en él y probablemente usted no ha estado expuesto a esas ideas si es que se ha limitado a utilizar JavaScript y Python".

Aquellos que quieran dar el salto de COBOL tendrán una habilidad rentable en un nicho importante en los años venideros.