Page History

...

...

1. Audit

2. Trasformazioni

3. Mapper

4. Servizi di generazione

5. Dispatcher (verificare con Jacopo i contenuti)

6. Interfacce al CUR

7. Interfacce e RDI

8. Interfacce al G.REG

9. Interfacce per Identity Server e policy di prodotto

10. Sync U-GOV

11. Interfacce e RLOC (Repository della Localizzazione)

12. Cambio password

13. Login page
14. Landing page

...

Premessa

Negli atenei, anche se con rare eccezioni, la direzione sistemi informativi e le singole unità organizzative (dipartimenti, centri, biblioteche, etc.) acquistano o sviluppano in autonomia servizi diretti agli stessi target utente. Inoltre, non si ha una conoscenza diffusa dei servizi disponibili e le diverse strutture raramente analizzano insieme i bisogni degli utenti e pianificano le funzionalità da esporre loro.

L’implementazione delle funzionalità è condotta spesso con tecnologie eterogenee, scelte più in base al know-how interno che per essere le più adatte allo scopo e senza condividere convenzioni di coding e asset. Ad esempio, molte applicazioni hanno una logica a stati, tuttavia sono implementate con linguaggi e framework di tipo funzionale o ad oggetti e non con tecnologie di business process management. Raramente sono condivisi standard internazionali sugli aspetti chiave di interoperabilità dei servizi, autenticazione e autorizzazione degli utenti.

Questo è particolarmente critico perché raramente i gestionali e gli altri sistemi acquistati o sviluppati dall’ateneo diventano la base per lo sviluppo di nuovi servizi: molti utilizzano i dati gestiti da questi sistemi ma sono rari i casi di interoperabilità applicativa e ancora più rari i casi in cui le funzionalità di sistemi diversi danno origine a nuovi servizi chiave e magari a processi complessi. 

Per l’ateneo i sistemi gestionali e le applicazioni sono quindi asset il cui costo potrebbe essere non solo ammortizzato, ma anche diventare un valore acceleratore di nuovi sviluppi e limitatore di ulteriori spese; anche gli sviluppatori ne traggono giovamento, perché possono eliminare dallo sviluppo le parti già disponibili diventate asset comuni. Costi e tempi di sviluppo si riducono, così come l'incidenza di errori e i costi di manutenzione che restano a carico dei soli asset condivisi.

L’approvvigionamento di nuovi servizi da fornitori esterni è un altro punto di sofferenza, perché in mancanza di interazione con i servizi asset dell’ateneo, di condivisione di policy di interoperabilità dei servizi, di autenticazione e autorizzazione degli utenti e altre convenzioni aumentano il costo delle forniture e i costi di manutenzione.

Inoltre è frequente che manchi la conoscenza diffusa dei servizi esistenti sotto il dominio della direzione dei sistemi informativi e delle unità organizzative. E che manchi anche un coordinamento di ateneo sulle funzionalità esposte agli utenti, e che alcune esigenze di costoro restino sconosciute e insoddisfatte. Oppure l’opposto, con applicazioni ridondanti, sviluppate in modo simile tra loro. 

Un altro punto di attenzione riguarda la continuità di servizio e la qualità percepita dagli utenti. È raro trovare strumenti di monitoraggio dello stato dell’intero parco servizi esposti e strumenti che misurino il cosiddetto sentiment degli utenti.

In questo scenario, la gestione operativa e la pianificazione strategica dei servizi risultano depotenziate, perché i responsabili e gli organi di governo dell’ateneo hanno difficoltà a conoscere gli investimenti che producono risultati apprezzati dagli utenti e dove questi non sono invece più necessari, e questa mancanza di polso della situazione aumenta quanto più i sistemi sono in periferia e lontani dal controllo del management strategico dei sistemi informativi.

Presentazione

La piattaforma tecnologica CINECA PST (Progetti e Servizi Trasversali), integrata nella soluzione U-GOV, risponde al bisogno delle grandi organizzazioni come gli atenei di gestire i propri servizi e l'autorizzazione dinamica degli utenti a quei servizi, ovvero copre le funzionalità di governo dei servizi e delle identità. Una gestione così integrata è indispensabile oggi più che in passato per dominare la complessità crescente, soddisfare esigenze di servizio via via maggiori e indirizzare il budget in modo più mirato.

La soluzione PST contiene un modello di governance dei servizi e gli strumenti di integrazione e controllo per attuarlo:

• web application, web service, processi e dati catalogati come asset
• interoperabilità e integrazione di servizi costruiti con tecnologie eterogenee, tramite standard
• esposizione degli asset in un ambiente organico tramite standard internazionali
• autenticazione e single sign-on (SSO)
• autorizzazione dinamica ai servizi in base allo stato dei servizi e alle variazioni di ruolo dell’utente nella sua carriera
• console di gestione unificata per gli amministratori dei servizi
• report comprensivi dei servizi online e indicatori di performance sul loro stato e gradimento.

La piattaforma è stata sviluppata sulla base di esigenze e modelli tecnologici maturati principalmente insieme all'Università di Torino a partire dal 2007 e proseguiti con Sapienza Università di Roma, Università di Brescia e università europee in incontri EUNIS. La soluzione ha beneficiato del confronto con specialisti di Oracle Corporation, WSO2, Forgerock, Bonitasoft e Gartner.

Prodotti della soluzione

Una tale soluzione di governo dei servizi e delle identità nasce allo scopo di collegare i servizi negli atenei, renderli governabili come sistema integrato e trasformarli in asset, perché le applicazioni e le informazioni in esse veicolate siano riusabili come componenti capaci di dar vita a nuovi servizi. In questo modo si collegano servizi residenti in Ateneo e servizi residenti al CINECA. E si collegano questi ad altri servizi erogati da altri atenei e altri provider di servizi. Ne risulta un modello di aggregazione per innovare e moltiplicare le possibilità di offrire servizi.

La soluzione è idealmente composta da tre aree di prodotto: lifecycle delle persone, lifecycle dei servizi e lifecycle delle relazioni fra persone e servizi; più un’area di servizi di base funzionali alle tre. Il termine lifecycle indica la dinamicità data da un approccio per processi che supera quello tradizionale procedurale.

Lifecycle delle persone: copre le esigenze di gestione dell’identità digitale e i processi di creazione e riconciliazione dei dati a partire dalle fonti che ne certificano l’autenticità. Sono inclusi connettori nativi verso U-GOV e connettori verso sistemi terzi basati su standard internazionali. Comprende tecnologie di autenticazione, single sign-on e federazione di atenei.

Lifecycle dei servizi: copre le esigenze di catalogazione dei servizi con processi di censimento da parte di sviluppatori interni o fornitori esterni all’ateneo. Include strumenti di monitoraggio della distribuzione dei servizi agli utenti e dello stato di funzionamento, di usco e di gradimento da parte degli utenti. Strumenti di governance riservati ai responsabili dei servizi e delle strategie dell’ateneo consentono di valutare in maniera più efficace interventi operativi e distribuzione degli investimenti.

Lifecycle delle relazioni tra persone e servizi: copre l'esigenza di automatizzare l’autorizzazione degli utenti ai servizi in base agli eventi di carriera e comunque in base a regole di business con cui l’ateneo regola l’accesso delle persone ai suoi servizi.

Impatto sull'organizzazione degli atenei

Il risultato è una piattaforma che dà una visione organica dei servizi dell’ateneo e consente di governarne la distribuzione agli utenti, costruire nuovi servizi, attingendo alle proprie applicazioni e dati, come risorse integrate e razionalizzate. Ha come scopo servire utenti finali, amministratori, responsabili e gli sviluppatori dell’ateneo.

La soluzione favorisce una struttura organizzativa più chiara ed efficiente, introducendo i ruoli di:

• responsabile delle identità digitali
• responsabile dei servizi
• sviluppatore di servizi su cloud.

Capability & Maturity model

In base alle condizioni tecniche e organizzative iniziali dell’ateneo e all’orizzonte temporale in cui desidera realizzare il percorso, la soluzione PST può essere adottata secondo un percorso a tappe. L’ateneo potrà fissare i propri obiettivi e l’estensione e la profondità dell’intervento secondo un modello di adozione graduale di tipo Capability & Maturity model.

Portabilità della soluzione

La soluzione PST è stata progettata per gli scopi di organizzazioni di dimensioni diverse che condividono esigenze e alcune complessità, non è specifica per il settore Università in Italia. Ha infatti poche caratteristiche, circoscritte e gestibili come moduli opzionali, disegnate per queste e non ha vincoli di localizzazione su dati, funzionalità e lingua italiana.

Questo perché le università italiane, riguardo ai bisogni di gestione dei servizi e delle identità digitali, non sono molto diverse da organizzazioni in altri settori industriali e altri paesi. La soluzione è quindi predisposta by-design per favorire gli eventuali obiettivi di CINECA in altri settori di mercato anche fuori dai nostri confini nazionali.

Inoltre, la sua natura aggregrante, le deleghe funzionali possibili e le funzionalità di garanzia della privacy sui dati rendono la piattaforma adatta a realizzare gli obiettivi di interoperabilità e federazione da sempre auspicati dal MIUR (Ministero dell'Istruzione, dell'Universita e della Ricerca) e a gestire servizi orientati ai processi, che sono ormai trend internazionali consolidati sui mercati.

...

1. Configurazione comune ai tenant 
2. Università di Torino
   1. Accesso
   2. Configurazioni (Stefania/Gian Luca: template per dati di accesso e parametri di configurazione — con Angelo, Francesca)
   3. Componenti per la generazione da Kernel (verificare il contenuto JACOPO)
3. Sapienza Università di Roma
   1. Accesso
   2. Configurazioni
   3. Componenti per la generazione da U-GOV AC
4. Università di Milano Verrocchio
   1. API
   2. Configurazioni
   3. Componenti specifici per l'esposizione dei dati
5. Supertenant (CINECA)
   1. Accesso al BAM
   2. Accesso all'ESB
   3. Accesso al G.REG (Registro dei Servizi)
6. Monitoraggio

...

1. Le farm 
   1. Ambiente di sviluppo (da fare Angelo)
   2. Ambiente di quality assurance (da fare Angelo)
   3. Ambiente di pre-produzione
   4. Ambiente di produzione
2. La virtual machine (per sviluppatori)
    
   

...