Argomento 5.3 — Ingegneria del software e piattaforme nel settore pubblico

Perché è importante per il valore pubblico

Quasi ogni servizio pubblico con cui un cittadino ha a che fare oggi – registrare una nascita, richiedere una prestazione, pagare un'imposta, fissare un'udienza – gira su un software da qualche parte dietro lo sportello o lo schermo. Quel software è raramente un acquisto una tantum; diventa parte dell'infrastruttura permanente dello Stato, sopravvivendo spesso all'amministrazione che lo ha commissionato, al fornitore che lo ha costruito e al linguaggio di programmazione in cui i suoi ingegneri sono stati formati. Un ente pubblico non sperimenta il software come sperimenta un edificio o una strada, dove lo stato del bene è visibile; il software si degrada in modo invisibile, e il conto di quel decadimento arriva anni dopo come un'emergenza.

La tensione che guida questo argomento è strutturale. Il software è intrinsecamente iterativo – i requisiti si chiariscono man mano che gli utenti interagiscono con un sistema funzionante, e la migliore pratica ingegneristica è costruire qualcosa di piccolo, imparare e adattarsi. I cicli di appalto e di responsabilità pubblica (vedi Argomento 3.7 — Appalti pubblici e affidamento dei servizi), al contrario, sono stati costruiti per opere di capitale e contratti di difesa: una specifica fissa, una singola grande aggiudicazione, pagamenti a tappe e un business case approvato anni prima che l'erogazione cominci. Quando un legislativo o un revisore si aspetta un contratto a prezzo fisso e a ambito fisso e un gruppo di ingegneria deve cambiare rotta dopo il primo rilascio, il disallineamento emerge come dilatazione dell'ambito, sforamento del bilancio o un sistema specificato correttamente nel 2019 e obsoleto quando viene messo in produzione.

Le piattaforme che la pratica ingegneristica di questo argomento esiste per costruire – sistemi condivisi di identità, canali di pagamento, strumenti di gestione dei casi riutilizzati fra i ministeri – sono il tema dell'Argomento 5.1 (vedi Argomento 5.1 — Governo digitale e trasformazione digitale); questo argomento riguarda la disciplina di costruire e acquistare il software che rende qualsiasi piattaforma di questo tipo, o qualsiasi singolo servizio, affidabile, sostituibile e di proprietà dell'ente pubblico che ne dipende anziché di qualunque fornitore l'abbia scritto per primo.

Concetti chiave

La decisione costruire-o-acquistare è la scelta fra commissionare software su misura scritto per il bisogno di una sola organizzazione e adottare software commerciale configurabile già costruito per un mercato di acquirenti simili. Acquistare è di solito più economico e a minor rischio per un bisogno non genuinamente distintivo – paghe, posta elettronica, gestione standard dei casi – mentre costruire è giustificato solo dove il requisito è abbastanza diverso che nessun prodotto configurabile si adatta, o dove la capacità è essa stessa un patrimonio strategico che l'organizzazione deve possedere e far evolvere.

Il debito tecnico è una metafora, coniata dall'ingegnere del software Ward Cunningham nel 1992, per il costo accumulato di scegliere un modo espediente di rilasciare software ora rispetto a uno più approfondito che avrebbe richiesto più tempo. Il debito tecnico, come il debito finanziario, non è intrinsecamente sbagliato da assumere – il punto di Cunningham stesso era che rilasciare rapidamente codice funzionante e rifattorizzarlo dopo può essere la scelta giusta – ma il debito che non viene mai ripagato matura interessi sotto forma di consegna più lenta, più difetti e rischio crescente, e un ente pubblico che non vede il proprio debito non può decidere se onorarlo o lasciarlo comporre.

Un sistema ereditato (legacy system) è una vecchia tecnologia, applicazione o piattaforma che resta in uso attivo nonostante sia superata, spesso perché sostituirla è costoso o perché nessuno rimasto nell'organizzazione capisce pienamente che cosa faccia. I sistemi ereditati sono particolarmente persistenti nel governo: sistemi centrali fiscali, di prestazioni e di assicurazione sociale scritti decenni fa in linguaggi come COBOL – il Common Business-Oriented Language, progettato nel 1960 per l'informatica amministrativa – elaborano ancora transazioni per milioni di cittadini, perché i sistemi funzionano e la conoscenza istituzionale necessaria per ritirarli in sicurezza è spesso andata in pensione prima di essi.

La modernizzazione del software è il termine generale per convertire, riscrivere o migrare un sistema ereditato verso un'architettura, un linguaggio o una piattaforma attuali. La modernizzazione del software spazia da una riscrittura completa a opzioni più conservative come ospitare di nuovo lo stesso codice su un'infrastruttura moderna, e la scelta fra esse è tanto una decisione di gestione del rischio quanto tecnica.

Il modello del fico strangolatore (strangler fig pattern) è un approccio di modernizzazione incrementale, dal nome di una vite che cresce attorno a un albero ospite e gradualmente lo sostituisce, in cui la nuova funzionalità è costruita accanto a un sistema ereditato e il traffico è reindirizzato ad essa pezzo per pezzo, anziché sostituire l'intero sistema in un solo passaggio. Il modello del fico strangolatore conta perché permette di verificare, annullare o mettere in pausa ogni incremento senza fermare l'intero servizio – l'opposto di una sostituzione big-bang, in cui il vecchio sistema è spento e il nuovo acceso in un solo momento senza ritorno se qualcosa non va.

La dipendenza dal fornitore (vendor lock-in) si verifica quando un cliente diventa così dipendente dalla tecnologia proprietaria, dai formati di dati o dai termini contrattuali di un solo fornitore che passare a un altro comporta costo o rischio proibitivi. La dipendenza dal fornitore è un pericolo particolare nel software del settore pubblico perché l'acquirente è un cliente ricorrente con limitata capacità pratica di andarsene da un sistema che gestisce un servizio critico, il che indebolisce la sua posizione negoziale a ogni successivo rinnovo.

Il software libero e open source è software distribuito con una licenza che concede agli utenti la libertà di usare, studiare, modificare e ridistribuire il codice sorgente. Il software libero e open source sta alla base di una politica open-source-by-default, per cui un ente pubblico pubblica per impostazione predefinita il codice sorgente che commissiona a meno che una ragione specifica – sensibilità di sicurezza, diritti di terzi – giustifichi il trattenerlo; la ragione è di solito riassunta come "denaro pubblico, codice pubblico": il software pagato una volta con fondi pubblici non dovrebbe aver bisogno di essere pagato di nuovo, in un'altra giurisdizione, da un altro ente pubblico che risolve lo stesso problema.

Un bene pubblico digitale (digital public good) è software, dati o contenuti aperti, rilasciati con una licenza aperta, progettati per aiutare a soddisfare un obiettivo pubblico di sviluppo o di governance anziché generare un ritorno commerciale. I beni pubblici digitali riformulano il rilascio open source di un governo come parte di un'infrastruttura condivisa più ampia a cui altri governi e organizzazioni della società civile possono attingere direttamente, non solo un gesto interno di trasparenza.

Lo sviluppo agile del software è un termine ombrello per approcci iterativi alla costruzione del software che privilegiano il software funzionante, la consegna frequente e il rispondere al cambiamento rispetto al seguire un piano fisso concordato in anticipo. Lo sviluppo agile del software si contrappone al modello a cascata (waterfall), un approccio sequenziale in cui requisiti, progetto, costruzione e verifica si completano ciascuno per intero prima che inizi il successivo; il fascino del modello a cascata per gli enti pubblici è sempre stato che le sue tappe si mappano ordinatamente su un contratto a prezzo fisso e su un ciclo annuale di bilancio, ed è per questo che tanta legislazione sugli appalti presume ancora tale modello, anche dove l'erogazione è genuinamente agile.

Un prodotto minimo vitale (minimum viable product) è la più piccola versione di un servizio che può essere rilasciata a utenti reali per verificare se funzioni e imparare che cosa costruire poi. Il concetto di prodotto minimo vitale, adattato nei manuali di servizio digitale del settore pubblico, dà a un gruppo iterativo un modo difendibile di mostrare a un finanziatore o a un revisore qualcosa di reale e funzionante molto prima che l'ambito pieno sia completo – purché il processo di responsabilità accetti un rilascio genuinamente minimo anziché trattarlo come il prodotto finito sotto un altro nome.

Buone pratiche

Acquistate per impostazione predefinita per i bisogni non differenziati e riservate il costruire a ciò che è genuinamente distintivo. Paghe, posta elettronica ed esigenze generali di gestione dei casi sono raramente abbastanza diverse da quelle di qualsiasi altra organizzazione da giustificare software su misura; costruite solo dove il requisito, la scala o il bisogno di possedere e far evolvere la capacità per decenni sia genuinamente diverso da ciò che il mercato offre.
Rendete visibile il debito tecnico prima di decidere quanto portarne. Mantenete un registro delle scorciatoie note, delle correzioni rinviate e delle dipendenze non supportate per ogni sistema in servizio, riesaminato a un ciclo fisso, così che portare debito per un altro anno sia un compromesso deliberato anziché nessuno che guarda.
Non pianificate mai un unico passaggio irreversibile come sola via d'uscita da un sistema ereditato critico. Preferite approcci incrementali come il modello del fico strangolatore che permettono di verificare, annullare e dispiegare gradualmente ogni pezzo; una sostituzione big-bang di un sistema da cui dipendono milioni di persone concentra anni di rischio in un solo fine settimana senza ritorno se qualcosa fallisce.
Trattate il codice sorgente che la vostra organizzazione paga per far scrivere come un bene che possiede, non come un servizio che affitta. Negoziate il deposito del codice sorgente (escrow) o la piena proprietà al momento della contrattazione, non dopo che è iniziata una controversia, poiché un fornitore che detiene l'unica copia del codice del vostro servizio critico è dipendenza dal fornitore per progetto.
Pubblicate il codice sorgente come aperto per impostazione predefinita e richiedete una giustificazione specifica per trattenerlo. Una politica open-source-by-default, applicata con coerenza, trasforma il software su misura di ogni ministero in un patrimonio condiviso fra amministrazioni anziché un costo una tantum e permette a esperti esterni di trovare falle di sicurezza che un gruppo interno da solo mancherebbe.
Scrivete contratti di software che rendano lecita, non solo tecnicamente possibile, l'erogazione iterativa. Un contratto che paga solo rispetto a una specifica fissa concordata alla firma costringe un gruppo a scegliere fra onesta pratica agile e conformità contrattuale; usate invece varchi di finanziamento a stadi legati a software funzionante dimostrato anziché una sola tappa alla fine.
Finanziate la modernizzazione come programma continuo, non come progetto di capitale una tantum. Un sistema ereditato modernizzato una volta e poi lasciato per altri vent'anni accumula lo stesso rischio da cui era partito; mettete a bilancio un rinnovamento continuo e incrementale come un'autorità stradale mette a bilancio la ripavimentazione, non una grande sostituzione una volta per generazione.
Scegliete standard aperti e formati di dati portabili anche quando acquistate software commerciale. Richiedere che il sistema di un fornitore memorizzi ed esporti i dati in formati aperti e documentati mantiene bassi i costi di cambio anche dove il software è proprietario, ed è spesso una salvaguardia a breve termine più realizzabile contro la dipendenza dal fornitore che insistere che ogni sistema sia open source.
Costruite un prodotto minimo vitale e mostratelo a utenti reali prima di impegnarvi sull'ambito pieno. Rilasciare una versione genuinamente minima, poi iterare su ciò che si è appreso, coglie i presupposti sbagliati quando sono ancora economici da correggere, anziché dopo che un sistema su piena scala è stato costruito contro di essi.
Mantenete una capacità di ingegneria interna sufficiente per essere un acquirente intelligente, anche dove l'erogazione è affidata all'esterno. Un ente pubblico che ha svuotato la propria competenza tecnica non può valutare la proposta di un fornitore, individuare i primi segnali d'allarme di un progetto in difficoltà né negoziare l'uscita dalla dipendenza, qualunque cosa dicano sulla carta le sue regole di appalto.
Ritirate il profilo di rischio di un sistema ereditato prima della sua interfaccia utente. Date priorità alla sostituzione di linguaggi non supportati, infrastrutture non aggiornate e integrazioni non documentate – i guasti che causano interruzioni e violazioni – prima della modernizzazione visiva, che comporta un rischio operativo molto minore.
Misurate la salute dell'erogazione con indicatori ingegneristici, non solo con la varianza di bilancio e di calendario. Frequenza di rilascio, tassi di difetti ed età della più vecchia voce di debito tecnico non affrontata dicono a un consiglio di governance più su se un programma riuscirà di quanto dica se sia attualmente nel bilancio, spesso l'ultimo indicatore a muoversi.

Domande da discutere con il vostro team

Sappiamo davvero quanto debito tecnico stiamo portando, sistema per sistema? La maggior parte degli enti pubblici sa dire il proprio bilancio di capitale dell'anno ma non sa dire, con alcuna sicurezza, quanto del proprio patrimonio software giri su componenti non supportati, logica non documentata o codice che nessuno del personale rimasto capisce pienamente. Usate questa domanda per chiedere a ogni responsabile di sistema nella stanza di stimare, onestamente, quanto sia sicuro che il proprio gruppo potrebbe modificare in sicurezza il proprio sistema più critico senza rompere qualcosa che nessuno aveva previsto. Discutete che cosa servirebbe per trasformare quelle stime in un registro effettivo, riesaminato a un ciclo fisso, anziché in conoscenza tribale che se ne va quando se ne va un ingegnere chiave. Considerate anche chi decida oggi quanto debito sia accettabile portare e se quella decisione sia deliberata o presa per impostazione predefinita.

Se il nostro sistema ereditato più critico dovesse essere sostituito a partire da oggi, pianificheremmo un passaggio big-bang o una migrazione incrementale – e perché? L'istinto di sostituire un vecchio sistema tutto in una volta è spesso guidato da cicli di bilancio e da comodità di gestione del programma anziché da necessità tecnica, e concentra un enorme rischio in un solo momento. Usate questa domanda per ripercorrere concretamente come apparirebbe una migrazione incrementale in stile fico strangolatore del vostro sistema ereditato più critico, pezzo per pezzo. Discutete che cosa vi impedisca di scegliere oggi quella via – un finanziamento strutturato attorno a una singola data di messa in produzione, un processo di governance che vuole una sola tappa pulita o un genuino vincolo tecnico che rende impossibile la migrazione incrementale per questo sistema.

Chi possiede effettivamente il codice sorgente del software che la nostra organizzazione ha pagato per far costruire, e potremmo dimostrarlo? Molti enti pubblici scoprono, solo quando un rapporto con un fornitore si guasta, che il contratto non ha mai garantito una chiara proprietà o deposito del codice da cui i loro servizi critici dipendono. Usate questa domanda per estrarre i contratti dei vostri tre sistemi su misura più importanti e verificare, specificamente, che cosa ciascuno dica su proprietà del codice, deposito e diritto di portare il codice a un altro fornitore. Discutete che cosa accadrebbe domani se il vostro fornitore principale di uno qualsiasi di quei tre sistemi cessasse l'attività o rifiutasse di continuare il rapporto.

Dove stiamo ricorrendo per abitudine al software proprietario chiuso quando un approccio open-source-by-default ci servirebbe altrettanto bene o meglio? Le politiche open-source-by-default esistono proprio perché la maggior parte degli enti pubblici risolve problemi sovrapposti in modo indipendente, ciascuno pagando l'intero costo di software che un altro ente pubblico ha già costruito e avrebbe potuto condividere. Usate questa domanda per individuare un sistema attualmente in costruzione o in specifica e chiedervi se ne esista già uno equivalente come software open source altrove nel governo, o se quello che state costruendo potrebbe utilmente essere rilasciato perché altri lo riutilizzino. Discutete quale specifico ostacolo – preoccupazione di sicurezza, abitudine d'appalto, mancanza di una politica chiara – stia effettivamente impedendo quel riutilizzo, anziché presumere che non sia rilevante qui.

Il nostro processo di appalto e di responsabilità consente davvero un'onesta erogazione agile, o rietichetta solo le tappe della cascata come sprint? È comune che un gruppo conduca cerimonie nominalmente agili pur essendo ancora finanziato, governato e rendicontato rispetto a una specifica fissa concordata alla firma del contratto, il che ricrea ogni modalità di fallimento della cascata sotto un'etichetta agile. Usate questa domanda per ripercorrere un programma digitale vivo dal suo business case alla sua attuale rendicontazione di governance e chiedervi se la struttura di finanziamento tollererebbe che il programma cambiasse direzione sulla base di ciò che un genuino rilascio precoce gli ha insegnato. Discutete che cosa dovrebbe cambiare in come il programma è finanziato e rendicontato perché l'erogazione iterativa sia reale anziché cosmetica (vedi Argomento 3.7 — Appalti pubblici e affidamento dei servizi).

Abbiamo abbastanza capacità di ingegneria interna per essere un acquirente intelligente dei sistemi da cui dipendiamo di più? Un'organizzazione che ha esternalizzato tutto il proprio giudizio tecnico, non solo la propria capacità di erogazione, non può dire se la proposta di un fornitore sia solida, se un progetto si stia silenziosamente dirigendo verso guai o quale sia un prezzo equo per il lavoro. Usate questa domanda per chiedere quante persone nella vostra organizzazione potrebbero credibilmente riesaminare una proposta di architettura tecnica per il vostro sistema più importante e come quel numero sia cambiato negli ultimi cinque anni. Discutete che cosa servirebbe per ricostruire quella capacità dove si è erosa e che cosa la vostra organizzazione perda, in posizione negoziale tanto quanto in rischio di erogazione, per ogni anno che ne resta priva.

In pratica: un esempio di valore pubblico

Un governo regionale immaginario – solo illustrativo, non una descrizione di alcuna giurisdizione reale – gestiva le richieste di indennità di disoccupazione attraverso un sistema scritto per la prima volta più di trent'anni prima, mantenuto da un numero decrescente di ingegneri che capivano il suo linguaggio di programmazione originale. Il volume delle richieste era cresciuto ben oltre quanto i progettisti del sistema avessero previsto, le elaborazioni notturne non si completavano sempre più spesso prima che iniziassero le transazioni del mattino e i vertici tecnologici dell'agenzia avvertivano che un'interruzione non pianificata che incidesse sui pagamenti delle prestazioni era ormai una questione di quando, non di se.

Il primo istinto dell'agenzia fu una risposta convenzionale a un problema che sembrava urgente: commissionare un unico grande contratto per sostituire l'intero sistema con una piattaforma moderna, specificata per intero in anticipo, consegnata rispetto a un calendario fisso di due anni con un solo fine settimana di passaggio alla fine. Una revisione pre-attuazione commissionata dal comitato di audit dell'agenzia pose una domanda difficile prima che il contratto fosse firmato: che cosa sarebbe accaduto ai pagamenti delle prestazioni per diverse centinaia di migliaia di richiedenti se il nuovo sistema avesse avuto un difetto non scoperto nella prima settimana di pieno funzionamento reale, con il vecchio sistema già dismesso e senza ritorno.

L'agenzia cambiò rotta. Mantenne in funzione il sistema ereditato come sistema di riferimento e cominciò a costruire accanto ad esso nuove funzionalità di accoglimento delle richieste e di valutazione dell'ammissibilità, con un approccio a fico strangolatore: ogni nuovo modulo era rilasciato prima a una piccola percentuale di nuove richieste, verificato rispetto all'output parallelo del vecchio sistema ed esteso solo quando i suoi risultati coincidevano. Entro diciotto mesi la maggior parte delle nuove richieste passava attraverso componenti moderni mentre il sistema originale gestiva un carico residuo decrescente, con la possibilità di instradare di nuovo qualsiasi singolo caso verso il vecchio percorso se qualcosa sembrava sbagliato. L'agenzia richiese anche, in ogni nuovo contratto emesso per questo lavoro, che il codice sorgente fosse di proprietà dell'agenzia e pubblicato come open source una volta completata la revisione di sicurezza, così che altri governi regionali di fronte allo stesso problema di mainframe invecchiati potessero adattare i componenti anziché ripetere la stessa costruzione da zero.

La sostituzione completa delle ultime funzioni residue del sistema ereditato richiese quasi quattro anni – più, sulla carta, di quanto promettesse il piano originale big-bang di due anni. Ma nessun richiedente sperimentò mai un'interruzione non pianificata durante la transizione, ogni incremento era abbastanza piccolo da poter essere annullato entro poche ore quando si trovava un difetto e due governi regionali vicini cominciarono ad adattare il codice pubblicato di valutazione dell'ammissibilità dell'agenzia per i propri sistemi entro il primo anno dal suo rilascio.

Quattro prospettive settoriali

Amministrazione locale

L'amministrazione locale gestisce tipicamente un gran numero di sistemi più piccoli e scollegati anziché una manciata di piattaforme di scala nazionale, il che significa che il debito tecnico si accumula in molte applicazioni acquistate e mantenute separatamente anziché in un unico sistema di punta visibile. Gli enti locali hanno di solito la minore capacità di ingegneria interna di qualsiasi livello di governo, il che rende particolarmente forte il caso di acquistare software commerciale configurabile anziché costruzioni su misura e rende le piattaforme condivise regionali o nazionali – il tema dell'Argomento 5.1 (vedi Argomento 5.1 — Governo digitale e trasformazione digitale) – una via particolarmente preziosa per evitare che ogni ente ricostruisca separatamente la stessa capacità.

Amministrazione nazionale

L'amministrazione nazionale è dove tendono a stare i sistemi ereditati più vecchi e consequenziali – amministrazione fiscale centrale, assicurazione sociale e prestazioni – perché furono spesso fra i primi sforzi di informatizzazione su larga scala nel governo e ora portano la posta in gioco più alta per qualsiasi fallimento di modernizzazione. L'amministrazione nazionale ha tipicamente la capacità commerciale e ingegneristica specialistica per condurre un programma di modernizzazione genuinamente incrementale e per negoziare nei propri contratti una reale proprietà del codice, ed è di solito il livello di governo meglio collocato per fissare una politica open-source-by-default con abbastanza scala dietro da far accadere davvero il riutilizzo fra amministrazioni.

Terzo settore e non profit

Le organizzazioni non profit e di beneficenza raramente costruiscono da sole grandi piattaforme su misura, ma si trovano spesso sul lato ricevente di software commissionato o imposto da un finanziatore governativo – un portale di rendicontazione, un sistema di gestione dei casi che una sovvenzione o un contratto richiede di usare – con poca influenza sul suo progetto, sul suo debito tecnico o sul suo fornitore. Un'organizzazione del terzo settore che dipende da un sistema imposto dal governo eredita i modi di fallimento di quel sistema senza ereditare alcuna leva per correggerli, il che è un'altra ragione per cui i rapporti di finanziamento basati sui risultati devono tenere conto dell'onere operativo della tecnologia imposta (vedi Argomento 3.7 — Appalti pubblici e affidamento dei servizi), non solo della metrica di risultato in sé.

Livello multilaterale e internazionale

Gli organismi multilaterali e le agenzie di sviluppo promuovono sempre più il software costruito per l'amministrazione pubblica di un paese come bene pubblico digitale riutilizzabile che altri paesi possono adattare, anziché ogni governo commissionare un sistema equivalente a un fornitore privato a costo pieno. Il rischio distintivo qui è che un bene pubblico digitale costruito per il contesto giuridico e amministrativo di un paese possa essere adottato altrove con troppo poco adattamento, importando presupposti – su identità, ammissibilità o processo – che non si trasferiscono davvero; la promessa di un'infrastruttura condivisa e aperta è reale, ma solo dove una genuina capacità di adattamento locale accompagna il codice.

Modalità di fallimento comuni

Il passaggio big-bang che fallisce al go-live. Un sistema ereditato critico è sostituito in un unico passaggio irreversibile dopo anni di sviluppo senza esposizione reale alla produzione, e un difetto che compare solo su scala reale o in un caso limite che nessuno ha verificato emerge il primo giorno di pieno funzionamento, senza modo di tornare al vecchio sistema perché è già stato dismesso. Il costo si misura in pagamenti mancati, servizi negati o interruzioni che colpiscono proprio i cittadini che il sistema esiste per servire, nel peggior momento possibile – il momento in cui tutti facevano affidamento sul funzionamento della sostituzione.

Accumulo silenzioso di debito tecnico. La pressione delle scadenze vince ripetutamente la discussione contro il tempo necessario per correggere le scorciatoie note, e ogni rinvio è singolarmente difendibile, finché il debito accumulato rende anche una piccola modifica sproporzionatamente costosa e rischiosa. Il costo emerge anni dopo come un sistema che nessuno può modificare in sicurezza, una forza lavoro che ha silenziosamente smesso di tentare qualsiasi cosa tranne le correzioni più urgenti e un eventuale programma di modernizzazione molto più grande e costoso di quanto sarebbe stato un rinnovamento continuo e più piccolo.

Dipendenza dal fornitore scambiata per stabilità. Un ente pubblico rinnova ripetutamente il contratto dello stesso fornitore perché cambiare sembra troppo dirompente da tentare, senza mai verificare quali sarebbero i veri costi di cambio né negoziare la proprietà del codice e i formati di dati aperti che li manterrebbero gestibili. Il costo è una posizione negoziale permanentemente indebolita su prezzo e termini, scoperta solo quando la qualità del servizio del fornitore cala o i suoi prezzi salgono e l'ente pubblico scopre di non avere alcuna alternativa credibile.

Agile cosmetico. Un gruppo di erogazione adotta le cerimonie agili – riunioni quotidiane, sprint, un backlog – mentre la struttura sottostante di contratto, finanziamento e governance presuppone ancora una specifica fissa e una singola tappa di via libera, così il gruppo riferisce la velocità degli sprint mentre in realtà eroga rispetto a un piano a cascata sotto. Il costo è che nessuno dei genuini benefici dell'agile – il feedback precoce degli utenti che cambia direzione, il rischio fatto emergere presto – si materializza, mentre l'apparenza di pratica moderna rende la rigidità sottostante più difficile da vedere e da contestare per gli organi di vigilanza.

Politica open source senza un piano di sostentamento. Un ente pubblico pubblica il codice sorgente per soddisfare una politica open-source-by-default ma tratta il rilascio come un passaggio di conformità una tantum, senza risorse per riesaminare i contributi esterni, correggere le vulnerabilità o mantenere la documentazione. Il costo è un repository pubblicato che appare aperto ma funziona come vicolo cieco non mantenuto, il che danneggia la fiducia nel più ampio programma open-source-by-default più di quanto non avrebbe fatto il non pubblicare mai.

Modello di maturità

Sotto-dimensione	Avvio	Sviluppo	Standardizzazione	Gestione	Orchestrazione
Il debito tecnico è visibile e gestito	Il debito non è documentato ed è noto solo informalmente ai singoli ingegneri	Esiste un inventario parziale per alcuni sistemi, non riesaminato a ciclo fisso	Un registro del debito copre tutti i sistemi critici ed è riesaminato a un ciclo documentato	La riduzione del debito è finanziata e seguita rispetto a obiettivi misurabili	I dati sul debito sono condivisi nell'intero patrimonio dell'organizzazione per dare priorità all'investimento in modernizzazione
La modernizzazione degli ereditati evita il rischio big-bang	Sostituzione è presunta significare un'unica riscrittura completa e passaggio	Approcci incrementali sono usati occasionalmente, senza un metodo coerente	La migrazione incrementale in stile fico strangolatore è il default documentato per i sistemi critici	Progresso della migrazione e prontezza al ritorno indietro sono attivamente misurati e riferiti	Metodo e strumenti di modernizzazione sono condivisi e migliorati fra enti pubblici pari
Le decisioni costruire-o-acquistare sono deliberate	Costruire o acquistare è scelto per abitudine o rapporto con il fornitore, non valutato	Una certa valutazione avviene, in modo incoerente, prima delle decisioni software importanti	Un quadro decisionale documentato è applicato a ogni scelta significativa di costruire o acquistare	Gli esiti di costruire-o-acquistare sono seguiti rispetto alla giustificazione originale nel tempo	Capacità e lezioni su costruire-o-acquistare sono condivise con altri enti pubblici che affrontano la stessa scelta
Codice sorgente e dati sono aperti per impostazione predefinita	L'erogazione chiusa e proprietaria è il default non messo in discussione	L'apertura del codice avviene occasionalmente, guidata da singoli gruppi	Una politica open-source-by-default è documentata e applicata con coerenza	Il codice pubblicato è attivamente mantenuto, con risorse per i contributi esterni	Il codice pubblicato è riutilizzato fra amministrazioni e da altre giurisdizioni, con il riutilizzo seguito come beneficio
Il metodo di erogazione si adatta alla struttura di responsabilità	Contratti e governance presumono la cascata a prescindere da come l'erogazione avvenga	Si usano cerimonie agili, ma finanziamento e governance fanno ancora da varco su una specifica fissa	Contratti e varchi di finanziamento sono strutturati attorno a software funzionante dimostrato	La salute dell'erogazione è misurata con indicatori ingegneristici, non solo con la varianza di bilancio e di calendario	Le regole di appalto e di responsabilità sono attivamente adattate, sulla base di evidenze, per adattarsi all'erogazione iterativa

Lista di controllo

Inventariate il debito tecnico di ogni sistema critico e riesaminate il registro a un ciclo fisso.
Applicate un quadro documentato di costruire-o-acquistare prima di impegnarvi su qualsiasi nuovo software significativo.
Per qualsiasi sostituzione di sistema ereditato, adottate come default un metodo di migrazione incrementale e richiedete una giustificazione esplicita per un passaggio big-bang.
Confermate i termini di proprietà o di deposito del codice sorgente in ogni contratto di software prima della firma.
Pubblicate il codice sorgente sotto una politica open-source-by-default, con un processo documentato di eccezione.
Dotate di risorse la manutenzione continua di ogni repository pubblicato sotto quella politica, non solo il suo rilascio iniziale.
Richiedete formati di dati aperti e documentati anche dove il software sottostante è proprietario.
Strutturate i varchi di finanziamento attorno a software funzionante dimostrato anziché a un'unica tappa a specifica fissa.
Costruite e verificate un prodotto minimo vitale con utenti reali prima di impegnarvi sull'ambito pieno.
Seguite frequenza di rilascio, tassi di difetti e debito tecnico in sospeso come indicatori permanenti di governance.
Valutate la capacità di ingegneria interna rispetto a ciò che serve per essere un acquirente intelligente e colmate le lacune individuate.
Date priorità a infrastrutture non supportate e integrazioni non documentate prima della modernizzazione cosmetica.

Fonti chiave

GOV.UK Service Standard, Government Digital Service, Regno Unito — uno standard nazionale di servizio digitale che richiede un'erogazione iterativa e centrata sull'utente e standard aperti per i servizi pubblici.
Office of Management and Budget, Federal Source Code Policy (M-16-21), Stati Uniti — la politica federale che richiede alle agenzie di considerare il riutilizzo e il rilascio open source per il software governativo sviluppato su misura.
Free Software Foundation Europe, campagna Public Money, Public Code — la motivazione, sviluppata per un pubblico europeo, per rilasciare il codice sorgente del software finanziato con denaro pubblico con licenze libere e open source.
Ward Cunningham, "The WyCash Portfolio Management System" (resoconto di esperienza OOPSLA 1992) — l'enunciazione originale della metafora del debito tecnico.
Digital Public Goods Alliance — un'iniziativa a più parti interessate che mantiene standard e un registro per software, dati e contenuti aperti progettati per servire obiettivi pubblici di sviluppo.

Riferimenti

Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
"The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
Digital Public Goods Alliance — https://digitalpublicgoods.net/