Architettura
Il termine architettura, riferito all'informatica, si riferisce alla "fondamentale organizzazione di un sistema che incorpora i suoi componenti, le loro relazioni con ciascuno di essi, l'ambiente, i principi che guidano la sua progettazione ed evoluzione”.
[ISO/IEC 15288:2008, System life cycle processes]
Analoga definizione è la seguente “Concetti fondamentali o proprietà di un sistema nel suo ambiente che incorpora i suoi elementi, relazioni, i principi della sua progettazione ed evoluzione”.
[ISO/IEC/IEEE 42010:2011, Systems and software engineering-Architecture description]
L’Architetto d’impresa per l’informatica è colui che progetta e supervisiona i concetti rilevanti che appaiono nella definizione:
- Sistema
- Componenti
- Ambiente
- Relazioni tra le parti
- Principi guida
Il data architect è un esperto di architettura dei dati che definisce come i dati devono essere memorizzati, utilizzati, integrati e gestiti da differenti entità, applicazioni e sistemi IT.
Rappresentare l’insieme degli elementi dell’architettura informatica è cosa complessa e, a differenza dell'architettura classica, di difficile visualizzazione riferendosi a oggetti spesso astratti. Il tema è definito da diversi rilevanti quadri di riferimento (Framework), metodologie, stili di visualizzazione. Tutti gli approcci architetturali mirano comunque ad offrire una visione integrata delle componenti per un migliore governo del sistema informativo.
In genere il termine architettura è accompagnato dalla parola impresa, è diffuso infatti il nome di Enterprise Architecture, per meglio intendere che si sta parlando di una visione generale di tutta un’impresa, dei processi di una organizzazione e la relativa documentazione (anche in una visione cross-enterprise).
Nella maggioranza dei Framework sono presenti alcuni elementi comuni, riconosciuti essenziali nei sistemi informativi/informatici di ogni tipo, come ad esempio:
- Servizi IT
- Applicazioni software
- Informazioni e dati
- Processi
- Documentazioni
- Management
Limitandoci a considerare solo alcuni dei termini citati, si può dire che i Servizi IT raggruppano più applicazioni software. Un’applicazione è definibile come “collezione coesa di procedure automatizzate e dati che supportano un obiettivo di business. Consiste in uno o più componenti, moduli o sottosistemi” [da Function Point Count Practice Manual - IFPUG - International Function Point User Group].
Un’applicazione ha un confine che la distingue dalle altre, riconoscibile dall’utente, seppur potrebbe contenere moduli riusabili in comune con altre applicazioni.
Un catalogo delle applicazioni software è alla base di una visione architetturale del sistema e contiene elementi caratteristici, come ad esempio:
- codice univoco identificativo;
- autore o team organizzativo;
- titolo e breve descrizione significativa (evitando sinonimi e termini ambigui come “stampe di prospetti”);
- anno di primo sviluppo e di eventuale dismissione;
- piattaforma tecnologica di riferimento;
- banche dati logiche utilizzate;
- programmi software (nome, linguaggio, Loc, Fp ed altre metriche di qualità del software)
- documenti connessi (schemi, modelli, specifiche)
- altre informazioni eventuali provenienti da segnalazioni del contact center
- tipo di utenza servita;
- potenziale riusabilità in altre organizzazioni;
- connessione con altre organizzazioni.
La disponibilità del Catalogo, tra l’altro, consente di conoscere il numero di applicazioni del sistema. In un sistema informatico di piccole dimensioni possono individuarsi un numero di applicazioni dell’ordine delle decine, in uno medio un numero dell’ordine delle centinaia ed in uno grande un numero dell’ordine delle migliaia.
Per quanto riguarda i dati un prodotto dell’architettura importante è definito con il termine Dizionario dati che può contenere varie informazioni, come ad esempio:
- nome del dato (univocità e sinonimia);
- descrizione;
- applicazione software in cui viene usato;
- banca dati logica di appartenenza;
- owner;
- livello di qualità del dato e regole di controllo (per fasi del ciclo di vita);
- eventuali segnalazioni di difettosità provenienti dal contact center;
- rilevanza esterna (es. master data)
- volatile o storico;
- aggiornabilità;
- riservatezza;
- conformità a normative internazionali.
Si può aggiungere che in genere un elenco puramente alfabetico dei dati, seppur utile, non è sufficiente a comprendere l’integrazione tra di essi, la loro gerarchia concettuale, ecc.. In questa prospettiva solo modelli contestuali/concettuali che offrono decomposizioni gerarchiche delle informazioni possono venire in aiuto.
Un riferimento standard per la descrizione dei processi è rappresentato dall’ISO/IEC 15288: 2008 “Systems and software engineering - System life cycle processes” e le relative documentazioni dall’ISO/IEC 15289: 2011 “Systems and software engineering - System life-cycle information products (documentation)”. Sempre rimanendo nell’ambito ISO lo standard ISO/IEC 38500: 2008 “Corporate governance of information technology” fornisce utili principi guida per il management di organizzazioni circa l’effettivo, efficiente ed accettabile uso dell’IT all’interno delle organizzazioni.
In conclusione appare evidente che solo un adeguato supporto automatico può tracciare in modo utile tutti questi elementi, specialmente se l’esigenza di disporre di un quadro architetturale emerge durante l’esercizio di un sistema e quindi raggiungibile con un approccio di “Reverse engineering” e non di “Forward engineering”. In ogni caso occorre trovare soluzioni “sostenibili” di Architettura che non costituiscano un appesantimento del ciclo produttivo, ma solo vantaggi di integrazione e affidabilità.
Similmente all’architettura classica che tende al benessere delle persone che la vivono attraverso l’estetica, la funzionalità, l’innovazione, l’architettura nell’IT mira a facilitare il governo degli elementi astratti nell’ambiente reale del sistema al fine di garantirne l’usabilità nel funzionamento.
Informativa sulla Privacy e sui Cookies.