È trascorso qualche anno dal 2013 quando Tim O’Really in un suo famoso articolo[1] propose il modello del “Government as a Platform”. Questo prevede una piattaforma digitale che espone servizi applicativi ad uso dei cittadini e di altri enti di governo e che poi terzi possono arricchire al fine di innovare la PA o sfruttare i dati commercialmente (aziende private). L’articolo ha dato lo spunto a diverse iniziative governative a livello internazionale dando vita a dei framework in grado di comunicare tra amministrazioni, di autenticare gli utenti in modo sicuro (caso Estone) ma soprattutto di sviluppare piattaforme di API messe a disposizione del pubblico. Tim O’Really individua nei dati il motore della sua proposta. I dati sono la ricchezza da valorizzare e sono il motore della digitalizzazione. Un articolo dell’Economist del 6 maggio riprende il discorso[2] affermando che sono i dati e non il petrolio la risorsa con maggior valore. Una riflessione sulla necessità di valorizzare economicamente gli usi commerciali dei dati in possesso della PA è necessaria e la rimandiamo in altra sede.
Molte volte questi framework rendono pubblici dati secondo il paradigma dei Open Data. Molte amministrazioni italiane si sono avvicinate agli Open Data realizzando portali di API o dataset. In ogni caso il modello è quello di esporre informazioni senza costi in modo che aziende private possano poi costruire servizi a valore aggiunto o l’associazionismo civico possa sviluppare servizi di pubblica utilità. In molti casi questo ha generato una serie di applicazioni utili per la trasparenza o l’informazione ai cittadini o delle app in grado di integrare fonti diverse.
Caso diverso la presenza di piattaforme come X-ROAD del governo estone che integrano diverse entità permettendogli di scambiare servizi e informazioni. X-ROAD fornisce servizi di interrogazione a diversi database e rappresenta la base per un sistema articolato di servizi al cittadino.
I servizi della PA sono sempre meno legati alla fisicità dello sportello e vivono sempre più nello spazio della rete. Questo significa che si abbatte la barriera tra digitale/virtuale e fisico. Una richiesta di servizio digitale diventa equivalente a quella di uno sportello fisico disintermediando la così detta burocrazia: il potere discrezionale che ha l’impiegato o il dirigente sulla nostra richiesta. In Italia i progetti di e-government sono stati spesso orientati alla costruzione di un front-end che eliminasse lo sportello lasciando poi nel back-office gli impiegati con i soliti processi di sempre.
La PA è fatta da servizi che vengono erogati dopo che sia stato effettuato un workflow definito, siano state verificate alcune condizioni fissate nelle leggi e qualcuno si sia assunto la responsabilità di approvare le richieste. Queste parte è costituita ancora molto dalla presenza del personale che esamina le richieste e procede secondo le direttive fissate da norme e procedure anche attraverso l’interpretazione delle stesse. Queste norme e procedure devono essere “neutrali” e formulate in modo da poter garantire ad ogni cittadino eguali diritti.
Nel settore finanziario assistiamo all’affermazione dello stesso principio. Si comincia ad affermare il Bank as a Platform[3] esponendo servizi bancari attraverso API. È solo di poche settimane fa la presentazione da parte di Banca Sella della sua piattaforma di API[4], mentre è interessante il caso di OpenBankProject[5] che si propone di creare una piattaforma di Api Open Source (in realtà con una licenza anche commerciale).
Le principali società di consulenza mondiale (da KPMG a Deloitte, da PwC a E&Y) sono impegnate a comprendere come questo paradigma stia trasformando i modelli di business già se ne intravede il limite. Sono sempre di più necessari anche i processi, gli algoritmi, in grado di trasformare i dati e quest’ultimi si debbono sempre di più adattare in tempo reale a seconda delle condizioni, delle policy, di ciò che accade. Algoritmi sempre più vicini a sistemi esperti a cui vengono dati i vincoli e gli ambiti di intervento delegando ad essi il percorso migliore per arrivarci.
Questo è molto simile al moderno paradigma del software delle infrastrutture cloud che è ormai orientato verso piattaforme in grado di esporre servizi e “orchestrare” comunicazioni, dati e processi integrando algoritmi che consentano automaticamente di soddisfare le regole e le policy prefissate.
Queste moderne piattaforme ad esempio prendono continuamente decisioni e seguono workflow complessi per rispettare policy e regole previste da livelli di servizio e norme contrattuali definite. Alcuni fanno uso di sistemi di intelligenza artificiale altri attraverso la codifica di regole secondo modelli what-if che prevedono specifiche azioni a fronte di eventi predefiniti.
Una Software Defined Network, ad esempio, è in grado di guidare una rete tecnologica raccogliendo milioni di dati di telemetria da sensori e, in tempo reale, prendere delle decisioni di instradamento o riconfigurare il traffico in base a regole e policy poste a guida del funzionamento della rete.
Software Defined Everything come paradigma di sistemi software in grado di rappresentare strutture complesse (infrastrutture tecnologiche, storage, processi e organizzazioni) assumendo decisioni in base a motori di intelligenza artificiale o a regole predefinite.
L’evoluzione naturale del government as a platform (così come Bank as a platform) appare sempre più quella di passare dall’esporre servizi e dati alla esposizione di servizi basati su regole e policy governati da un software “orchestratore”: software defined government e software defined bank.
Questo genere di piattaforme non solo dovrebbero esporre servizi in grado di interrogare o modificare/aggiungere dati ma dovrebbero essere in grado di attuare le policy (le leggi) in modo dinamico rispondendo in modo automatico alle richieste dei cittadini o di terze parti instradando opportunamente le richieste o anticipandole. Il che significherebbe burocrazia zero e una PA “invisibile” in grado di intercettare prima i bisogni e soddisfarli.
Se possiamo essere “profilati” per venderci pubblicità possiamo anche essere “profilati” per essere serviti meglio dalla PA. A cosa serve ancora prevedere che il cittadino faccia una richiesta per ottenere un proprio diritto, l’ottenimento di uno sgravio fiscale o di un contributo al reddito, il posto all’asilo o le tante altre richieste che normalmente siamo costretti ad effettuare alla PA? Spesso queste richieste sono effettuate sulla base di norme fissate dalla PA e utilizzando dati che la PA possiede. Potremmo essere avvisati direttamente che abbiamo i requisiti per ottenere un beneficio eliminando lavoro inutile e fastidi al cittadino e alle imprese. Eliminando la tanto odiata “domanda”, i moduli da firmare e inviare e trasformare l’ottenimento di un diritto da “petizione di una richiesta” a diritto automatico acquisito.
La richiesta di una licenza edilizia potrebbe essere fatta attraverso dei servizi applicativi in grado di verificare le informazioni presenti nei diversi database, le informazioni presenti nella richiesta e procedere con il via libera in tempo reale. Magari anche sulla base della prassi adottata dall’ufficio e cristallizzata nel sistema. Al cittadino spetterebbe di inserire la richiesta con le informazioni aggiuntive il resto dovrebbe essere automatico.
Una smart city potrebbe verificare in tempo reale attraverso le telecamere su strada il superamento dei limiti di velocità e inviare una notifica all’automobilista. La multa, che è fatta per incutere timore e richiamare l’attenzione dell’automobilista ad un comportamento corretto, potrebbe così trasformarsi in un richiamo o una “minimulta” automatica (ovviamente cambiando le norme) ogni volta che avviene un comportamento sbagliato in automatico, ottenendo prima e meglio comportamenti socialmente accettabili. Potrebbe essere più dissuasivo se ogni volta che commetto una infrazione ricevessi una multa di pochi euro prelevati direttamente dal mio telefonino. Per non parlare della necessità di piattaforme di questo tipo nella gestione dei sensori e attuatori di una smart city.
Esistono già delle piattaforme open source che potrebbero essere prese come base per la realizzazione di questi sistemi, non sarebbe un progetto troppo complicato dal punto di vista tecnico. La cosa difficile come al solito è l’aspetto politico e organizzativo.
Valorizzare i dati e gli algoritmi attraverso il Software Defined Government può diventare anche una ulteriore fonte di finanziamento dei servizi pubblici affiancandolo al driver del prelievo fiscale. Fatto salvo il diritto alla trasparenza dei cittadini, l’enorme disponibilità di informazioni e la capacità di essere una terza parte neutrale in grado di verificarne la validità deve diventare un asset da valorizzare. Si può pensare ad esempio di vendere servizi alle aziende (con tutte le garanzie di legge e di privacy), o utilizzare dati di terze parti integrandoli ai propri per creare nuovi servizi frutto di mashup ricompensando poi ogni soggetto secondo meccanismi di compensation predefiniti. Si parla molto di tecnologie come blockchain per disintermediare le transazioni dalla moneta, tuttavia la gran parte di cittadini e imprese continua a fidarsi delle istituzioni sapendo che poi possono far valere i loro diritti, questo fiducia è la base di ogni transazione economica e vita civile.
Pensare ad un Software Defined Government significa riscrivere molti dei processi utilizzati finora, Digital Trasformation, ripensare i servizi, il backend, ripensare le regole con le quali si progettano i sistemi della PA e le stesse infrastrutture. Soprattutto mettere mani alle norme e a come si definiscono. Ma non basta, significa anche pensare a terze parti accreditate, degli auditor, che possano verificare se gli algoritmi implementati in fase di sviluppo rispondano o meno ai criteri delle leggi, siano liberi da black hole che possano rendere l’infrastruttura insicura o che possano garantire a mal intenzionati di poter usufruire in modo fraudolento di servizi. Verificare che quanto realizzato nel software corrisponda veramente a quanto previsto dalle norme e non si determinino discriminazioni o vantaggi illeciti. Si apre una questione etica non più rinviabile.
Per realizzare questo servono delle piattaforme general purpose in grado di essere configurate e riconfigurate in un linguaggio non tecnico al cambiare delle norme. È necessario pensare a piattaforme di orchestrazione, sistemi di interfacciamento con il backend e con il frontend e sistemi che consentano di implementare le regole attraverso un linguaggio facilmente comprensibile e standardizzato un po’ come il BPEL (Business Process Execution Language). Un linguaggio che sia facilmente comprensibile da chi deve dettare le policy. Per estremizzare, non mi stupirebbe se un domani non molto lontano in allegato ad una legge approvata dal parlamento ci fosse anche la descrizione dell’algoritmo con il quale realizzare i servizi, sarebbe un bel sistema per evitare interpretazioni ed errori che penalizzano la società e i cittadini.
Servono nuovi progettisti di algoritmi in grado di implementare le leggi, le policy. Il personale della pubblica amministrazione da mero esecutore di procedure deve trasformarsi nel controllore che i servizi informatizzati rispettino le leggi, devono gestire le eccezioni di chi si sente ingiustamente colpito ad un errore in un algoritmo. Gli algoritmi devono essere pubblici e modificabili da personale specializzato in modo da garantire trasparenza ed essere modificati a secondo delle disposizioni legislative e istituzionali.
Software Defined Government può essere utilizzato a tutti i livelli: comunità locali, città, regioni, governi nazionali. Nei fatti ogni organizzazione, pubblica o meno, può implementare un sistema di policy e regole che siano in grado di esporre servizi.
Il settore bancario è un uno dei tanti altri settori pesantemente coinvolti in questa trasformazione digitale (Software Defined Bank), in questo caso i servizi devono necessariamente essere associati ad un modello di vendita che sia in grado di misurare in modo più analitico il valore generato per il cliente.
Mentre il nuovo Piano Triennale della PA di AgID si annuncia in direzione di una sempre più forte integrazione via API il futuro di cui parliamo è forse meno futuro di quello che si pensa.
Mi rendo conto che è difficile parlare di Software Defined Government in un paese che non riesce a realizzare l’ANPR o fa fatica a diffondere la CIE ma se non ci diamo delle sfide alte saremo sempre il fanalino di coda dell’innovazione. Per cogliere questa sfida ci sarà bisogno della figura di architetti tecnologi che siano in grado di mettere insieme la capacità di conoscere le dinamiche delle organizzazioni, i modelli di business, le architetture tecnologiche, le evoluzioni digitali. Il tema delle piattaforme digitali sarà uno dei driver principali della trasformazione digitale che ci attende nel prossimo futuro, è importante saper cogliere questa sfida e questa opportunità.
