Anche il software è soggetto allo scorrere del tempo. Invecchia, esattamente come noi. Anzi, in modo molto più rapido di noi. Per mantenere la sua utilità, deve quindi venire manutenuto ed evoluto.
Per quali ragioni, un servizio digitale ha l’esigenza di evolvere?
Il primo fattore è legato a tutto ciò che possiamo definire dinamiche di business: l’attività delle aziende si evolve nel tempo e il software, che nasce per essere uno strumento che supporta e promuove il business, deve di conseguenza evolvere con lui.
Ma non è l’unico motivo: anche l’ecosistema tecnologico in cui si inserisce il servizio digitale cambia e impone evoluzioni per mantenere la funzionalità del software.
Cosa succede a questo punto? Molto spesso, quando un servizio digitale viene fatto evolvere, viene aggiunto un pezzetto in più alla sua architettura originale. Ogni volta che un software subisce una modifica si crea dunque una stratificazione di nuove funzionalità e configurazioni. Qui i possibili scenari sono molto diversi tra loro e dipendono dalle modalità di gestione della manutenzione.
Una manutenzione gestita in modo organizzato ed in ottica continuativa può prolungare la validità del software ai fini del business per molto tempo, in certi casi anche compensando la stratificazione con un’attività di risoluzione dei fattori di complessità pre-esistenti, ad esempio con attività che vanno a “ricompattare” interventi incrementali passati.
Questa “buona pratica” è tuttavia rara oggigiorno, principalmente per la necessità di dar risposta in tempi strettissimi a esigenze di business che nascono in modo imprevisto e generano situazioni di urgenza. In questi casi, accade che il tempo e le risorse dedicate all’attività ridotti all’osso spingano a optare per modifiche posticce, effettuate senza prendere in esame l’architettura del software su cui vanno ad innestarsi .
In questi casi, o comunque in assenza di un piano di manutenzione preventivamente definito cosa accade? Accade che l’aggiunta di nuovi layer avviene in modo caotico e l’intera applicazione diventa nel tempo qualcosa di articolato e disordinato. La complessità dell’architettura aumenta.
A noi piace scrivere, dai un’occhiata alle nostre guide e approfondimenti
Library di Innovazione Digitale.--. .---. .---|__| .-. |~~~| .--|===|--|_ |_| |~~~|--. | |===| |'\ .---!~| .--| |--| |%%| | |.'\ |===| |--|%%| | | |%%| | |\.'\ | | |__| | | | | | | | \ \ |===| |==| | | | | | |__| \.'\ | |_|__| |~~~|__| | |===|--| \.'\|===|~|--|%%|~~~|--| ^--^---'--^ `-'`---^-^--^--^---'--'
L’effetto dell’usura del servizio digitale è dunque spesso un suo degrado a livello di coerenza dell’architettura. Il software diventa più complesso ed intervenire su di esso richiede analisi sempre più approfondite, ed ovviamente onerose. Ma non solo: diventa anche più fragile, dal momento che ogni intervento su di uno strato intermedio mette a rischio la funzionalità di quelli che si appoggiano su di esso.
L’usura non comporta problemi solo a livello di manutenibilità. La maggiore complessità compromette anche la funzionalità del software: le performance potrebbero essere impattate e si potrebbero registrare più facilmente malfunzionamenti, mentre i costi operativi rischiano di crescere nel tempo. A questo punto, il servizio digitale passa dall’essere un supporto all’essere un pericolo per il business.
Non è possibile bloccare lo scorrere del tempo e l’evoluzione di business e tecnologie. Come contenere allora i rischi di usura del software? Agendo fin dall’inizio: è necessario da un lato sviluppare da subito un prodotto pensato per essere durevole e, dall’altro, controllarne con costanza il processo di invecchiamento prevedendo un piano di manutenzione ed evoluzione che ne gestisca la long tail del ciclo di vita.
Per ogni prodotto software che realizza, Bottega52 garantisce un servizio di tenuta in funzione che si distingue per l’adozione di un’ottica di risk management e di un modello di gestione delle operations basato su di un processo continuativo di manutenzione ed aggiornamento.
,---------------------------------------.---------. | | | | ,-----------------------------. | . | | | | | | | | | ,-------------------. | | | | | | | | | | | | | | `---- ,---- | | | | | | | | @ | | | | | | | ,---------"---------: | `----' | | | | | | | | `----: ,---------. | `---------. | | | | | | | | | . | | . | | ---------' | | | | | | | | | :----' | | | | | ,--------------: | | | | | | | | | . | `----' | | | ----. | | | | | | | | | | `----"--------- | | `---------' | | | | | `------------------------' `-------------------'