Ocho de cada diez empresas españolas mantiene sistemas obsoletos en el 'core' de sus negocios, pese a que trata de abordar los desafíos de la transformación digital incorporando herramientas de nuevo cuño. Es la difícil convivencia entre tecnologías de distintas eras vitales.
#6:
El problema suele ser que aunque hay pasta mas que de sobra para hacer un upgrade no hay cojones de hacerlo, porque tras años de que docenas de manos (en el caso español muchas veces de sub-sub-contratados de carnicas sin mucha motivacion para ser excelentes en su trabajo dada la excelencia de sus condiciones) metan configuraciones, parcheos y apaños a toda prisa, por supuesto sin documentar nada y aquello es un puto marron que no hay cojones de migrarlo sin crujir seriamente los niveles de servicio de todo el tinglado y la cosa se pospone hasta que hay una petada que cruje y deja a los "manajers" sin mas remedio que ponerle el cascabel al gato porque esta todo pendiendo de un hilo. Pero esto no solo pasa en España, pasa en todos los paises en los que he currado (aunque alli el tema va mas por la enorme rotacion de contratistas que no hay forma de retener conocimiento).
El problema suele ser que aunque hay pasta mas que de sobra para hacer un upgrade no hay cojones de hacerlo, porque tras años de que docenas de manos (en el caso español muchas veces de sub-sub-contratados de carnicas sin mucha motivacion para ser excelentes en su trabajo dada la excelencia de sus condiciones) metan configuraciones, parcheos y apaños a toda prisa, por supuesto sin documentar nada y aquello es un puto marron que no hay cojones de migrarlo sin crujir seriamente los niveles de servicio de todo el tinglado y la cosa se pospone hasta que hay una petada que cruje y deja a los "manajers" sin mas remedio que ponerle el cascabel al gato porque esta todo pendiendo de un hilo. Pero esto no solo pasa en España, pasa en todos los paises en los que he currado (aunque alli el tema va mas por la enorme rotacion de contratistas que no hay forma de retener conocimiento).
#9 Claro. Pero y el día en que haya que cambiar a la fuerza, o lo que es peor, falle algo y no haya por donde cogerlo?
También es cierto que eso dependera de cada caso. No es lo mismo un sistema antiguo pero bien diseñado , que un cúmulo de parches, wrappers..etc que hagan imposible un troubleshooting.
#11 Normalmente un sistema que lleva 10 años funcionando de forma estable no falla a lo grande. Pero de nuevo riesgos-beneficio, el que falle es un riesgo, ¿merece la pena asumirlo? pues depende: Si lo que tienes es a Frankestein tambaleándose normalmente los beneficios de cambiar a uno nuevo son mayores y debería hacerse más pronto que tarde; Si lo que tienes es la gran pirámide de Giza, pues si, es antigua y tiene sus secretos ocultos, pero es estable y aún da sus beneficios.
El problema es que al final todo depende de quien tome las decisiones, de lo bueno que sea evaluando riesgos y beneficios del valor que tenga.
#13 Te pongo una situación jodida: imagina que tienes un sistema Solaris programado en COBOL. Resulta que llega un momento en que tienes que sustituir las estaciones Sun del año del picor por unos equipos nuevos porque ya no dan más de si. Cambias los equipos y, por narices, cambiar de Solaris a, por ejemplo, Windows Server. Me parece que la versión de COBOL, para empezar, no va a ser ni de lejos la misma (igual es pasar de un 85 a un 2014). Y eso si encuentras a algún programador que pueda pillar el programa antiguo y pasarlo al sistema nuevo sin hacer mucho destrozo, que buenos programadores de COBOL no es que abunden.
Ahora, la otra posibilidad: antes de llegar a ese escenario, rehacer el programa desde cero, manteniendo todo lo más parecido posible al antiguo, pero con un sistema más actual (me da igual si es C++, .NET, Java o lo que sea) y tener tiempo para probarlo bien antes de hacer el cambio.
#14 Si sabes que vas a sustituir las estaciones y como dices no te queda otra que tocar código entonces desde mi punto de vista habría que actualizar pues riesgo aumenta, es posible que ya no sea el core estable que tenias, a la vez que el beneficio es mayor, puedes poner una tecnología que se adapte mejor a los nuevos equipos. No obstante, puede que hubiera una solución intermedia, virtualización, no se en Windows Server, pero en Centos yo he virtualizado Solaris 11 usando KVM. En este caso, otra vez, habría que evaluar los riesgos y beneficios y decidir.
Como ves mantengo mi postura, es la relación riesgo beneficio la que debería determinar el mejor momento para actualizar. Todavía no he recibido un argumento en contra suficientemente convincente, hay que evaluar los riesgos de mantener el core antiguo y los beneficios de actualizar a un sistema nuevo. En el momento en que los riesgos o el beneficio pasa a ser muy alto es el momento de cambiar.
Me recuerda lo de 'parche sobre parche' o 'desde-cero' en el clásico ejemplo de los bancos y su COBOL o lo que tengan.
O cambiar ya, y arreglar todos los marrones que salgan a raíz de eso, o parche sobre parche y mantener sistemas arcaicos con la esperanza de que nunca haya que cambiarlos.
No trabajo en un banco (sólo por lo que me cuentan) así que no sé si están en proceso o sigue todo igual....
#1 en aseguradoras lo mismo. Software en cobol de hace 40 años, mal documentado y que a base de cambiar de manos ya no hay nadie con conocimiento funcional de todo. Software que es el núcleo, envuelto en mil capas de servicios web
#1#4 Las cosas no son mejores por ser nuevas o antiguas. No conozco esos sistemas, antes de tocar algo que funciona pienso en riesgos y beneficios, y si, sé que el mantenimiento de esas plataformas tiene que ser complejo como poco. Pero tocar o cambiar estos "cores" muchas veces tiene más riesgos que beneficios, hasta que eso no cambie, yo tampoco metería mano, más cuando hay muchas ocasiones puedes usar un wrapper empleando la funcionalidad antigua sin llegar a modificarla junto con software de última tecnología ofreciendo nuevas funcionalidades.
Pues claro. Han aparecido nuevos usos, pero aún se siguen teniendo que sacar nominas, gestionar inventarios y llevar contabilidades.
¿Para que cambiar, lo que funciona, y sigue siendo esencialmente lo mismo?
#3 por que el dia que se rompa algo, que llegara, ni dios sabe como ostias estaba montado o como montarlo de nuevo en un equipo moderno puesto que los equipos que han muerto tienen 20 años o mas
Las nóminas solo son Core si tú e.lresa se dedica a hGerle nóminas a otras empresas . El inventario es Core si eres Amazon y la contabilidad es Core si vendes servicios de contabilidad. Parando resto de las empresas eso no es Core.
Comentarios
El problema suele ser que aunque hay pasta mas que de sobra para hacer un upgrade no hay cojones de hacerlo, porque tras años de que docenas de manos (en el caso español muchas veces de sub-sub-contratados de carnicas sin mucha motivacion para ser excelentes en su trabajo dada la excelencia de sus condiciones) metan configuraciones, parcheos y apaños a toda prisa, por supuesto sin documentar nada y aquello es un puto marron que no hay cojones de migrarlo sin crujir seriamente los niveles de servicio de todo el tinglado y la cosa se pospone hasta que hay una petada que cruje y deja a los "manajers" sin mas remedio que ponerle el cascabel al gato porque esta todo pendiendo de un hilo. Pero esto no solo pasa en España, pasa en todos los paises en los que he currado (aunque alli el tema va mas por la enorme rotacion de contratistas que no hay forma de retener conocimiento).
#9 Claro. Pero y el día en que haya que cambiar a la fuerza, o lo que es peor, falle algo y no haya por donde cogerlo?
También es cierto que eso dependera de cada caso. No es lo mismo un sistema antiguo pero bien diseñado , que un cúmulo de parches, wrappers..etc que hagan imposible un troubleshooting.
#11 Normalmente un sistema que lleva 10 años funcionando de forma estable no falla a lo grande. Pero de nuevo riesgos-beneficio, el que falle es un riesgo, ¿merece la pena asumirlo? pues depende: Si lo que tienes es a Frankestein tambaleándose normalmente los beneficios de cambiar a uno nuevo son mayores y debería hacerse más pronto que tarde; Si lo que tienes es la gran pirámide de Giza, pues si, es antigua y tiene sus secretos ocultos, pero es estable y aún da sus beneficios.
El problema es que al final todo depende de quien tome las decisiones, de lo bueno que sea evaluando riesgos y beneficios del valor que tenga.
#13 Te pongo una situación jodida: imagina que tienes un sistema Solaris programado en COBOL. Resulta que llega un momento en que tienes que sustituir las estaciones Sun del año del picor por unos equipos nuevos porque ya no dan más de si. Cambias los equipos y, por narices, cambiar de Solaris a, por ejemplo, Windows Server. Me parece que la versión de COBOL, para empezar, no va a ser ni de lejos la misma (igual es pasar de un 85 a un 2014). Y eso si encuentras a algún programador que pueda pillar el programa antiguo y pasarlo al sistema nuevo sin hacer mucho destrozo, que buenos programadores de COBOL no es que abunden.
Ahora, la otra posibilidad: antes de llegar a ese escenario, rehacer el programa desde cero, manteniendo todo lo más parecido posible al antiguo, pero con un sistema más actual (me da igual si es C++, .NET, Java o lo que sea) y tener tiempo para probarlo bien antes de hacer el cambio.
#14 Si sabes que vas a sustituir las estaciones y como dices no te queda otra que tocar código entonces desde mi punto de vista habría que actualizar pues riesgo aumenta, es posible que ya no sea el core estable que tenias, a la vez que el beneficio es mayor, puedes poner una tecnología que se adapte mejor a los nuevos equipos. No obstante, puede que hubiera una solución intermedia, virtualización, no se en Windows Server, pero en Centos yo he virtualizado Solaris 11 usando KVM. En este caso, otra vez, habría que evaluar los riesgos y beneficios y decidir.
Como ves mantengo mi postura, es la relación riesgo beneficio la que debería determinar el mejor momento para actualizar. Todavía no he recibido un argumento en contra suficientemente convincente, hay que evaluar los riesgos de mantener el core antiguo y los beneficios de actualizar a un sistema nuevo. En el momento en que los riesgos o el beneficio pasa a ser muy alto es el momento de cambiar.
#15 Igualmente seguirías teniendo el problema de que cada vez hay menos programadores de COBOL.
Me recuerda lo de 'parche sobre parche' o 'desde-cero' en el clásico ejemplo de los bancos y su COBOL o lo que tengan.
O cambiar ya, y arreglar todos los marrones que salgan a raíz de eso, o parche sobre parche y mantener sistemas arcaicos con la esperanza de que nunca haya que cambiarlos.
No trabajo en un banco (sólo por lo que me cuentan) así que no sé si están en proceso o sigue todo igual....
#1 en aseguradoras lo mismo. Software en cobol de hace 40 años, mal documentado y que a base de cambiar de manos ya no hay nadie con conocimiento funcional de todo. Software que es el núcleo, envuelto en mil capas de servicios web
#1 #4 Las cosas no son mejores por ser nuevas o antiguas. No conozco esos sistemas, antes de tocar algo que funciona pienso en riesgos y beneficios, y si, sé que el mantenimiento de esas plataformas tiene que ser complejo como poco. Pero tocar o cambiar estos "cores" muchas veces tiene más riesgos que beneficios, hasta que eso no cambie, yo tampoco metería mano, más cuando hay muchas ocasiones puedes usar un wrapper empleando la funcionalidad antigua sin llegar a modificarla junto con software de última tecnología ofreciendo nuevas funcionalidades.
Pues claro. Han aparecido nuevos usos, pero aún se siguen teniendo que sacar nominas, gestionar inventarios y llevar contabilidades.
¿Para que cambiar, lo que funciona, y sigue siendo esencialmente lo mismo?
#3 por que el dia que se rompa algo, que llegara, ni dios sabe como ostias estaba montado o como montarlo de nuevo en un equipo moderno puesto que los equipos que han muerto tienen 20 años o mas
Lo principal es untar a quien tienes que untar, lo demás es secundario...
Las nóminas solo son Core si tú e.lresa se dedica a hGerle nóminas a otras empresas . El inventario es Core si eres Amazon y la contabilidad es Core si vendes servicios de contabilidad. Parando resto de las empresas eso no es Core.
Super guay el core es legacy
#2 Esta review me ha tocado mi legacy core.
Nunca se me dio bien el Corel Draw.
Quizás sea lo único bueno que ha hecho la Junta de Andalucia, pero cambiaron el sistema de Hacienda:
Jupiter, Natural Adabas
x
Giro, SAP
En su día vi cursos de SAP "casi prometiendo" que te colaban en Hacienda. Creo que costaban 5.500 euros.
Un funcionario es un "gasto",
un externo es una "inversión".