Raccolgo la sfida del presidente di Anorc Professioni Andrea Lisi e mi accingo a riproporre una proposta di digitalizzazione già fatta a suo tempo, tra l’altro parzialmente perseguita, e poi lasciata miseramente morire perché metteva in discussione gli equilibri ma soprattutto gli interessi dei fornitori di soluzioni informatiche per la PA.
Nel 2004, in occasione del primo bando di e-government, fu avviato un progetto, chiamato People (Progetto Enti On-line Portali Locali E-government), che aveva come obiettivo la standardizzazione delle interfacce tra il front-office ed il back-office degli uffici pubblici. In pratica, questo progetto, che aveva ricevuto un cospicuo finanziamento pubblico, voleva raggiungere i seguenti obiettivi, dal punto di vista concettuale:
- Censire tutti i servizi che dovevano essere erogati dagli enti locali ai cittadini, alle imprese ed alle altre amministrazioni;
- definire uno standard di contenuti (strutture dati) necessarie per poter richiedere uno specifico servizio, in modo che, quale che fosse il comune cui ci si rivolgeva, la richiesta contenesse sempre solo i dati necessari;
- Nel rispetto della legge Bassanini, nessun cittadino doveva più obbligato a comunicare ad una PA informazioni già in possesso di un’altra amministrazione.
Per perseguire questi obiettivi, dal punto di vista pratico, si doveva costruire un portale general purpose, messo a disposizione dell’allora CNIPA, che potesse essere utilizzato da qualunque amministrazione, senza aggravio di costi.
Il progetto era stato pensato per essere assolutamente rispettoso del titolo V, che lasciava agli enti locali la libertà di organizzarsi al proprio interno secondo le proprie scelte.
I risultati di quel progetto sono stati soddisfacenti a metà.
Da una parte è stata curata la parte semantica, condivisa con i rappresentanti degli enti locali partecipanti al progetto (e quindi non calata dall’alto) e mediata da alcuni specialisti che avevano il ruolo di ‘custodi dell’ortodossia’, ovvero da coloro che, nel mare magno delle richieste degli enti, avessero l’autorevolezza per dire qualche no. A titolo di esempio, nella costruzione dei dati anagrafici un comune voleva inserire i ‘titoli nobiliari’, ed è stato fatto loro presente che erano stati aboliti dalla Costituzione già da parecchi anni!
Il risultato è stato un insieme di oltre 10.000 oggetti (entità per chi non riesce a scrollarsi di dosso il passato) modellati, per oltre 200 servizi della PA locale. I modelli sono stati realizzati in UML ed in RDF/OWL e da questi venivano generate automaticamente le definizioni XSD dei file XML, nonché i WSDL per costruire gli endpoint.
Con questi presupposti, fu chiesto ad alcune aziende, rappresentanti oltre l’80% dei comuni, di adeguare le interfacce dei loro prodotti software per dialogare tramite web service sia tra comuni, che con le amministrazioni centrali. Purtroppo, come sempre avviene in questo paese, non sono state messe delle penali nei contratti con i quali si affidava alle aziende lo sviluppo delle soluzioni software, per cui l’azienda chiamata a certificare le soluzioni presentate ne ha trovata una soltanto conforme ai modelli. Le altre niente, non hanno nemmeno tentato di rendere conformi i loro prodotti.
Giunge quindi spontanea la domanda: perché le aziende non hanno rispettato i modelli?
La risposta è ovvia: perché se lo avessero fatto avrebbero perso potere nei confronti dell’amministrazione. Perché se tutti gli enti pretendessero di utilizzare interfacce comuni, ogni azienda potrebbe essere sostituita nell’ente in cui è presente, lasciando spazio a delle new entry più capaci e moderne di loro.
All’epoca, era previsto che fosse il progetto a finanziare l’adeguamento dei prodotti alle nuove interfacce, quindi finanziando meno di dieci aziende si sarebbe standardizzato l’intero parco software della PA locale.
In particolare, visto che i servizi a cui era stata data la precedenza erano quelli anagrafici, il risultato sarebbe stato quello di avere delle interfacce formali standard verso un’anagrafe centrale, che non fosse una ‘porcheria’ come il vecchio SAIA.
Oggi, visto l’esito del referendum Costituzionale, e la mancata riforma/abolizione del titolo V, rimane a tutt’oggi appeso il problema della proprietà dei dati Anagrafici: sono dei Comuni o sono del Ministero dell’Interno?
Con la soluzione proposta il problema sarebbe stato irrilevante, poiché ci sarebbero state le interfacce per interrogare le singole anagrafi in maniera puntuale, e, con l’avvento del Cloud, si sarebbero potuti mettere sulla nuvola tutte le diverse soluzioni dei comuni, e magari utilizzare un Database a grafo per interrogarle nella loro complessità.
Niente lavori di accentramento, o di statalizzazione dell’informatica, ma soprattutto niente opposizione da parte dei comuni alla nuova Anagrafe Unica, perché i comuni avrebbero mantenuto i loro software integrati con la loro anagrafe, e non avrebbero dovuto introdurre una soluzione calata dall’alto, che da un lato fa funzionare una cosa (l’anagrafe) ma dall’altro scarica sugli enti il costo dell’adeguamento dei propri software per riuscire a seguitare a far funzionare gli altri servizi.
Conosco personalmente molte delle persone che hanno partecipato e coordinato le fasi iniziali del progetto dell’anagrafe unica quando Francesco Caio era ‘Digital champion’: tutti grandi professionisti provenienti dalla PA centrale, cui mancava nel proprio DNA il concetto di architetture distribuite e che vedevano internet come qualcosa da vietare ai dipendenti.
Ma veniamo ad un altro punto: nel progetto People era stata avviata una nuova attività, quella di censimento dei processi interni della PA locale, divisi per aree tematiche di competenza.
Infatti, partendo dai servizi, erano stati costruiti i seguenti due assiomi:
- ogni ente deve erogare soltanto servizi diretti a soddisfare le esigenze di un altro reparto al proprio interno, di un’altra amministrazione, dei cittadini e delle imprese. Qualunque altro servizio che non risponda a questi requisiti deve essere eliminato;
- ogni servizio deve avere uno ed un solo responsabile (Owner), e si esplica attraverso la compilazione di una richiesta standard cui corrisponde una risposta anch’essa standard o un’eccezione applicativa.
Attraverso questi due assiomi basilari, sono stati assemblati processi complessi, che vedevano la partecipazione, sia sincrona che asincrona, di diversi soggetti.
Oggi è arrivato il momento di riprendere in mano quel progetto, rivederlo nelle tecnologie, ed attuarlo.
Come ho già sostenuto più volte, non c’è bisogno di costruire 20 data center per la PA in Italia. Se proprio vogliamo esagerare ed essere autonomi in tutto e per tutto, ne basterebbero 3 o addirittura 2, in modo da essere uno backup dell’altro.
Nel progetto People avevamo anticipato il concetto degli AWS (Amazon Web Services), i dati non potevano essere portati all’estero, quindi il problema di installare tutto su un data center Amazon o Google non si poneva affatto.
Però si poneva e si pone tuttora il problema di avere in Italia un soggetto che sia in grado di fornire soluzioni SAAS, IAAS e PAAS: nessuna delle nostre grandi aziende che si spacciano per provider di soluzioni cloud è in grado di mettere in campo un’offerta in tal senso sul territorio nazionale.
Per cui, ben venga la realizzazione di 2 o 3 centri servizi, purché siano al servizio del paese e non un inutile orpello sulla giacca di qualche governatore regionale.
I soldi riservati al Commissario di Governo per il digitale Diego Piacentini dovrebbero essere spesi in questa direzione, per creare degli standard e non per creare delle soluzioni applicative.
Infine, due parole sulle gare. Il sistema delle gare è marcio al suo interno: lo si sa da sempre, da sempre si sa che è possibile pilotarne l’esito, da sempre si sa che è il fuoco che alimenta le attività illecite. Si veda l’ultimo scandalo Consip.
Io sono anni che vado raccontando in giro che, almeno nel campo informativo, in Italia, le gare andrebbero abolite. Provo a rispiegare il perché.
L’Italia è però il paese delle piccole aziende, degli artigiani, degli inventori. E allora, cerchiamo di muoverci in modo da favorire le piccole aziende, quelle che magari hanno una collocazione territoriale, che non hanno sulle spalle strutture organizzative pachidermiche il cui unico risultato è aumentare a dismisura i costi.
Diamo spazio ai talenti. Se le specifiche formali di una applicazione sono chiare, qualunque azienda può essere capace di realizzare una soluzione: internet lo dimostra. E allora, proviamo ad ammettere chiunque a rispondere alle necessità applicative, selezionando le aziende solo in base alla loro capacità realizzativa e non, ad esempio, al loro fatturato, cosa che lascia fuori il 99% delle aziende o costringe le piccole a raggruppamenti di impresa dove l’obiettivo della impresa principale consiste nel fare utile sulla pelle delle altre aziende senza metterci un briciolo di lavoro, ma anzi, riciclando quanto hanno di legacy negli scantinati.
In fondo si tratta di fare una cosa piuttosto semplice: rivedere attraverso un approccio agile tipo Scrum, il concetto di bando gara.
La cosa spaventa, anzi terrorizza perché rende democratico l’intero processo, e non permette più gli inciuci che oggi sono la norma.
Dal punto di vista tecnologico c’è tutto quello di cui abbiamo bisogno, basta decidersi ad utilizzarlo.
- E’ possibile partire da microservizi, fornendo specifiche di interfaccia standard espresse in un formalismo standard.
- È possibile selezionare a priori degli strumenti automatici di test, in grado di verificare se il componente software superi oppure no l’insieme dei test per lui definiti. Tali strumenti saranno a disposizione sia del committente che di tutti i partecipanti.
- È possibile definire a priori i test che devono essere effettuati sul servizio, al fine di poterlo accettare.
- È possibile valutare la complessità del servizio, proprio in base al numero di test che sono stati individuati, e di conseguenza, valutarne a priori il costo complessivo,
- È possibile riempire un contenitore (backlog) di tutti questi servizi, lasciando che siano le aziende a decidere quali vogliono affrontare, sulla base di un’equa distribuzione del fatturato fra tutti i pretendenti.
- È possibile richiede al fornitore, dopo un certo periodo, anche una delivery continua, attraverso sistemi automatici di compilazione che ogni notte costruiscano la build corrente, rendendo chiaro lo stato di avanzamento dei lavori e la rispondenza ai test.
Ecco, chiamerei questo un approccio democratico allo sviluppo del software.
Un approccio che favorisce gli innovatori, le aziende più veloci ad utilizzare le nuove tecnologie, quelle capaci di rispondere nel minor tempo possibile e con i più elevati standard di qualità alle richieste della committenza.
Fare questo per lo sviluppo software è possibile: basta un po’ di lungimiranza e, ovviamente, la volontà politica.
E chissà che non si possa applicare un approccio simile anche per la manutenzione delle strade!
