Los productos que llegan hoy al mercado rara vez son puramente mecánicos. Coches, maquinaria industrial, tecnología médica: en todas partes hay software. Y eso, de entrada, es bueno. El software se puede actualizar, corregir errores, añadir funciones nuevas, sin que el cliente tenga que devolver físicamente el equipo.
Pero ¿se cumple esa promesa en la práctica? Quien haya tenido en las manos un dispositivo antiguo que ya no recibe actualizaciones conoce la respuesta: no por sí sola.
Las actualizaciones de software a largo plazo no son una ley natural de la tecnología. Son el resultado de decisiones conscientes: en la arquitectura del producto, en el modelo de negocio y en los procesos con los que se gestionan los requisitos y las pruebas a lo largo de todo el ciclo de vida.
De eso trataba precisamente mi ponencia “Leveraging Long Term Software Update Strategies” en SIEMENS Realize LIVE 2024 en Las Vegas (el informe de la conferencia lo encontráis aquí). El foco de la feria era la sostenibilidad, y el argumento detrás es en realidad sencillo: un producto es realmente sostenible cuando tiene una vida larga. Y tiene una vida larga cuando puede recibir actualizaciones de software también a largo plazo.
Para ello deben encajar tres piezas.
1. El modelo de negocio tiene que permitir las actualizaciones
Suena evidente, pero no lo es. Muchas empresas han ganado históricamente su dinero con el hardware. El soporte era un anexo que debía costar lo menos posible. En esa lógica, las actualizaciones de software gratuitas y de por vida son un bloque de costes sin retorno.
Por eso la pregunta es: ¿quién va a pagar esto? Si la respuesta es “nadie”, tampoco habrá nadie que se asegure de que las actualizaciones sean buenas, o de que lleguen siquiera.
Puede ser un contrato de servicio, un modelo de suscripción, un nivel de soporte escalonado. El modelo en sí tiene un papel secundario. Lo decisivo es que ofrecer buenas actualizaciones de software resulte rentable. De lo contrario, la sostenibilidad se queda en retórica.
2. La arquitectura del producto tiene que permitirlo
El segundo problema es técnico: muchos productos han crecido de tal forma que una actualización de software para una generación de producto determinada supondría un desarrollo completamente nuevo. Quien haya acoplado estrechamente mecánica, electrónica y software —porque en su momento había que ir rápido— tiene un problema cuando, cinco años después, hay que actualizar un componente de software.
Aquí la palabra clave es modularización y estandarización. Cuando los componentes de software tienen interfaces claramente definidas y el mayor número posible de generaciones de producto comparte la misma base de software, una actualización se vuelve planificable y económicamente viable.
Esto es más fácil de decir que de hacer. Pero es una decisión que se puede tomar conscientemente, y cuanto antes se tome, más barata sale.
3. El ALM aporta la transparencia necesaria
Supongamos que el modelo de negocio es correcto y la arquitectura es modular. Entonces llega el tercer reto: ¿cómo mantengo la visión de conjunto sobre qué requisitos han entrado en qué componente de software? ¿Qué pruebas existen para ello? ¿Qué dependencias entre componentes podrían bloquear una actualización?
Aquí es donde entran en juego las herramientas de ALM. Application Lifecycle Management —con herramientas como Polarion, Codebeamer o Jira— crea una conexión continua entre requisitos, desarrollo, pruebas y entrega. En el caso ideal, el sistema sabe:
- ¿Qué requisito ha desencadenado qué función?
- ¿Qué pruebas verifican esa función?
- ¿Qué otros componentes dependen de ella?
Esta transparencia es el requisito previo para un alto grado de automatización. Cuando el impacto de un cambio de una actualización planificada es visible con solo pulsar un botón, los ciclos de desarrollo pueden acortarse notablemente, y el riesgo de romper algo disminuye.
- El modelo de negocio debe contemplar las actualizaciones de software como fuente de ingresos; sin una base económica, las actualizaciones no se entregan de forma sostenible
- La arquitectura del producto necesita modularización e interfaces claras, para que el mayor número posible de generaciones de producto pueda recibir las mismas actualizaciones
- Las herramientas de ALM, bien empleadas, aportan la transparencia sobre requisitos, pruebas y dependencias: la base para la automatización y las actualizaciones seguras
Ver la ponencia
Para quien quiera verlo en formato de charla: el vídeo está disponible en YouTube.
Una nota sobre sostenibilidad y vuelos a Las Vegas: la pregunta es legítima. No pretendo darme con ello la absolución, pero compensé de mi propio bolsillo las emisiones de CO2 de mi vuelo a través de un proveedor certificado.
