Jacobo Lero, como cada fin de mes, saca su teléfono móvil de última generación (un smartphone de esos) para realizar algunas comprobaciones: ver si ha cobrado la nómina, cuanto lleva acumulado en la tarjeta de crédito y cuanto va a pagar este mes de teléfono.
Lo primero que hace es buscar la aplicación de su banco. La abre, introduce sus datos y una rueda dentada que gira le indica que sus datos se están descargando.
Jacobo es informático, un programador de esos. “Como ha cambiado todo.” Piensa. “¿Quien me iba a decir hace siete años, cuando acabe la carrera, que prácticamente no iba a necesitar un pc para todas estas cosas? La informática avanza tan rápido que en seguida todo queda obsoleto”.
Lo que Jacobo no sabe, bien porque nadie se lo ha contado, bien por que nunca se lo ha preguntado, es que la app que esta usando acaba de realizar una conexión con un servicio SOAP (ni siquiera REST) que a su vez ha conectado con un mainframe de la serie Z de IBM a través invento satánico llamado CICS Transaction Gateway.
Esta criatura del averno se encarga de llamar al vetusto programa COBOL que devuelve los últimos movimientos de una cuenta corriente.
Sí, Jacobo, un programa desarrollado en el año 1982 que todavía está en mantenimiento lee de un fichero VSAM (porque todavía no se han decidido a migrar esos datos a una base de datos relacional) la información que terminas viendo en tu móvil… El tiempo pasa rápido, Jacobo, pero no para todos. Muahahahahaha
¿Vas a hablar otra vez de COBOL? vamos, no me jodas.
Los jóvenes de hoy no parecen tener respeto alguno por el pasado ni esperanza ninguna para lo porvenir. Hipócrates (s. V AC-s. IV AC) Médico griego.
El COBOL es un lenguaje viejo, muy viejo. Seguro que todos habréis oido hablar de él y si no ha sido así, aquí teneis unas cuantas opiniones. Muchas de las cosas que se dicen de él son ciertas pero no entiendo los argumentos que insisten en acabar con él, simplemente, por ser viejo.
— Cobol
Hace un par de años hice un curso en Coursera sobre como construir una plataforma SaaS y me llamó la atención que el libro de texto que usaban como material de referencia tuviera en la portada una imagen del Acueducto de Segovia. En el interior, los autores explicaban que habían cogido esa imagen porque querían buscar un ejemplo de arquitectura duradera. El libro ahora se llama Engineering Software as a Service, cuando yo lo compré se llamaba Engineering Long-Lasting Software. Supongo que los autores recibieron críticas de las hordas coding-talibanes sobre los problemas que podría plantear para el futuro una aplicación Ruby on Rails que durase mucho tiempo pero yo aprendí una cosa: hay una parte de la comunidad que quiere hacer aplicaciones duraderas y estables en el tiempo.
Yo llevo diez años trabajando en proyectos con base tecnológica en COBOL y en contra de una de los argumentos generales anti-cobol el 90% de los proyectos que he realizado han sido de nuevo desarrollo. Es decir, que en estos diez años he participado en la creación de unas cuentas Nuevas Aplicaciones COBOL. Por supuesto que hay mantenimiento: la adaptación al mercado, a nuevas legislaciones , a nuevas políticas del departamento de sistemas,… implican modificaciones en los programas existentes. También hay desarrollo correctivo, no solo de errores incluidos en cambios recientes si no también de errores ocultos durante años.
¿Por qué las empresas siguen con COBOL y no cambian?
Los seres humanos estamos lleno de contradicciones. Por un lado nos gusta decir expresiones del tipo “si funciona, no lo toques” y por otro lado nos empeñamos en modernizar cosas que funcionan perfectamente simplemente porque son viejas. Los programas COBOL están presentes en bancos y aseguradoras de todo el mundo, además de en departamentos de sistemas de Ministerios españoles para los que la información es vital (Hacienda, Seguridad Social). Las conciliaciones bancarias, muchas operaciones de compraventa de valores, los procesos de verificación de los modelos de hacienda… están desarrollados en COBOL. ¿Creeis que la Agencia Tributaria tiene ganas de cambiar a Python simplemente por que el programa de verificación del modelo 347 está escrito en un lenguaje de los años 60? El testing de la migración de ese único proceso sería la leche. No hablemos ya de lo que supondría la renovación completa. Y no nos engañemos… “si funciona, no lo toques.”
La mayoría de las empresas que siguen utilizando COBOL en sus instalaciones lo hacen por una sencilla razón: Confían en su software que, aunque tenga errores, ya se encargan de irlo corrigiendo. Son conscientes de que deben estar en el mercado y abrazar las últimas tecnologías pero no pueden cambiar todo el software que llevan años desarrollando y manteniendo a un lenguaje más moderno simplemente porque el lenguaje en el que están codificados sus programas sea viejo. Conozco de primera mano las carencias del COBOL frente a algunos lenguajes mejor vistos (Java, .Net, Ruby, Objective-C,..) y se lo fácil que sería hacer algunas cosas que hacemos en COBOL en estos lenguajes pero aun con esto, tengo claro porque seguimos haciendo nuevos desarrollos en COBOL.
Aunque alguna excepción habrá (como la herramienta de consulta de inventario de El Corte Ingles) en la mayoría de las empresas donde se siguen usando estos servicios, la única justificación para realizar un cambio de lenguaje es que una consultora puede pillar un buen pellizco. Las limitaciones del lenguaje no suelen ser un gran problema y cuando lo son, estos mismos sistemas pueden convivir en perfecta armonía con otros servicios desarrollados en Java, por ejemplo.
El pacto con el Diablo… International Business Machines.
Y en todo debate sobre COBOL siempre termina saliendo IBM. Aunque no sean hermanitas de la caridad tampoco son los responsables de la perpetuación de este lenguaje. Es más bien una simbiosis: las empresas con sistemas basados en tecnología mainframe necesitan a IBM y IBM las necesita a ellas. Estoy convencido de que si algún día IBM decidiera dejar los mainframe igual que hizo con los sobremesa, todas las empresas con mainframes se unirían para pedirle a alguna otra empresa que se hiciera cargo del hardware y de la evolución de su software porque si, amigos míos, el software de los mainframes evoluciona y aunque no lo creáis está a la última: casi todos los mainframes tiene desde hace tiempo una pequeña partición UNIX, accesible desde el sistema operativo Z/OS y que le permite usar prácticamente cualquier servicio que corra sobre UNIX.
De lo que si es responsable IBM es de haber utilizado Java para dotar a los mainframes de todo aquello de lo que adolece COBOL. Con .Net también se puede acceder a la capa de servicios de un mainframe pero lo más habitual (y si miras el portafolio de productos de IBM lo entenderas) es que estas aplicaciones web estén hechas en Java. Ya veréis, dentro de unos años, cuando se hable de acabar con esos viejos “ear´s” programados a finales del siglo XX en Java…
Conclusion
El COBOL es una realidad. En nuestro día a día hay un sin fin de procesos que ejecutan programas COBOL sin que nosotros lo sepamos. No voy a negar que el COBOL es viejo, feo, con una pésima interfaz de desarrollo, con muchísimas limitaciones en comparación con otros lenguajes pero funciona, es mantenible y permite nuevos desarrollos. La renovación ira llegando poco a poco, a medida que unas empresas vayan absorbiendo a otras y en la fusión se decida utilizar la plataforma con el lenguaje más moderno, pero será lenta.
Yo no digo, aunque haya escrito sobre ello, que el backend de la próxima red social de moda se haga en COBOL, pero que va a seguir con nosotros durante mucho tiempo es seguro… y no hay nada malo en ello, creedme.
