Il ponte tra business e IT

La rapida evoluzione del contesto di sviluppo del proprio business e la spinta innovativa proveniente da un ripensamento generale dei sistemi informativi in chiave strategica ha portato negli ultimi anni le banche italiane a identificare logiche volte ad abilitare un dialogo sempre più efficace tra le funzioni del business e quelle dell’IT.

Se da un lato, infatti, la necessità di una sempre maggiore adesione alle richieste del business ha portato l’IT delle banche a sviluppare sistemi sempre più flessibili e più facilmente scalabili su nuovi contesti di operatività, dall’altro la necessità di definire un linguaggio mutuamente intellegibile e cross-funzionale ha portato a condividere una rappresentazione coerente delle reciproche architetture – di processo, funzionali, informative, applicative e infrastrutturali.

La visione integrata che ne scaturisce porta quindi a definire un modello di Enterprise Architecture che rappresenta il punto di contatto attraverso cui si viene a definire un percorso aziendale condiviso di business transformation.

In tale scia si sono poste le attività dell’Osservatorio sulle Architetture IT di ABI Lab, nato nel 2008 con l’intento di mettere a fattor comune le competenze sui differenti percorsi di mappatura delle architetture IT e sulle scelte adottate nell’ambito dei più importanti progetti infrastrutturali attivati dalle banche italiane.

Si articolano lungo due principali direttrici:

Dal punto di vista metodologico quindi, l’obiettivo macro che il sistema bancario sta perseguendo è quello di definire un unico meta-modello di rappresentazione cui poter riferire tutte le mappe che descrivono, sui differenti livelli concettuali, i domini legati all’operatività interna ed esterna della banca.

Attività primaria è quindi quella di sviluppare e consolidare una base di conoscenza comune, che porti all’identificazione di un dizionario unico e condiviso cui riferirsi all’interno dell’azienda, condividendo non solo la definizione degli elementi di base che costituiscono le mappe e che compongono il framework complessivo, ma anche la meta-struttura che correla tali elementi e che ordina le mappe in un contesto univoco, definendo regole di mappatura comuni e identificando uno schema entro cui rendere omogenei i differenti livelli di astrazione che caratterizzano la rappresentazione stessa.

Questo l’obiettivo sul quale si è consolidata l’attività dell’Osservatorio e che ha portato a condividere una prima struttura organica del meta-modello architetturale, che può essere divisa concettualmente in tre parti:

Nel , lungo la direzione verticale viene riportato il livello di profondità descrittiva degli elementi che sono rappresentati, distinguendo quindi i livelli successivi anche sulla base di una cardinalità differente, mentre lungo la direzione orizzontale vengono riportati i livelli concettuali differenti che compongono la struttura complessiva dell’Enterprise Architecture.

Pur essendo il meta-modello così definito una struttura rappresentabile su due dimensioni, la composizione di livelli concettuali differenti porta alla possibilità di definire mappature incrociate tra gli elementi che lo compongono, introducendo di fatto n dimensioni aggiuntive, in cui ogni livello contribuisce con una configurazione iniziale, che evolve nel tempo in accordo a regole relazionali correlabili alla definizione delle differenti fasi dei processi che si stanno analizzando.

Conseguentemente il modello stesso evolve in un’ottica di rappresentazione non più solo tassonomica, ma ontologica, che prende in considerazione quindi non solo l’elencazione organizzata e completa degli elementi che afferiscono ai singoli livelli identificati nel modello, ma anche le relazioni tra essi, abilitando in ultima istanza la definizione di concetti in grado di sopravvivere alle potenziali modifiche introdotte da cambiamenti tecnologici, procedurali o organizzativi.

Un modello che diviene quindi descrittivo del business bancario, e che resta stabile anche nei cambiamenti operativi.

E se la definizione di un modello unico di riferimento porta a identificare un approccio metodologico in grado di collegare Business e IT sul piano concettuale, l’utilizzo operativo che di tale modello si fa nel percorso di business trasformation della banca porta invece ad individuare quelle caratteristiche qualitative e quantitative utili a prioritizzare gli interventi e a supportare concretamente le scelte progettuali.

Tra esse, un ruolo di assoluto rilievo è riferibile alla flessibilità. Ma cosa si intende per flessibilità e perché è evidenziata dalle banche come caratteristica di importanza cruciale?

In un momento storico in cui i cambiamenti operativi e procedurali derivanti dalle operazioni di integrazione funzionale stanno inducendo adeguamenti continui in termini operativi, la capacità dell’IT di seguire rapidamente le evoluzioni del Business e in alcuni casi addirittura di anticiparlo risulta sempre di più essere un fattore distintivo che permette alla banca di ottenere un vantaggio competitivo.

La flessibilità dell’IT alle richieste del business quindi viene intesa come velocità di adeguamento alle strategie di innovazione, reattività all’estensione geografica, strutturale o funzionale della banca, possibilità reali di abbreviare il time-to-market di nuovi servizi.

E proprio sulla caratteristica della flessibilità si è incentrata una survey condotta da ABI Lab, volta a definire un modello di analisi condiviso e a fornire una valutazione qualitativa delle applicazioni cui è demandata la gestione e l’esecuzione delle attività core business della banca.

In accordo alle esigenze descritte, gli sono stati definiti indicatori riconducibili a caratteristiche di flessibilità funzionale, legate alle estensioni supportate (multilingua, multitenant, multicurrency, multi regime fiscale), flessibilità di implementazione, legata agli aspetti tecnologici (architettura a servizi, personalizzazione e upgrade, semplicità di evoluzione funzionale) e flessibilità evolutiva, legata alla reattività al cambiamento (livello qualitativo dei documenti, livello di indipendenza dal fornitore per l’utilizzo dell’applicazione, livello di indipendenza dal fornitore per la gestione/ personalizzazione dell’applicazione).

Il quadro generale che emerge, , evidenzia una maggiore flessibilità delle applicazioni core nei loro aspetti più prettamente operativi, mentre si raggiungono livelli più bassi per quelli funzionali e tecnologici. In particolare si evidenzia una generale buona capacità di esporre le principali funzionalità implementate mediante modalità a servizio, riconfermando quindi la forte attenzione che il settore ha riversato negli ultimi anni su logiche implementative di tipo SOA.

Viceversa, per quanto concerne le infrastrutture tecnologiche a supporto è possibile notare come risultino ancora fortemente orientate all’utilizzo di una singola piattaforma e di un singolo DBMS. In linea con quanto evidenziato, inoltre, il livello di indipendenza dal fornitore sottolinea la tendenza prevalente a sviluppare le soluzioni relative all’area Operations internamente alla banca.

Si rileva altresì un buon livello di flessibilità evolutiva per quanto riguarda le fasi relative alla progettazione, al controllo di qualità, e alle scelte tecnologiche.

Un’ultima notazione è relativa a un diffuso basso supporto funzionale rispetto ai requisiti legati alle caratteristiche di multicurrency, multi-lingue e multi-regime fiscale, limitazione che indica una diffusione ancora bassa di tale necessità operativa e principalmente limitata ai grandi gruppi con una forte presenza all’estero.