Cosa significa fare convergere voce, dati e video su un’infrastruttura e a quali compiti sono chiamati It e network manager.
In questo spazio (Techne – Con parole mie) i protagonisti della tecnologia raccontano e si raccontano, portando alla luce la miscela virtuosa di tecnica ed esperienza al servizio delle esigenze dell’utenza. Parlano sulla base della conoscenza, evitando di fare riferimento alla propria produzione, bensì portando il discorso su un piano generale e fruibile da tutti.
Le aziende di telecomunicazioni si trovano ad affrontare interessanti sfide ed opportunità. Da un lato, alcune delle loro principali aree di guadagno si stanno trasformando in commodity, cosa che comporta una caduta dei prezzi e la necessità della massima efficienza. Dall’altro, hanno l’opportunità di usare i massicci investimenti effettuati sulle reti per portare traffico di diverso tipo e, cosa ancor più importante, per offrire nuovi prodotti. Uno dei principali tra questi è il cosiddetto triple-play, ovvero l’offerta di voce, dati e video/Tv su un network di telecomunicazioni piuttosto che su reti dedicate.
Agli occhi di un It manager, queste opportunità si traducono in una maggiore richiesta di integrazione tra le applicazioni che reggono il business. L’integrazione non è fine a se stessa, ma nasce quando fattori di business la richiedono, o portano miglioramenti all’architettura It, e la rendono più veloce ed economica. Quello che sta succedendo nel mondo delle telecomunicazioni è un esempio di come i nuovi approcci e gli standard di integrazione vengano stimolati da due dei più importanti driver di business -necessità di ridurre i costi e introduzione di nuovi prodotti.
Se i prezzi dei classici prodotti di telecomunicazione si abbassano, significa che le aziende di questo settore devono tagliare i loro costi. Ad esempio, devono accorpare i call center di cui dispongono, per ridurne il numero o migliorarne la flessibilità, in modo che ogni call center possa gestire un numero maggiore di prodotti. In entrambi i casi, devono integrare le interacce utente dei call center con più applicazioni di back-end in grado di gestire più e più prodotti. Ma, oltre a ridurre i costi, devono stimolare gli investimenti con nuovi prodotti e devono mantenere i clienti che già hanno offrendo loro sempre di più. Tra gli esempi che si possono citare c’è la fatturazione unica di linee fisse e mobili, ed un miglior supporto al cliente. Ad esempio, se un cliente comunica con un call center in giorni diversi, prima per una linea fissa, poi per una linea mobile, il call center dovrebbe riconoscere che si tratta della stessa persona.
Una mancanza di integrazione porterebbe il cliente a doversi ripetere più volte (ad esempio per un cambio di indirizzo) e l’azienda a non poter offrire prodotti attrattivi su misura (come la fatturazione unica ed i piani fedeltà che coprono diversi prodotti).
A rendere le cose più difficili, i tempi a disposizione per l’offerta di nuovi prodotti e per il miglioramento dei servizi si sono ridotti. Nessuna Telco può più permettere anni per la ricerca, lo sviluppo e l’offerta di un nuovo servizio, cosa che fino a poco tempo fa era la norma in ogni settore. La sfida oggi è quella di offrire velocemente molti nuovi servizi, ed anche di lasciar decidere al mercato quali saranno destinati alla nicchia e quali invece avranno una più ampia diffusione. Questo porta all’It ulteriori sfide, quali: velocità di sviluppo e installazione, investimenti che richiedono ritorni immediati, codici riutilizzabili, massimo sfruttamento degli investimenti nei sistemi legacy, aderenza agli standard.
In generale, il mondo delle telecomunicazioni ha le stesse preoccupazioni di ogni altro settore verticale. Ma ha anche una serie di problematiche specifiche, che nascono dalla quantità e dalla profondità della tecnologia tipicamente utilizzata dalle grandi aziende di Tlc. Detta in un altro modo, un’azienda di telecomunicazioni non si deve solo preoccupare delle applicazioni che si definiscono Bss (Business Support System), dedicate a problematiche quali la fatturazione ed il customer care, ma deve seguire anche il cuore del sistema di telecomunicazioni, il cosiddetto Oss (Operations Support System), che si appoggia sugli switch per gestire gli allarmi ed aiutare a raccogliere informazioni per la fatturazione, tra le altre funzioni.
Non solo un Oss è complesso, ma tutte le grandi Telco ne contano differenti istanze, spesso di vendor differenti, per gestire diversi tipi di rete, o semplicemente per coprire le ampie dimensioni di una rete carrier, che copre un Paese intero, ed a volte si estende per più nazioni e continenti. La necessità di ridurre i costi e offrire nuovi prodotti ha messo questa complessità al centro dell’attenzione: per rispondere a queste necessità di business, i diversi Oss che operano in azienda devono essere integrati in modo nuovo con software di più alto livello. Ad esempio, per offrire una fatturazione unica linee fisse e mobili, le informazioni relative, raccolte da più Oss, spesso molto differenti tra loro, devono essere integrate con un billing engine a livello di Bss. Il triple-play porta requisiti ancora maggiori, tra cui la necessità di gestire almeno tre tipi di traffico molto differente su una rete, e di effettuare una fatturazione in base ad attività ed aspettative dei clienti, molto diverse tra loro.
Per aiutare a risolvere queste problematiche tecniche, il TeleManagement Forum ha introdotto lo standard Multi-Technology Operations System Interface, o Mtosi. Questo definisce come debba presentarsi l’interfaccia verso l’Oss, sia a livello alto (quali servizi deve fornire) che a livello dettagliato (quali operazioni deve fornire ogni servizio all’ambiente nel quale opera l’Oss). Mtosi è definito in un linguaggio di interfaccia chiamato Web Services Definition Language (Wdsl) che, per ogni operazione, definisce il messaggio di input e quello di output. Questi messaggi sono definiti in Xml (eXtended Markup Language).
Al livello più semplice, questo significa che c’è una definizione Xml di ogni messaggio di input e output per e da un Oss. Il problema è che gli Oss esistenti non si attendono di ricevere richieste in formato Xml o di dover rilasciare risposte (o altre richieste) in Xml. Sono stati scritti prima che Xml diventasse un metodo popolare di definire i messaggi. Effettivamente, la maggior parte degli Oss usano middleware Corba per integrare le molte componenti che fanno un singolo Oss, ed è naturale per loro presentare interfacce Corba alle applicazioni che operano su di essi. Questa non è una grande difficoltà in realtà, perché un layer Wsdl/Xml può facilmente essere aggiunto sopra Corba. Un layer Xml può essere sovrapposto a un Oss nuovo o già esistente, e renderlo compatibile con Mtosi.
Più complesso è il fatto che, se Mtosi utilizza Wsdl/Xml per definire le interfacce verso un Oss, ciò non vuol dire che un Oss debba per forza ricevere e mandare messaggi in Xml. Questo legherebbe la nuova interfaccia Mtosi a una singola tecnologia di messaggistica, e non aiuterebbe in termini di compatibilità futura dell’interfaccia verso l’Oss. Che cosa succederebbe tra cinque o dieci anni, quando ci sarà necessità di aderire a nuovi standard di interoperabilità delle applicazioni? Inoltre, la messaggistica Xml ha vantaggi (i messaggi sono autodescrittivi) e svantaggi (i messaggi sono più grandi e più costosi da elaborare rispetto a quelli di un middleware come Corba), e le aziende di telecomunicazioni non intendono legarsi per sempre a questi vantaggi e svantaggi.
Effettivamente, Mtosi usa Xml per definire quali dati deve contenere ogni messaggio, ma un Oss ha comunque la scelta di quale middleware utilizzare per portare i messaggi in entrata e uscita, e di quale formato questi messaggi debbano avere durante la trasmissione. Elemento fondamentale della definizione “Multi-Technology” del nome stesso Mtosi è la definizione di un’interfaccia verso l’Oss che sia indipendente dalla sottostante tecnologia middleware, che realmente trasporta i messaggi. Un Oss conforme a Mtosi potrebbe usare Corba, un altro Soap ed i Web service.
Idealmente, un Oss dovrebbe essere indipendente dalla scelta del middleware: dovrebbe essere possibile implementare lo stesso Oss per usare uno o più differenti middleware, a seconda delle necessità tecniche (la velocità, ad esempio) o delle preferenze aziendali.
L’ultimo elemento è molto importante, perché ogni azienda di telecomunicazioni ha delle preferenze per un numero limitato di middleware, di cui possiede le licenze e su cui il proprio staff ha esperienza di gestione a livello di runtime. E’ anche un vantaggio per gli Isv, che ora possono sviluppare un Oss (o una parte di un Oss), e lasciare ad ogni azienda di telecomunicazioni la scelta su come installarlo.
Per aiutare ad ottenere i vantaggi di Mtosi, le aziende di Tlc e gli Isv stanno adottando una nuova architettura di integrazione chiamata Soa (Service Oriented Architecture). Si tratta di un approccio che esiste da tempo, con i primi esempi che risalgono al 1997, ma che negli ultimi tre anni è diventato l’approccio di riferimento, raccomandato da tutti i maggiori analisti. Se usato per realizzare Mtosi, ogni componente di un Oss viene rappresentato come un servizio che poggia su un software bus, ed ognuno di offre di portare richieste per ogni altro servizio (ad esempio altri servizi Oss o Bss) che si trovano sullo stesso bus. Questo bus è noto come Enterprise Service Bus (Esb), dove la parola “enterprise” sta ad indicare il fatto che i servizi possono essere resi disponibili per tutta una grande azienda, ma anche che il bus stesso deve essere in grado di garantire scalabilità e prestazioni di livello enterprise, ed avere caratteristiche quality of service, quali sicurezza e gestione.
Una necessità specifica per offrire Mtosi è che l’Esb sia multi-technology. Questo vuol dire cose diverse, come ad esempio:
– I servizi sull’Esb devono essere in grado di utilizzare qualsiasi middleware desiderino all’interno della propria implementazione.
– Un cliente di un servizio deve essere in grado di utilizzare un middleware diverso da quello usato dal servizio, e l’Esb deve poter effettuare ogni traduzione che sia necessaria perché i due comunichino tra di loro.
– Ci deve essere la possibilità di scegliere quale middleware, o quale mix di middleware debba essere usato per trasportare i messaggi tra client e server. Scelte differenti possono essere fatte in diverse aree dell’azienda, a riflettere differenti necessità tecniche o diverse preferenze da parte dello staff di sviluppo o gestione.
Gli Esb multi-technology porteranno grandi differenze nel modo in cui l’integrazione viene fatta in tutti i mercati, ma giocheranno un ruolo particolarmente importante nel mondo delle telecomunicazioni, per la necessità che in questo mercato esiste di integrare Oss differenti di diversi vendor e per lo standard Mtosi.
(*)L’autore è fondatore e Chief Scientist di Iona Technologies
