Las empresas toman con naturalidad contar con software legacy o heredado: piezas que se desarrollaron cuando muchas de las tecnologías actuales no existían y cuando el mercado y los clientes requerían cosas muy diferentes a las que necesitan hoy, muchas veces por proveedores que ya no dan soporte al producto y que funcionan sobre hardware obsoleto o sistemas operativos con la vida útil ya vencida. En general, se trata de entramados complejos de código, con parches que fueron incorporándose con el paso de los años, que generan altísimos costos de mantenimiento y que obstaculizan la modernización del negocio, ya que incluir cualquier nueva característica implica un enorme desgaste de tiempo y recursos.

¿Cómo nos garantizamos que el producto software que creamos hoy no será el software Legacy de dentro de unos años? ¿Es posible apelar a una estrategia de desarrollo “a prueba de futuro”, en particular en tiempos tan vertiginosos como los que estamos viviendo?

En principio, el universo cloud y los microservicios nos quitan el peso de depender de proveedores específicos. El modelo de contenedores nos permite independizarnos de la infraestructura física y también del sistema operativo: son paquetes de elementos que nos permiten ejecutar una aplicación en distintos contextos. Cuanto más abierta y flexible sea la arquitectura elegida, más factibles serán los cambios a futuro y mayores posibilidades habrá de que el producto de software continúe siendo funcional y útil cuando las condiciones cambien. El mismo criterio corre para la elección de frameworks y los lenguajes de código.

Luego, en la etapa de construcción del producto de software, habrá que concentrarse en modularizar al máximo posible: uno de los grandes problemas del software legacy es esa estructura monolítica por la cual un cambio menor en un servicio podría producir efectos secundarios en cualquiera de los otros. Al separar los módulos en unidades funcionales interconectadas, se simplifican las potenciales modificaciones, reemplazos o eliminaciones que surjan. Y al mismo tiempo, se evita que cualquier actualización que exija el negocio, cualquier cambio en el comportamiento de los consumidores o cualquier disrupción producida por alguna nueva tecnología afecte el producto en su conjunto.

En esa misma línea, otra buena práctica es revisar las probables dependencias de productos de software externos y abstraerlas, de forma tal que si esos productos terceros por alguna razón dejan de funcionar o de tener soporte no “arrastren” a nuestra aplicación a fallas. Esas abstracciones permiten “mover” esas dependencias con costos mínimos y muy bajo riesgo.

Proporcionar la documentación adecuada de cómo se hicieron las pruebas y de toda la información sobre soporte y mantenimiento es una manera de tomar conciencia de que los desarrolladores pasan y los productos pueden sobrevivirlos: si en algún momento cambian los profesionales a cargo, es bueno que puedan sostener la línea y no tener que empezar de cero.

El cambio es constante. Los productos de software no pueden detenerlo. Pero, con las prácticas adecuadas y una serie de recaudos con la mirada puesta en el futuro, definitivamente pueden acompañarlo