Bill Curtis, ahora jefe de análisis de software y la empresa de medición de CAST, ha dicho que los bancos deben quedarse con las antiguas aplicaciones COBOL ya que estas no tienen los problemas de seguridad y desarrollo que aparecen con los nuevos lenguajes como Java.
|
etiquetas: cobol , java , bancos , análisis 
Lo que pasa es lo que pasa siempre: A ver quién es el chulito que migra el HOST ese que lleva 22 años encendido.
Edit: Todo lo demás, son excusas.
La verdad es que el artículo es un simple recordatorio del estado en el que se encuentran los sistemas informáticos del sector bancario.
Hay algo que no entiendo, ¿por qué no se olvidan de "migrar" el código existente y se dedicar a hacer un buen análisis de los procedimientos implicados para que así sea fácil realizar la programación en cualquier lenguaje? Me refiero, llevan décadas "migrando" el código y dedicando muchísimos recursos al asunto, no entiendo por qué siguen teniendo esta dependencia de COBOL/FORTRAN, la verdad.
La cuestión entonces sería, ¿me permite la plataforma y sistema actual atender correctamente a todas mis necesidades actuales? ¿Puedo seguir actualizando mi sistema para acomodarlo a nuevos procedimientos o cambios en los procedimientos existentes?
¿Se puede seguir trabajando con una plataforma AS/400 con un código COBOL escrito hace 30 años y remodelado a lo largo de los años?
Porque seguramente esté arrastrando código frankenstein que esté generando errores o consumo de recursos (CPU, RAM, tiempo de procesamiento) exagerados.
Porque seguramente cada mínima modificación que tengan que hacer sea carísima (y a lo mejor, de ahí viene que todos los procesos bancarios sean tan lentos y tediosos).
Porque el coste de mantenimiento tiene que andar por las nubes (¿dónde encuentras tú un experto en COBOL hoy en día?)
Hay muchos motivos. Otra cosa es que no quieran gastarse el dinero que cuesta rehacer el sistema porque prefieran pan para hoy.
Aparte que el lenguaje esta mas que trillado y los posibles debug estan mas que conocidos y catalogados. Puesto que no ha cambiado apenas el codigo , no hay errores nuevos por conocer.
Ademas te puedo presentar a mas 15 programadores entre ellos varios expertos. Aun se enseña el lenguaje, y en estos momentos hay empresas que realizan cursillos para enseñar a sus nuevas incorporaciones.
Y respecto a las modificaciones y a donde encontrar expertos, no solo existen aún veteranos en activo, viejos guerreros de los 80 (y puede que hasta alguno de los 70) sino que quienes tienen software en COBOL se encargan de formar más para no quedarse sin gente. Te lo digo como alguien que aprendió a programar con COBOL hacia 1980 y que muy probablemente va a volver a trabajar en COBOL de nuevo este año después de haberlo dejado hace unos 25 años o más... vamos, aún usábamos GOTOs a mansalva
Un buen paralelismo creo que sería con los editores de texto. A día de hoy cualquier editor de texto te permite hacer 800 cosas, desde formatear y maquetar texto hasta diseñar diagramas pero si tus necesidades únicamente son de formateo de texto seguramente cualquier editor de texto de los 80 cubra todas tus necesidades con un consumo ínfimo de recursos. Con los programas de gestión pasa lo mismo: si tus necesidades son las mismas que hace 20 años (y en la mayoría de casos, al igual que con los editores de texto, lo son) hay muy pocas soluciones modernas que sean más óptimas que las antiguas.
Como anécodta personal recuerdo la primera empresa para la que trabaje que estaba migrando todos sus programas de Prolog a un lenguaje moderno (velazquez, actual velneo) y no había ni un solo cliente que no se quejase de que los programas nuevos en sus superservidores modernos iban más lentos que sus viejos y vetustos servidores con su software en Prolog. Por supuesto todos decían que era mucho más bonito el tener barras de progreso, interfaces gráficas, botoncitos... pero a la hora de la verdad todos trabajaban más lento que, a fin de cuentas, es lo que les importaba.
#17 ¿Un experto en Cobol? Sin levantarme de mi silla tengo a 2 enfrente. Si me levanto y me doy una vuelta por el departamento creo que son unos 20 (y eso solo en una empresa que, además, solo tiene una parte de sus sistemas en Cobol). Depende mucho del sector en el que trabajes pero expertos en Cobol hay muchos más de los que pueda parecer.
#17 Lo ganan los que están dentro y los pocos que se van incorporando. Es como un gremio, con un nicho de bastante seguridad como son los bancos y aseguradoras.
www.itworld.com/career/341879/cobol-will-outlive-us-all
Está pasando. El ser humano involuciona, ya no se entiende la tecnología, es como si las cosas funcionaran de un modo mágico. la gente de dentro de 100 años hablará de las maravillas de los Antiguos, y se maravillarán de ellas aunque hayan dejado de funcionar por falta de energía o de mantenimiento
El Java, C, C++ o lo que sea claro que puede hacer lo que hace el COBOL, el problema es que no hay huevos a tocar unos programas que llevan 20 años funcionando y tienen una red de interdependencias que no conoce ni el tato. El apagar un programita en COBOL puede arrastrar consecuencias en sistemas que ni se sospecha porque ni están documentados. Si a esto le añadimos que suelen mover el core del negocio y está relacionado con pasta, el COBOL va a durar tanto como el banco.
Esto es extrapolable a los sistemas (en el lenguaje que sea) que lleven 15 años o más. También han desarrollado una red de dependencias que nadie se atreve a desentramar.
Si no se quita el COBOL no es porque no se pueda, es que no hay huevos (que conste que yo tampoco me atrevería)
#43 lo mismo que decía Bill Gates yo ya lo tenía claro hace 25 años. Mi primera profesora de Cobol siempre tenía esa frase en la boca.
¿Navegando por meneame en horas de trabajo? Juan Manuel, pase por mi despacho mañana a primera hora
Al parecer el objetivo es empezar por un banco alemán si las pruebas de rendimiento obtienen los frutos esperados
Realmente nadie puede hacerlo con garantías y sobretodo nadie quiere asumir esas responsabilidades y riesgos. Los Mainframes de IBM sobre los que corre el Cobol tienen unos niveles de seguridad, eficiencia y funcionamiento a prueba de fallos absolutamente espectaculares, y no se equivoque nadie, son sistemas que se modernizan igual que todo lo demás, bueno, quizás algo más lentos, pero se modernizan, aunque los programas que llevan 40 años corriendo en ellos y que son el núcleo y corazón de auténticas corporaciones enormes no sean fácilmente modificables, ese "nivel" de integración con la lógica del negocio se ha perdido, cuando un programador actual de cobol y java pasan en 90% de su tiempo peleándose contra sus propias limitaciones y las de los lenguajes que utilizan (Java, sin ir más lejos, da trabajo en sí mismo, entre arreglos de fallos, softwares deficientes y demás, sin entrar siquiera en la lógica de negocio a grandes rasgos o ser capaz de presentar algo presentable en pantalla).
Me lo dijo una vez un jefe de informática de una empresa, El Cobol a nadie le gusta excesivamente, se ve antiguo y feo, pero funciona, joder que sí funciona, y el 90% de la lógica vital del negocio está en él. ¿Quién va a poner su trabajo en peligro por tener cuatro colorines más y acceso Web si no es 100% vital para la empresa? Sobretodo cuando el acceso Web lo puedes tener igualmente parcheando esos Coboles y buscando soluciones alternativas sin cambiar una línea del código "obsoleto", transformando el Java en un simple "frontend" del viejo y feo Cobol, que sigue siendo donde corre lo importante y que no puede fallar.
Os tocará la moral a los de Java, pero las cosas son como son.
Parece que al final me tendré que tragar mi orgullo y aprender cobol
(con lo feliz que era con C, Java, PHP, Python, Nodejs, ...)
Que digan que no tienen ni puta idea de como funcionan los programas que tienen hechos, o que costaria mucho la creacion de cero de programas mas modernos, pero que no digan sandeces.
De hecho, el mantener COBOL porque no tienen ni puta idea de como funcionan sus sistemas les hace a la larga tener muchos mas problemas. La migracion a java les puede durar 5 o 6 años, con un buen plan y gastandose el dinero en buenos equipos (no en consultoras). Mantener COBOL les va a salir mucho mas caro y problematico a la larga. Pero ellos sabran (o quiza el problema es que no saben...)
De todas formas, como comentáis, ni con un bomba nuclear se tumba algo en COBOL.
Pero no os creáis, que se va haciendo, ¿eh?
Lo que pasa es que "si funciona, no lo toques". No saben cómo funcionan sus programas, sólo que funcionan, y rehacerlos en otro lenguaje sería muy costoso y aparecerían errores nuevos, algo normal al traducir algo de un lenguaje a otro.
Por cierto, el tío del informe no tiene ni pajolera idea de Cobol. ¿600 líneas un programa o rutina COBOL? En esas líneas entran poco más que comentarios, declaraciones de entorno, constantes, variables y unas pocas líneas de proceso. Un programa de 600 líneas es sencillísimo. Yo he trabajado con alguno de 30.000 líneas.
Lo que les faltaba a los bancos, atarse a SAP.
www.youtube.com/watch?v=E3418SeWZfQ
Al final es coste de migrar sistemas de este tipo se dispara, porque no es solo el software de la aplicación si no hardware, migración de datos, tests....
Y la justificación de la P.O.O. no me sirve, hay otros lenguajes orientados a objetos... incluido el PHP. Tarde o temprano las grandes empresas se darán cuenta de los costes brutales que están asumiendo por apostar por el Java y se pasaran a PHP, Ruby, Python...
#58 "Mantener COBOL les va a salir mucho mas caro y problematico a la larga"... por qué? Eso me suena a dogma que no se puede demostrar. En un gran empresa, Java tiene sentido para lo que no puedas hacer en Cobol (servicios web, comunicación via xml, ...), y aun así creo que hay opciones más sencillas.
Aparte de eso, suele haber una experiencia muy desastrosa en el proceso de retirada de aplicaciones. Apagas una y se caen 10 que dependían de ella, directa o indirectamente.
Dónde trabajé durante años, toda la planta está almacenada en un sistema mainframe (tan moderno que ni siquiera incluye DNI para identificar al propietario, eso hay que ir a buscarlo a otro sistema) y el resto de los sistemas de la compañía han crecido a su alrededor.
El cambiar esto, significa al menos, volver a probarlo todo. En el peor de los casos, modificar cientos de aplicaciones que también han evolucionado y crecido de una manera similar.
Luego hay una segunda derivada, un poco más cachonda. En su día y con el efecto 2000 hubo que recuperar a algún dinosaurio de IBM para modificar programa en ensamblador del OS/360 (ni me acuerdo que CPU llevaba)
Había dos teorías para justificar aquellos programas en ensamblador:
- Eficiencia. Eran programas muy rápidos, adecuados a las soluciones HW de su época.
- Hemos perdido los fuentes y no han quedado más cojones que desemsamblar y modificar aquí.
Cada cual que elija la que más le guste.
Ahora mismo SAP es, te guste o no, una plataforma super potente.
Si haces como los mainfraneros, es decir, te prohíbo el SQL dinámico, te corto todas las transacciones que duren más de 2 segundos de CPU, para los sistemas 7x24 todos los días dos horas para hacer la copia de seguridad, te hago yo estable hasta un Windows Vista.
A lo que voy, cualquiera que entienda de Java ni se plantea sustituir COBOL con JAVA. Es absurdo comparar 2 lenguajes diseñados para cosas diferentes. Soy de los que piensan q ya va tocando sustituir COBOL porque por mucho que diga este tío tiene que haber soluciones mejores, pero como ya han dicho por ahí a ver quién es el guapo que cambia algo que esta hiperdepurado y que se conoce tan bien que todos los fallos que da son predecibles y controlables. A lo anterior añadiremos el insignificante detalle de que esas aplicaciones manejan la pasta.
De todas formas de sustituirse jamás debería hacerse por JAVA. simplemente porque Java no está hecho para ese tipo de operaciones intensivas. Java está hecho para llegar a cualquier equipo informático; se diseñó para que algo hecho con él pudiera ejecutarse hasta en una tostadora. Pero eso tiene un precio llamado JVM q es pesada hasta decir basta y es de locos usar algo tan pesado para hacer operaciones sobre datos de forma intensiva.
En resumen, la discusion COBOL Java me parece tan absurda como decir que es mejor un deportivo que un camión. Ambos son vehículos pero cualquiera puede ver que no se diseñaron para lo mismo por lo tanto no se puede comparar.
Asique que se planteen cambiar COBOL. Que se tomen su tiempo en probar nuevas soluciones pero las tiene q haber mejores y mejorables fuera de COBOL. Eso si x su bien que dejen java para los frontales web y no para las transacciones sino van a tener q aflojar una pasta en maquinas.
Lo del SAP es de juzgado de guardia. Que metan esos clavos por implantarte un sistema rígido y cerrado, que implica enormes dificultades de adaptación, solo es posible porque quién toma la decisión de comprar SAP no tiene demasiada idea de informática y se ha dejado convencer (o untar) por algún comercial.
Podría hablarte de una famosa ONG que se dejó varios millones de euros en un SAP cuando se le propusieron otras soluciones en software libre por un 10% del coste.
en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria
En fin que yo tampoco digo que sea la panacea SAP, pero que no veo yo a un banco montando sus sistemas en PHP + MySQL... o en Java... Lol.
La media 2000... bueno, si las COPY's las pones a saco, me creo lo de las 30000 ..pero de experto..
COBOL es un lenguaje compilado con el que puedes desarrollar aplicaciones autónomas, y ABAP es un lenguaje que se usa exclusivamente dentro de una aplicación comercial (SAP) para extender sus funcionalidades.
La potencia depende principalmente del hardware, así que el SAP no se justifica tampoco por ese lado.