Negli ultimi anni si è fatto un gran parlare, a tutti i livelli, di concetti come interoperabilità e cooperazione e integrazione applicativa. Ci è stato spiegato come questo fosse un fattore chiave per la realizzazione di sistemi informativi aperti ed interconnessi, infrastrutture necessarie per il raggiungimento degli obiettivi maggiormente qualificanti dell’Agenda Digitale. In effetti di ciò si è parlato diffusamente nel Piano Triennale per l’Informatica, dove l’aspetto dell’interoperabilità è dichiarato essere, cito testualmente, “un asse portante dell’intero sistema informativo pubblico: assicura l’interazione e lo scambio di informazioni tra le PA senza necessità di specifiche integrazioni, garantendo la piena collaborazione tra le amministrazioni pubbliche e i soggetti privati”.
Una delle maggiori promesse era quella di poter disporre di sistemi informativi le cui componenti fossero pienamente integrate, modulari e scalabili. In grado di mitigare il problema del “vendor lock-in” ed in contemporanea stimolare ed aprire il mercato. Vediamo se sta davvero andando così.
Cosa si intende per interoperabilità
Di definizioni di interoperabilità ne esistono diverse. Ne mostro qui una, probabilmente la più diffusa: “L’interoperabilità è la capacità di un prodotto o di un sistema – la cui interfaccia è completamente dichiarata, quindi senza parti di codice celato – di interagire e funzionare con altri prodotti o sistemi, esistenti o ancora in divenire, senza alcuna restrizione per l’accesso o le implementazioni”. A volte, anche a costo di essere pedanti, è bene soffermarsi sulle definizioni. Quella riportata qui sopra è molto ampia e si estende non solo a diversi sistemi ma anche ai prodotti (intesi, anche, come software). Ed in effetti è quella che in genere fra informatici si preferisce proprio per la sua genericità in grado di abbracciare la più ampia gamma di casistiche.
Manca però in questa definizione un aspetto importante, forse implicito, ma che invece andrebbe ben esplicitato: la standardizzazione. Nel senso che software che svolgono le stesse funzioni dovrebbero implementare ed esporre le medesime interfacce. La standardizzazione delle interfacce è un aspetto fondamentale laddove lo scopo dell’interoperabilità sia anche, quando non prioritariamente, quello di evitare dipendenze fra i diversi software. Facciamo un esempio concreto: supponiamo che all’interno del medesimo sistema informativo siano presenti alcuni software gestionali, ad esempio, un software contabile, un gestore documentale e, tanto per esporre un caso riferibile ad una PAL, un software per la gestione dell’anagrafe/stato civile.
Se, cosa assai probabile, volessimo che questi tre software comunicassero loro, dovremmo innanzi tutto verificare se questi espongono delle opportune interfacce di comunicazione (web services) e quindi chiedere ai rispettivi produttori di realizzare nel loro software le necessarie modifiche per fare in modo che questo possa comunicare, tramite le summenzionate interfacce, con gli altri. In questo modo è sì possibile realizzare un sistema le cui parti sono perfettamente integrate, ma risulta palese come questo tipo di integrazione soffra di alcuni limiti abbastanza seri:
- ogni fornitore dovrà apportare al proprio software tante modifiche/aggiunte, tanti sono i prodotti con cui si deve integrare, anche se dello stesso tipo; in altre parole se si dovesse integrare con 10 software contabili, 10 saranno le interfacce diverse con cui dovrà comunicare e quindi supportare;
- anche se le interfacce esposte dovrebbero rappresentare dei veri e propri “contratti” fra chi le espone e chi le utilizza, è frequente che le queste, per motivi anche leciti, possano variare; ciò, se non opportunamente comunicato e gestito, può rompere l’integrazione e conseguentemente causare malfunzionamenti anche gravi;
- l’integrazione così ottenuta rappresenta un legame forte, e quindi una dipendenza “legacy” fra i vari software; nel caso si volesse sostituire uno di questi, tutte le integrazioni con gli altri andrebbero riviste e probabilmente reimplementate; più il sistema sarà integrato, maggiore sarà la difficoltà nel sostituire una delle sue parti; in buona sostanza ci si stringe il cappio da soli.
Per ovviare a queste problematiche, molto diffuse nel mondo dell’informatica, si sono sviluppate negli anni tecniche e prodotti ad hoc. La loro complessità e il loro costo, non solo economico, rendono tuttavia la standardizzazione, laddove possibile, la strada maestra.
Il concetto di interoperabilità nel CAD e Piano Triennale
Nel Codice dell’amministrazione digitale, si definisce l’interoperabilità alla lettera dd) dell’articolo 1 comma 1: “Interoperabilità: caratteristica di un sistema informativo, le cui interfacce sono pubbliche e aperte, di interagire in maniera automatica con altri sistemi informativi per lo scambio di informazioni e l’erogazione di servizi”. Subito sotto alla lettera ee) è definito anche il concetto di cooperazione applicativa: “Cooperazione applicativa: la parte del Sistema Pubblico di Connettività finalizzata all’interazione tra i sistemi informatici dei soggetti partecipanti, per garantire l’integrazione dei metadati, delle informazioni, dei processi e procedimenti amministrativi”.
Si noti come queste definizioni siano più restrittive e declinino interoperabilità e integrazione applicativa solo nell’ottica di comunicazione fra sistemi e fra software del medesimo tipo. Lo stesso dicasi anche per il Piano Triennale che, d’altronde, discende direttamente da ciò che il CAD prescrive. Nulla è scritto riguardo alla standardizzazione delle interfacce e alla comunicazione fra i diversi software. Nel CAD l’interoperabilità è un concetto limitato al dialogo fra sistemi (e sw dello stesso tipo). E non si tratta solo di una cosa teorica, basta guardare cosa è stato implementato finora per rendersi conto che è realmente così. D’altronde non si poteva immaginare diversamente, visto l’impianto generale delle norme. Piano Triennale e Linee Guida incluse. Basta vedere com’è stato realizzata la cooperazione applicativa (leggi porte di dominio) o le indicazioni presenti nella pur ottima circolare 60 Agid (un vero quanto raro esempio di buon lavoro regolatorio), o le interfacce definite per ANPR, per rendersene conto. Si tratta di un problema? Sì, a mio avviso lo è, ed ha ripercussioni abbastanza importanti.
Gli effetti per PA e il mercato
Chiunque abbia affrontato il problema di integrare fra loro diversi software del proprio sistema informativo sa che è un’attività non banale, onerosa e dagli esiti non sempre certi. Che richiede una struttura IT degna di questo nome, non alla portata di tutti, specie nella PA, ancora di più nella PAL, che paradossalmente sono quelle che hanno sistemi informatici maggiormente articolati, vista la molteplicità delle funzioni svolte ed il loro ruolo di prima interfaccia con cittadini ed imprese. Sa anche che, come per altro afferma la legge stessa, avere un sistema ben integrato è una priorità e tenderà a cercare il più possibile di trovarne di già pronte.
La mancanza di standardizzazioni delle interfacce però rende da un lato, come si diceva sopra, molto più problematica l’integrazione, dall’altro limita la “soluzione pronta” ad un solo tipo: l’applicazione “monolitica” (quella che i produttori chiamano “suite”). Che per sua natura, essendo una sola applicazione che “fa tutto” è integrata per definizione. E nel mercato, ormai da alcuni anni, la tendenza è proprio questa: accentrare le diverse applicazioni in un unico grande “moloch”. E il marketing ha gioco facile nell’affermare che è l’unica soluzione che garantisce la piena integrazione. Perché al momento, la realtà è davvero questa. E senza qualcosa che spinga (magari costringa) i fornitori dalla PA ad esporre interfacce omogenee è destinata a rimanere tale. Peccato che questa sia una declinazione distorta di integrazione ed interoperabilità. E che ha come effetto quello di acuire, invece che mitigare, il vendor lock-in. Consegnando nelle mani di un unico fornitore l’intero sistema informativo di un Ente. Spesso non solo la parte applicativa ma, con l’avvento del Cloud, anche quella infrastrutturale.
Non solo, ma visto che solo poche grandi aziende sono in grado di realizzare una suite composta da decine di moduli, si sta assistendo alla vera e propria fagocitazione dei più piccoli da parte di questi pochi. Aspetto questo non necessariamente negativo nell’asfittico panorama del mercato della PA (e ancor più delle PAL) ma che al momento non pare aver contribuito all’innalzamento della qualità complessiva dei prodotti, anzi in alcuni casi ha tolto dal mercato piccole realtà molto valide, e nel contempo ha di fatto originato un semi monopolio.
Open source e Open format
Eppure, in un contesto dove si tende a normare e a regolare tutto, definire un set di interfacce minime, almeno per i contesti applicativi primari, non sembrerebbe un’impresa impossibile. E darebbe risultati apprezzabili, semplificando l’integrazione fra le applicazioni (in teoria si potrebbero sostituire i singoli moduli come fossero dei plug-in), riducendo la dipendenza dai fornitori e nel contempo riaprendo il mercato anche a quelle realtà focalizzate su singoli ambiti, dove magari rappresentano delle eccellenze, ma che non hanno la forza di realizzare un’intera suite. In fondo la PA è, dal punto di vista operativo, una sola entità, che segue norme omogenee. Pensare che i sw espongano interfacce omogenee non solo è lecito (anche imposto per legge e/o contrattualmente) ma quasi ovvio. D’altronde l’alternativa sarebbe quella, da molti ventilata, di avere un unico sw per tutte le PA. Che sarebbe un vero disastro, specie in Italia.
E, almeno allo stato attuale, nemmeno l’OSS, sebbene molto sponsorizzato anche di recente dalla Ministra Pisano, sembrerebbe una soluzione a portata di mano. Per tantissimi motivi. Esula lo scopo di questo articolo dissertare su questo tema, assai complesso. Va tuttavia precisato come OOS e formati (o interfacce) aperti non siano mutuamente dipendenti. O meglio, OSS presuppone implicitamente che i formati lo siano (come minimo li si può desumere dai sorgenti…), ma non vale il viceversa. Basti pensare a MS Word che, pur non essendo OSS, fa utilizzo di formati aperti. E in ogni caso, focalizzando il contesto alle applicazioni gestionali, che sono il “core” funzionale dei sistemi informativi della PA e la maggiore fonte di spesa, non si può che sottolineare come non solo le soluzioni OSS di fatto non esistano (una fetta estremamente maggioritaria appartiene a suite proprietarie, proprio l’esatto opposto di OSS), ma anche laddove esistessero, se non basate su interfacce aperte, causerebbero problemi di lock-in, se non a livello di vendor, come minimo a livello di software. Perché a livello di integrazione applicativa la loro sostituzione comporterebbe di fatto le stesse problematiche delle soluzioni proprietarie.
La presenza di interfacce aperte standardizzate, sarebbe quindi da prevedere anche in caso si volesse percorrere prioritariamente la strada dell’OSS. Non solo, la sua presenza sarebbe probabilmente un volano, un tramite, per supportare, creando il corretto substrato, l’adozione di questo modello. In altre parole, anche per percorrere la strada dell’OSS, sarebbe necessario seguire il corretto percorso, definendo delle priorità di intervento: prima l’adozione dei formati aperti, quindi la definizione e l’adozione di interfacce aperte e standard per i singoli ambiti funzionali e solo alla fine l’adozione di soluzioni OSS. Avere interfacce standard sarebbe molto più vicino al concetto di formato aperto, molto più “liberale” ma non meno efficace dell’open source, meno vincolante, anche dal punto di vista della scelta (tutta imprenditoriale) del modello di business da utilizzare. Perché non pensarci? Si aggiungerebbe un tassello il cui valore potrebbe essere più che apprezzabile.
