I servizi sono sempre più rilevanti nella nostra vita e nei paesi di tutto il mondo. Il concetto di servizio copre un ampio spettro di aspetti nelle relazioni moderne tra amministrazioni pubbliche, fornitori privati e utenti finali.
Continua a leggere su Docs Italia.
al par.2.1.1 viene proposta una importante classificazione basata sul consumatore (consumer).
il testo del Batini 2015 rispetto a questa classificazione interno/esterno riporta anche una specifica che non è stata tradotta, ed invece sarebbe importante riportare per chiarezza:
the interest in eGov project regards above all external services, which are supplied to final users. However, since, as we will see, in the context of value aspects tied to production costs and service supply are relevant, it is interesting to conceive internal services that positively influence external service production.
il passo qui sopra chiarisce che sono rilevanti (e di interesse per i progetti) anche i servizi interni, sia che essi siano “autoprodotti” da una PA che fa da fornitore (provider) oppure che essi siano affidati da una PA ad un fornitore privato (che agisce sulla base di un contratto o in via sussidiaria).
i servizi interni sono infatti trascurati, mentre sono essenziali nell’ottica di creare veri ecosistemi di interoperabilità.
sarebbe anche importante citare il concetto di “servizio” del d.lgs. n.279/1997 art.10 comma 5…
I servizi esprimono le funzioni elementari, finali e strumentali, cui danno luogo i diversi centri di costo per il raggiungimento degli scopi dell’amministrazione. Essi sono aggregati nelle funzioni-obiettivo che esprimono le missioni istituzionali di ciascuna amministrazione interessata. In base alla definizione dei servizi finali e strumentali evidenziati nelle rilevazioni analitiche elementari, il Ministro competente individua gli indicatori idonei a consentire la valutazione di efficienza, di efficacia e di economicita’ del risultato della gestione (…)
…chiarendo che i “servizi esterni” corrispondono ai “servizi finali” del d.lgs. n.279/1997 e che i “servizi interni” corrispondono ai “servizi strumentali” del d.lgs. n.279/1997.
infine, andrebbe forse chiarito che un servizio interno può essere sia quello destinato ai dipendenti/operatori della stessa PA che lo eroga, sia quello a favore di dipendenti/operatori appartenenti ad altre PA (altri organismi pubblici).
rispetto a questo passo del par.2.2.1…
Classificazione in base alla natura del fornitore di servizi. In questo caso, abbiamo:
- servizi amministrativi (o abilitanti), la cui fornitura non ha carattere discrezionale da parte della PA, in quanto derivano da procedimenti amministrativi definiti dalla legge;
- servizi che chiamiamo orientati al mercato o facilitanti, che la PA può decidere o meno di fornire, in base alla presenza di un obbligo procedurale, e che sono più spesso erogati da fornitori privati del mercato dei servizi.
…in Batini 2015 è riportato il termine “procedures defined by law” che tradurre con “procedimenti” è molto limitativo.
Sarebbe interessate riprendere/citare la definizione di servizio in CPSV-AP_IT (vedi servizi.gov.it) che è la seguente:
Per servizio pubblico si intende qualsiasi atto obbligatorio o discrezionale espletato da una pubblica amministrazione (o per conto di una pubblica amministrazione) nei confronti di cittadini, imprese/professionisti.
nonchè la definizione presente nella delibera n.88/2010 della CIVIT…
servizio pubblico: l’attività con cui, mediante l’esercizio di un potere autoritativo o l’erogazione di una prestazione, un’amministrazione pubblica rende un servizio al pubblico, e soddisfa un interesse giuridicamente rilevante, direttamente riferibile ad un singolo soggetto ed omogeneo rispetto ad una collettività differenziata di utenti
quindi per i servizi abilitanti invece di “procedimenti amministrativi definiti dalla legge” sarebbe meglio tradurre con un generico “obblighi derivanti dalle leggi” e per i servizi facilitanti invece di “un obbligo procedurale” sarebbe meglio tradurre con “una discrezionalità lasciata dalla legge”.
i servizi pubblici derivano sia dall’esercizio di un potere autoritativo (solitamente tramite un “procedimento”) oppure dall’erogazione di una prestazione (di varia natura, tangibile o intangibile).
inoltre dove si dice “che sono più spesso erogati da fornitori privati del mercato dei servizi” andrebbe chiarito che il fornitore (provider) può agire per conto della PA sulla base di un contratto/concessione o in via sussidiaria (per facilitare il servizio della PA, sia come intermediario con un ruolo formale previsto/accordato dalla PA che come facilitatore indipendente dalla PA utilizzando le API di un ecosistema).
al par.2.1.2 viene riportata questa definizione di “servizio digitale”…
Un servizio digitale (talvolta anche indicato come electronic service o e-service) è un servizio che viene erogato via Internet o in una rete, la fornitura è essenzialmente automatizzata o comporta solo un intervento umano minimo, ed è impossibile da garantire in assenza di tecnologia informatica
…sarebbe importante chiarire che questa traduzione da Rowley 2006 è da considerarsi del tutto equivalente alla definizione riportata nel CAD, art.1 comma 1 lettera n-quater), ovvero la seguente:
n-quater) servizio in rete o on-line: qualsiasi servizio di una amministrazione pubblica fruibile a distanza per via elettronica;
altrimenti si può pensare che parliamo di concetti diversi generando ulteriore confusione rispetto ai concetti di servizio digitale/web/on line/in rete.
al par.2.1.3. viene introdotta la distinzione tra “Interfacce semplici e complesse”.
poco sopra, al par.2.1.1., è stata introdotta la distinzione tra “servizio elementare” e “servizio composito” derivata dalla nomenclatura EIF.
forse sarebbe meglio uniformare le dizioni, parlando di “interfacce elementari” e “interfacce composite” (o almeno citarli come sinonimi).
tra l’altro il termine semplice è usato anche per distinguere interfacce “semplici e mission-critical” e usare due volte semplici induce confusione.
al par.2.1.4 si parla anche di “erogatori” del servizio. andrebbe chiarito se si tratta della stessa cose dei “fornitori” del servizio, ovvero sempre del concetto di “provider”. inoltre, quando si parla di “erogatori esterni” si intende un provider che agisce per nome e per conto di una PA? l’uso del termine esterno fa pensare ai “servizi esterni” che non è corretto in quanto un erogatore esterno potrebbe operare anche un servizio interno (per la stessa PA o altre PA)
al par.2.1.2 sta scritto…
si utilizza il termine interfaccia di servizio per indicare l’esposizione delle funzionalità applicative che sono necessarie per realizzare un servizio digitale. (…) Un’interfaccia di servizio si compone in generale di varie operazioni, e può essere realizzata come un web service, un’API, una Web API, ecc (…)
…quando si parla di “interfacce di servizio” si intende lo stesso concetto che nel CAD è definito “interfacce applicative” ?
il CAD all’art.64-bis, comma 1-bis, riporta quanto segue:
1-bis. Al fine di rendere effettivo il diritto di cui all’articolo 7, comma 01, i soggetti di cui all’articolo 2, comma 2, i fornitori di identità digitali e i prestatori dei servizi fiduciari qualificati, in sede di evoluzione, progettano e sviluppano i propri sistemi e servizi in modo da garantire l’integrazione e l’interoperabilità tra i diversi sistemi e servizi e con il servizio di cui al comma 1, espongono per ogni servizio le relative interfacce applicative e, al fine di consentire la verifica del rispetto degli standard e livelli di qualità di cui all’articolo 7, comma 1, adottano gli strumenti di analisi individuati dall’AgID con le Linee guida.
altra domanda: queste linee guida in consultazione forniranno anche le indicazioni ex art.64-bis, comma 1-bis oppure solo quanto all’art.12 comma 2 del CAD e/o art.7 comma 1?
Buongiorno Giovanni,
e grazie per le tue considerazioni.
Ti chiedo un chiarimento su questo intanto - visto che il resto delle considerazioni sui riferimenti normativi merita un’analisi più attenta.
Oltre la parte sugli schemi di dato - che vale sicuramente per ogni tipo di servizio - quale altre parti raccomanderesti?
se per servizi interni consideriamo la definizione proposta nella bozza di LG…
servizi interni, quando il servizio è dedicato agli utenti interni all’organizzazione erogatrice, sia essa PA che erogatore di servizi privato
…la galassia dei servizi interni è molto ampia. per questo suggerivo di aggiungere alla LG una traduzione di un ulteriore passo presente nel Batini ovvero questo:
the interest in eGov project regards above all external services, which are supplied to final users. However, since, as we will see, in the context of value aspects tied to production costs and service supply are relevant, it is interesting to conceive internal services that positively influence external service production.
Andrebbe infatti chiarito che le LG si applicano (integralmente) anche ai servizi interni (tento una traduzione)…
quando il servizio interno ha valore rilevante in termini di costo di produzione e/o dei destinatari del servizio stesso, rimanendo nell’ottica di concepire servizi interni che influenzano positivamente la produzione dei servizi esterni
Un esempio di rilevanza dei destinatari di un servizio interno si ha quando il servizio ha un utente (umano o macchina) che è dentro una diversa articolazione della stessa PA (ad esempio due direzioni e/o dipartimenti di un ministero che dialogano tra loro via API nell’ambito delle loro competenze/procedimenti… magari sono pure due AOO diverse) oppure dentro una diversa PA (ad esempio il dipendente di un comune che accede al “Registro imprese” nazionale di Infocamere, quindi attori entrambi pubblici ma in organizzazioni diverse).
Seguendo questo principio, le LG non si applicheranno di solito ad una replica di database tra due datacenter… a meno che questo abbia un costo tale da essere considerato rilevante, e quindi da tracciare, oppure nel caso in cui i due datacenter siano di proprietà di PA diverse.
utilizzare unità di misura del sistema internazionale (ad es., secondi, bytes);
Sebbene alcuni prefissi adottati dal Sistema Internazionale siano applicati anche alla formazione di multipli del byte, non sembrerebbe incontrovertibilmente accertabile la presenza di tale unità tra quelle del SI propriamente detto.
Nota teorica interessante!
Il Sistema Internazionale contiene un riferimento al Byte ed un rimando ad IEC 60027-2:2005.
Andremo sicuramente a raffinare questa parte: grazie mille!
Un saluto a tutti e vi prego di voler considerare il presente contributo.
Ritengo che da un punto di vista architetturale la PDD (e non la busta eGov) abbia felicemente assolto negli anni al compito di centralizzare le interazioni A2A machine, assicurando le dovute misure di security, logging e audit.
Tale valenza architetturale dovrebbe essere mantenuta soprattutto in considerazione dell’auspicata maggiore ‘apertura’ sia semantica che sintattica.
Il modello punto-punto applicativo oltre a produrre la replicazione a carico di ciascun applicativo delle suddette funzioni, inibirebbe de-facto la possibilità di orchestrare servizi compositi.
Ritengo pertanto irrinunciabile mantenere la presenza di un middleware di razionalizzazione architetturale (ESB).
Il protocollo SOAP è ancora collocabile sul cosiddetto “plateau of enlightenment” soprattutto per la conseguita maturità e, anche se richiede un poco di lavoro in più per lo sviluppo, è ancora il protocollo più stabile negli scenari A2A machine.
Il protocollo REST, irrinunciabile per l’ambito mobile, forse non riguarda lo scenario A2A e A2B machine.
Potrebbe essere utile un richiamo allo European Interoperability Reference Architecture (EIRA) e alla Digital Service Infrastructure (DSI) con la chiara definizione dei Bulding Block fondanti.
Infine, per assicurare maggiore efficacia comunicativa, suggerirei di aggiungere un capitolo di sintesi sulle indicazioni operative, con riguardo ai diversi scenari in esame ed i relativi integration pattern (standard) a cui riferirsi. Sarebbe utile accennare ai tempi per la dismissione delle PDD.
Buongiorno Dante,
purtroppo la PDD non ha avuto i risultati sperati. I costi sostenuti ne hanno limitato l’adozione, ed ha complicato in diversi casi le interazioni tra le amministrazioni.
A livello architetturale, il nuovo modello lascia libertà di scelta sulle soluzioni middleware e suggerisce di usare dei proxy gateway per centralizzare la security, il logging e l’audit. Quando un middleware non ha tutte le informazioni per l’audit/log (eg. end-to-end encryption) va’ comunque valutata la necessità di un audit applicativo.
Nessuno vieta di usare SOAP, ma come altri paesi viene introdotto REST. Da questo ci aspettiamo un migliore service management, ed un maggiore riuso delle interfacce per a2a ed a2c.
Stanno emergendo specifiche per API, anche in ambito UE, eg:
ed è fondamentale che l’Italia non resti indietro rispetto ai nuovi scenari che plasmeranno l’EIRA del futuro.
In questi giorni stiamo lavorando sulla parte tecnica: se hai dei contributi e/o best practices su REST/SOAP che vuoi condividere, scrivimi pure: roberto@teamdigitale.governo.it
API MANAGEMENT: La piattaforma di API management dovrebbe essere anche in grado di valorizzare da un punto di vista economico gli scambi di valore resi possibili dalle API qualora questa situazione possa applicarsi in un contesto di PA
ATTORI E INTERAZIONI: Le soluzioni tecnologiche a supporto dei diversi scenari di integrazione dovrebbero essere in grado di garantire meccanismi flessibili di sicurezza, autenticazione e autorizzazione, sia in fase di riconoscimento e censimento dei consumer sia in fase di erogazione dei servizi a runtime, per meglio adattarsi alle peculiarità di ciascuno scenario di interazione
ribadisco ed estendo qui quanto già scritto nella consultazione 2018 (ma quanto scritto nella vecchia consultazione è stato già preso in esame? è automaticamente valido per la nuova? ci sarà un report finale che dice quali segnalazioni della consultazione sono state prese in considerazione e quali escluse?):
Per servizio pubblico si intende qualsiasi atto obbligatorio o discrezionale espletato da una pubblica amministrazione (o per conto di una pubblica amministrazione) nei confronti di cittadini, imprese/professionisti.
il testo del Batini 2015 rispetto a questa classificazione interno/esterno riporta anche una specifica che non è stata tradotta, ed invece sarebbe importante riportare per chiarezza:
the interest in eGov project regards above all external services, which are supplied to final users. However, since, as we will see, in the context of value aspects tied to production costs and service supply are relevant, it is interesting to conceive internal services that positively influence external service production.
…il passo qui sopra chiarisce che sono rilevanti (e di interesse per i progetti) anche i servizi interni, sia che essi siano “autoprodotti” da una PA che fa da fornitore (provider) oppure che essi siano affidati da una PA ad un fornitore privato (che agisce sulla base di un contratto o in via sussidiaria). i servizi interni sono infatti trascurati, mentre sono essenziali nell’ottica di creare veri ecosistemi di interoperabilità.
si potrebbe quindi aggiungere una traduzione di quanto sopra ovvero: quando il servizio interno ha valore rilevante in termini di costo di produzione e/o dei destinatari del servizio stesso, rimanendo nell’ottica di concepire servizi interni che influenzano positivamente la produzione dei servizi esterni
Un servizio digitale (talvolta anche indicato come electronic service o e-service) è un servizio che viene erogato via Internet o in una rete, la fornitura è essenzialmente automatizzata o comporta solo un intervento umano minimo, ed è impossibile da garantire in assenza di tecnologia informatica
…sarebbe importante chiarire che questa traduzione da Rowley 2006 è da considerarsi del tutto equivalente alla definizione riportata nel CAD, art.1 comma 1 lettera n-quater), ovvero la seguente:
n-quater) servizio in rete o on-line: qualsiasi servizio di una amministrazione pubblica fruibile a distanza per via elettronica;
altrimenti si può pensare che parliamo di concetti diversi generando ulteriore confusione. invece di “servizio digitale” si può mettere “servizio in rete”
e riprendere la definizione del CAD? perchè inventare un nuovo concetto qui?
forse sarebbe meglio uniformare le dizioni, parlando di “interfacce elementari” e “interfacce composite” (o almeno citarli come sinonimi).
tra l’altro il termine semplice è usato DUE volte in quanto usato anche per distinguere interfacce “semplici e mission-critical” e usare due volte “semplice” induce confusione.
inoltre per il concetto di “critico” consideriamo valida la definizione di Cloud PA
oppure è un tipo di criticità diversa?
