Diritti digitali, sistema nervoso digitale della PA e archittettura logica dei sistemi informativi della PA

L'obiettivo del d.lgs 217 del 2017 (G.U. del 12/01/2018), disposizioni integrative e correttive al d.lgs 179 del 2016 in materia di riorganizzazione delle amministrazioni pubbliche, è quello di contribuire alla definizione di un quadro normativo idoneo ad abilitare e supportare le azioni di attuazione dell'agenda digitale dotando i cittadini, le imprese e le amministrazioni di strumenti e servizi idonei a rendere effettivi i diritti di cittadinanza digitale.
Il CAD stabilisce che le pubbliche amministrazioni si debbano organizzare utilizzando le tecnologie dell'informazione e della comunicazione per la realizzazione degli obiettivi di:

• efficienza
• efficacia
• economicità
• imparzialità
• trasparenza
• semplificazione
• partecipazione

 nel rispetto dei principi di uguaglianza e di non discriminazione per l'effettivo riconoscimento dei diritti digitali dei cittadini e delle imprese.
Uno degli obiettivi più complesso da raggiungere è la trasparenza e l'open government. Mettere a disposizione l'enorme patrimonio informativo della pubblica amministrazione può diventare il volano, oltre che della trasparenza, ma anche della partecipazione.
Benché la dematerializzazione, l'archiviazione sostitutiva, la gestione elettronica dei documenti, la firma digitale, la PEC, SPID, PagoPA e la marca da bollo telematica siano mezzi indispensabili per l'attuazione delle procedure amministrative informatizzate che tendono a rendere più efficienti ed economici gli attuali processi della PA,  è solo attraverso la reingegnerizzazione dei processi che si raggiunge il vero obiettivo di efficacia.
Alla base della dematerializzazione c'è il processo di digitalizzazione dei documenti carteacei pregressi e la produzione di documenti "nativi" digitali attraverso procedure completamente informatizzate riviste rispetto alle procedure classiche preesistenti. Fondamentale per questo passaggio è l'archivio digitale le cui caratteristiche principali riguardano:

1. il titolario di classificazione, il massimario di scarto e l'individuazione dei metadati (profilo dei documenti che descrivono i documenti e aggregati logicamente superiori nelle due coordinate di tempo e di spazio)
2. la sostituzione dei documenti cartacei con i documenti informatici e attuazione delle politiche di scarto
3. l'individuazione del sistema informativo e adozione delle misure di sicurezza logica e fisica del sistema
4. l'alimentazione dell'archivio con i nuovi documenti "nativi" digitali

A fondamento della attività delle PA, oltre alle procedure, c'è l'enorme patrimonio informativo acquisito nel tempo e il corrispondente "magazzino" dei documenti prodotti e acquisiti. L'enorme "docwarehouse" della PA deve essere opportunamente mantenuto e deve poggiare su di una infrastruttura sempre disponibile, solida, scalabile e sicura. La PA per poter implementare e condurre una infrastruttura con tali caratteristiche deve sostenere un costo notevole in termini di risorse economiche, umane e logistiche. 

Inoltre una delle problematiche spesso evidenziate è che, anche volendo esternalizzare tale servizio, vi è l'incapacità di scrivere capitolati e specifiche dei requisiti che possano ben veicolare la fornitura. Questa incapacità è dovuta in parte alla mancanza di competenze specifiche negli organici delle amministrazioni e in parte al voler relegare quelle poche risorse presenti con le adeguate competenze tecniche a meri esecutori dell'ordinaria operatività tenendoli lontane dalle figure decisorie.

La naturale conseguenza è quella che vede l'amministrazione pubblica in posizione di sudditanza rispetto al fornitore dei servizi informatici e il verificarsi di situazioni di lock-in rispetto al fornitore stesso.

Per poter evitare il verificarsi di tali situazioni sarebbe opportuno che la PA si dotasse di Data Center di Stato dislocati sul territorio italiano, come già prefigurato dal Ministero per l'Innovazione Tecnologica, suddivisi per zone geografiche (ad es. un data center per il nord, uno per il centro, uno per il sud e due per le isole) che offrono un unico paradigma di piattaforma cloud a cui tutti gli enti possano far riferimento per l'implementazione ed erogazione dei propri servizi online. Ogni ente pagherebbe, oltre allo sviluppo e manutenzione dei propri servizi, una percentuale dei costi di conduzione proporzionale alla dimensione dei servizi stessi ospitati sul cloud della PA. Questo abbatterebbe drasticamente i costi che ogni amministrazione deve sostenere per i servizi di base di gestione di un CED (energia, condizionamento, logistica, asset hardware e software, aggiornamento tecnologico e manutenzione, sicurezza fisica e logica, adeguamento alle certificazioni di qualità, risorse qualificate per la conduzione dei sistemi, ecc…). Questa condivisione di risorse di base faciliterebbe anche la buona pratica del riuso che spesso è ostacolata da voler far funzionare piattaforme software in contesti hardware e software diversi da quelli in cui originariamente sono abituate a funzionare. Un unico investimento iniziale verrebbe messo a fattor comune per tutte le amministrazioni che potranno dedicarsi esclusivamente alla definizione dei servizi che intendono erogare, raggiungendo così l'obiettivo di economicità. 

La costellazione dei data center della PA, insieme alla diffusione pervasiva della connettività, nonché alla diffusione della banda ultralarga costituirebbero il sistema nervoso digitale della PA italiana. Sviluppare un tale sistema di infrastrutture digitali può garantire al nostro Paese l’autonomia tecnologica necessaria per il controllo dei nostri dati.

Dal punto di vista dell'architettura logica il modello da adottare dovrebbe essere quello dei microservizi, servizi autonomi che interagiscono tra di loro, dove ognuno è specializzato in un sol compito. Un unico compito fatto bene con il suo piccolo insieme di responsabilità. 

Nell'ambito di una richiesta di un macroservizio da parte del client, per fare da router verso i microservizi necessari è stata introdotta l'API Gateway. Essa espone una interfaccia verso il client e si preoccupa di realizzare la logica in maniera trasparente.

Quando un client chiama un unico macroservizio è l'API Gateway che lo realizza chiamando gli n servizi necessari e si occupa di restituire l'output.

Nell'architettura a microservizi la comunicazione tra i servizi in genere è basata su chiamate HTTP tramite le API REST, passando i dati in formato JSON e spesso attraverso una coda di messaggi.

Per garantire un accoppiamento lasco, ogni servizio ha un proprio schema DB. Un servizio che ha bisogno di transazioni ACID (Atomiche, Consistenti, Isolate, Durabili o persistenti) potrebbe usare un database relazionale, mentre un servizio di social network potrebbe usare un database NOSQL.

La comunicazione tra i servizi avviene attraverso la rete al fine di garantire l'indipendenza tra i servizi ed evitare ogni forma di accoppiamento.

Ogni microservizio è visto all'esterno come una black-box. Esso espone solo una interfaccia applicativa astraendo rispetto al dettaglio di come sono realizzate le sue funzionalità, al linguaggio specifico e alla tecnologia usati. In questo modo il cambiamento di ciascun microservizio non impatta sugli altri.