I prodotti che arrivano oggi sul mercato sono raramente puramente meccanici. Auto, macchine industriali, tecnologia medica: ovunque c’è del software. Ed è una buona notizia: il software si può aggiornare, si possono correggere errori o aggiungere funzioni, senza che il cliente debba restituire fisicamente il dispositivo.
Ma questa promessa vale anche nella pratica? Chi ha mai avuto tra le mani un dispositivo vecchio che non riceve più aggiornamenti conosce già la risposta: non da solo.
Gli aggiornamenti software a lungo termine non sono una legge naturale della tecnica. Sono il risultato di decisioni consapevoli — nell’architettura di prodotto, nel modello di business e nei processi con cui requisiti e test vengono gestiti lungo tutto il ciclo di vita.
Di questo ho parlato nel mio intervento “Leveraging Long Term Software Update Strategies” al Siemens Realize LIVE 2024 a Las Vegas (il resoconto della conferenza lo trovate qui). Il tema centrale della fiera era la sostenibilità — e l’argomento di fondo è in realtà semplice: un prodotto è davvero sostenibile quando dura a lungo. E dura a lungo quando può continuare a ricevere aggiornamenti software anche nel lungo periodo.
Per questo devono combinarsi tre elementi.
1. Il modello di business deve rendere possibili gli aggiornamenti
Sembra ovvio, ma non lo è. Molte aziende hanno storicamente guadagnato con l’hardware. Il supporto era un’appendice, che doveva costare il meno possibile. In questa logica, aggiornamenti software gratuiti per tutta la vita del prodotto sono solo un costo senza ritorno.
La domanda è quindi: chi deve pagarli? Se la risposta è «nessuno», allora nessuno si occuperà di far sì che gli aggiornamenti siano fatti bene — o che arrivino affatto.
Può essere un contratto di servizio, un modello in abbonamento, un livello di supporto a scaglioni. Il modello in sé conta relativamente poco. Decisivo è che fornire buoni aggiornamenti software sia economicamente sostenibile. Altrimenti la sostenibilità resta pura retorica.
2. L’architettura di prodotto deve permetterlo
Il secondo problema è tecnico: molti prodotti sono cresciuti in modo tale che un aggiornamento software per una determinata generazione di prodotto equivarrebbe a un completo nuovo sviluppo. Chi ha legato strettamente meccanica, elettronica e software — perché allora bisognava fare in fretta — si ritrova con un problema quando, cinque anni dopo, bisogna aggiornare un componente software.
Modularizzazione e standardizzazione sono qui le parole chiave. Se i componenti software hanno interfacce ben definite e il maggior numero possibile di generazioni di prodotto condivide la stessa base software, un aggiornamento diventa pianificabile ed economicamente sensato.
Più facile a dirsi che a farsi. Ma è una decisione che si può prendere consapevolmente — e prima la si prende, più conviene.
3. L’ALM garantisce la trasparenza necessaria
Supponiamo che il modello di business sia corretto e l’architettura sia modulare. Arriva allora la terza sfida: come mantengo il controllo su quali requisiti sono confluiti in quale componente software? Quali test esistono per verificarli? Quali dipendenze tra componenti potrebbero bloccare un aggiornamento?
È esattamente qui che entrano in gioco gli strumenti di ALM. L’Application Lifecycle Management — con strumenti come Polarion, Codebeamer o Jira — crea un collegamento continuo tra requisiti, sviluppo, test e consegna. Nel caso ideale il sistema sa:
- Quale requisito ha generato quale funzione?
- Quali test verificano questa funzione?
- Quali altri componenti dipendono da essa?
Questa trasparenza è il presupposto per un elevato grado di automazione. Se l’impatto di un aggiornamento pianificato è visibile con un clic, i cicli di sviluppo possono essere notevolmente abbreviati — e il rischio di rompere qualcosa diminuisce.
- Il modello di business deve prevedere gli aggiornamenti software come fonte di ricavo — senza una base economica gli aggiornamenti non vengono forniti in modo sostenibile
- L’architettura di prodotto ha bisogno di modularizzazione e interfacce chiare, affinché il maggior numero possibile di generazioni di prodotto possa beneficiare degli stessi aggiornamenti
- Gli strumenti ALM, usati correttamente, creano la trasparenza su requisiti, test e dipendenze — la base per l’automazione e per aggiornamenti sicuri
Guardare l’intervento
Per chi vuole vedere il tutto in forma di intervento: il video è disponibile su YouTube.
Una nota sul tema sostenibilità e viaggi aerei verso Las Vegas: la domanda è legittima. Non voglio assolvermi da solo — ma le emissioni di CO2 del mio volo le ho compensate di tasca mia tramite un fornitore certificato.
