L’application maintenance comprende le attività necessarie per mantenere un’applicazione aziendale affidabile, sicura, aggiornata e compatibile con l’evoluzione dell’ecosistema IT. Interviene dopo il rilascio del software e prosegue lungo l’intero ciclo di vita, governando correzioni, adeguamenti tecnici, aggiornamenti e modifiche funzionali.
La manutenzione applicativa, quindi, non coincide con il semplice supporto agli utenti. Un sistema ERP, un’applicazione verticale o una piattaforma cloud dipendono da interfacce, database, servizi esterni, configurazioni e componenti infrastrutturali. Una modifica apparentemente circoscritta può influire su processi e sistemi collocati in altre aree dell’architettura.
Gestire l’application maintenance significa controllare queste dipendenze e introdurre i cambiamenti senza compromettere la continuità operativa.
Che cosa comprende l’application maintenance
Lo standard ISO/IEC/IEEE 14764:2022¹ colloca la manutenzione del software tra i processi del ciclo di vita e ne descrive attività, compiti e differenti tipologie. La manutenzione deve quindi essere pianificata, eseguita, controllata e valutata, esattamente come lo sviluppo iniziale.
La manutenzione correttiva interviene quando l’applicazione non si comporta come previsto. Può riguardare, per esempio, un errore nel calcolo di un prezzo, nella contabilizzazione di un documento o nello scambio di dati con un sistema esterno.
La manutenzione adattiva adegua invece il software a un contesto modificato. Rientrano in questa categoria gli interventi necessari in seguito all’aggiornamento di un sistema operativo, alla variazione di un’API, all’introduzione di nuovi requisiti normativi o alla migrazione di un servizio verso il cloud.
La manutenzione preventiva punta a ridurre la probabilità di problemi futuri. Comprende aggiornamenti, sostituzione di componenti obsoleti, revisione del codice e consolidamento delle integrazioni.
La manutenzione evolutiva, infine, introduce o modifica funzioni in risposta alle esigenze aziendali: un nuovo workflow approvativo, una regola di controllo, un report o l’automazione di un’attività manuale.
Nella pratica, le quattro aree si sovrappongono. Una correzione può evidenziare una configurazione ormai inadeguata, mentre un adeguamento normativo può richiedere modifiche applicative, nuovi test e la revisione delle interfacce.
Gestire le dipendenze prima di modificare l’applicazione
Il punto di partenza di ogni intervento dovrebbe essere l’impact analysis, cioè la valutazione preventiva delle componenti coinvolte e delle conseguenze che la modifica può produrre.
In un ambiente SAP, per esempio, una variazione apportata a un’anagrafica, a una regola di pricing o a un processo autorizzativo può interessare moduli diversi, sviluppi ABAP, applicazioni esterne e flussi di integrazione. Anche un intervento limitato a una schermata può modificare dati utilizzati da sistemi di analytics, portali, piattaforme logistiche o applicazioni di fabbrica.
L’impact analysis deve ricostruire il percorso seguito dal dato e identificare applicazioni coinvolte, interfacce, personalizzazioni, utenti, autorizzazioni e finestre operative. Deve inoltre stabilire quali processi saranno oggetto dei test e quali condizioni consentiranno di considerare la modifica correttamente rilasciata.
Questa attività richiede una documentazione aggiornata dell’ecosistema applicativo. Diagrammi delle integrazioni, inventario delle interfacce, specifiche funzionali, configurazioni e storico delle modifiche riducono il rischio di dipendere dalla conoscenza individuale dei tecnici. Permettono inoltre di valutare l’intervento prima che il problema raggiunga l’ambiente produttivo.
La tracciabilità mantiene il collegamento tra richiesta iniziale, analisi, modifica eseguita, test, approvazione e rilascio. In caso di anomalia, consente di ricostruire rapidamente che cosa è cambiato e quali componenti possono essere interessate.
Patch, aggiornamenti e test di regressione
Gli aggiornamenti tecnici costituiscono una parte rilevante dell’application maintenance. Possono correggere vulnerabilità, risolvere difetti, introdurre requisiti di compatibilità o rendere disponibili nuove funzioni. Non devono però essere trattati come operazioni isolate.
La NIST Special Publication 800-40 Rev. 4² definisce l’entreprise patch management come un processo che comprende identificazione, prioritizzazione, acquisizione, installazione e verifica di patch, aggiornamenti e upgrade. Il NIST lo considera una forma di manutenzione preventiva finalizzata a ridurre compromissioni, violazioni dei dati e interruzioni operative.
Prima del rilascio occorre verificare prerequisiti, compatibilità e dipendenze. In un sistema personalizzato, una patch del produttore può entrare in conflitto con codice custom, add-on o connettori sviluppati in precedenza. La decisione deve quindi considerare gravità del rischio, criticità del processo, complessità dei test e disponibilità di una procedura di rollback.
I test di regressione servono a controllare che le funzioni già operative continuino a produrre il risultato previsto. Devono essere costruiti sui processi reali e sui punti maggiormente esposti alla modifica, evitando verifiche troppo generiche. Dopo il rilascio è inoltre necessario controllare log, code di integrazione, tempi di elaborazione e correttezza dei dati generati.
Scalabilità e controllo dell’obsolescenza
Un ecosistema applicativo è scalabile quando può accogliere nuovi utenti, sedi, processi e applicazioni senza moltiplicare eccezioni, interventi manuali e dipendenze difficili da governare. L’application maintenance contribuisce a questo risultato attraverso standardizzazione delle configurazioni, riuso delle componenti, documentazione delle interfacce e controllo delle personalizzazioni. Ogni modifica dovrebbe essere valutata considerando il costo di manutenzione futuro, oltre all’esigenza immediata.
Anche l’obsolescenza tecnica deve essere gestita in modo programmato. Versioni non più supportate, librerie datate, API prossime alla dismissione e sviluppi privi di documentazione aumentano il rischio operativo. Se questi elementi vengono rilevati soltanto quando producono un incidente, l’azienda dispone di meno tempo per analizzare alternative, eseguire test e pianificare la sostituzione.
Gli strumenti di Application Lifecycle Management aiutano a mantenere una visione coordinata del ciclo di vita. SAP include nell’ALM³ la raccolta dei requisiti, la documentazione delle soluzioni, il trasferimento delle modifiche in produzione e i servizi necessari per l’operatività continuativa. SAP Cloud ALM, in particolare, supporta processi standardizzati per implementazione e gestione di ambienti cloud, on-premise e ibridi.
Dall’application maintenance a un servizio AMS strutturato
Quando il perimetro applicativo cresce, le attività di manutenzione devono essere organizzate attraverso responsabilità, priorità, procedure di rilascio e livelli di servizio definiti. Gli Application Maintenance Services forniscono questa struttura e collegano competenze tecniche, conoscenza dei processi e capacità di intervento continuativo.
Nel nostro modello di Application Maintenance Services integriamo gestione delle segnalazioni, monitoraggio delle performance, aggiornamenti, supporto evolutivo e affiancamento al team IT. L’obiettivo è mantenere affidabile l’ecosistema SAP e governarne l’evoluzione sulla base delle dipendenze applicative e delle priorità aziendali.
L’application maintenance assume così una funzione specifica e fondamentale: mantenere aggiornabili i sistemi, ridurre i rischi associati alle modifiche e preparare l’architettura ad accogliere nuovi processi senza perdere controllo, tracciabilità e continuità operativa.
Vuoi approfondire questi temi con i nostri esperti?
Prenota una call e raccontaci le esigenze della tua organizzazione.
¹ Fonte: iso.org
² Fonte: csrc.nist.gov
³ Fonte: support.sap.com
