Le soluzioni SaaS devono consentire l’interoperabilità dei sistemi informativi fra le Amministrazioni pubbliche e fra gli altri applicativi in uso presso il medesimo Acquirente. A tal fine le soluzioni SaaS devo esporre opportune Application Programming Interface (API).
Continua a leggere su: http://cloud-pa.readthedocs.io/it/latest/circolari/SaaS/allegato_docs/interoperabilita-e-portabilita.html
E’ possibile avere un dettaglio del cosa si intende con il requisito RIP10?
Interoperabilità
Nel caso di CSP internazionali, si chiede se il requisito di interoperabilità con le altre applicazioni SaaS per le PA (es.: SPID, PagoPA, ecc.) debba essere inteso come obbligatorio
Interoperabilità
Si chiede se all’interno del Cloud PA i CSP PaaS e IaaS sono o saranno tra di loro interoperabili
Throttling (RIP4)
In primo luogo si vuole fare notare che per quanto concerne le limitazioni di carichi di lavoro sottoponibili il throttling non è sempre applicabile; si pensi ad esempio i servizi Saas con User Interface dove il limite solitamente è dato dal nro di utenti concorrenti.
In secondo luogo non tutti i servizi Saas utilizzano il throttling come strumento di limitazione dei carichi sottoponibili.
Si consiglia quindi di modificare il requisito richiedendo il throttling od altri strumenti di limitazione dei carichi.
Interoperabilità con SPID e PagoPA (RIP6)
I servizi Saas dei principali provider sono per loro natura standard e fruibili da una molteplicità di clienti sia pubblici che privati, mentre gli strumenti SPID e Saas sono per loro natura dedicati al mercato pubblico italiano. La creazione di una interfaccia per il loro utilizzo imporrebbe un investimento specifico
Si consiglia quindi, di rendere tale requisito opzionale e di demandarne la realizzazione alla fase di procurement
Retention Period (RIP7,SLI0, SLI08))
I servizi Saas sono per loro natura dinamici; il loro provisioning è inoltre guidato dal cliente. I principali Saas provider sono anche fornitori di servzi Paas/Iaas e quindi forniscono a catalogo tool per la gestione dei dati e dei backup; il provisoning e la gestione dello storage per la gestione dei dati è di responsabilità del cliente. Ne consegue che il periodo di “retention” dei dati è definito dal cliente che in caso di phase out dovrà allocare lo storage per la retention dei dati.
Si suggerisce di eliminare il requisito ed i relativi SLI oppure, in alternativa di sostituirli con un requisito che indichi la possibilità per il Cliente di acquistare i soli servizi di storage e backup all’atto della terminazione delle attività elaborative.
NOTA: di norma il Service Provider non notifica la terminazione del servizio, essendo questo sempre attivo.
Piano di reversibilità (RIP10, CL17)
Un fornitore Saas può fornire le modalità di estrazione dei dati applicativi e di quelli derivati in formati che siano degli standard di mercato; non è possibile in ogni caso garantire la “portabilità”, infatti un SaaS provider non puo’ conoscere i formati necessari all’ambient Target, ma puo’ garantire l’aderenza dei dati ai principali standard di mercato in merito all’export degli stessi
Si consiglia quindi di riformulare il requisito richiedendo “la disponibilità all’export dei dati del servizio secondo i principali standard di mercato”.
NOTA: se per reversibilità si intende che un servizio Saas deve poter essere erogato su diverse piattaforme, si fa notare che le diverse piattaforme previste dal piano triennale (SPC1, PSN e CSP) hanno stack tecnologici diversi e tra loro probabilmente non compatibili. Si suggerisce quindi di limitarsi a prevedere la possibilità di estrazione dei dati.