devono essere soddisfatti o si intende che è obbligatoria la Dichiarazione Fornitore SaaS?
In altre parole prendendo come mero scopo di esempio il requisiti preliminari RP1 è obbligatorio che venga soddisfatto e quindi che l’applicazione SAAS sia in grado di interagire con le API esposte dalla piattaforma Cloud oppure si intende obbligatoria la dichiarazione (sia essa positiva o negativa)?
Se basta la dichiarazione, ci isono dei requisiti che vanno obbligatoriamente soddisfatti?
Salve Andrea,
per poter ottenere la qualificazione è necessario disporre almeno di tutti i requisiti del Livello 1 (L1) riportati nella tabella che hai indicato. Ogni requisito richiede adempimenti differenti e presuppone diversi tipi di verifiche (indicate nella terza colonna delle varie tabelle dei requisiti).
Nella sezione “Tipologie di verifiche previste” sono proprio spiegate le diverse verifiche e anche cosa si intende per “Dichiarazione del Fornitore SaaS”.
Nel caso di RP1-RP4 si tratta di requisiti che interessano solo le soluzioni destinate ad essere installate su PSN o su Cloud SPC Lotto 1, quindi è sufficiente dichiarare se la soluzione opera o meno in quelle condizioni. Queste informazioni sono anche funzionali alla predisposizione di eventuali “verifiche tecniche” nei casi in cui queste sono previste.
Molto probabilmente quest’ultimo aspetto non è chiarissimo, possiamo sicuramente trovare una formula che lo renda più esplicito, quindi grazie mille per la segnalazione.
Salve Antonio,
sempre sul tema dei requisiti… da una lettura più accurata della circolare non risulta chiaro - o perlomeno non sembra essere trattato nel dettaglio - il tema dell’equiparazione dei requisiti necessari a poter erogare servizi SaaS con il fornitore dell’attuale insieme di servizi SaaS del lotto 1 SPC-Cloud.
Il rischio è che si possano creare disparità rispetto ai requisiti formulati a suo tempo nel capitolato della gara SPC-Cloud e quanto previsto in questo circolare.
A titolo esemplificativo ma non esaustivo ci sono requisiti, relativi al Lotto 1 SPC-Cloud (capitolo 1.5 Tipologia Servizi L1.S5 – SaaS: requisiti trasversali) come questi:
disponibilità di funzionalità/strumento (console e/o pannello) integrato con il “Portale di governo e gestione della fornitura”, di gestione delle licenze/risorse/servizi disponibili/acquistate e disponibilità di rappresentazione in grafici;
possibilità di integrare la soluzione in cloud agli applicativi già in uso tramite un set di API (Advanced Programming Interfaces);
disponibilita di reportistica personalizzata, aggiornata con cadenza almeno mensile, sull.utilizzo dei singoli servizi a livello di singolo utente;
disponibilita di una funzionalita di configurazione notifiche/alert customizzati (via email, SMS, …) sugli indicatori di performance monitorati e sulle informazioni di carattere amministrativo (ad esempio raggiungimento/avvicinamento delle soglie di utilizzo dell.importo contrattuale …).
Anche altri più generalizzati nel contesto dell’intero capitolato SPC-Cloud Lotto 1 hanno la loro rilevanza in questo cohtesto come:
il trattamento dei dati, la localizzazione dei data center da usare per erogare i servizi, il fatto che l’infrastruttura debba essere dedicata all’erogazione di servizi rivolti alla pubblica amministrazione, ecc.
Ho letto (anche se un po’ in ritardo) il documento.
I dubbi che ho sempre nell’accettare i servizi SPC-X sono:
quanto è già vecchio tempo che la burorazia completa il corso?
Ovvero: meglio fare una gara che preveda sempre lo stesso server o che preveda sempre la fornitura di un server con determinati requisiti:
es.
processo XYZ o processore di penultima generazione (in caso ne appaia una nuova?)
come evolve all’evolvere della tecnologia?
Esempio: ipotizziamo che google possa partecipare con GSuite, se domani l’AI porta una disruption nelle piattaforme SAAS questa nuova implementazione mi verrà garantita o resto legato fino a fine contratto ad un modello “vecchio”?
Esempio: ipotizziamo che la soluzione proposta sia una soluzione custom/poco conosciuta? Se rimane immobile tra tre anni avrò un “ferro vecchio”, cosa faccio? La domanda quindi è: come è gestita la parte evolutiva? Mi aspetto siano incluse le evoluzioni fino a fine contratto oltre alle manutenzioni?
La fase di uscita: ipotizziamo che oggi aderisco ad un software SaaS perchè il migliore presente sul mercato. Tra 3 anni diventa obsoleto, la fase di uscita dal servizio va gestita e non ci sono mai garanzie sul fatto che il fornitore aiuta in questa fase di phase-out e migrazione ad altra piattaforma. Parlando con Tim che gestisce l’SPC-Cloud attuale (tra gli altri) la risposta è: si può prolungare per altro X tempo e comunque eventualmente possiamo garantire le stesse condizioni a chi vuole proseguire. Ma se io non voglio proseguire, la migrazione come la gestisco?
La domanda è: il fornitore prevederà dei servizi di cloud disabling?
Nel SPC-Cloud attuale ad esempio non sono previste le vpn. Può capitare che nel fare una gara molto grande qualcosa sfugga. Come gestire questi aspetti “customizzati”? Di solito finisce che si gestiscono fuori gara in trattativa privata. Dovendo andare in SPC-CLOUD se si entra in trattativa secondaria per altri aspetti si è abbastanza legali economicamente e ci si lega ancora più nel tempo. C’è spazio per gestire dall’inizio eventuali “mancanze” della gara che possono capitare perchè prevedere tutto con l’evoluzione tecnologica attuale è praticamente impossibile?
Salve. Poiché la piattaforma Disqus sembra non riuscire a gestire correttamente i post, risottometto anche in questo Forum il mio contributo.
Si segnala in generale un processo di qualificazione oneroso e complesso per il Fornitore , sia con riferimento alla documentazione da produrre sia come attività/processi da adottare.
Con riferimento all’articolo 3 punti 1 e 2 della Bozza di Circolare, nel caso in cui la soluzione SaaS da qualificare sia basata su servizi cloud di tipo IaaS/PaaS erogati da un datacenter di un Terzo ( ad esempio un datacenter di un Public Cloud Provider) non è chiaro se il Fornitore di Iaas/Paas debba richiedere una preventiva qualificazione di detti servizi . Come potrebbe il CSP qualificarsi mancando i requisiti relativi ai servizi relativi a Iaas/Paas ?
Nel caso in cui la soluzione SaaS sia l’aggregazione di più servizi erogati in modalità SaaS, è opportuno poter qualificare la soluzione nella sua interezza- invece di chiedere la qualificazione e di ciascuno dei servizi di cui la soluzione è composta . Si segnala che in quest’ultimo caso ci sarebbe una moltitudine di servizi affini da qualificare singolarmente.
Tenuto conto che la Bozza di Circolare prevede che l’istanza di qualificazione debba essere presentata (per ciascuna soluzione) da un “fornitore” -non meglio specificato- che deve essere iscritto al portale “Acquisti in rete”, non è chiaro se la domanda debba essere presentata dal titolare dei diritti sulla Soluzione oppure possa essere effettuata da altro soggetto (es. Partner).
La bozza di Circolare definisce il Cloud della PA come quello “composto dalle infrastrutture e i servizi IaaS/Paas erogati da Cloud SPC, dai PSN e dagli altri CSP che saranno qualificati come compatibili con i requisiti della P.A. Non è chiaro se Agid intenda prescrivere la necessità dei suddetti requisiti e della specifica procedura di qualificazione solo per le soluzioni SaaS per la PA erogabili su Cloud della PA e- quindi- ammetta implicitamente la permanenza sul mercato di CSP che non operano su Cloud della PA oppure se, dopo l’avvio del Marketplace, non sia più possibile l’approvvigionamento di soluzioni SaaS erogate su infrastrutture non appartenenti al CloudPA. Riteniamo necessario che la Circolare chiarisca in maniera inequivocabile l’ammissibilità della coesistenza dei suddetti ambiti o modelli o che preveda espressamente anche dopo l’avvio del Marketplace che permanga la possibilità per le P.A. di approvvigionarsi su infrastrutture non appartenenti al Cloud PA .
Si rileva che la Bozza di Circolare prevede l’allegato “B” costituito dalla Circolare “Disposizioni per il procurement dei servizi SaaS per il cloud delle PA” (redatte da Consip - 10 ottobre 2017), si segnala quanto segue:
a) Il documento Consip è relativo ad un regime transitorio e non può costituire un allegato ad una Circolare che delinea un assetto definitivo in relazione alle soluzioni SaaS ;
b) nello stesso documento (segnatamente nella parte dedicata alle disposizioni per il procurement dei prodotti SaaS in regime transitorio) si afferma che “nella fase corrente, nell’attesa che sia operativa la circolare Agid indicante “Criteri per la qualificazione di servizi SaaS per il Cloud della PA”, le offerte di mercato per servizi Cloud di tipo SaaS, già presenti nei cataloghi degli strumenti di acquisto Consip del Me.Pa, dello SDA e delle Convenzioni, continueranno ad essere disponibili alle Amministrazioni”. Consip aggiunge che “successivamente all’entrata in vigore della suddetta normativa, Consip provvederà ad deguare la vetrina del Marketplace SaaS con le soluzioni qualificate che si renderanno via via disponibili e procederà a specializzare le categorie dei servizi Cloud “Marketplace SaaS” in modo progressivo inizialmente nel Me.PA, successivamente nello SDA”. Per le future edizioni delle Convenzioni relative al software, Consip non prevedel’inserimento nei listini di licenze di tipo Cloud”.
Ci sembra controproducente (non solo per gli operatori di mercato, ma anche per le stesse amministrazioni) escludere lo strumento delle Convenzioni che, invece, è una metodologia di acquisto che ben si concilia con la creazione di un Marketplace.
In alcuni punti della circolare si fa riferimento ad attività di verifiche documentali sulle soluzioni SaaS con disponibilità di API e Documentazione tecnica (ad es. RSP 21). Come si concilia questo tipo di richiesta nel caso in cui le informazioni richieste siano coperte da segreto industriale?
Con riferimento al requisito RS9 Si segnala che alcune soluzioni Saas disponibili sul mercato prevedono il blocco del traffico “da” ma non “verso” URL presenti in una black list. Si chiede di non escludere a priori dette Soluzioni in quanto la funzionalità di blocco “verso” può essere garantita attraverso l’acquisizione di software/soluzioni esterni alla Soluzione Saas.
Con riferimento al Requisito RipS7 se per configurazioni si intendono quelle relative alla piattaforma multi-tenant gestita dal provider per erogare il servizio, si segnala che la richiesta non è – nel concreto – praticabile in quanto le medesime configurazioni non fornirebbero informazioni intellegibili e comunque non potrebbero essere riapplicate. Nel caso in cui per configurazioni si intendano quelle applicate dal singolo cliente nella personalizzazione dei propri servizi, generalmente l’onere del tracciamento dei cambiamenti è di pertinenza del cliente stesso, tramite i propri sistemi (tipicamente CMDB).
Si segnala che per alcuni CSP l’eventuale variazione degli SLA viene comunicata nell’ambito di comunicazioni tecnico- commerciali rivolte a tutta la clientela (per es. sui siti dei Fornitori). Detta comunicazione può essere considerata equipollente alla notifica?
Con riferimento al seguente requisito :
il Fornitore SaaS dovrà garantire che la portabilità della soluzione SaaS (o reversibilità) sia conforme con i criteri e gli scenari delineati nel documento “Piattaforma SPC Cloud e Reversibilità” (disponibile online all’indirizzo https://www.cloudspc.it/fil… Inoltre, il Fornitore SaaS dovrà predisporre e consegnare all’Acquirente un dettagliato piano di reversibilità.
si richiede ad Agid di specificare se questa richiesta riguarda le soluzioni erogate da SPC/PSN o anche quelle erogate da CSP.
12)Nella Bozza di Circolare sembra che Agid tratti in modo uniforme soluzioni Saas pure e soluzioni Saas che poggiano su Iaas chiedendo che rispondano agli stessi requisiti senza distinguere le due casistiche. Si segnala che i requisiti tipici di un modello non necessariamente sono compatibili con l’altro e che si rende necessario operare le opportune distinzioni in modo da prevedere una regolamentazione corretta ed effettivamente applicabile.
13)Con riferimento a quanto richiesto al punto RPS2 si segnala che il ripristino delle configurazioni sw non è in alcuni casi tecnicamente o concretamente esigibile, a titolo esemplificativo nel caso del modello multitenant. Pertanto, è necessario che la Circolare debba prevedere tale requisito solo “ove applicabile”.
La circolare, in consultazione, prevede un processo di qualificazione delle soluzioni SaaS e specifica all’articolo 6 “Si specifica, inoltre, che in caso di aggiornamento del software che incide su almeno uno dei requisiti di cui all’art. 4, il soggetto interessato deve procedere a presentare una nuova richiesta di qualificazione della soluzione SaaS. In tal caso, al fine di semplificare il nuovo processo di qualificazione, l’Agenzia potrà tenere conto della documentazione già presentata e procedere alla sola verifica dei nuovi requisiti”.
Il mercato e l’evoluzione tecnologica in questo settore sono rapidissime, assistiamo ad aggiornamenti continui soprattutto delle componenti PaaS sia in termini di nuove funzionalità che ad aggiornamenti anche significativi.
Alla luce dei costi necessari per ottenere una qualificazione (sia per gli operatori di mercato che per Agid) e dei rispettivi tempi (documentare la soluzione e verificarla), la necessità di ripercorrere l’intero processo per ogni nuova funzionalità / componente che vuole essere erogata dalla medesima piattaforma, rischia, paradossalmente e contrariamente agli obiettivi del Piano Triennale, di rallentare l’innovazione nell’offerta di soluzioni SaaS.
Questo ragionamento vale per tutti i modelli identificati dalla circolare “Custom”, “Multi-tenant”, “configurable”, “Scalable”, così come per tutte le tipologie di requisiti individuati “preliminari”, “organizzativi”, specifici.
Nel caso in cui una applicazione o una suite di applicazioni ottenga la qualificazione con una determinata offerta ad una certa data, e si voglia poi integrare le funzionalità o le componenti fornite (es. integrare un gestionale con un chatbot, inserire motori di BI e analytics, machine learning etc.), dalla lettura della circolare sembra che sia necessario attivare un nuovo e completo processo di certificazione per le nuove funzioni introdotte o per aggiornamenti importanti dovuti a modifiche degli strati PaaS con tutto quello che comporta in termini di tempi (anche tenendo conto del fatto che si lavora solo sul nuovo cosi come indicato nell’articolo 6)
Per ovviare a questo, che secondo noi è un limite alla velocità di adozione delle nuove possibilità offerte dal Cloud per la PA, si ritiene necessario prevedere un processo specifico (ovviamente più light, ad esempio in modalità RFC request for change o con meccanismi di autocertificazione) per mantenere la qualificazione di una soluzione precedentemente qualificata, alla quale si siano aggiunte nuove funzionalità che riduca al minimo i tempi e i costi così da incentivare l’ampliamento funzionale delle soluzioni SaaS per la PA.
Luigi Zanella - Dedagroup Public Services
Pongo alcune domande relative ad architetture e requisiti discussi nell’allegato A al fine di avere chiarimenti in merito:
Nel modello architetturale “Scalable SaaS application” si parla di scalabilità delle istanze applicative. Come la grafica lascia intendere, la scalabilità è richiesta anche sulla componente database oppure soltanto sulle componenti applicative (BL, UI, API, …)?
Con il requisito RP1 si intende che la responsabilità di “autoscaling” è data alla soluzione SaaS quando tipicamente sono competenze delegate ad un layer sottostante (PaaS). I servizi infatti si ritroverebbero a dover interagire con le API della piattaforma Cloud nei momenti di maggior carico. Come occorre considerare tali requisiti in caso di adozione di PaaS con questo tipo di caratteristiche?
Sul requisito RP2 inerente ai KPI, l’Aquirente è interessato a tutti quegli indicatori che possono impattare sul’erogazione del servizio. Alcune delle metriche citate relative al consumo di risorse cloud (computazionali, storage, rete, …) potrebbero non essere direttamente legate alle performance o al costo della fornitura (fortemente dipendente dai contratti). In questi casi vanno comunque considerata l’esposizione di metriche sull’utilizzo di risorse computazionali?
Nel requisito RP3 viene chiesto di poter accedere al “logging/tracing relativo all’esecuzione di processi di sistema”. Cosa si intende precisamente? Si fa riferimento al logging della stessa soluzione SaaS? In ambito Cloud SPC/PSN sono previte API per l’accesso a questo genere di servizi?
Il requisito RPS8 non è riportato direttamente tra i requisiti di Performance e Scalabilità. Tuttavia è riportato negli impegni contrattuali al punto CL12. E’ da intendersi come un refuso? Tra l’altro nella definizione RPS7 fa riferimento alla multi-tenancy mentre sempre al punto CL12 è scritto in modo diverso. Quale versione è corretta?
in relazione al requisito organizzativo RO1 per la qualificazione dei servizi SaaS (account di test utilizzabile da AgID), volevo sapere se sarà sufficiente fornire due account (un utente applicativo ed uno con privilegi di amministratore), abilitati ad operare su un ambiente di test.
confermo che il fornitore SaaS dovrà rendere disponibile, su richiesta, un account di test utilizzabile da AgID per effettuare ogni tipo di verifica che si renderà necessaria per il mantenimento della qualificazione.
La richiesta avverrà in fase di mantenimento della qualificazione.
I profili utente degli account per effettuare i test saranno concordati in fase di richiesta e di verifica.
Salve. Nella fase di adeguamento del nostro software finalizzata alla certificazione, avrei necessità di capire vi è l’obbligatorietà di implementare tutti i requisiti o, al contrario, l’obbligo è soggetto alle funzionalità del software.
A titolo d’esempio, il requisito RIP6 prevede l’interoperabilità con i servizi SPID e PAGOPA. Il prodotto, attualmente, non prevede pagamenti e l’accesso è consentito solo agli operatori. Dovrà quindi essere comunque interoperabile con SPID o gli operatori potranno accedere con le rispettive credenziali di sistema?
Lo stesso dubbio lo abbiamo per i seguenti requisiti: RIP4, RIP5, RS9, RIP1, RIP4.
Grazie Debora