1 Schema dei Principi di Enterprise Architecture del Comune di Milano

(1)

EA-PRIN-Principi-1.1.docx

SIAD.EnterpriseArchitecture@comune.milano.it | https://comunemilano.sharepoint.com/sites/innesco

Direzione Sistemi Informativi e Agenda Digitale - Comune di Milano 1 / 11

Principi Fondamentali

EA-PRIN

^Data ^Versione ^Stato

Enterprise Architecture

Principi 05/04/2019 1.1 Definitivo

1 Schema dei Principi di Enterprise Architecture del Comune di Milano

2 Contesto di riferimento

Questo documento contiene i principi fondamentali di Enterprise Architecture per il Comune di Milano e aggiorna gli standard di interoperabilità. Le indicazioni fornite nell’ambito di ciascun principio non possono essere oggetto di deroga e devono essere rispettate integralmente: le soluzioni architetturali che violano nella sostanza i principi espressi in questo documento non saranno ritenute conformi al modello di Enterprise Architecture. Gli standard de facto definiti, a livello tecnologico, applicativo, funzionale e aziendale (business), rispondono alle linee guida di Trasformazione Digitale dettate da AGID, e al modello di interoperabilità definito dalla Commissione Europea.

Tale approccio infatti:

- scompone l’architettura in livelli semplificando la complessità intrinseca di un ecosistema integrato;

(2)

- disaccoppia le soluzioni tra i livelli consentendone la manutenzione per blocchi;

- offre un livello di standardizzazione internazionale necessario per evitare la produzione di sistemi con standard propri e locali;

- si basano sull’interoperabilità tra i diversi livelli dell’architettura, ma anche tra i verticali.

COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT European Interoperability Framework – Implementation Strategy

2.1 La Trasformazione Digitale nel Comune di Milano

Di seguito si riportano i principi estratti dalla mission digitale del piano nazionale dei Comuni dai quali derivano gli imperativi della trasformazione digitale del Comune di Milano.

(3)

3 I principi di Enterprise Architecture

A partire dai principi generali è possibile derivare alcuni principi architetturali.

Per mantenerne il legame con i principi generali i principi architetturali saranno raggruppati per imperativo della trasformazione digitale del Comune:

1. Componenti digitali integrate e orchestrate 2. Processi interni digitali end to end

3. Informazioni complete accessibili e sicure

4. Servizi al “City User” a valore aggiunto e di facile fruizione

NB. I principi elencati oltre alle linee guida metodologiche e tecniche devono guidare i singoli progetti/iniziative al fine di sfruttare le singole progettualità nel processo di “Trasformazione” del sistema informativo dallo stato attuale al disegno architetturale Target

La seguente figura riassume i principi di Enterprise Architecture per il Comune di Milano, ottenuta partendo sia dagli imperativi strategici che dai progetti analizzati. Per ogni principio individuato la figura mostra se il principio discende direttamente dagli imperativi strategici, dai progetti analizzati o da una nostra proposta.

Principi di Enterprise Architecture del Comune di Milano

Segue la descrizione di ogni principio, per mezzo di alcuni attributi che derivano dalla metodologia TOGAF.

(4)

3.1 Componenti digitali integrate e orchestrate

3.1.1 Architettura a Servizi

Nome Architettura a Servizi

Definizione Progettare le applicazioni ed i sistemi con un’architettura a livelli, favorendo un approccio a servizi/API. Sia in caso di acquisizione di prodotti che di sviluppi di applicazioni custom prevedere l’esposizione di funzionalità a servizi.

Razionale ▪ Supportare l'aggiunta di interfacce indipendenti e interfunzionali su qualsiasi componente, applicazione o piattaforma.

▪ le applicazioni sono più facili da aggiornare, integrare ed evolvere

Implicazioni ▪ La progettazione dell'applicazione deve prevedere revisioni in fasi definite.

▪ L'integrazione di sistemi e applicazioni legacy può richiedere la creazione di componenti applicativi “wrapper” il cui scopo è quello di incapsulare le funzionalità dell'applicazione esistente per esporla come servizio/api e renderla riutilizzabile.

3.1.2 Riuso

Nome Riuso

Definizione Preferire il riutilizzo di asset e di sistemi «Enterprise» condivisi tra le strutture organizzative a sistemi frammentati e specifici per singola struttura organizzativa Razionale ▪ L’adozione di una soluzione unificata e condivisa per tutta l’azienda rispetto alla

duplicazione e all’adozione di soluzioni verticali per struttura organizzativa permette di ridurre i costi di sviluppo ed operativi, sfruttando in modo più efficiente le competenze di tutta l'azienda.

▪ L'utilizzo di servizi e strumenti aziendali comprovati e collaudati permette migliore qualità e riduzione dei rischi operativi a beneficio delle strutture organizzative

Implicazioni ▪ Nel valutare i sistemi per uso aziendale, preferire in ordine:

o Riuso o Acquisto

o Sviluppo custom

▪ Deve esistere ed essere mantenuto aggiornato un repository affidabile con il censimento di tutti i sistemi aziendali, disponibile ed accessibile in modo che tutti in fase di progettazione possano capire quali sistemi e funzionalità esistono e possono essere riutilizzate.

▪ Deve essere prevista l’infrastruttura necessaria a supportare il riuso

▪ L'uso di sistemi “comuni” a livello aziendale può prolungare l'utilizzo di tecnologie legacy e limitare le innovazioni.

▪ Devono essere definiti ed usati processi di sviluppo e di maintenance consistenti e consolidati

3.1.3 Scalabilità

Nome Scalabilità

Definizione Il disegno dell'architettura applicativa e tecnologica deve agevolare la scalabilità del servizio offerto

(5)

Razionale La capacità di un sistema di "crescere" o diminuire di scala in funzione delle necessità permette di erogare il servizio garantendone la disponibilità senza degradarne la qualità.

Implicazioni ▪ La progettazione e lo sviluppo di un sistema deve prevedere la scalabilità dalle prime fasi di ideazione.

▪ Il sistema per essere scalato deve essere in primis osservabile ed osservato: questo richiede monitoraggio

3.1.4 Gestione del ciclo di vita

Nome Gestione del ciclo di vita

Definizione Tutti gli asset ed i servizi acquisiti o sviluppati devono essere gestiti per tutto il loro ciclo di vita e un piano di gestione del ciclo di vita deve essere diffuso, condiviso, e mantenuto aggiornato dalle strutture organizzative responsabili.

Razionale ▪ Le decisioni e le direzioni sulle componenti tecnologiche, legate alla creazione di nuovi servizi, devono mirare all’obiettivo di ridurre il TCO “Total Cost of Ownership”

e non devono considerare solo il costo di acquisizione/costruzione immediato.

▪ Il miglioramento continuo dei processi e delle implementazioni tecnologiche porterà a costi ridotti, maggiore efficienza ed efficacia.

Implicazioni ▪ Richiedere l'implementazione di un processo e di un piano di gestione del ciclo di vita per tutte le tipologie di asset presenti nel sistema informativo

▪ Man mano che le tecnologie cambiano e le esigenze aziendali si evolvono, devono evolvere anche i processi e le tecnologie messe in atto per sostenerli, garantendo una protezione e un'efficienza adeguata. Senza una revisione e gestione continua le soluzioni diventano ingombranti, costose ed inefficienti.

▪ Miglioramento continuo di strumenti e processi

Esempio

In fase di acquisizione di un nuovo asset o di creazione di un nuovo servizio è importante valutare correttamente come questo possa aderire al ciclo di vita adottato dal Comune, garantendo che tutti i componenti possano essere mantenuti nel modo più efficiente possibile anche a fronte di maggiori costi iniziali per ricondurlo al ciclo di vita standard.

L’adozione di tecniche e pratiche per aumentare il livello di qualità (esempio test automatici) possono in un primo momento sembrare costose, ma consentono di ridurre il TCO garantendo un minor costo di gestione e di evoluzione di un asset o di un servizio.

3.1.5 Continuità Operativa (Business Continuity)

Nome Business Continuity (Garantire la continuità del servizio)

Definizione Il disegno della soluzione e le tecnologie utilizzate per la realizzazione dei servizi devono essere costruite per minimizzare le interruzioni del servizio

Razionale ▪ Il business dipende dalla tecnologia per fornire servizi, per tale motivo l'affidabilità è un requisito non funzionale che deve essere considerato nella progettazione e nell’utilizzo

▪ Al fine di ridurre al minimo gli effetti di eventuali interruzioni del servizio, le strategie e le azioni di risoluzione devono essere pianificate prima che queste si verifichino e preferibilmente al momento della progettazione del sistema, in base alla criticità e alla sensibilità del bene.

Implicazioni ▪ Le attività aziendali devono essere valutate per la criticità e l'impatto sul business, al fine di determinare quale livello di continuità e protezione è

(6)

necessario.

▪ Scalabilità, recuperabilità e ridondanza devono essere indirizzate in fase di progettazione in relazione al rischio e alla valutazione dell'impatto.

▪ Ciascuna struttura organizzativa deve avere la

capacità di continuare a funzionare secondo le criticità valutate ed il corrispondente piano di continuità.

▪ I test delle azioni di ripristino previste dai piani di continuità devono essere pianificati e condotti regolarmente

Esempi

Nel caso di componenti infrastrutturali o applicativi “trasversali” l’interruzione di servizio potrebbe compromettere il funzionamento di una o più applicazioni. Per garantire la business continuity nell’erogazione dei servizi al cittadino o alle imprese devono essere considerate le criticità e le dovute contromisure.

Ciascun progetto deve considerare la criticità del servizio erogato, e deve considerare ed indicare le possibili soluzioni che possono mitigare problemi di interruzione del servizio.

▪ Es. PagoPA, è un servizio di pagamento che richiede un alto livello di servizio in quanto un malfunzionamento al sistema compromette da un lato l’esperienza utente che sarebbe costretto a ricorrere a metodi alternativi e dall’altro causa una potenziale perdita di introito invalidando la digitalizzazione.

▪ Un problema all’infrastruttura del Documentale potrebbe compromettere le funzionalità di un utente che necessita il recupero di un documento.

▪ Un progetto che utilizza tecnologie Cloud e architetture scalabili ed elastiche riduce implicitamente il rischio di interruzione del servizio causata da problemi di capacity.

L’adozione di cloud ibridi con la possibilità di scalare su cloud pubblici riduce il rischio di interruzione del servizio.

3.1.6 Utilizzo di Standard Aperti

Nome Utilizzo di Standard Aperti

Definizione Preferire l'utilizzo di tecnologie Open Source e di standard aperti quando adeguati e possibile

Razionale ▪ Massimizza le opzioni per la selezione di prodotti e dei servizi tecnologici e previene il lock-in su un particolare fornitore.

▪ Migliora l'interoperabilità ed abilita l'integrazione tra i sistemi.

Implicazioni ▪ Gli standard aperti possono non avere la maturità o la completezza richiesta per la data soluzione; quindi devono essere attentamente valutati prima dell’adozione.

▪ Interoperabilità, apertura e standard devono essere seguiti a meno che non ci sia una motivazione business convincente per implementare una soluzione non standard.

▪ Gli standard definiti e approvati devono essere selezionati, garantendo il rispetto delle normative vigenti.

▪ Il supporto a standard aperti è un criterio necessario per l'acquisizione di soluzioni tecnologiche

(7)

3.1.7 Adattabilità e flessibilità

Nome Adattabilità e flessibilità

Definizione Funzionalità quali processi aziendali, informazioni, applicazioni e risorse tecniche sono in grado di evolvere e adattarsi ad un ambiente in evoluzione.

Razionale Poiché le priorità e le esigenze del Comune di Milano e dei consumatori dei servizi cambiano, i servizi pubblici dovranno evolversi e adattarsi senza bisogno di essere ricreati. Con l'emergere di servizi cloud, le agenzie devono promuovere l'uso di uno sviluppo agile, i servizi devono essere progettati per adattarsi ai cambiamenti, portando a una reazione più rapida ed economica, compresa la valutazione e l'implementazione del business, ai mutevoli requisiti.

I servizi offerti dal comune e i relativi sistemi dovranno essere in grado di evolversi e adattarsi per soddisfare le mutevoli priorità, funzionalità ed esigenze di capacità riducendo al minimo i costi, i rischi e l'impatto delle modifiche sul consumatore e sul sistema.

Implicazioni ▪ È richiesta l’adozione di approcci agili.

▪ Ciascuna struttura organizzativa dovrà adattarsi agli ambienti in evoluzione, all'aumento della domanda dei consumatori, al miglioramento del business ed all'innovazione tecnica.

▪ Le singole strutture dovranno essere in grado di rispondere con successo e rapidamente ai cambiamenti.

▪ È probabile che le singole strutture debbano spendere di più per analizzare le esigenze e le tendenze a lungo termine.

▪ Le strutture dovranno considerare in fase di progettazione aspetti architetturali quali: architettura orientata al business, disaccoppiata, orientata ai servizi.

▪ Servono approcci più agili al business, come nel sourcing e nella selezione dei componenti della soluzione (non solo agilità tecnica attraverso la progettazione dei servizi).

▪ Tutte le strutture organizzative dovranno concentrarsi sui principi di consolidamento, semplificazione e standardizzazione, orientamento al servizio e interoperabilità.

3.1.8 Governo tecnologico

Nome Governo Tecnologico

Definizione La diversità tecnologica viene controllata per ridurre al minimo il costo di gestione e di manutenzione

Razionale Esiste un costo reale dell'infrastruttura necessaria per supportare le tecnologie e gli ambienti non omogenei. Definire standard architetturali e tecnologici consente di ridurre il numero di componenti supportati, semplificandone la manutenibilità e riducendone i costi.

Maggior efficienza dell’”IT operation":

▪ Riduzione dei costi di sviluppo, delle correttive e di manutenzione del software

▪ Maggior portabilità delle applicazioni

▪ Maggiore interoperabilità e più semplice la gestione dei sistemi e delle reti

▪ Maggiore capacità di indirizzare issue a livello aziendale come il tema della sicurezza

▪ Maggior semplicità ad aggiornare o cambiare componenti dei sistemi (v. upgrade) Implicazioni Le politiche, gli standard e le procedure che regolano l'acquisizione della tecnologia

devono essere strettamente legati a questo principio.

Esempi

(8)

Se si supportano più versioni dello stesso DBMS valutare le iniziative di migrazione o di adeguamento al fine di allineare tutti i DBMS alla stessa versione, semplificandone la gestione.

3.1.9 Coerenza Innovativa

Nome Coerenza Innovativa

Definizione Le decisioni di investimento e di innovazione sono guidate da opportunità e da requisiti.

Razionale ▪ Ciascuna iniziativa e trasformazione del sistema deve essere guidata e motivata da opportunità e da requisiti. Ad esempio, la razionalizzazione tecnologica o l’innovazione devono essere considerate sfruttando le opportunità di iniziative che nascono con uno scopo ben preciso (es. l’esposizione di nuove funzionalità al cittadino, la partecipazione a progetti Europei, ecc.).

▪ Il disegno architetturale non può essere completato in modalità Big Bang, è fondamentale gestirne la corretta evoluzione/trasformazione sulla base delle esigenze.

Implicazioni ▪ Quando si fa innovazione è necessario tenere in considerazione anche i processi, gli aspetti organizzativi e culturali.

▪ L’innovazione come ogni evoluzione deve tenere in considerazione anche come questa si innesta con il resto del sistema.

3.2 Processi interni digitali end to end

3.2.1 Standardizzazione di pratiche e processi

Nome Standardizzazione di pratiche e processi

Definizione La standardizzazione deve essere utilizzata per aggiungere valore, coerenza, ripetibilità.

Razionale ▪ L’utilizzo di standard garantisce un modello univoco e condiviso di operare riducendo l’effort di gestione e di governo e garantendo maggiore efficienza.

▪ Garantire standard riduce al minimo gli ostacoli al cambiamento.

▪ Le attività standardizzate apportano il beneficio delle economie di scala al governo.

▪ Processi standard sono ripetibili, prevedibili, scalabili e più efficienti

▪ È più facile focalizzare l'attenzione, le risorse, le conoscenze e gli investimenti in un ambiente standardizzato

Implicazioni ▪ Tutti i processi di approvvigionamento e sviluppo che coinvolgono asset e servizi devono rispettare gli standard

▪ Le eccezioni sono possibili utilizzando processi ben definiti

▪ Gli standard saranno rivisti regolarmente e aggiornati prima di essere obsoleto o non fornire più valore.

▪ Le iniziative di standardizzazione devono avere un chiaro modello di governance

▪ Lo sviluppo di applicazioni a livello aziendale è preferito rispetto a sviluppo di applicazioni simili o duplicate che sono solo d’interesse di una singola organizzazione.

(9)

3.3 Informazioni complete, accessibili e sicure

3.3.1 Sicurezza

Nome Sicurezza

Definizione Le informazioni devono essere accessibili e devono sempre essere garantite la riservatezza, l’integrità, il non ripudio, la disponibilità e l’autenticità.

Razionale ▪ Il livello di protezione delle informazioni deve essere coerente con la natura delle informazioni.

▪ La protezione delle informazioni deve essere garantita oltre che nelle applicazioni anche tra le applicazioni

Implicazioni ▪ Al fine di fornire un accesso adeguato alle informazioni mantenendo al contempo le informazioni sicure, le esigenze di sicurezza devono essere identificate e

considerate a tutti i livelli (es. dati, applicazioni, infrastruttura, ecc.) fin dalle fasi di progettazione.

▪ Le informazioni per essere messe in sicurezza devono classificate a seconda della loro natura.

▪ Le informazioni per essere messe in sicurezza devono essere governate. Questo implica processi e pratiche come la data governance e la data lineage.

3.3.2 Multicanalità

Nome Multicanalità

Definizione Lo stesso servizio viene erogato attraverso più canali (es. sportello, web, mobile) Razionale ▪ Il modo in cui le informazioni sono accessibili e visualizzate deve essere

sufficientemente adattabile per soddisfare una vasta gamma di utenti interni ed esterni e i relativi metodi di accesso ai servizi erogati.

Implicazioni ▪ Realizzare servizi multicanale richiede una maggiore attenzione nella fase di raccolta dei requisiti e analisi.

▪ La multicanalità implica il riuso dei servizi e quindi l’esistenza di un’architettura pensata per favorire il riuso dei componenti.

3.3.3 Conformità a leggi e regolamenti

Nome Conformità a leggi e regolamenti

Definizione I processi di gestione dell'informazione sono conformi con tutte le leggi, policy e regolamenti rilevanti

Razionale ▪ I processi aziendali devono favorire il rispetto di leggi e regolamenti nazionali ed europei.

Implicazioni ▪ Necessità di revisione continua di processi e sistemi per effettuare adeguamenti normativi.

3.3.4 Privacy by Design

Nome Privacy by Design

Definizione La progettazione dei sistemi deve prevedere opportune funzionalità di sistema che permettano ad ogni cittadino di esercitare sui propri dati i diritti le operazioni tipiche

(10)

previste dal GDPR quali ad es: accesso, modifica, cancellazione, trasferimento, limitazione.

Razionale ▪ L'evoluzione della normativa Privacy estende i diritti dei cittadini, il cui esercizio dev'essere garantito dall’Ente per i trattamenti di dati di cui è Titolare.

▪ Prevedere in fase di progettazione delle funzionalità di estrazione e modifica dati per la singola posizione di un cittadino, permette di risparmiare tempo e sforzi per ottemperare alle richieste che pervengono all’Ente da parte dei cittadini, migliorando di fatto la gestione della Privacy.

▪ Rendere possibile la gestione di tali operazioni tramite le interfacce applicative, senza imporre onerosi interventi di verifica a livello infrastrutturale o direttamente su DBMS.

Implicazioni ▪ Tutti i sistemi di nuova progettazione devono offrire di base la possibilità di effettuare le operazioni previste dalla normativa, ma anche a possibilità di configurare quali funzioni sono attivabili e quale profilo applicativo le può invocare: non è detto che il cittadino debba avere lo strumento diretto per operare le richieste e non è detto che alcune richieste (es. cancellazione dati da anagrafe) siano possibili in base alle diverse normative cogenti.

3.3.5 Privacy by Default

Nome Privacy by Default

Definizione La progettazione dei sistemi deve prevedere che ogni acquisizione di dati dei cittadini sia ristretta ai soli dati indispensabili per effettuare i trattamenti richiesti dal servizio che l’applicativo realizza (data minimisation). Qualsiasi conferimento opzionale di dati previsto dal servizio dev’essere disabilitato di default (modalità opt-in).

Razionale ▪ L'evoluzione della normativa Privacy prevede uno stretto controllo della legittimità di ogni trattamento di dati. Non si possono acquisire informazioni se non sono strettamente connesse alla finalità dei trattamenti o per finalità da stabilire in futuro.

Implicazioni ▪ È opportuno rendere altamente e facilmente configurabili tutte le fasi di input e raccolta dati in modo da minimizzare l’impatto di successive modifiche che dovessero restringere o ampliare il perimetro dei dati trattati e in modo da rendere facilmente opzionali uno o più dati in fase di input

▪ È opportuno che la progettazione di un sistema sia fatta a stretto contatto con il censimento del trattamento di dati che viene operato.

3.4 Servizi al “City User” a valore aggiunto di facile fruizione

3.4.1 Centralità dell’utente (User Centricity)

Nome User Centricity

Definizione Servizi e i processi devono consentire e incoraggiare le interazioni dell’utilizzatore finale, garantendo coerenza indipendentemente dal metodo di accesso.

Razionale ▪ Fornire all’utente un servizio migliore ed a valore aggiunto, più intuitivo attraverso l'uso di interfacce e processi applicativi coerenti, indipendentemente dal canale di accesso.

(11)

Implicazioni ▪ L'interazione con l’utente finale diventa una considerazione primaria nello sviluppo di servizi e di processi.

▪ L'accesso ai servizi deve essere semplificato e devono essere sviluppati, approvati e comunicati processi coerenti.

▪ Le applicazioni richiedono un meccanismo coerente per scoprire, cercare, accedere e presentare le informazioni utilizzando un "aspetto comune"

▪ Le interfacce dell'applicazione devono essere sufficientemente adattabili per soddisfare un'ampia gamma di stakeholder (ad esempio anche persone con disabilità) e i loro corrispondenti metodi di accesso.

3.4.2 Accessibilità

Nome Accessibilità

Definizione Aumentare il grado di semplicità di accesso alle informazioni da parte di tutti gli utenti (cittadino, operatore)

Razionale ▪ La disponibilità di accesso ai dati consente una risposta tempestiva alle richieste di informazioni e all'erogazione dei servizi.

Implicazioni ▪ Il modo in cui le informazioni sono accessibili e visualizzate deve essere sufficientemente adattabile per soddisfare una vasta gamma di utenti e i relativi metodi di accesso.

3.4.3 Semplicitià

Nome Semplicità

Definizione I servizi devono essere facili da utilizzare ed intuitivi.

Razionale ▪ La complessità della tecnologia sottostante deve essere trasparente per gli utenti, in modo che possano concentrarsi sulle attività di loro competenza.

▪ La facilità d'uso è un incentivo positivo per l'uso delle applicazioni e dei servizi, indipendentemente dalla tipologia di utilizzatore.

▪ Incoraggiare gli utenti a lavorare all'interno di un sistema informativo il più possibile integrato, limitando quando possibile la divergenza tecnologica/funzionale/user experience ed evitando l’introduzione di sistemi verticali isolati.

▪ Nel caso di sistemi utilizzati da utenti interni, la coerenza e l’uniformità del modello di funzionamento delle applicazioni e delle interfacce utente garantisce una minor complessità nell’adozione di nuovi strumenti, con la conseguente riduzione dei costi di formazione ed una diminuzione del rischio di utilizzo improprio dell’applicazione.

Implicazioni ▪ È necessario progettare standard comuni per le interfacce utente e sviluppare criteri di usabilità omogenei.

▪ Le linee guida per le interfacce utente non devono essere quanto più possibile indipendenti dalla tecnologia.