L’implementazione di una soluzione Ibm Tivoli ha permesso a Banca Popolare di Novara di governare i servizi informatici, indipendentemente dalla piattaforma
La coesistenza di sistemi eterogenei rappresenta una situazione frequente all’interno dei grossi sistemi informativi, in grado a volte di compromettere l’efficienza della gestione del servizio erogato.
Banca Popolare di Novara (Bpn) ha deciso di affrontare questo problema. L’istituto di credito dispone, infatti, di soluzioni differenti sui diversi canali informatici: nell’ambito Internet adotta da circa due anni una soluzione Candle e, in ambito distribuito, utilizza la soluzione Tng di Computer Associates per la gestione delle filiali; dispone, inoltre, di soluzioni in ambiente Unix e di sistemi Ibm dal lato host.
«A fronte di un’esigenza della banca che è quella di essere disponibile in modo reale 24 ore al giorno, 7 giorni su 7 – ha commentato Giuseppe Primicerj, Cio di Bpn – il nostro problema era quello di avere la possibilità di unificare tutti i sistemi di allarme per governare contestualmente il mondo Internet, quello dipartimentale e tutta la parte storica».
Bpn ha, quindi, scelto Ibm Tivoli per realizzare una soluzione adatta a visualizzare e monitorare tutti i principali servizi informatici della banca. Questo progetto viene
considerato dall’istituto di credito di notevole valenza strategica, in quanto ritenuto fondamentale per migliorare i livelli di servizio erogati in tutte le linee di business. Permette, infatti, a Bpn di consolidare tutti gli strumenti di gestione, sia per il mondo host che per quello distribuito, sotto un’unica visione, riducendo così la complessità e l’eterogeneità degli ambienti gestiti; inoltre consente al management It di oltrepassare il semplice controllo delle risorse tecnologiche per muoversi verso una gestione dei
servizi di tipo end-to-end.«Su questo progetto abbiamo scelto Ibm – ha spiegato Primicerj – perché ritenevamo avesse tutte le competenze per essere un system integrator ideale per una pluralità di soluzioni applicative che oggi governano in maniera diversa sia il mondo host sia il mondo dipartimentale».
I principali componenti della soluzione adottati sono Tivoli Enterprise Console e Tivoli Business Systems Manager (Tbsm): il primo per una gestione operativa e sistemistica, il secondo per una gestione dei servizi e quindi di più alto livello.
«Per evitare di avere una pluralità di competenze e, soprattutto, di applicazioni che gestivano, ognuna molto bene, la propria realtà, abbiamo lavorato con Ibm perché
Tbsm fosse un concentratore di dati, affinché il nostro operatore di sala potesse, in unica videata, disporre di tutte le informazioni necessarie per l’identificazione di qualsiasi problema».
Grazie a un accordo con Telecom è stato, inoltre, possibile un ulteriore ampliamento del progetto, che ha permesso il controllo dello stato dei router. In caso di guasto di un router in una filiale o in cui si dovessero presentare problemi di linea, l’informazione del disservizio viene indirizzata automaticamente su Tbsm che, a sua volta, è collegata alla piattaforma presente nella struttura di help desk, ovvero Remedy.
«In maniera nativa qualora si dovesse bloccare un’applicazione – ha spiegato Primicerj – Tbsm fa arrivare direttamente su Remedy l’informazione affinché il personale dell’help desk possa vedere online le applicazioni che sono bloccate e quindi rispondere immediatamente. In precedenza ricevevamo dalla filiale la segnalazione del disservizio sull’applicazione e poi cercavamo di individuarne la causa. Spesso era poi difficoltoso rintracciare rapidamente il responsabile».
Le informazioni appaiono ora al personale di sala con la stessa modalità senza dover differenziare tra Unix, Internet, trading o host. Le indicazioni di disservizio vengono veicolate automaticamente ai responsabili competenti dell’applicazione tramite Sms o e-mail. Inoltre tutte le piattaforme si aggiornano vicendevolmente: quando il problema è sistemato viene effettuato il riaggiornamento automaticamente e all’operatore è notificata la risoluzione del problema. L’implementazione della soluzione ha richiesto un tempo di sei-otto mesi. La principale difficoltà di tipo tecnologico, indicata dal responsabile di Bpn, è stata quella di gestire la quantità di informazioni che ogni applicazione e ogni sistema governa: messaggi di diversa importanza o urgenza, selezionare le informazioni strategiche e quelle legate al business per dar loro la corretta priorità in modo che sul cruscotto unificato venissero evidenziati solo i messaggi davvero necessari.
«Si è trattato di un lavoro svolto congiuntamente a Ibm – ha spiegato Primicerj – che ha richiesto un grosso lavoro di analisi dei messaggi veicolati dai diversi sistemi. Si tratta di una serie di procedure che vanno continuamente affinate giorno dopo giorno».
Con questo progetto Bpn sta realizzando un notevole salto qualitativo in termini di gestione della propria infrastruttura It.Grazie a questa soluzione Tivoli, Bpn ha potuto preservare tutti gli investimenti precedenti fatti verso soluzioni Ibm e non, che sono state integrate all’interno del progetto; la soluzione è inoltre flessibile e scalabile tale cioè da permettere di integrare con semplicità all’interno del progetto nuovi ambienti. Questa soluzione si inserisce in una collaborazione di tipo più integrato avviata da Bpn con Ibm e che ha in corso d’opera anche la messa a punto di una soluzione di disaster recovery.
Si tratta di un progetto che ha indotto Bpn ad acquistare una seconda macchina Shark (in aggiunta alla preesistente) in modo da disporre di una capacità complessiva di circa 7-8 Terabyte.
L’obiettivo finale di questo progetto è la realizzzazione di una soluzione in grado, entro una distanza di 10 Km, di commutare “a caldo” su un altro sistema.
