El pasado 8 de agosto, Delta, la segunda aerolínea más grande del mundo, se vio obligada a cancelar más de dos mil vuelos. Cientos de miles de pasajeros tirados en aeropuertos, pérdidas millonarias, y problemas acumulados con retrasos y cancelaciones adicionales que persistieron durante varios días, todo ello derivado de un fallo en sus sistemas.
No es en absoluto un caso aislado: el pasado 20 julio, Southwest Airlines también tuvo que cancelar en torno a dos mil vuelos debido a un fallo de software, problemas similares a los que sufrieron United Continental el 8 de julio, JetBlue el 14 de enero, y el pasado año 2015, Alaska Airlines en octubre y American Airlines en septiembre. Y todo indica que esto es tan solo el principio, y que veremos más casos similares a medida que los problemas derivados de tecnologías con varias décadas de antigüedad y recubiertas con cientos de capas para tratar de incorporar nuevas funcionalidades van demostrando su creciente vulnerabilidad.
Los problemas de los legacy systems han sido tratados en infinidad de ocasiones en la literatura académica: sistemas basados en las tecnologías existentes cuando fueron puestos en marcha, que suponen la funcionalidad principal de muchas compañías o que, como es el caso de las aerolíneas, resulta prácticamente imposible actualizar porque comparten funcionalidades entre múltiples compañías de todo el mundo, aquejadas además por problemas económicos, que no consiguen ponerse de acuerdo para actualizarla. Al final, el resultado es que todos terminan priorizando las inversiones a corto plazo, y utilizando sistemas de la década de los ’60, parcheados en tantas ocasiones que ya han perdido la memoria de quién cambió qué, utilizados a través de todo tipo de interfaces que abren pantallas que parecen auténticas experiencias de viajes en el tiempo.
Basta con echar un vistazo a la pantalla que se abre en el mostrador de cualquier aerolínea o agencia de viajes: sea a toda pantalla o en una ventana, veremos un espacio generalmente azul o negro en entorno carácter, que viene a ser el acceso al sistema de reservas utilizado por la mayoría de las líneas aéreas, el conocido como Transaction Processing Facility o TPF, un sistema de código cerrado diseñado por IBM en 1979 como evolución de su Airline Control Program (ACP), puesto en marcha en 1965. El núcleo de ese sistema original, SABRE (Semi-Automated Business Research Environment), al que corresponde la captura de pantalla que ilustra esta entrada, sigue aún en funcionamiento. La última actualización significativa del sistema fue hecha por IBM hace aproximadamente una década.
Este tipo de circunstancias, la dependencia de sistemas completamente anticuados, son habituales en muchas industrias, desde las aerolíneas a la administración, pasando, entre muchas otras, por la distribución, los seguros o la banca. ¿De verdad puede considerarse la banca preparada para su incorporación a un futuro basado en blockchain, como afirma el World Economic Forum? ¿Pretenden hacerlo poniendo el enésimo parche sobre los vetustos programas que aún tienen corriendo sobre Sistema 36? ¿Y con personas que aún ni entienden «de que va eso del bitcoin«?
Habitualmente, resulta fácil constatar este tipo de circunstancias: yo mismo no puedo evitar tratar de echar un vistazo a las pantallas que manejan las personas cuando llevo a cabo transacciones en todo tipo de sitios, y constato la gran cantidad de ocasiones en las que me encuentro con sistemas operativos de principios de siglo, imposibles de actualizar, y corriendo programas aún más arcaicos sobre ventanas en entorno carácter. El alcance de los problemas que surgen del uso de ese tipo de sistemas puede ser de muchos tipos: la respuesta «problemas con los ordenadores», que tanto suena a excusa para no confesar incompetencia, es aún tristemente real en una buena parte de los casos en que se utiliza.
Periódicamente, vemos cómo una industria sufre el impacto de la disrupción en parte derivada de su propia incapacidad para actualizar, entre otras muchas cosas, su software. Dejémonos de mitos sobre la solidez de los sistemas, la confianza en lo que ya funciona y el «si no está roto, no lo arregles». La tecnología ha evolucionado exponencialmente a lo largo de los últimos años, y hoy es, además, uno de las principales factores que determinan la competitividad de las compañías. Ser competitivo hoy utilizando herramientas de los años ’60 es como encender fuego con dos piedras: tal vez lo consigas, pero te costará mucho más tiempo y te pillarás los dedos en varias ocasiones. Si quieres saber cómo le va a ir a una compañía en el futuro, trata simplemente de echar un ojo a los monitores que utilizan los que trabajan en ella.
This article is also available in English in my Medium page, “If you want to evaluate a company, take a look at its computer screens«
La pura verdad… hace como 20 años llegaron nuevos bancos a mi país, y mi profesor decía que seria una oportunidad para introducir nuevas tecnologías en lugar de los usuales mainframes, lo que luego me entere es que esos flamantes bancos también habían venido con su mainframe bajo el brazo…. y así siguen todos, capas sobre capas, los fintech tienen una oportunidad por ahí…. pero lo de la aviación… mas complicado. Ahh… y justo ayer en una conferencia alguien de IBM comentaba que ya no eran la vieja compañía de computadoras… sera?
Cierto, las fintech tienen una oportunidad por ese lado. En cuanto a la aviación, es cierto que no existen las «airtech» para que les hagan la competencia a las aerolíneas actuales, pero la burrada de dinero que han tenido que perder Delta y Southwest, con 2.000 vuelos cancelados cada una, y el inmenso daño a la marca, posiblemente sean incentivo suficiente para que empiecen a hacer las cosas de forma diferente.
No tiene nada que ver. Hay mucho software en modo texto que funciona perfectamente, además con el añadido de que es muchísimo más rápido que otro software en modo gráfico.
Existe infinidad de software realizado con las últimas tecnologías y son un desastre total.
Saludos.
El problema es cuando tienes que hacer cambios o integraciones, por ejemplo.
Que sea en modo texto no influye en los cambios.
No estamos hablando de modo texto vs. GUI, sino de programas antiguos, muy antiguos. Son en modo texto porque son de otra época, y siguen apareciendo en las pantallas de inmumerables empleados porque no se ha querido o no se ha sabido reemplazarlos por un equivalente funcional.
La guerra «texto vs GUI» se acabó hace muchos años, la ganó el GUI. Esos programas no aparecen en la pantalla del empleado porque tengan un interfaz de usuario cojonudo, aparecen porque son del siglo pasado.
Como mínimo, con esos programas, no se está separando el front-end del back-end. O tal vez sí, porque lo mismo te puedes encontrar con un back-end arcaico, al cual se sigue accediendo con un front-end arcaico por la única razón de que nadie sabe cómo acceder al back-end de otro modo. Ese conocimiento se perdió en la noche de los tiempos. O tal vez alguien lo sabe, pero no le da la real gana de hacerlo.
Ahora bien, mi broma favorita (porque suena a broma aunque sea cierto) es cuando alguien se las arregló para poner un front-end gráfico, el cual maneja el front-end arcaico (modo texto) a base de simular ser un humano, y a su vez el front-end arcaico maneja el back-end que nadie sabe manejar.
Lo cual, por supuesto, es un problema cuando tienes que hacer cambios o integraciones.
Que funcione bien no significa que esté bien hecho. Y como dice el artículo, el problema viene a la hora de hacer correcciones, mejoras, o incorporar características nuevas.
El tema de la velocidad también es ridículo, ya que los procesadores, memorias, buses… sobre los que están diseñados los sistemas actuales son cientos o miles de veces más rápidos que los que usan estos sistema anticuados, los lenguajes de programación y los compiladores están mejor optimizados con técnicas nuevas que antes se desconocían, son más fiables desde el punto de la seguridad informática, disciplina que hace 30 años ni siquiera existía.
Mantener sistemas con tecnología tan antigua es un absurdo desde muchos puntos de vista. Pero quienes toman las decisiones miran la inversión a corto plazo y no tienen ni la más remota idea de tecnología. Y así nos va.
Que funcione bien no significa que esté bien hecho. Y como dice el artículo, el problema viene a la hora de hacer correcciones, mejoras, o incorporar características nuevas.
El tema de la velocidad también es ridículo, ya que los procesadores, memorias, buses… sobre los que están diseñados los sistemas actuales son cientos o miles de veces más rápidos que los que usan estos sistema anticuados, los lenguajes de programación y los compiladores están mejor optimizados con técnicas nuevas que antes se desconocían, son más fiables desde el punto de la seguridad informática, disciplina que hace 30 años ni siquiera existía.
Mantener sistemas con tecnología tan antigua es un absurdo desde muchos puntos de vista. Pero quienes toman las decisiones miran la inversión a corto plazo (como bien marca el artículo) y no tienen ni la más remota idea de tecnología. Y así nos va.
Y sé de lo que hablo, trabajo de programador para una gran aseguradora que tiene todo el back-end en Cobol, y el front-end y middle-ware en Java. También te digo que muchos de los fallos de Java no son del lenguaje, sino de programadores que no tienen ni idea de lo que hacen. Y que también los hay en Cobol (no veas qué gracia que un viernes a mediodía te llamen para decirte que hay una serie de abends en producción).
En la Fundacion de Asimov, el Imperio se derrumbó porque se perdió el conocimiento acumulado debajo de un número infinito de capas de abstracción.
Es muy cierto y valido lo que dices Enrique, en lo único que no estoy de acuerdo es, que por la forma como lo describes los «entornos carácter» como los llamas, suenan a herramientas arcaicas y eso no es del todo correcto, Hay muchas piezas de software muy moderno que reciben actualizaciones permanentes y que se ejecutan desde una consola.
Existe el problema del legacy pero no puedes insinuar que el software para ser «moderno», «actualizado» y «seguro» tiene que ejecutarse sobre una colorida GUI .
El entorno carácter está más que justificado para algunas cuestiones, yo mismo lo uso en muchas de las cosas que hago. Pero cuando la interfaz que utiliza tu personal de cara al público está en entorno carácter, es un síntoma revelador de que algo va muy mal…
Yo sigo viendo en muchos sitios desarrollos pequeños hechos en el msdos y los colores de borland, y sin problema. Y hoy en dia un curses hecho en linux más que decente…. Para la mayoria de los usos. El GUI no digo que sea malo, pero cuando quieres probar un algoritmo, lo sigo haciendo en el terminal con el CLI…
No necesariamente… el cara al público requiere velocidad y fiabilidad. El modo carácter no suele necesitar ratón, que hace ir muy lentos a muchos usuarios, suele funconar mediante cambios de campo por tabulaciones y los sistemas aéreos funcionan con muchas teclas rápidas, cadenas y comandos, que hacen que quien los usa, lo haga muy rápido.
100% en todo el artículo, menos que el modo caracter, cara al público incluido, es malo o peor que el GUI.
Buen tema Enrique,
Puedo estar de acuerdo contigo en casi todo, me gustaría sin embargo señalar estos puntos que no citas, y reflexionar como cuadra lo que dices con…
A.- normalmente el software legacy está muy probado y los bugs tienden a cero. El renovarlo correctamente es el punto dificil
B.- usar lenguajes de programación nuevos, repecto a lo que hablas, con problemas conocidos e incluso reflejados en sus disclaimers, pueden conducir a problemas muy graves en su performance, p.ej. Java…. Hoy en día la mayoría de los programadores de medio pelo, saben de lo que saben, y trabajan de lo que puden, dado como esta el sector, sino se lo han llevado a Bangalore, además lenguajes, que no compilan en su codigo máquina, y los problemas son conocidos. Asumamos que siguen con lenguajes legacy (ojo que tomo a Java como novedad).
C. La falta de programadores en sistemas legacy no creo que sea el problema, si el llevar el desarrollo y mantenimiento al eterno problema del mínimo coste, que trae los problemas que trae,… Ahora tenemos la moda del outsourcing del outsourcing, y la calidad del producto pues es la que es.
Resumiendo, más que un problema de desfase, es más un desfase del proyecto de mantenimiento en su conjunto y el eterno, reducir al máximo los costes. No digo que no sea normal, pero si eres piojoso no te quejes que te pique la cabeza… No es un problema de la tecnologia usada sino de rateria empresarial…
Tener un programa arcaico significa:
– En general la gente que lo programó ya no está en ese desarrollo porque han escalado en la empresa o se han ido a otra empresa.
– En general la documentación es escasa, y al haber ocurrido lo primero, los que han llegado nuevos están perdidos.
– En general se tienen arquitecturas antiguas y poco escalables con lo cual los cambios son muy dificiles de implementar.
– En general se han corregido los bugs poniendo parches y sin refactorizar el código, lo cual complica más las mejoras.
Existe algo que se llama deuda tecnológica, y eso es lo que tienen estos programas, mucha deuda tecnológica.
Y hablar de lenguajes de programación es lo menos importante, lo más importante es la metodología de desarrollo. En muchas ocasiones el cliente tiene una necesidad y se empieza a desarrollar y cuando se finaliza a los seis meses (por decir una cifra) su necesidad ya no es tan importante, pero tiene otras necesidades …
Llevo fuera del mercado más de diez años, por tanto puede que hayan cambiado las cosas, pero puedo dar fe, que hacia el años 2000, en Banesto, que era el banco que tenía fama de poseer la Informática más adelantada de España. aun tenían en Medina del Campo un centro que manejaba tarjetas perforadas. Y sin llegar a tanto, la inmensa mayoría del Back Office del banco funcionaba bajo Cobol. y ficheros de datos clásicos.
Como tu dices, había una capa bajo otra capa, unida por interfaces cada vez más complicadas y remendadas que traspasaban los datos una y otra vez de una aplicación a otra y viceversa…
La razón es que la necesidad de desarrollos urgentes del banco era tan alta que siempre había que echar mano de los equipos que pretendían poner al día las aplicaciones mas viejas para añadir nuevos desarrollos que hacían falta.
Por poner un ejemplo, yo trabajé para Euroseguros, del Banco de Bilbao, que era la compañía de seguros con facturación de España, (hacia los seguros de las hipotecas inmobiliarias), pues bien, cuando se produjo la fusión del Bilbao Vizcaya, multitud de sucursales se fusionaron o desaparecieron, por tanto un cargo contra una cuenta, había cambiado de sucursal y el numero de cuenta cambiaba en los dígitos iniciales. Uno de mis trabajos, fue hacer un programita que tomaba los números de cuenta viejos de los pagos, los chequeaba y los cambiaba por los nuevos.
Sólo necesitaba una tabla que tuviera dos columnas, la sucursal vieja y la nueva. Jamás conseguí que se me diera una tabla actualizada, porque nadie sabia donde residía tal cosa. Se metían los cambios en un agujero negro que en algún lado producía la maldita tabla, después de varias fases intermedias. Consecuencia: no la tuve jamás al día, sí con varios días de retraso pero no al día. Nunca pudimos cobrar al día la totalidad de las remesas de pagos, el sistema rechazaba un montón de pagos por cuenta desconocida.
Doy fe de lo que dices del Cobol. Tengo un compañero de carrera que está trabajando para una multinacional alemana especializada en software para banca y a día de hoy sigue programando en Cobol para sus sistemas.
Y lo del Banco Bilbao tiene tela macho, con lo poco que costaría tener unas cuantas tablas maestras (y que sean intocables) y a partir de ahi manejarlo todo (Cuentas bancarias, etc…). Ya son ganas de poner palos a las ruedas…
Yo te puedo decir que cuando trabajaba de informático en el hospital y antes que llegara SAP, teníamos un software parecido para admisiones, y las administrativas ya ni usaban ratón para moverse, todo por teclas de comando: ctrl+a, ctrl+t… en 2 segundos ya tenían la pantalla para hacer una nueva admisión.
Y ya que hablas de temas de seguros, cuando trabajaba como informático en una empresa que tenía un ERP para el sector de seguros y hacía traspasos de programas de la competencia al nuestro, he visto ERPs que graban sus registros en ficheros de texto plano (y sin encriptar ni nada, tal cual). Claro, cuando un txt pesa un montón de MB, el programa se vuelve lentísimo…
Con esto quiero decir que, a pesar que a día de hoy hay software totalmente valido con una interfaz bonita y clara, a veces la interfaz no lo es todo, sino que es el back lo más importante, todo el mainframe: conexión al servidor, capa lógica, etc… es aquí donde todo ha de ser robusto y bien estructurado.
Pero si estamos hablando de arquitecturas de los años 60, mal vamos…
Te podría contar precisamente lo contrario, el cambio por el cambio. Multinacional del Ibex35 cambiando su sistema principal y fallando por todas partes, problemas de interfases entre sus propios sistemas, dejando de dar servicio a sus usuarios, problemas judiciales, perdiendo dinero…
No es barato cambiar y estamos en el tiempo del low cost, ya lo ha dicho JOSE ANTONIO GARCIA más arriba. Aunque a mi modo de ver la cosa se resume en dos cuestiones: Requerimientos (no se asignan lo recursos suficientes: tiempo, personas) y Pruebas (tampoco se asignan lo recursos suficientes: tiempo, personas).
En el sector bancario (entre otros) se sigue usando sistemas como el COBOL (o similares) por varios motivos:
– No hay sistema «moderno» (como JAVA) que sea capaz de manejar el volumen de operaciones con el que se trabaja (del orden de muchos millones de registros al día)
– Nadie puede asegurar que al cambiar a un sistema «moderno», todo vaya a funcionar igual
– Ningún sitema «moderno» asegura la fiabilidad actual del COBOL para ciertas tareas. Esto es, entendiendo que el sistema está bien diseñado y estructurado. Yo me encuentro a menudo programas con 30 años de antigüedad que siguen haciendo su tarea de manera efectiva y sin errores.
– El coste de sustitución de un software por otro tendría un coste altísimo
– Para la empresa que pagaría esa cantidad (el banco o quien fuera), dicho cambio no le supondría ninguna ventaja, más allá de la estética
– La seguridad que a fecha de hoy lleva implícita el uso de sistemas como COBOL no se puede conseguir con otros lenguajes más modernos.
– Ningún responsable de informática de dichas empresas con …taytantos años de experiencia en COBOL va a promover un cambio a un software que no domina
– Y por mucho que nos pese, a fecha de hoy, COBOL (y lenguajes similares) no tiene ningún sustituto que esté a la altura
Dicho esto, desconozco en concreto el caso de las líneas aéreas.
Por otro lado, Enrique, cada vez que hablas de software, creo que desconoces con detalle lo complicado que es programar y los múltiples problemas que conllevan los cambios más simples.
Si no has tomado la «Hour of code», te la recomiendo. Y si pudieras realizar un curso de programación algo más avanzado (como de JAVA, por ejemplo), te ayudaría a hablar con más propiedad de algunos temas relativos al software.
Con todo el respeto ;)
Soy experto en COBOL y corroboro solo en parte, tus afirmaciones. El COBBOL es el lenguaje más apropiado para trabajar en equipo en programas de gestión, de eso no hay duda.
Sin embargo el COBOL del año 2000 (cuando lo dejé yo), nada tiene que ver con el Cobol de los años 70, cuando empecé (Y ya tenía años de antigúedad).
En el viejo COBOL estaba diseñado para trabjar en lotes, diseñar un listado era una proeza llenas de ### y solo manejaba ficheros clásicos con regitros de aceso por clave ( lo cual ya era un avance a los ficheros únicamente secuenciales anteriores, que yo tambien he tratado).
Luego ha evolucionado y hoy trabaja hacer un listado o manejar una Base de Datos no tiene misterio en el COBOL actual. Pero si tienes las aplicaciones mas básicas de un banco, como las cuentas corrientes, el calculo de intereses en COBOL de los 70 y tienes que conectarla a los aplicaciones modernas como de cajeros automáticos, basads en Dase de Datos, tienes que montar un pifostio para mantener sicrónicos el contenido de los ficheros clasicos y la Base de Datos. Y si por el medio, hay que dar y recibir infortmación, para una serie de paquetes bancarios, de lo más variopinto, mercado de divisas, calculo de riesgos, tesoreria, … y cada paquete esta desarrollado en los lenguajes mas variados la cosa adquiere un complejidad inmensa que no es fácil de simplificar. Máxime cuando todos tus informáticos no dan a basto a mantener aplicaciones viejas pensadas para trabajar por lotes trabajando On.line y desarrollando como locos nuevas aplicaciones, porque un loco del departamento de Marketing ha decidido dejar de querer ser tu banco y ha inventado la CUENTA 1-2-3 y nadie le ha parado los pies.
Que de generalizaciones gratuitas y vaya recomendación final para Enrique en su propio blog…
Creo que el punto de Enrique de que nada construido en este tipo de tecnologías puede constituir la base de una ventaja competitiva es indiscutible. Creo que tampoco das ningún argumento en contra de esta postura, sino que hablas de temas accesorios al punto del artículo
El resto de mis comentarios los concreto en java, aunque los tiros en realidad no van por una tecnología X o Y.
Java se creó en 1995, luego me parece que ha tenido tiempo para demostrar si las arquitecturas en las que se utilizan son seguras o tienen un correcto rendimiento. Decir que cobol es más fiable porque lleva más tiempo es como decir que mi padre es más adulto que yo; puede ser cierto pero no tiene mucho sentido. Por otro lado simplemente no es cierto. Java esta presente en arquitecturas más o menos «tradicionales» pero también en sistemas embebidos que se utilizan en industria aeronáutica, aeroespacial, armamentística… decir que estas industrias tienen unos requerimientos de seguridad menores que un banco no parece razonable.
Entiendo que tus comentarios sobre la imposibilidad de gestionar volúmenes grandes en otra cosa que no sea cobol serán tenidos muy en cuenta en LinkedIn, Facebook o incluso en Google. Preveo migraciones masivas inmediatas a cobol. En breve mi teléfono ejecutará cobol. El watson de IBM tiene que estar basado en cobol. Necesariamente.
«– Para la empresa que pagaría esa cantidad (el banco o quien fuera), dicho cambio no le supondría ninguna ventaja, más allá de la estetica»
Impresionante. Estamos en un mundo cada vez más cambiante, donde las empresas son cada vez más «extendidas» cubriendo clientes, partners, servicios externos… el poder «gestionar volumenes» es algo higiénico no supone ninguna ventaja competitiva. Si sigues este blog tendrías que que conocer múltiples argumentos de por qué hablamos de la flexibilidad como argumento existencial para las empresas. Si no te gustan los artículos de software de este blog ni de los transformación digital entiendo que tienes ya muchas ideas preconcebidas y no las vas a cambiar.
«Ningún responsable de informática de dichas empresas con …taytantos años de experiencia en COBOL va a promover un cambio a un software que no domina»
No es cierto. Hay responsables que si que ven la necesidad y están trabajando en fomentar el cambio y en desarrollar equipos comprometidos conscientes de la necesidad de evolucionar. Lo que ocurre es que, como dices es complicado y caro.
«– Y por mucho que nos pese, a fecha de hoy, COBOL (y lenguajes similares) no tiene ningún sustituto que esté a la altura»
Sí tan superior es, no sé por qué nos tendria que pesar que siguiera utilizándose. Deberíamos fomentarlo en las universidades y en nuestra estrategia de i+d+I de país.
No conozco una sola implantación nueva de cobol; y he estado y conozco muchas de muchas tecnologías.
Es un lenguaje en desuso dirigido a mantener la base existente.
Yo me bajo aquí para no hacer una guerra religiosa.
Perdona, en el sistema bancario, como en otros hay gente que sigue anclada en el pasado, pero hay otra gente que ha dejado o está dejando el COBOL por el java o similares desde hace tiempo y todo sigue funcionando igual.
A ver a quien le suena esto… Director de IT de banco en vez de sacar un macroproyecto de externalización y poder hacer la «evolución» coherente y con una empresa grande y de calidad del sector, lo parte en 1000 trozos para poder seguir manteniendo el control con su capa de gestión, y ya que pierde recursos, al menos sigue siendo necesario en controlar las n empresas…. Las sinergias y las referencias le importan un rábano y a la vez las empresas amigas de siempre salen beneficiadas, y el consejo a por uvas, …
Vaya por delante que no soy experto en el tema, pero lo que pasa, hasta donde soy capaz de ver, es que no se siguen toda una serie de buenas prácticas, que son lugar común en Informática desde hace muchos años, pero que no se están siguiendo por el motivo que sea, posiblemente porque de lo único que se han preocupado durante décadas es de conseguir que cada nueva incorporación funcionase sobre el legacy, en lugar de cambiar el legacy para incorporar estas buenas prácticas:
– Usar protocolos abiertos. Todos los programadores deberían saber cómo comunicarse con todas las máquinas. Además, permite reemplazar cuando se desee el hard y el soft antiguos, usar protocolos abiertos y la modularidad de los sistemas son 2 cosas que van unidas.
– Los datos se almacenan en bases de datos (a las cuales, por supuesto, se accede mediante protocolos abiertos).
– El interfaz de usuario (para los empleados, o incluso para los clientes vía web o app móvil) debería ser un simple front-end de la base de datos. Es simplemente absurdo que el interfaz de usuario sea el de un programa en modo carácter, es un claro signo de que no se están siguiendo las reglas anteriores.
– Las bases de datos deberían ser distribuidas, y los sistemas en los que se ejecutan deberían ser redundantes (de verdad, no «supuestamente redundantes»).
Seguro que me dejo más de una buena práctica en el tintero. No es exactamente un problema de que el soft, o incluso el hard, sean antiguos. Seguro que en el kernel Linux todavía quedan unas cuantas rutinas de hace más de 20 años, pero funciona perfectamente porque sus interfaces están claramente definidos, y cada vez que ha sido necesario cambiar el kernel para que este cumpliese mejor con los protocolos y otros estándares abiertos, así se ha hecho.
Lo que vemos aquí es pura chapucería.
Lo dices como si fuera tan simple implementar un cambio. Olvidas que los bancos, aunque no abran sus oficinas, trabajan las 24 horas al dia todos los dias del año con operaciones internacionales. No se puede un dia desconectar un banco de repente para meter un cambio que afecte a sus principales sistemas y encima que todo funcione bien.
Sistemas redundantes, bases de datos distribuidas. Te lo creas o no, es perfectamente posible actualizar esos sistemas máquina a máquina, y sin que el sistema deje nunca de funcionar.
Como programador que soy disiento de gran parte de tu discurso: la culpa no es de la herramienta utilizada sino del mantenimiento que se le haga tanto al software como al hardware.
¿Crees que ahora esperas mucho a que una pantalla te confirme una reserva de avión? ¿Y crees que un sistema que debe alimentar a miles de pantallas y que estuviera programado en, por ejemplo, Oracle iba a ser más rápido?
El problema está, como siempre, en que las empresas siempre consideran que la informática solo es un gasto que debe minimizarse, así que despiden a sus viejos y caros programadores para, si acaso, sustituirlos por jóvenes peor pagados y peor motivados, jóvenes que no tienen ni idea del castillo de software al que se enfrentan.
Solo las empresa que han sufrido un buen porrazo informático terminan apreciando ese departamento.
Por lo demás de acuerdo con Gorki o Mr Anónimo, demasiada ligereza al hablar de ciertas cosas.
Enrique hace poco mas de un mes viniste a la ciudad financiera a dar una charla sobre transformación digital ( coloquio que vi unos días después en la intranet del Santander) pues ya podías haber hecho una mencción sobre este tema porque si hubieras visto sobre los softwares tipo carácter a los que nos vemos obligados a trabajar en esa empresa darías un salto del susto.
Saludos Soy de Latinoamerica -Peru ,trabaje un tiempo como soporte tecnico y por ejemplo en mi región , se ve muchos software clasico por ejemplo se usa el lenguaje Fox Pro for DOS aun el desarrollo de los sistemas de casi la mayoria de los hospitales estatales y algunas universidades publicas.
En tanto las cadenas de farmacias usan y miles de bodegas usa sistemas hechos en el lenguaje Visual Fox Pro.
Es bastante complejo el entorno pero se ve un diversidad de tecnologia bastante retro en las empresas y instituciones estatales
Trabajé en Sabre durante casi una década. Te aseguro que el gran problema era puramente político. Demasiada gente interesada en mantener sus ‘comfort zones’ y a ‘su gente’. Decisiones técnicas tomadas utilizando la política.
Qué tema tan interesante, daría para días de debate. Algunas reflexiones:
– Independientemente de que tengan interfaz gráfico, podemos considerar SAP o Microsoft Dynamics legacy systems, ¿verdad?
– ¿Qué tiene más riesgo, mantener mis sistemas «anticuados» o migrar millones de líneas de código? ¿Qué hacen mis competidores?
– ¿Los problemas Southwest y Delta se habrían evitado si tuviesen sistemas basados en tecnologías más modernas?
– ¿Qué garantía tengo de que la tecnología a la que migre me de otros 30 o 40 años? ¿O tal vez me vea obligado a actualizar otra vez dentro de 10 años?
– ¿Cuánto cuesta migrar? ¿Y no migrar?
– Migrar no puede ser una decisión sólo de IT, es un paso que tiene que tener el apoyo de toda la organización.
Personalmente no creo que mantener los sistemas legacy sea consecuencia de cortoplacismo, política, luchas de poder o miopía. En muchos casos es simplemente la opción menos mala. Y totalmente de acuerdo en que periódicamente, vemos cómo una industria sufre el impacto de la disrupción en parte derivada de su propia incapacidad para actualizar, entre otras muchas cosas, su software.
Ah, pero ¿es necesario migrar millones de líneas de código? ¿Todo de golpe? ¿No se supone que los sistemas deberían ser modulares, distribuidos, y redundantes?
No hay nadie que tenga un sistema informático más gordo que Google, operando a escala mundial las 24 horas del día, 7 días a la semana, intensísimo en operaciones (búsquedas, Gmail, Youtube, etc, etc). Los de Delta y Southwest son hormigas en comparación. Y sin embargo, a Google no le pasan estas cosas. Ni a Facebook, ni a Amazon…
Desde luego, no será porque las punto-com estén usando hard de excelencia inconmensurable. Al contrario, en sus datacenters usan hard relativamente barato. Sus discos duros (el componente más proclive a fallos) están petando continuamente. En un porcentaje bajo, claro está, y los reemplazan según van reventando, pero el caso es que sus sistemas siguen funcionando sin pestañear.
Estas punto-com reinventaron los datacenters, los que tienen ahora no son como los que tenían antes, y hubo incluso una época anterior en la que ni siquiera tenían datacenters. Cuando se fundó, todo Facebook estaba en un único PC.
¿De verdad alguien se piensa que puede seguir haciendo en su sistema informático las cosas como las hacía hace 20 años? ¿Y que las va a poder seguir haciendo así dentro de 20 años? Una mentalidad así es receta segura para el desastre.
No es que mantener el legacy sea la opción menos mala, es que ni siquiera es una opción. Antes o después vas a tener que romper con el pasado, y de hecho lo conveniente no es mirar a ver si vas a poder aguantar 30 o 40 años sin migrar, o si van a ser 10, sino planteártelo más bien como una evolución continua.
Google cumple el mes que viene 18 años, Amazon cumplió el mes pasado 22, y Facebook es todavía un niño de 12 años. Pese a su juventud, no paran de cambiar sus propios sistemas informáticos, ellos sí están en una migración continua.
En el mundo actual, sin importar si eres una punto-com, una aerolínea, un banco, o un fabricante de chuches, el sistema informático tiene una importancia vital y creciente. Ya no puedes operar sin él, y en el futuro las consecuencias de su malfuncionamiento serán cada vez peores.
Como has señalado, hay un riesgo que es incluso peor que la gran petada, la fosilización. Tus empleados, desde la base hasta los más altos ejecutivos, van poder hacer lo que tu sistema informático les permita hacer.
Google es un bebe al lado de los sistemas de gestión bancaria, de aerolíneas y de ERP. Quizás ni siquiera llegue al 1% del volumen de información que se mueve en esos ámbitos.
Raúl, por favor…
http://searchengineland.com/google-now-handles-2-999-trillion-searches-per-year-250247
Hombre, Google se creó en el el 98, desde cero y pensada de cero.
El core de los bancos se implementó en los 50 y con el día a día del banco en plena producción.
Esa es la gran diferencia.
Google también ha estado en plena producción desde que se creó, su crecimiento ha sido muchísimo más acelerado que el de los bancos, y su funcionamiento es de 24 horas y respuesta inmediata, nada de «cerramos a las 3, y las transferencias que hemos hecho hoy ya aparecerán en su destino mañana, salvo que sea viernes, que entonces no aparecerán hasta el lunes».
En sus cortos 18 años de vida Google ha pasado del servidor solitario, o unos pocos servidores en la misma ubicación, a la red de datacenters, y después (al igual que otras punto-com) redefinió los datacenters. Es decir, en 18 años ha roto con su legacy en 2 ocasiones. Facebook lo mismo en solo 12 años.
Como siempre, en España todos somos entrenadores de fútbol y nos permitimos el lujo de decir lo fácil que sería redundar un sistema o mantener unas tablas maestras o tirar a la basura unas infraestructuras para cambiarlas por otras más modernas, con más colores y en la nube (esto se os ha olvidado).
Hablar de sistemas legacy no significa que lleven 30 años sin actualizarse, como se intenta hacer entender en esta entrada. La tecnología hardware del Mainframe se actualiza cada 4 años. Cada nueva versión incluye mejoras notables en velocidad, rendimiento, gestión de memoria,… De la misma forma, el software se evoluciona constantemente, nuevos productos, nuevas tecnologías, nuevas empresas.
Si a lo que os referís es a la situación de programas diseñados hace 30 años que, independientemente de la tecnología, se han ido parcheando y ya nadie sabe qué había en la cabeza del que lo diseñó. Estoy completamente de acuerdo. Ahora bien, habrá que ver como envejece un programa Java (o C, o como quieras) escrito en el año 2000 por un recién licenciado en informática (de esos que arreglan cualquier problema con «unas tablas maestras»).
Si queréis hablar de la mala calidad del software y su gestión, adelante. Pero no mezclemos cosas de una forma tendenciosa (o sin saber)
Cuando quiero implementar una nueva funcionalidad para ya porque la competencia lo está haciendo y tengo que llegar antes que la competencia, y eso ocurre muchísimo hoy en día, necesito un sistema fácilmente modificable, y en general estos sistemas han sido parcheados tantas veces, que funcionan genial pero no se les puede tocar. Cuando tienes algo así, hoy en día tienes un problema.
Lo que voy a decir ya sé que es una herejía para algunos (o muchos), pero el propio concepto del mainframe es simplemente incorrecto hoy día.
Ya mencioné que empresas como Google y Facebook reinventaron los datacenters. En lo concerniente a servidores esta reinvención no consistió en instalar mainframes, y ni siquiera servidores de última generación de HP, sino en diseñar sus propios servidores «adelgazados», reducidos a lo esencial, relativamente baratos, y especialmente adaptados a lo que es el nuevo concepto de datacenter.
La última katana de Hattori Hanzo tal vez sea la mejor de las katanas que se han construido jamás, pero sigue siendo una espada. Si algún día me mandan a la guerra, no quiero que me den esa katana, quiero que me den cualquier buen rifle de asalto.
Sistemas redundantes y distribuidos, con protocolos abiertos y modulares (con hard y soft fácilmente reemplazables), y por supuesto con el front-end separado del back-end (esos programas en modo texto…). Esto es lo que es escalable y adaptable a las crecientes y cambiantes necesidades.
¿Envejecer? Haz las cosas bien y tendrás la fuente de la eterna juventud, porque no estarás encadenado a ningún elemento legacy.
¿Y porque presupones (incorrectamente) que esa pantalla de texto no sigue un paradigma MVC?
Aunque tu no lo creas ese concepto ya se usaba antes de que alguien le pusiera ese nombre. COBOL hace décadas que tiene un componente DISPLAY para separar la vista del resto del programa (e incluso generalmente corren en sistemas separados)
Cierto Raul. De hecho, en realidad, todo el problema de mezclar todo en uno vino en los 80, con el PC y la idea de tener tu propio ordenador personal con todo integrado. Es ahora que nos estamos adaptando de nuevo a separar conceptos (aún hoy en día estamos en ello) .
Mientras la idea original del PC era tener un ordenador personal sobre el que hacer ciertas actuaciones, muchas empresas optaron por sustituir los terminales por un PC para cada usuario, incrementando los riesgos (información que no llega a la BD central porque el usuario se la maneja en un excel y nunca notifica al dept de informática de que es necesaria, o la simple reparacion de discos duros cada x tiempo).
Parte de esos programas no tienen la estética de los programas DOS, sino de los terminales ANSI, que son anteriores. Así que no, el PC no fue el origen de este mal, aunque también haya ocurrido con el DOS (y con Windows NT, este ya con modo gráfico).
Bueno, pues entonces explícame por qué es de texto. ¿De verdad de verdad de la buena está 100% separado? ¿Puedo hacer una versión del front end para Android tal cual suena, sin historias raras?
Es decir, me indicas qué protocolo usas, y ya está, solo con eso ya se puede hacer el front-end. ¿Es así?
En caso afirmativo (poco probable), ¿por qué sigue siendo interfaz en modo texto, y con esa estética arcaica a más no poder? ¿Cuál es la ventaja de ese interfaz frente a otros tipos mucho más modernos? ¿Por qué han pasado décadas sin que lo actualizasen?
Sin dudas que llega un punto en que la actualización tecnológica se vuelve una necesidad, y sería mejor no esperar a que todo explote.
Otra cuestión importante es que migrar estos sistemas a uno nuevo requiere una esfuerzo monumental, y si no está bien gestionado y planificado, al menos temporalmente, llevará a una situación peor a la anterior. Lo que refuerza la resistencia al cambio y hace todo más difícil.
La pantalla es como la prueba del 9: generalmente te dice cuando algo está mal, pero también puede dar por bueno un resultado erróneo.
En la pantalla se tiene sólo la vista, que si es poco amigable suele soportar a una aplicación de características similares, pero a veces se puede tener una vista elegante y aparentemente moderna que oculta una base de datos arcaica.
Al revés (vista simple que oculta una aplicación bien diseñada) es más difícil de encontrar.
Perdón por la puntualización porculera de informático viejuno: creo que te refieres al S/360, no al S/36 que iba destinado a PYMES.
Saludos.