Curiosamente, los humanos tendemos a sobreestimar el futuro cercano y a subestimar el futuro lejano. Hace 10 años muchos pronosticamos la muerte de los dinosaurios tecnológicos (sistemas legados corriendo en mainframes), los pronósticos eran para los próximos 3 o 4 años. La muerte de los dinosaurios sigue siendo inevitable, pero el tiempo ha pasado inexorable.
El problema de los sistemas legados no es propio del tercer mundo, ni por mucho, entre más grande la organización, más grande es el probable problema. El problema va mucho más allá de los altos costos, aunque siempre se han tratado de justificar los proyectos de reemplazo y/o modernización en base a los costos. Otros problemas que acarrean los dinosaurios tecnológicos son la escasez de personal, la cual se acentúa más cada día, la falta de documentación y la falta de flexibilidad (es muy difícil efectuarle cambios y modificaciones).
Ninguno de los anteriores se traduce a dólares fácilmente, lo cual dificulta la justificación financiera.
Pero, tal vez, el obstáculo más grande a la modernización son las constantes presiones de los usuarios por más y mejores funcionalidades, ya que cuando se intenta cambiar la tecnología y la funcionalidad al mismo tiempo aumenta el riesgo, y si se intenta cambiar solo la tecnología el usuario no percibe valor agregado.
Para complicar aún más la trama, durante los últimos 10 años, los costos de los mainframes han bajado mucho (en términos de costo y desempeño) y la tecnología de middleware se ha desarrollado enormemente. Middleware permite tapar el sol con un dedo, por lo menos durante un tiempo. Con buenas aplicaciones de middleware es posible actuar como si el sistema legado no existiera, construir nuevas fachadas y nuevas funcionalidades alrededor del sistema legado minimizando al máximo la necesidad de modificar el sistema legado.
La pregunta difícil es: ¿hasta cuándo se podrá tapar el sol con un dedo? Los cínicos dicen que esa pregunta se debe hacer en base al tiempo de servicio del Director de Tecnología (o más bien ¿cuánto tiempo le falta?), pero eso es a todas luce irresponsable.
Haciendo nuevas y mejores interfases no desaparece el problema. Las manera responsable de enfocar el problema es lo antes posible, aunque la solución no necesariamente debe ser de golpe y porrazo. De hecho hay tres enfoques posibles.
El enfoque de golpe y porrazo se le llama en inglés “rip and replace” y consiste es reemplazar el sistema legado por un paquete, este tipo de proyectos pueden ser altamente riesgosos (las estadísticas a nivel mundial no arrojan un porcentaje de éxito que estimule el enfoque), pero el mayor riesgo puede ser salir del sartén para caer en el fuego, esto es pasar de depender de un proveedor de hardware a depender de uno de software. Una ventaja de este enfoque es el aprovechar las buenas prácticas del negocio que vienen incluidas en el paquete, aunque claro está las “mejores prácticas” no se venden, esas las tienen los líderes del mercado y no las comprante fácilmente. Este enfoque en ocasiones es llamado la estrategia del empate, ya que se puede aspirar a empatar con todos los competidores que adquieran el mismo paquete.
El otro enfoque es el de rediseño y desarrollo desde cero. Este enfoque es riesgoso por el tiempo requerido, pero tiene el potencial de ofrecer una posible ventaja competitiva (si se tienen procesos del negocio únicos). Desafortunadamente las estadísticas muestran porcentajes de éxito de este tipo de proyectos aún inferiores a los de implementación de paquetes.
El tercer enfoque es el de la conversión de los sistemas legados a nuevas tecnologías. Este tipo de proyectos presenta un menor riesgo ya que los requerimientos son claros y fijos (reproducir la funcionalidad del sistema legado con nueva tecnología), el costo suele ser menor que el desarrollo, pero puede ser mayor que la implantación de paquetes. Hay dos maneras de hacer este tipo de proyectos, manualmente con empresas de software con procesos muy maduros (CMMI nivel 5) o utilizando herramientas modernas que convierten un alto porcentaje de manera automática.
Obviamente la mejor estrategia es diferente para cada empresa y para cada sistema. En el trabajo de investigación que realizó Declan Good para el Club de Investigación Tecnológica en 2002 hay una excelente guía para tomar este tipo de decisión. Un modelo basado en la volatilidad del sistema (qué tan frecuentemente sufre cambios) y la unicidad del mismo (qué tan particular a la empresa en el sistema) ofrece muy acertadas recomendaciones para proceder.
Lo que definitivamente es irresponsable es continuar posponiendo la muerte de los dinosaurios asumiendo que le tocará a otro su ejecución.
Artículo publicado en la revista Blue Tech
