Vorrei richiamare in questo forum un recente ottimo articolo di @Patrizia_Saggini sperando che raggiunga le persone che in Agid stanno lavorando alla revisione delle regole tecniche:
Aggiungo un punto di vista: l’integrazione con il protocollo informatico è un requisito per una buona parte dei casi in cui si intenda adottare una qualsiasi soluzione SaaS per erogare servizi ai cittadini o gestire workflow interni. In questi casi, l’esigenza primaria è relativamente semplice, ovvero fare in modo che il servizio SaaS possa protocollare documenti via API e ricevere le informazioni di segnatura. Sfortunatamente, l’assenza di una API standard esposta da tutti i sistemi di protocollo informatico rende impossibile per un operatore di mercato la predisposizione dell’integrazione a priori, perché questa richiede uno sviluppo custom caso per caso a seconda dello specifico software di protocollo adottato dall’amministrazione.
Oltre a generare costi e aumentare la complessità dei sistemi, questo è un fattore limitante per lo sviluppo del mercato dei SaaS rivolti alla PA perché gli operatori di mercato non hanno modo di rispondere al requisito (come invece possono fare con altri requisiti come ad esempio SPID o pagoPA su cui la standardizzazione rende giustificabile l’investimento a priori) se non proponendo sistemi proprietari che includono il proprio protocollo informatico (di fatto una forma di lock-in) o lasciando alle PA il compito di incaricare un ulteriore fornitore che faccia un’attività di integrazione in forma di consulenza, con la necessità di ospitare tale connettore in una apposita soluzione IaaS o PaaS.
Il meccanismo descritto nell’allegato 6 “Comunicazione tra AOO di Documenti Amministrativi Protocollati” è molto vicino a quello che servirebbe per coprire anche questo scenario.
(Un workaround provvisorio, in attesa dell’adeguamento delle regole, sarebbe quello di collaborare alla realizzazione di un gateway open source che esponga una API unificata e parli con tutte le soluzioni di protocollo di mercato…)