Archivi tag: Enterprise architecture

L’Enterprise Architecture, da diversi punti di vista

15 mercoledì Feb 2017

Posted by in Enterprise Architecture, Enterprise Information Management, SemWeb

≈ Lascia un commento

Tag

, , , , ,

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.

Cinque viste diverse

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:

  1. essere logicamente distinte fra loro
  2. poter evolvere e specializzarsi indipendentemente
  3. poter essere facilmente correlate e integrate fra loro per dare la visione d’insieme

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.):

  • Vista business – Tutti i concetti e le relazioni direttamente afferenti al modo business dell’azienda e di solito usati dai gruppi business (macroprocessi, processi, attività, servizi business, entità di business ecc.)
  • Vista architetturale – Tutti i concetti e le relazioni che afferiscono alle dinamiche architetturali dei sistemi IT e di solito usati dai gruppi architetture (concetti della SOA, framework, linee guida, piattaforme, componenti ecc.)
  • Vista applicativa – Tutti i concetti e le relazioni che servono per descrivere il dominio applicativo e di competenza dei vari gruppi applicativi (applicazioni, componenti applicative, dipendenze applicative/flussi ecc.)
  • Vista infrastrutturale – Tutti i concetti e le relazioni coinvolti nelle dinamiche di dominio infrastrutturale e usati dai vari gruppi infrastrutture/operation (componenti infrastrutturali, hardware, software, server/host, data center, reti ecc.)
  • Vista organizzativa – Tutto quanto rappresenta gli aspetti organizzativi dell’azienda. Tale dominio solitamente è particolare in quanto trasversale rispetto agli altri (persone, responsabili, ruoli/profili, unità organizzative, organigramma, compagnie di gruppo, organizzazioni 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

Un esempio reale nell’ambito bancario

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:

  • Vista business: l’applicazione implementa molte delle funzionalità fondamentali nel processo di business denominato “Disposizione Bonifici”, come per esempio la ricerca in una anagrafica di destinatari, implementa il front-end di immissione delle coordinate e di tutti i dati necessari o ancora la creazione della transazione e l’avviso sull’esito via SMS o altro canale. Tutte queste sono diverse attività di business del processo di business padre “Disposizione Bonifici”.
  • Vista Architetturale: dalla prospettiva dell’architettura IT, l’applicazione deve rispondere a determinate linee guida e pattern architetturali, espone dei servizi riusabili in ottica SOA e viene sviluppata usando specifici framework tecnologici.
  • Vista applicativa: in questa ottica l’applicazione ha diversi attributi tecnici che la descrivono e viene formalmente classificata rispetto ad una tassonomia (es. ABI Lab). Può inoltre può essere composta da diverse sottocomponenti tecnologiche riusabili che ne implementano le diverse sotto-funzionalità. L’applicazione bonifici ha delle dipendenze applicative (flussi) verso altre applicazioni/componenti applicative per richiedere dati o servizi o aggiornarne altri dati di cui non è master.
  • Vista infrastrutturale: l’applicazione e le sue componenti applicative sono “deployate” su application server o su ESB o ancora useranno uno specifico DBMS che gira (in cluster o meno) a sua volta su macchine fisiche o virtuali in base agli ambienti (sviluppo, produzione o test).
  • Vista organizzativa: L’applicazione ha diverse relazioni con diverse unità organizzative e persone fisiche in termini di referente tecnico, funzionale o responsabile business. Tali responsabilità potrebbero essere ereditate verso l’alto nell’organigramma (un’unità è responsabile indirettamente delle applicazioni di cui sono responsabili le sottounità).

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

NEL PROSSIMO ARTICOLO…

…faremo un sunto dei primi due articoli cercando di enfatizzare i concetti cardine dell’approccio semantico con qualche spunto di riflessione.

To be continued… 😉

Gestire le informazioni di EA con… senso!

06 lunedì Feb 2017

Posted by in Enterprise Architecture, Enterprise Information Management, Linked Open Data, SemWeb

≈ Lascia un commento

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.

Enterprise architecture ed esami di “maturità”

18 venerdì Nov 2016

Posted by in Enterprise Architecture

≈ Lascia un commento

Tag

,

worry student have a problem with mathematics

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.

Enterprise architecture: un interesse crescente

01 martedì Nov 2016

Posted by in Enterprise Architecture

≈ Lascia un commento

Tag

, ,

03rotterdam-oma-13-12-6345

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.