Stack tecnologico: componenti tecnologiche attualmente in uso, ad es. database usato e rispettiva versione, ambiente di runtime, sistemi di notifica, sistemi di gestione di code, web server

Uso di componenti sostituibili con l’equivalente servizio cloud-native: componenti on-premise utilizzate dall’applicativo che sono sostituibili con servizi gestiti dal cloud provider, ad es. database, LDAP, load balancer, SMTP server

Dimensionamento delle componenti infrastrutturali: componenti infrastrutturali attualmente in uso che garantiscono il corretto funzionamento dell’applicativo, ad es. # di server, dimensione dello storage, CPU, memoria (questa informazione aiuta in particolare a calcolare l’impatto economico che la migrazione al cloud dell’applicativo può avere)

Utilizzo effettivo delle componenti infrastrutturali: utilizzo effettivo delle risorse sulla base di misurazioni effettive o stime (questa informazione aiuta in particolare a dimensionare il cloud di destinazione e a calcolare l’impatto economico che la migrazione al cloud dell’applicativo può avere)

Dipendenza dall’hardware fisico: situazione attuale in cui l’applicativo si trova in termini di dipendenza dall’hardware fisico, specificando ad esempio se si usano macchine virtuali, container oppure se l’applicativo o parti di esso sono su macchine fisiche

Misure di sicurezza: minacce a cui l’applicativo è esposto, specificando quali componenti e dati sono più vulnerabili e richiedono protezione

Sistemi on-premise da cui dipende: sistemi on-premise interni ed esterni da cui l’applicativo dipende, ad es. IDP, LDAP, sistema di notifiche. Non devono essere inclusi qui i sistemi già in cloud, come le piattaforme abilitanti della PA (ad es. Spid, PagoPA)

Sistemi on-premise che dipendono: sistemi on-premise interni ed esterni che dipendono dell’applicativo, ad es. i sistemi che consumano i dati dell’applicativo

Presenza di test di validazione: presenza di test che possano validare le eventuali modifiche da effettuare sul codice sorgente per ridurre il rischio di regressione (ad es. test unitari, di integrazione, funzionali, performance). Per un approfondimento su questa tipologia di test vedi capitoli 5.5 e 6.4

Modificabilità del codice sorgente: livello di modificabilità del codice sorgente, che può essere:

• nulla, ovvero inesistente

• parziale, se il codice può essere parzialmente modificato ad es. influenzando le scelte evolutive del prodotto realizzato da terze parti

• completa, se il codice sorgente può essere completamente modificato ad es. in quanto se ne ha la proprietà o se la licenza del codice sorgente lo permette (ad es. open source)

Disponibilità di documentazione tecnica: disponibilità della documentazione tecnica che spiega il funzionamento interno dell’applicativo e delle sue componenti per intervenire in modo mirato e controllato. Per approfondimento sulla documentazione vedi capitolo 4.3.2.2

Connettività minima necessaria: impatto della connettività in termini di latenza ed ampiezza di banda, in relazione agli SLA che il fornitore deve garantire, sull’usabilità dell’applicativo. Si richiede di scegliere tra:

• rete locale, se l’accesso alla rete locale è un requisito vincolante all’usabilità di questo applicativo

• internet, se per l’applicativo l’accesso a internet è un requisito vincolante all’usabilità di questo applicativo

Dimensione della base di dati: dimensione dei dati da migrare nell’unità di misura opportuna fra Byte, KB, MB, GB, TB, ecc.

Frequenza di consultazione dei dati (annuale): ogni quanto i dati vengono consultati nell’arco di un anno

Frequenza di aggiornamento dei dati (annuale): ogni quanto i dati vengono aggiornati nell’arco di un anno

Ciclo di vita dei dati: quantità di tempo dopo la quale il dato può essere considerato obsoleto e quindi eliminabile dal sistema. Seguire le indicazioni di data retention del GDPR laddove applicabili. Si consiglia qui, se ritenuto necessario, di differenziare per tipologia di dato

Applicativi che trattano gli stessi dati: applicativi che trattano gli stessi dati gestiti da questo applicativo (tutti o un sottoinsieme). In particolare, si fa riferimento a quegli applicativi che hanno una copia dell’insieme di dati considerato e che necessitano una sincronizzazione. Si consiglia di riportare in questo campo sia i nomi degli applicativi che il sottoinsieme dei dati trattati

Rappresentanti delle aree impattate: persone da coinvolgere o da tenere informate sia perchè con potere decisionale, sia perché utilizzatrici dell’applicativo o perché impattate dalla migrazione. Si raccomanda di considerare un eventuale coinvolgimento di personale esterno all’amministrazione (ad es. fornitori con un’influenza sulla migrazione). Nella scheda di assessment è presente un foglio di lavoro separato da riempire con queste specifiche informazioni

Processi impattati e punti di attenzione: Riportare i processi interni o esterni dell’organizzazione che vengono impattati da questo applicativo e se vi sono dei punti d’attenzione da considerare durante il processo di migrazione

# medio di utenti unici giornalieri negli ultimi 12 mesi: numero medio di utenti unici in un giorno nell’ultimo anno. Il periodo considerato di 12 mesi vuole evitare periodi di prolungato inutilizzo. Per questo campo si consiglia di utilizzare, se disponibili, i dati degli strumenti di analytics

# massimo di utenti unici giornalieri negli ultimi 12 mesi: numero massimo di utenti unici in un giorno nell’ultimo anno. Il periodo considerato di 12 mesi vuole evitare periodi di prolungato inutilizzo. Per questo campo si consiglia di utilizzare, se disponibili, i dati degli strumenti di analytics

# minimo di utenti unici giornalieri negli ultimi 12 mesi: numero minimo di utenti unici in un giorno nell’ultimo anno. Il periodo considerato di 12 mesi vuole evitare periodi di prolungato inutilizzo. Per questo campo si consiglia di utilizzare, se disponibili, i dati degli strumenti di analytics. Se ci sono giorni in cui l’applicativo è inutilizzato o spento, mettere “0” come valore

Periodi di utilizzo in una settimana: fasce orarie in cui il servizio è utilizzato durante una settimana. Devono essere evidenziate qui eventuali fasce in cui si hanno picchi di utilizzo significativo. Se l’utilizzo è mediamente costante nell’arco della giornata e della settimana, indicare “utilizzo omogeneo”

Periodi di utilizzo in un mese: fasce orarie in cui il servizio è utilizzato durante il mese. Devono essere evidenziate qui eventuali fasce in cui si hanno picchi di utilizzo significativo. Se l’utilizzo è mediamente costante nell’arco del mese, indicare “utilizzo omogeneo”

Periodi di utilizzo in un anno: fasce orarie in cui il servizio è utilizzato durante l’anno. Devono essere evidenziate qui eventuali fasce in cui si hanno picchi di utilizzo significativo. Se l’utilizzo è mediamente costante nell’arco dell’anno, indicare “utilizzo omogeneo”

Costi dell’infrastruttura: tempi e costi per l’allestimento, la manutenzione dell’infrastruttura attuale ed il suo eventuale potenziamento (provisioning di nuove risorse). Questa informazione aiuta in particolare a calcolare l’impatto economico che la migrazione al cloud dell’applicativo può avere.

Licenze: tutte licenze che sono utilizzate, specificando il loro costo e quando scadono. Anche questa informazione aiuta in particolare a calcolare l’impatto economico che la migrazione al cloud dell’applicativo può avere. Nella scheda di assessment è presente un foglio di lavoro separato da riempire con queste specifiche informazioni. Per il riuso considerare le Linee Guida su acquisizione e riuso di software per le pubbliche amministrazioni pubblicate su Docs Italia

Criticità: eventuali aspetti critici dell’applicativo, ad esempio:

• performance o stabilità che impattano l’operatività degli utenti finali o richiedono una spesa specifica per la loro risoluzione temporanea (perché una definitiva non è attualmente possibile)

• conformità normativa, ad esempio GDPR

• sicurezza

Evoluzione del servizio nei prossimi tre anni: aree di evoluzione previste o ipotizzate per il servizio supportato dall’applicativo per identificarne la centralità rispetto alla strategia dell’organizzazione. Tenere in considerazione, nel caso siano disponibili, i piani pluriennali definiti ed eventuali scadenze già definite. Considerare qui la tipologia e la numerosità delle evoluzioni attese per l’applicativo

Alternative SaaS: esistenza di alternative SaaS per l’applicativo in analisi all’interno del Cloud Marketplace di AGID

Disponibilità di import dei dati: garanzia che il fornitore SaaS provveda la possibilità di importare i dati all’interno del servizio SaaS tramite formati pubblici e aperti