20 Nov 2019
Posted in SemWeb
Parigi, settembre 2019: un gruppo di persone aspettava l’inizio del nostro intervento… Matteo Busanelli ed io eravamo al SMWCon nella sua veste autunnale, un evento che ogni anno riunisce sviluppatori, utenti, organizzazioni o semplicemente curiosi attorno all’ecosistema di Mediawiki e SemanticMediawiki sulle tematiche di knowledge management.
15 Feb 2017
Questo post è il secondo di una mini serie dedicata alla gestione delle informazioni in contesto Enterprise Architecture (EA) iniziata con Gestire le informazioni di EA con… senso! dove spiegavo come il contesto di EA si prestasse alla modellazione semantica delle informazioni.
Per poter descrivere e gestire in maniera completa e coerente le diverse dinamiche di gestione dell’EA e governance dei dati è fondamentale individuare le diverse viste (view point) da cui le informazioni possono essere osservate e i vincoli a cui sono sottoposte. In particolare, le informazioni devono:
Da letteratura possiamo identificare almeno cinque viste o livelli (layer) diversi, indispensabili per descrivere l’EA e riconosciute da tutte le principali metodologie (es. ITIL, TOGAF ecc.):
La stessa informazione può quindi (e deve) essere scomposta in viste diverse da n punti di osservazione differenti che coincidono con specifici domini/aree aziendali: Le informazioni verranno poi ricomposte/riaggregate all’occorrenza in base alle necessità del momento (un problema da risolvere, documentazione da produrre, report da generare, una domanda puntuale a cui rispondere ecc.).
Diverse viste di un solido come metafora delle informazioni di EA
Consideriamo per esempio un’applicazione banca per la disposizione di bonifici online. Proviamo a scomporre le informazioni relative a tale applicazione rispetto alle viste che abbiamo elencato sopra:
Nella modellazione semantica tutte queste viste vengono rappresentate da modelli formali diversi (logicamente distinti da diversi namespace) fra loro indipendenti ma interconnessi da relazioni cross (trasversali) definite ad un livello più alto che li armonizza (state model) in modo da restituire la visione di insieme: quella dell’EA appunto.
Viste business, architetturale, applicativa e infrastrutturale integrate fra loro nello state model
…faremo un sunto dei primi due articoli cercando di enfatizzare i concetti cardine dell’approccio semantico con qualche spunto di riflessione.
To be continued… 😉
06 Feb 2017
Questo post vuole essere il primo di una mini serie dedicata all’argomento della gestione delle informazioni in un contesto particolarmente complesso come l’Enterprise Architecture (EA).
In particolare cercherò di spiegare l’approccio che Imola Informatica adotta ormai da diversi anni basato sull’uso di tecnologie semantiche al fine di enfatizzare come ciò che conta nella gestione delle informazioni non sia tanto la forma ma piuttosto il SENSO che le informazioni assumono per le persone che le osservano ma anche per le macchine che le usano.
Significato Vs. Struttura
Occuparsi di Enterprise Architecture vuol dire in primis governare la complessità di una azienda passando necessariamente per la capacità di integrare informazioni di Business, IT e organizzative con una visione sistemica e globale.
Questo significa riconoscere le relazioni causali e soprattutto non causali fra Business e IT in modo da comprendere le interdipendenze fra le varie parti di un sistema complesso come quello IT per esempio di una banca e definire le migliori strategie evolutive, di gestione del demand o del rischio.
In un tale contesto la gestione delle informazioni diventa attività fondamentale e altamente critica. Si deve infatti agire in modo che le informazioni siano:
Il modello formale delle informazioni dovrebbe descrivere il perimetro business e quello IT integrandoli e rispettando terminologia, relazioni e consuetudini aziendali per essere il più possibile compreso e condiviso da tutti (una sorta di dizionario globale).
Non può quindi essere un modello vincolato ad uno specifico strumento ma piuttosto dovrebbe emergere bottom-up in maniera iterativa dalle diverse aree ed esperienze aziendali in modo da rappresentare una visione realistica e di insieme del particolare sistema azienda.
L’approccio che Imola Informatica ha maturato negli anni di esperienza presso i clienti mette al centro delle attività di EA la definizione e condivisione di modelli semantici delle informazioni di Business e di IT detti “ontologie” e rappresentati in un formato standard RDF/OWL.
Una ontologia di EA descrive i concetti e le relazioni fra i concetti in modo da modellare le principali dinamiche di EA. Vengono definite a partire da modelli più generici e via via specializzati per lo specifico contesto del cliente. In tal modo nessuno modello ontologico risulta mai uguale ad un altro – si pensi per esempio alle diverse possibili accezioni del concetto “Servizio” che si possono avere e di relazioni con esso.
Rappresentazione degli snapshots temporali e roadmap
Una delle prerogative della modellazione semantica delle informazioni è quella di rendere possibile rappresentazione della dimensione evolutiva di un sistema (linea temporale) tramite la descrizione di specifici stati detti snapshot (metafora nata dalla parola inglese per “foto istantanea”). Ciò permette di definire una roadmap aziendale tramite una serie di step intermedi per raggiungere specifici obiettivi («TO-BE») a partire dallo stato attuale («AS-IS»)
Vedremo più in dettaglio quali siano le diverse viste indipendenti dell’EA, come possano essere formalizzate in modelli ontologici e riconciliate fra loro per creare una unica vista di insieme. Per capire meglio faremo anche un piccolo esempio.
To be continued… 😉
Aggiornamento 15 febbraio 2017 – Nuovo post: L’Enterprise Architecture, da diversi punti di vista.
18 Nov 2016
Posted in Enterprise Architecture
Una delle frasi ricorrenti che sentiamo dire dai clienti quando proponiamo o iniziamo con loro un percorso di enterprise architecture è “non siamo ancora maturi”: i dati non sono maturi, l’organizzazione non è matura, le persone non sono mature…
Ma cosa significa “essere maturi” dal punto di vista dell’enterprise architecture e quando un’organizzazione può considerarsi tale?
Il grado di maturità è legato al livello di conoscenza, condivisione e accettazione nell’organizzazione del processo e del modello dati di enterprise architecture. Fare enterprise architecture significa disegnare l’architettura di un’organizzazione per allineare le iniziative di evoluzione IT alle strategie aziendali. Un enterprise architect promuove una visione d’insieme dell’azienda: occorre integrare informazioni potenzialmente eterogenee con livelli di dettaglio differenti dalle diverse aree, riconducendurle ad un modello comune e condiviso e fornire viste (business, architetturale, applicativa, infrastrutturale, organizzativa) adeguate alle esigenze dei vari interlocutori. Il livello di maturità dipende quindi da quanto il processo di enterprise architecture incide sulle decisioni all’interno dell’organizzazione.
Sfortunamente dati, organizzazione e persone non maturano da soli. Se i dati e il modello non sono gestiti si rischia di trarre conclusioni basate su una fotografia che non corrisponde più alla realtà. Aggiornare dei dati obsoleti può avere dei costi molto elevati perché il divario può diventare talmente alto da vanificare gli sforzi iniziali, il che equivale quasi a ripartire da zero. Se non si coinvolgono le persone nel miglioramento dell’enterprise architecture le decisioni possono apparire come calate dall’alto, le informazioni possono risultare incomplete, inesatte o non del grado di dettaglio utile, di fatto diminuendo la credibilità e il livello di condivisione del processo e del modello dell’EA.
La buona notizia è che un percorso di enterprise architecture può essere intrapreso in modo graduale. Quando un’organizzazione si interessa ai temi di EA perché è consapevole che dover ricostruire lo stato corrente dei propri sistemi a ogni nuova iniziativa non è utile né efficace ha già un grado di maturità sufficiente per iniziare. Si può partire da qualsiasi area, in generale quella su cui si ritiene di avere più informazioni o si pensa che siano più facili da recuperare (processi? applicazioni? infrastruttura?). Si può proseguire per passi, aggiungendo i dati necessari per lo scopo che si vuole ottenere, mantenendo aggiornati quelli esistenti e migliorandone la qualità, coinvolgendo gli interlocutori potenzialmente interessati e cercando di fornire ad ogni passaggio analisi e informazioni significative.
Non esiste quindi un esame di maturità finale perché non c’è un punto di arrivo definitivo. L’enterprise architecture è un’attività continua che deve seguire e agevolare i cambiamenti all’interno dell’organizzazione.
01 Nov 2016
Posted in Enterprise Architecture
Iwan Baan Photography, Rozenstraat 145, 1016 NP Amsterdam, The Netherlands e-mail: studio@iwan.com — all images © Iwan Baan 1996 – 2016
Negli ultimi decenni, per motivi economici, sociali e tecnologici la gestione di organizzazioni e aziende di grandi dimensioni ha raggiunto livelli di complessità tali da rendere insufficienti gli approcci classici. E’ stato quindi necessario individuare nuove metodologie, nuovi processi e nuovi strumenti. Per questo motivo si parla spesso di enterprise architecture come disciplina fondamentale per affrontare questa crescente complessità. Ma di che cosa si tratta e perché tanto interesse?
Se si pensa al significato più tradizionale del termine “architettura” viene in mente il disegno degli elementi che costituiscono una struttura e delle loro interazioni. L’enterprise architecture riprende questo concetto estendendolo alle organizzazioni. Fare enterprise architecture significa quindi disegnare l’architettura di un’organizzazione (enterprise) in tutti i suoi aspetti, a livello di business, di processi e di sistema informativo gestendo e analizzando i dati tramite metodologie adeguate. Occorre fornire le informazioni, le linee guida e gli strumenti necessari ai vari interlocutori per poter prendere decisioni consapevoli e avviare iniziative efficaci come risposta alle sfide e ai cambiamenti che coinvolgono le organizzazioni.
Nel settore finanziario una delle spinte principali che hanno incrementato l’interesse verso l’enterprise architecture è stata l’introduzione della normativa 263 della Banca d’Italia. Alcuni temi inseriti nella normativa sono la gestione dei rischi, della sicurezza, dei dati e della continuità operativa. Le banche hanno dovuto adeguarsi e, in qualche caso, dotarsi di processi e strumenti per governare i loro sistemi informativi.
Un altro fattore fondamentale è stato l’aumento del numero di fusioni e acquisizioni. Le società acquisite oltre ad essere strutturate in modo diverso hanno anche processi e IT eterogenei che occorre gestire e uniformare senza dare discontinuità di servizio, riducendo la complessità e i costi, mantenendo i dati ed eliminando eventuali duplicazioni funzionali. L’enterprise architecture fornisce la metodologia per costruire una mappa dei vari sistemi che lega le applicazioni ai processi di business e alle organizzazioni, fino alla parte tecnologica e infrastrutturale, in modo da poter valutare gli impatti dei cambiamenti, tempi, rischi e costi.