Il Service Management totale di Ibm Tivoli

Abbiamo l’opportunità di intervistare Joao Perez, Ibm Vp Worldwide Sales Tivoli, area nella quale duemila persone sono dedicate al service management del cloud. Perez viene spesso al Laboratorio Ibm di Roma, che dopo l’acquisizione di Tivoli (1996), oltre ad esserne il Briefing Centre Emea, ha assunto responsabilità globali di sviluppo per il cloud, fra cui i prodotti per il Provisioning e l’Automazione agli utenti finali dei servizi cloud.
“Altro che il vaporware di cui parla Larry Ellison [Ceo di Oracle – ndr]”, è categorico il responsabile globale di Tivoli, “il cloud computing consiste nell’applicazione strategica all’infrastruttura It (storage, server e risorse rete) di standardizzazione e consolidamento, virtualizzazione, automazione e approvvigionamento dinamico”, i cui effetti combinati portano alla genesi di tre dominî virtualizzati, destinati a coesistere nel tempo: It “on premise”, cloud privato e pubblico.
Lapidaria la missione dei laboratori Ibm: “Fornire i tre ambienti virtualizzati. Ed è missione di Tivoli il service management per gestire l’ambiente ibrido risultante, in sicurezza (le aziende dovranno convincersi a mettere i loro dati nei cloud) e conformità alle regolamentazioni delle diverse geografie.”
I fattori differenzianti il service management per il cloud offerti da Tivoli? Joao Perez ne snocciola cinque: “Primo, è un service management aperto ed estendibile, al limite agnostico: hardware Sun, Hp o Ibm; database Db2, Oracle, Sybase; ma anche governance Bmc, Hp Mercury, Ca. Tutto legittimo. I clienti – prosegue Perez – scelgano ciò che credono meglio, a noi spetta competere per fornirlo. Secondo, Tivoli è una tecnologia di service management per servizi, singoli o combinati, da uno qualsiasi dei tre dominî: il cliente potrà sempre vedere lo stato dell’infrastruttura in produzione in tempo reale in ogni dominio, sicché se uno switch, router, printer o db si rompe, si possano intercettare le conseguenze correlate all’evento su dashboard e verificarle con lo Sla cui il fornitore è commesso. Non così la concorrenza, che – è ancora Perez che parla – si presenta con due soluzioni, una per ‘on premise’, l’altra per cloud interno, e che non ‘vede’ oltre al firewall nel cloud pubblico. Terzo, Tivoli ha un Board of adviser con le 25 Aziende clienti più grandi al mondo, alcune clienti Ibm, altre no; ogni sei mesi presenta le sue strategie da oltre quattro anni: un periodo sufficiente per essere sicuri di star sviluppando ciò che il Board chiede. Quarto, Tivoli è un asset indifferente, oltre al dominio, al formato con cui è consumato (può essere una semplice appliance compatta, cloudburst, disponibile su Intel e a breve su Unix e Sistemi Z, oppure essere esclusivamente software); o può far parte di un contratto di managed service. Quinto, è implicita una totale scalabilità del service management da un server a un numero grande a piacere, mantenendo identici tecnologia e codice.”
All’evento “Dynamic Infrastructure” (Las Vegas 23/3/2010). È stato annunciato che Maximo (gestore di ciclo di vita e manutenzione di risorse con soluzioni industry in settori disparati, acquisito con Mro Software da Ibm nel 2006) è stato esteso alla gestione degli asset It e a tutta la complessità degli eventi, diventando un Master repository di tutta l’informazione utile al service management (asset, server, desktop, telefoni, switch, cavi, connettività, relazioni fra gli asset), in modo simile a ciò che Sap fa con le risorse aziendali. Così, sostiene Perez, il miglior modo per dispiegare la Soa nei tre dominî è di usare Tivoli come “Sistema operativo per il Service Management”, facendo leva su Maximo: Service Management Tivoli diventa un “Os” per i tre dominî che tiene sotto controllo in tempo reale.