Introduzione Quello che si vuole descrivere in questo articolo non è soltanto uno scenario reale (è effettivamente occorso presso uno dei maggiori gruppi bancari Italiani) ma è soprattutto generalizzabile e estremamente rappresenta …
Introduzione
Quello che si vuole descrivere in questo articolo non è soltanto uno
scenario reale (è effettivamente occorso presso uno dei maggiori gruppi
bancari Italiani) ma è soprattutto generalizzabile e estremamente rappresentativo
delle tipiche problematiche che sottendono la realizzazione di una soluzione
enterprise che si deve inserire nel sistema informativo di una organizzazione
di grosse dimensioni e con una notevole distribuzione sul territorio.
Lo scenario
Si immagini di dover realizzare un sistema che supporti le fasi del processo
di vendita di prodotti assicurativo/finanziari di un gruppo bancario variegato
e di notevoli proporzioni. Al di là delle sfide rappresentate dalla complessità
dei processi che governano la vendita esistono delle sfide di carattere tecnologico
e funzionale che tale sistema deve raccogliere. Elenchiamo alcune di esse:
– multibanca: le sinergie di gruppo rendono richiedono che
la vendita dei prodotti sia possibile dagli sportelli di tutte le diverse banche
del gruppo. Queste ultime pur appartenendo ad uno stesso gruppo finanziario
conservano una loro identità individuale e non sono sempre completamente
integrate in termini tecnologici (standard, procedure, infrastruttura di rete,
ecc.) anche perchè la loro entrata nel gruppo in alcuni casi è
ancora troppo recente.
– multicompagnia: il sistema deve supportare ugualmente bene
tutte le compagnie "di prodotto" che coprono segmenti diversi del
mercato assicurativo. Tra l’altro, tali compagnie sono spesso configurabili
come aziende separate e pertanto, anche per queste ultime, valgono le considerazioni
di cui al punto precedente.
– multicanale: le funzionalità offerte dal sistema debbono
poter essere riutlizzate da una molteplicità di soggetti, quali ad esempio:
operatore di filiale, promotore finanziario, titolare di un account di home
banking, ecc. Al di là delle differenze in termini di modelli di utilizzo,
questa varietà di soggetti crea un altro fattore di disomogeneità:
quello del canale attraverso il quale si accede (intranet, internet, wap, ecc.).
Questo fattore deve essere necessariamente neutralizzato con opportune scelte
architetturali per evitare l’esplosione di complessità che deriverebbe
da un’adattamento dei sistemi alle caratteristiche peculiari dei canali.
– sistemi esterni: l’interazione con procedure già esistenti
e la coesistenza con standard tecnologici giò adottai è un altro
fattore di cui tener conto. Ne consegue la necessità di risolvere in
modo efficace il problema di garantire interfacce (mono o bi-direzionali) con
una serie di sistemi esterni (applicazioni dipartimentali, legacy transactions,
ecc.)
Perchè i Web Services
Gli elementi riportati nel pararagrafo precedente ci forniscono degli spunti
diu riflessione circa le esigenze che la soluzione da realizzare deve soddisfare:
– interoperabilità: come colmare i gap tecnologici tra
le diverse entità di un complesso gruppo bancario? Questo tipo di problema
è stato affrontato per molto tempo in termini di portabilità,
ovvero sulla possibilità di far girare una soluzione su un ampio parco
di piattaforme (CPU, sistemi operativi, data base, ecc.). L’esperienza ha dimostrato
che la portabilità non costituisce sempre la risposta migliore anche
a causa della difficoltà di annullare le differenze tra diverse piattaforme.
Tutto ciò ha spesso conseguenze indesiderate quali il degrado di prestazioni
e un onere di gestione aggiuntivo della soluzione dovuto a differenze ineliminabili
tra le piattaforme in termini di comportametno e configurazione.
Un nuovo concetto si sta proponendo come alternativa credibile e in molti casi
più efficace: l’interoperabilità. In uno scenario di interoperabilità
per ciascun componente viene scelta la piattaforma hw/sw che risulta più
congeniale e l’integrazione tra di essi viene garantita attraverso protocolli
standard e specifiche condivise. L’idea consiste nel riformulare la soluzione
alle problematiche di integrazione focalizzandola principalmente sulle interfacce
che i componenti espongono e ottenendo pertanto un disaccoppiamento naturale
tra piattaforme diverse.
– esternalizzazione: uno dei requirements esplicitati per il
caso in oggetto è quello di fornire un unico sistema a supporto delle
differenti compagnie di prodotto del gruppo, tanto per le esigenze presenti
che per le evoluzioni future. In questa ottica diventa indispensabile costruire
la soluzione in termini di mattoni che non possono limitarsi a rispondere unicamente
alle esigenze di implementazione di signole funzionalità per una specifica
compagnia. E’ necessario pertanto uno shift dal paradigma delle applicazioni
costruite su componenti (realizzati in modo specifico per queste ultime) ad
un modello basato su servizi che hanno come riferimento l’universo applicativo
di una o più aree di un’azienda e diventano un asset di quest’ultima
nel suo complesso. Tutto ciò spinge il concetto di riutilizzabilità
oltre i limiti classici permettendo di raggiungere dei benefici ulteriori in
termini di ritorno di investimento.
– location transparency: nel processo di evoluzione dei sistemi
informativi di un’azienda con un notevole grado di distribuzione sul territorio,
può rendersi necessario (o almeno fortemente conveniente) rimettere in
discussione la collocazione geografica di applicazioni, servizi, ecc. In questa
ottica è fondamentale creare i presupposti per cui i mecanismi attraverso
i quali i servizi vengono fruiti non siano dipendenti dall’ubicazione di questi
ultimi in modo da neutralizzare l’impatto derivante da ridistribuzioni geografiche
o anche semplicemente da ridefinizioni delle topologie di rete. Ciò che
si richiede è pertanto una trasparenza dell’ubicazione (location transparency).
I web services rappresentano una soluzione standard, economica ed efficente
alle problematiche sopra descritte. Sono infatti basati su un insieme di standard
gestiti da organizzazioni neutrali (ad es. www.w3.org) e appoggiati dai leader
del mercato IT (ad es. Microsoft e IBM) che già oggi sono stati implementati
sulle più svariate piattaforme. Possono appoggiarsi a protocolli di trasporto
anch’essi standard (ad es. HTTP) che semplificano drasticamente le problematche
di invocazione dei servizi anche quando è necessario attraversare i confini
di diverse reti aziendali. Tutto ciò ne semplifica anche la gestione
operativa vista la solida esperienza che il personale IT ha avuto modo di formare
su queste tecnologi di base.
La semplicità di implementazione è garantita da un’ampia
scelta di toolkit e strumenti sviluppo. Microsoft Visual Studio .NET eil .NET
framework rappresentano un esempio notevole in tal senso sia per la facilitazione
del ciclo di implementazione che per la completezza del supporto in termini
di standard e protocolli (SOAP, XML, WSDL, UDDI, ecc.)
La soluzione
La soluzione effettivamente implementata (ad oggi già in produzione)
è illustrata in linea generale dal diagramma di fig. 1:
Alla luce dei requisiti dello scenario era necessario fornire una soluzione
sufficientemente flessibile da consentire l’implementazione di nuovi prodotti/funzionalità
in tempi brevi, facilmente manutenibile e tale da semplificare l’aggiunta
nel tempo di nuovi canali di vendita da supportare.
Per soddisfare il primo requisito è stato realizzato un framework ad
hoc che consente di creare un prodotto assicurativo a partire da moduli di base
comuni a tutti i prodotti quali ad esempio: sottoscrizione, denuncia sinistro,
richiesta riscatto parziale etc.
Ciascun modulo contiene al suo interno la definizione delle informazioni da
acquisire, dei controlli da implementare, dei calcoli da eseguire e la sequenza
con cui reperire queste informazioni. La creazione di un nuovo prodotto avviene
come composizione di questi moduli attraverso strumenti di configurazione con
un elevato riutilizzo delle funzionalità.
Il framework espone le sue funzionalità sotto forma di web services.
Tutto ciò permette riutilizzare tali servizi da applicazioni e canali
di distribuzione delle diverse aziende del gruppo e consente contemporaneamente
alle compagnie assicurative di prodotto di gestire in proprio i servizi e quindi
le caratteristiche dei prodotti.
La multicanalità della soluzione è garantita da una infrastruttura
propria del cliente (Multi-channel service interface) oltre che dall’architettura
della soluzione che rende piuttosto semplice aggiungere supporto per nuove tipologie
di client. Al momento è già attivo il canale per le filiali (fig.
2) mentre sono in fase di planning o prototyping gli altri canali.
Conclusioni
Il caso reale descritto in questo articolo costituisce una esempio evidente di come i web services possano fornire un valore aggiunto ad una soluzione come quella descritta e a tutte quelle per le quali valgono (anche soltanto in parte) le considerazioni fatte fin qui.
Tra i benefici conseguiti della soluzione in oggetto è il caso di menzionare senz’altro:
– l’utilizzo di un unico framework a supporto della vendita di prodotti assicurativi nell’ambito del gruppo con ovvia riduzione di costi e di consistenza dei sistemi
– il ridotto time-to-market con il quale tutte le compagnie di prodotto possono creare nuovi prodotti che a loro volta possono essere commercializzati da tutte le banche del gruppo attraverso i diversi canali distributivi
– il notevole grado di interoperabilità (garantito dall’adozione di standard aperti) con conseguente facilità di integrazione con sistemi eterogenei che scongiura scenari indesiderati di dipendenza da singoli vendor di tecnologie
Indicazioni future:
– definizione standard (transazioni, security, ecc.)
– comprensione dell’approccio service oriented
