by 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:
- essere logicamente distinte fra loro
- poter evolvere e specializzarsi indipendentemente
- 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.).
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.
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… 😉