Solution Design

Il progetto di upgrade è risultato essere un processo più complesso del previsto in virtù del fatto che è stato necessario un passaggio non ad una nuova versione successiva, bensì a due.

La scelta in merito alle strategie di azioni perseguibili potevano essere due differenti:

1. Realizzare un upgrade alla versione 8 per poi fare modifiche relativamente meno sostanziali richiesti nel passaggio dalla versione 8 alla 9, in quanto le due risultano essere abbastanza congruenti l’una con l’altra. Il collo di bottiglia in sostanza si trova nel passaggio dalla versione 7 alla 8, come suggerito dalla documentazione ufficiale BMC.

2. Realizzare un upgrade dalla 7.6.04 direttamente alla 9.1.03.

Alten Italia ha deciso di optare per la seconda strategia, utilizzando dei tool specifici e delle modifiche, consapevoli del fatto che la procedura di upgrade fosse comunque più complessa.

Come detto in precedenza, prima di procedere alla realizzazione vera e propria dell’upgrade, ALTEN ha deciso di analizzare approfonditamente la current situation con la versione obsoleta e sono stati messi in luce i moduli con livello di customizzazione più elevato, e che dunque necessitavano di molto lavoro nella fase di upgrade.

Il modulo di change management e altri ad esempio si avvicinavano molto alla soluzione out of the box, a differenza della service request management che era molto custom.

Per la gestione delle service request al momento dell’offerta l’azienda disponeva di due strumenti all’interno di Remedy: strumento OOTB di BMC con circa 300 service request (SR) ed uno strumento custom sviluppato dall’azienda IT&T con una decina di SR.

Prima del progetto di Upgrade, Alten ed il cliente belga aveva collaborato in un progetto detto Fusion per poter permettere la migrazione delle SR ancora presenti nel portale IT&T e dismettere quindi del tutto il sistema legacy per garantire così

70

un’unica soluzione centralizzata di gestione delle SR. Tale migrazione è stata possibile con l’upgrade.

A questo punto dell’analisi preliminare, occorre fornire dettagli più specifici per descrivere come effettivamente è stata implementato l’upgrade a livello architetturale.

Come suggeriscono le best practice relative all’ITSM, BMC suggerisce lavorare su sistemi che si organizzano in tre ambiente differenti, ognuno avente uno scopo ben preciso:

1. un ambiente di sviluppo Development (DEV): ambiente utilizzato per le fasi di testing. Le implementazioni iniziano da questo ambiente non appena il cliente ed il Service Provider definiscono e sottoscrivono User Requirements e Design Specification.

2. un ambiente di Quality Acceptance (QACC): ambiente che viene utilizzato per assicurarsi della conformità ai requisiti rispetto a ciò che è stato implementato e configurato in DEV. Tipicamente questo ambiente deve essere la copia esatta della Produzione in quanto è oggetto di testing da parte dei Key Users dal punto di vista delle performances. Quindi tutto quello che viene accettato dagli utenti in questo ambiente viene spostato in Produzione, come versione definitiva.

3. Un ambiente di Production (PROD): una volta giunti al rilascio della Suite Remedy, gli utenti dell’intera organizzazione a livello globale potranno accedere e lavorare direttamente in questo ambiente.

In fase di Solution Design sono state definite tre architetture per ciascuno dei tre ambienti. In particolare, l’ambiente DEV rispetto agli altri due dispone di un’architettura più semplice in quanto ha la funzione di testare preliminarmente la piattaforma ed eventualmente sperimentare alcune soluzioni custom ove esse risultino essere necessarie. Per quanto riguarda gli ambienti di QACC e PROD invece, questi dal punto di vista architetturale, così come nelle funzionalità e nei contenuti devono essere assolutamente identici. Questo perché ad un certo momento del progetto verrà chiesto a dei Key User di testare le funzionalità del sistema e di fornire dei feedback in merito ai flussi di lavoro, alle prestazioni e alla

71

rispondenza ai requisiti del prodotto. Di conseguenza, al momento del rilascio in PROD gli utenti devono poter accedere ad un ambiente che hanno già testato. In relazione ai tre ambienti, ALTEN Italia ha proposto le seguenti architetture, rappresentata graficamente di seguito:

▪ Development

72 ▪ Production

Quella presentata è una descrizione dell’architettura semplificata, ma ben comprensibile nelle sue componenti. Prima di entrare nel merito dei singoli elementi hardware, ciò che accomuna le tre architetture è la suddivisione in layer, ovvero partendo dal basso si trova un DB Layer, composto da due tipologie di Database, un Data Base Mictosoft SQL ed un Mongo DB in cui vengono immagazzinati tutti i dati relativi agli applicativi social.

Proseguendo verso l’alto si trova un secondo layer che è l’Application Layer, in cui si trovano i Server AR System, i quali scrivono direttamente sul Data Base (DB) e rappresenta il back end, ovvero il livello intermedio fra interfaccia front end e il DB.

In ultima istanza si passa al Web Layer, in cui è presente il Mid Tier, inteso come interfaccia front end utilizzata dai clienti per connettersi attraverso Web Browser. Il Mid Tier prende in carico i dati inseriti dagli utenti per poi riversarli a cascata nel Server AR System e quest’ultimo direttamente nel DB.

Quella descritta fino ad ora è l’architettura tradizionale che BMC ha sempre utilizzato. Negli ultimi tempi ha deciso di introdurre anche l’utilizzo del mobile.

73

Installando il Mid Tier non è possibile accedere in Remdy attraverso un mobile device e quindi ha deciso di introdurre due nuove interfacce chiamate MyIt e Smart IT: la prima è per l’utente finale, mentre i gruppi di supporto, ovvero tutti gli operatori che processano le richieste utilizzano Smart It. Questa è una interfaccia nuova paragonabile al Mid Tier, ma è semplificata, più user friendly ed accattivante nella grafica, che permette quindi non solo di aprire una SR da mobile, ma anche approvarla, ad esempio.

Il prodotto è unico, con l’unica differenza che questa seconda interfaccia è più semplificata.

MyIt e Smart IT hanno anche tutta una parte di social (chat) quindi oltre al DB classico su cui poggiano Mid Tier, MyIt e SmartIT è stato introdotto un altro tipo di DB, open source, specifico per poter memorizzare e processare i dati legati al social, detto Mongo DB.

Quindi per maggiore chiarezza, si può ripercorrere un percorso standard.

Un qualunque end user, di qualunque funzione di appartenenza riscontra ad esempio un malfunzionamento o necessita di più memoria nel disco. Accede a MyIT da browser o da mobile, accede con le proprie credenziali e apre una Service Request, ovvero una richiesta di assistenza contenente tutti i dettagli del caso. A questo punto gli operatori del gruppo di supporto possono prendere in carico e processare la richiesta, che Remedy avrà classificato come un incident o una change request, accedendo a Mid Tier o Smart IT a seconda di quelle che sono le preferenze.

A questo punto l’utente finale riceve dei feedback in relazione alla richiesta aperta attraverso MyIT. Il flusso visibile lato utente finisce qui, ma tutte le informazioni e le azioni che sono state messe in gioco in questo scambio vengono riversate a cascata prima a livello di AR System e di conseguenza a livello di DB in ultima istanza.

Tenendo conto di questa struttura, le strategie a livello operativo per poterla implementare erano sostanzialmente due. BMC, infatti, prevede di realizzare il processo di upgrade attraverso due possibili metodologie alternative.

74

La prima strada prevede di realizzare l’upgrade direttamente sulle macchine di ciascun ambiente attualmente esistente nella vecchia versione. Generalmente questa operazione si fa su un ambiente alla volta.

Il che vuol dire fare una copia di ciascuna macchina, effettuare l’upgrade su questa per ogni ambiente e successivamente sostituire le macchine obsolete con quelle precedentemente copiate su cui è stato eseguito l’upgrade.

La prima opzione non è sembrata fattibile dal momento che il progetto è complesso e non compatibile con l’esigenza di lasciare che i singoli utenti possano continuare con le attività lavorative day-by-day sul sistema anche durante il processo di upgrade.

In sostanza questa opzione implica spegnere le macchine per tutto il tempo necessario finché l’upgrade sia completato, impossibile quindi per il cliente finale che non può interrompere i propri processi di normale funzionamento.

Uno dei problemi è legato al fatto che le macchine precedentemente detenute dall’organizzazione erano obsolete anche dal punto di vista dei sistemi operativi, come ad esempio la versione di Java o del Tomcat, i quali costituiscono dei tools indispensabili per l’ITSM.

È evidente che la complessità sta anche nel fatto che l’upgrade non si limita alla versione, bensì dell’intero sistema operativo.

Di conseguenza Alten Italia ha deciso di utilizzare una strategia, rodata ormai da anni, che consiste sostanzialmente nel prendere una macchina server dell’ambiente DEV 7.6.04, successivamente copiare un DB di PROD sempre nella versione 7.6.04. A questo punto è stato lasciato il sistema operativo obsoleto (solo Java è stato aggiornato), e su questo è stato fatto l’upgrade. Questo ambiente è stato chiamato CLONE, che non è un DEV, ma proprio un quarto ambiente a sé stante, dotato di Virtual Machine (VM) vecchie ma con un DB nuovo, allineato con quello di Produzione.

A questo punto sono stati creati tre nuovi ambienti, fresh, con un DB ciascuno senza dati, vuoto.

Non appena il DEV è stato messo a disposizione dall’organizzazione, è stato possibile installare su questo il DB nuovo creato nell’ambiente CLONE con tutti i

75

dati in esso contenuti e aggiornato alla versione 9.1.03. Su questo ambiente sono stati svolti i test degli applicativi.

A questo punto, una volta installato l’ambiente ACC, in questo è stata realizzata una copia del DEV, perché nel frattempo sul nuovo DB del DEV sono state fatte delle modifiche e correzioni che lo rendono più performante rispetto a quello presente nel CLONE.

Secondo tale strategia, non appena i key users avessero svolto i test di performances in ambiente QACC e quando questo sarebbe risultato funzionante è stato trasferito in ambiente PROD, pronto per essere funzionante a livello operativo senza comunque andare ad intaccare le normali attività del cliente, che sono state penalizzata il meno possibile dalla presenza del nuovo sistema.

Di seguito è riportato un prospetto contenente i dettagli a livello Hardware. Le dimensioni dell’ambiente di produzione sono stati stimati in conformità con le raccomandazioni BMC tale da gestire circa 2000 utenti contemporaneamente.

76

77

Figura 16 - Environment Hardware Details

Quanto descritto finora è la descrizione della strategia operativa con cui il progetto è stato condotto e che sicuramente è risultata vincente in quanto ha garantito un rilascio del prodotto funzionante, con elevati livelli di performance e soprattutto in linea con i requisiti d’uso.

78