Llevo desde hace tiempo con la idea de escribir esta entrada, a partir de experiencias personales en el mundo laboral, y la noticia sobre el fin de soporte a Windows XP por parte de Microsoft me ha animado a escribirla.

Podemos leer en Tweaktown.com la siguiente noticia:

ATM operators to replace Windows XP with Linux.

Many banks and ATM operators are making plans to migrate its ATM systems to Linux as Windows XP’s support will no longer be provided from April 8th. The report indicated that this will allow companies and operators to have more control over the hardware and software of the machines.

Si habéis estado atentos a las noticias de tecnologías de los últimos meses, ya sabréis que Microsoft anuncio el fin de soporte a Windows XP hace unos cuantos meses.

Algo normal si pensamos en que el veterano SO de Microsoft cuenta ya con 12 años de vida, que ha sido parcheado muchas veces y ha recibido hasta 3 Services Pack en todos esos años. Muchos dirán que todo esto no es más que una estratagema para obligar a los usuarios a migrar a Windows 7 o Windows 8 (el primero tiene mucha más aceptación en las empresas), pero lo cierto es que habiendo probado XP y W7 debo decir que me quedo con el segundo de lejos.

Aunque Windows XP supuso en su día un SO de éxito y un soplo de aire fresco en comparación con W98, NT o W2000 en las empresas, no está libre de sus ‘achaques’ y pegas, como su progresivo deterioro en su rendimiento a medida que pasa el tiempo.

Además de que nunca ha contado con una versión de 64bits en condiciones, quitando una versión que tenía sus problemas, lo que en un entorno donde lo habitual son equipos con un mínimo de 4GB de RAM supone desperdiciar recursos por culpa de las limitaciones de XP.

Pero lo realmente llamativo de todo este asunto, no es que XP desaparezca, sino el hecho de que haya pillado a tantas y tantas empresas con el pie cambiado, y que sus respectivos departamentos de TI no hayan previsto antes esta eventualidad (más aún en un sector como el bancario).

Nada es para siempre.

Efectivamente, como dice el dicho no hay nada eterno, y mucho menos en el mundo del Software donde todo discurre a una velocidad de vértigo.

Sin embargo, aún es muy habitual encontrarse con software ‘heredado’ (Legacy Software) de una época anterior que de repente, como en el ejemplo de Microsoft y XP, pasa de ser una verdad absoluta a ser un quebradero de cabeza para los responsables de TI o del propio software porque ‘se queda desfasado’.

Entonces, de repente, ese software que hasta entonces nadie cuestionaba y todos usaban, al que tan solo había que dedicar un poco de mantenimiento, pasa a ser considerado con uno o varios de los siguientes adjetivos: obsoleto, anticuado, ineficaz, desfasado, problemático, inútil…

Pero si nos fijamos, resulta que la mayoría de calificativos se pueden unificar en uno solo: antiguo.

Pero, realmente ¿es algo que ha sucedido sin más de un día para otro?

En realidad no, pero en este mundo del Software, como mencionaba antes, el tiempo es aún más inexorable de lo habitual y lo que hoy se considera ‘moderno’, en apenas unos cuantos años se ve superado por los avances que surgen, y más adelante se van quedando obsoletos porque nada permanece inmutable, ni el software, ni nuestra empresa, ni nuestro método de trabajo, ni nuestros productos y ni siquiera nosotros mismos.

Y si hablamos de sistemas que surgen ligados a plataformas hardware propietarias, o que con el tiempo no evolucionan como la competencia y se van quedando atrás, o simplemente no tienen la debida acogida y son descontinuadas, el problema es aún más grave puesto que ya no se trata solo de que nuestro software esté ‘mayor’, sino que encima el hardware sobre el que funciona también puede fallarnos y encontrarnos con el problema de no poder encontrar ni los repuestos necesarios.

Pero, ¿podemos evitarlo o al menos prevenir futuros problemas?

Trabaja en el presente, pero pensando en el mañana.

Hace años, cuando la Informática empezó a llegar a las empresas (antes de hacerlo masivamente en los hogares) lo habitual era ver cómo una empresa se gastaba mucho dinero en adquirir sistemas propietarios que se iban amortizando a lo largo de los años. Eran sistemas que se adquirían pensando en que durasen muchos años, en una época en que las innovaciones iban llegando más despacio, lo que daba margen a acometer en un momento dado del futuro la migración de estos sistemas a futuros sistemas (compatibles o no).

Y quizás de aquella época también se ha heredado ese pensamiento de que el sistema que empecemos a diseñar hoy y al que migremos mañana, vendrá para quedarse durante mucho tiempo o será una solución casi eterna.

Pero lo cierto es que aunque incluso los sistemas en sí, nuestra aplicación, pueda tener una vida ‘larga y próspera’, deberemos de tener siempre un ojo puesto en el futuro. No solo por las futuras funcionalidades que debamos de integrar el día de mañana porque nuestro negocio evolucione, o las que debamos actualizar si nuestro negocio cambia, sino también por los cambios tecnológicos que surgirán:

• Evolución del hardware.
• Evolución del Sistema Operativo.
• Evolución de los COTS (Software de terceros) que utilicemos.
• Evolución de los Lenguajes de Programación.

Así, si lo que estamos estudiando es integrar un Software de Terceros al completo (por ejemplo un sistema SAP) deberemos de tener en cuenta además de lo obvio: ¿soluciona mis necesidades y requisitos?; cosas como cuál será su evolución, tiempo de vida y soporte de la empresa propietaria a la versión que adquiramos, si el software está ligado a una plataforma hardware cerrada o podemos cambiarla sin un gran impacto, cómo de complejas son las migraciones entre versiones, el coste de dichas migraciones (en tiempo y dinero por los upgrades a versiones superiores), o incluso el software que usa por debajo para estar seguros de que en el futuro no nos dejarán colgados.

Y si nuestro caso es el de contratar un desarrollo a medida, además de los puntos anteriores también deberemos tener en cuenta las características más técnicas de la solución que nos propongan:

• Arquitectura SW de la aplicación: escalabilidad (en el futuro puedo necesitar más servidores), flexibilidad (para incluir nuevas funcionalidades, incluso debiendo mantener las antiguas o distintas versiones de la misma funcionalidad), robustez, seguridad…
• Arquitectura HW: ¿va ligado a un HW específico? ¿puedo instalarlo en el HW de otro fabricante sin problemas?
• Lenguaje de implementación: versión usada para el desarrollo, conocer los ciclos de vida de las versiones y si se asegura retrocompatibilidad, cómo de conocido y aceptado está por la comunidad de desarrolladores (un lenguaje muy potente pero poco conocido dificultará encontrar gente que lo mantenga o evolucione), si hay más empresas que trabajen con él (en un momento dado podemos querer cambiar de proveedor).
• COTS: quién los evoluciona y da soporte, si están basados en estándares o son propietarios, si requieren de contratar soporte externo, compatibilidad de los mismos entre ellos, con la plataforma HW o con el lenguaje que los implementa.

El haber previsto en mayor o menor medida todo esto nos ayudará a poder migrar nuestros sistemas, ya sea de forma total o solo en lo que respecta al SW de base y/o plataforma que usemos, consiguiendo así que no solo no se quede ‘antiguo’, sino que su vida útil se pueda alargar.

Tener en cuenta además de que en el caso de desarrollos de grandes sistemas a medida, desde el momento en que se toma la decisión de diseñarlo y solicitar su desarrollo, hasta su puesta en funcionamiento pueden haber pasado 2-4 años, tiempo más que suficiente para que la vida útil del HW o los COST usados se haya reducido a unos pocos años más.

En la próxima entrada, veremos con un ejemplo real cómo se detectó y solventó una de estas situaciones.
photo credit: x-ray delta one via photopin cc