¿Cómo y por qué gastamos miles de millones en mantener software antiguo? Desde 2010, empresas y gobiernos en todo el mundo han gastado unos 35 billones de dólares en productos y servicios tecnológicos informáticos. De esta cifra, tres cuartas partes se gastaron en el mantenimiento y operatividad de sistemas tecnológicos informáticos ya existentes. Al menos 2,5 billones de dólares se gastaron en tratar de sustituir sistemas informáticos heredados, de los cuales unos 720.000 millones de dólares se desperdiciaron en reemplazos fallidos.
Comentarios
#3 Los siento@cosmonauta.
Por muchos negativos que me pongas la realidad es la que es. En el comentario anterior he hablando de lo que es mi trabajo con sistemas legacy. Vamos, lo que es mi día a día.
Si quieres rebatirme algo lo haces con un comentario pero el negativo por el negativo te lo metes por donde te quepa.
Los sistemas nuevos no funcionan necesariamente mejor. Cuando son muy grandes y complejos hasta que funcionan bien pasan meses o años. Ahora mismo estamos estabilizando un sistema nuevo que está reemplazando a un sistema antiguo que tampoco había llegado a funcionar bien. Si estoy ahora conectada es precisamente porque no funciona bien y estoy haciendo un trabajo en producción que no sería necesario hacer si funcionase bien. Y eso que en este caso solo ha sido subir un par de versiones el producto.
#8 Iepp,..Keep Calm!!!! Yo no he puesto ese negativo conscientemente. Supongo que le di al botón sin querer. Es que además, estoy totalmente de acuerdo contigo. No descarto que incluso quisiera votat positivo.
Insisto, se trata de un error. Pero oye..que ya llevas tiempo por aquí y no creo que sea la primera vez que te pasa. Igual estás sobreactuando un poco. Solo es un infinitésimo de karma perdido y, compensado de nuevo en tu último comentario.
#9 Disculpas aceptadas. El síndrome del dedo tonto lo tenemos todos alguna vez.
Son las horas perdidas a estas horas de la noche (y las que me quedan) mientras hago una operación delicada con un sistema nuevo que debería funcionar mejor que el sistema al que sustituye. Lo hace mejor en algunas cosas y peor en otras, aunque da más trabajo y le vaticino otros tres meses hasta que empiece a trabajar como debe sin que una persona se tenga que dejar todos los sábados los cuernos para que funcione.
#10 Yo también estoy currando. Estamos los dos igual, pero tu en un legacy y yo en una patata startupera ultramoderna buscando un hacker que nos está amargando la vida porque esto es un colador
Hay sistemas tan jodidamente grandes y complejos que es imposible portarlos, la única opción es volver a crearlos (Y reemplazar todo, software, hardware, los pomos de las puertas y el color de las paredes), y la mayoría de responsables de estos casos pasan de meterse en un fregado de tales magnitudes (Y mas si son tipos que tienen intención de pasar por el puesto e ir a otra parte)
Por lo menos los casos que me he encontrado en mis 20 años de IT
Recuerdo cuando en la empresa que trabajaba contrataron a un "jefe-genio" que convertiría el sistema basado en Cobol-CICS a JAVA en 6 meses...
Después de 3 años y muchos problemas consiguieron que "parte" del sistema funcionara en JAVA y dieron la migración por terminada.
No hace falta decir que, los que currabamos, sabiamos perfectamente que la parte realizada o era muy simple o era llanamente una pintada por encima de los procesos en Cobol que seguian corriendo sobre los procesos de siempre y con la base de datos no relacional de siempre.
Hubo mucho cachondeo, pero fue una clara experiencia de que no es tan facil actualizar un gran sistema como puede parecer al principio.
#4 yo he estado currando en un sistema donde la parte Java daba acceso exterior al nucleo del sistema hecho con cobol-cics.
Y el mayor problema era la inexistencia de documentación sobre la lógica del sistema.
Más de una vez, el cliente quería cambiar el tratamiento o negocio de ciertas entidades, y darle un nuevo enfoque, y resultaba un trabajo tedioso por parte de todo el equipo determinar lo que implicaba dicho cambio, ya que tenías que tirar de ir mirando código, tanto a nivel java y sobretodo a nivel de cics.
¿Por qué cambiar algo que funciona perfectamente?. Las empresas no siguen ninguna moda.
#2 El problema es que muchos no funcionan perfectamente. Se pusieron en producción con sangre, sudor y lágrimas y sobre todo tarde y con mucho sobrecoste. Y solo empezaron a funcionar medianamente bien después de llevar algún tiempo en producción. De nuevo más sobrecoste.
La mayoría de incidencias que tienen están muy localizadas y perfectamente procedimentadas y se resuelven en un periquete por cualquier espécimen neumotorácico que sepa leer en el idioma en que está escrita la enorme guía de procedimientos de solución de problemas puede aplicar.
Pocas organizaciones están preparadas para pasar otra vez por ese ciclo de sangre, sudor, lágrimas, retrasos y sobrecostes y retrasan esas movimientos lo más posible. Al final lo que crece es un sistema paralelo para gestionar la infraestructura nueva (o los nuevos impuestos, o lo que sea). Que va creciendo a lo largo de los años en funcionalidad mientras el sistema antiguo decrece y conviven los dos mucho más tiempo. Es más, puede que un tercer sistema entre a reemplazar al sistema nuevo y termine conviviendo con el más antiguo de todos, donde aún queda algo de funcionalidad muy poco importante como para asignarle presupuesto, o demasiado complicada en relación al coste de migrarla.
#2 Es como cuando eres pequeño y tenías una bicicleta para ir a ver a tus amigos. Luego creces, tus necesidades cambian y has de desplazarte kilómetros para ir a estudiar o trabajar, por lo que decides cambiar tu bicicleta por un coche.
También puede ser que decidas ir siempre en bicicleta, pero tienes pareja e hijos, con lo que tu bicicleta no sirve.
Y te planteo que te puedas deshacer de tu bicicleta, ya que en lo que es el artículo, sería coger tu bicicleta y ponerle el motor de un coche, o poner más asientos.
#5 si pero tus herramientas son las mismas (si es que tienes)