Contenuto:
4. Allegato A: Istruzioni per il calcolo del TCO
Il capitolo pare essere stato preso di peso dalla Circolare 6/2013 (pagina 28 e seguenti), ma il copia&incolla è incompleto mancando i citati “esempio 1” e “figura 3”.
La parte mancante della circolare specifica un poco meglio i criteri di valutazione dei costi, in particolare quelli di “Migrazione dati e utenti”, ponendo l’accento sulla preferenza nei confronti dei formati aperti (la cui adozione da parte della soluzione in esame abbatte il suo costo di TCO).
Forse sarebbe opportuno rielaborare per intero il contenuto originale?
Quale metodologia/fonte è stata utilizzata per elaborare le istruzioni per il calcolo del TCO?
E’ previsto lo sviluppo di un tool ad hoc da fornire alle amministrazioni per il calcolo del TCO?
Come è possibile stimare il costo delle licenze per i software commerciali? Ad esempio, se un’applicazione utilizza un’istanza di Oracle DB e l’amministrazione ha sottoscritto un contratto di tipo ULA, come stimo il costo di tale licenza? Tecnicamente l’applicazione non genera alcun costo aggiuntivo diretto in quanto ho un accordo ULA, ma non penso sia corretto non imputare alcun costo di licenza.
Devo imputare il costo per adeguamento hardware ad una singola applicazione? Quindi se per un’applicazione devo acquistare un server che potrà essere utilizzato anche per altre applicazioni, dovrei imputare tutto il costo del server alla singola applicazione che genera l’esigenza di acquisto del server? E’ necessario imputare anche i costi di facilities (es. energia elettrica)?
Visto che le amministrazioni dovranno seguire un percorso di razionalizzazione dei data center e migrazione al cloud, è possibile aggiungere un riferimento al costo a consumo delle risorse Cloud?
Grazie,
Adriano Avenia
Potrebbe essere utile sviluppare, sulla base della metodologia individuata come riferimento da adottare, un piccolo tool che consenta di simulare l’intero TCO. Questo mi sembra un supporto concreto e utilizzabile dalle PA che devono realizzare piani di migrazione/adozione/riuso di nuovo o esistente SW
Developers Italia potrebbe rappresentare il luogo dove stimolare le comunitĂ che vi fanno parte a realizzare il tool in una prospettiva collaborativa.
Che ne pensate?
Ugo Bonelli
1 Mi Piace
Da parte del Centro Hermes per la Trasparenza e Diritti Umani Digitali:
Il calcolo del TCO dovrebbe, per quanto attiene al processo di riuso, identificare dei pesi e delle metriche relative alla manutenzione evolutiva e correttiva, perché la queste rappresentano il costo principale del ciclo di vita del software nel medio periodo.
Ovviamente, ciò va ad impattare direttamente il percorso di scelta definito nel capitolo 2, con particolare considerazione alla differenza fra “Software in Riuso” e “Software Opensource” laddove entrambe le soluzioni sono a codice aperto, ma il secondo potrebbe avere una comunità di contributors di ordini di grandezza superiore al “Software in Riuso” .
Al capitolo 2.5.2 sono identificati i parametri che, nella sostanza, impattano in modo diretto i costi di medio periodo relativi alla manutenzione evolutiva e correttiva:
“Sostenibilità del progetto Open Source attraverso la valutazione di indicatori visibili sul repository Open Source, quali per esempio frequenza delle modifiche (code activity), frequenza dei rilasci (release history), comunità degli utenti (user community), longevità del progetto (longevity).”
Tuttavia questi parametri non sono considerati ed esplicitati nel calcolo del TCO, laddove si debba effettuare una valutazione non già fra “Software proprietario” vs. “Software Opensource” ma fra “Software Opensource” e “Software in Riuso” .
Ipotizziamo che un “Software in Riuso” sia stato basato su “Software OpenSource” e a distanza di un anno ci troviamo con la seguente situazione:
- Software OpenSource: 450 code commit, 250 fork, 12 rilasci con nuove features
- Software in Riuso: 20 code commit, 2 fork, 1 rilascio con minor bugfix
In uno scenario del genere, la scelta del “Software in Riuso”, nella componente e metrica di manutenzione che guarda al medio periodo, in considerazione della scarsa sostenibilità , comporterebbe costi maggiori e sarebbe preferibile la scelta del “Software OpenSource” .
Ovviamente uno scenario simile potrebbe essere frutto di un Maintainer poco attivo o di un Fornitore che opera come Maintainer che adotta questa strategia per ridurre i suoi costi e portare a maggiori richieste commerciali di supporto e assistenza.
Al fine di evitare che ci si possa trovare di fronte a situazioni di “abuso del riuso” per via di un vizio procedurale di scelta preferendo il “Software in Riuso” rispetto al “Software OpenSource” è necessario espandere nell’elemento di valutazione del TCO relativo alla manutenzione le metriche effettive di sostenibilità .