Tag

, , , , , ,

Introduzione

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

Enterprise Architecture: un contesto perfetto per dare senso ai dati

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:

  1. Condivise e non recluse nelle “scrivanie” dei vari responsabili di dominio
  2. Indipendenti da logiche applicative e non designate per su uno strumento specifico
  3. Facilmente integrabili fra loro e non ridondate ed inconsistenti
  4. Mantenute vive ed aggiornate e non censite da zero ogni volta
  5. Facilmente riusabili per scopi non conosciuti a priori e non usa e getta per un singolo uso.

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»)

Nel prossimo articolo…

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.