Rete come piattaforma

La competizione tra gli operatori è sempre più agguerrita e il consolidamento del fenomeno Over-The-Top “OTT” [nota 1] ha causato una significativa riduzione dei profitti: gli operatori devono essere “smart” e trovare nuovi flussi di ricavi, rivedendo i loro modelli di business in modo da essere non solo fornitori di pura connettività (connectivity provider).

 

Introduzione

L’industria delle telecomunicazioni ha goduto per un periodo lunghissimo di un formale e sostanziale monopolio che ha da un lato garantito uno sviluppo tecnologico robusto e condiviso, ma dall’altro non ha permesso agli operatori di sperimentare nuovi modelli di business poiché non necessario.
L’industry controllava l’e2e del mercato e della tecnologia: i costruttori dei terminali erano i medesimi delle infrastrutture di rete e insieme agli operatori lavoravano alla definizione degli standard da applicare. Un industry auto-referenziante.
Il primo snodo è avvenuto con la comparsa di Apple che si è presentata nel mercato dei terminali mobili senza seguire le impostazioni né le tecnologie che l’industry telco stava utilizzando. Nessuno credeva che Apple ce l’avrebbe fatta e invece impostando un nuovo modello di Business, aprendolo agli sviluppatori Apple ha disegnato la strada alle Platform Company subito seguita da Google.
L’industry telco ha faticato ad adattarsi al cambiamento ancorata alla sua comfort zone, che però non era più allineata al cambiamento di mercato: ha provato varie iniziative soprattutto nel mondo dei contenuti, ma sempre con un atteggiamento protezionista e poco orientato all’apertura.
Non bisogna poi dimenticare un fattore determinante per la fatica che gli operatori hanno fatto e stanno facendo rispetto al successo degli OTT. I servizi forniti da un operatore sono localmente Universali ma Regionali ad un livello globale. Persino l’operatore maggiormente “globale” non riesce a operare su scala mondiale. D’altro lato, un qualsiasi OTT può sfruttare la reale raggiungibilità universale di Internet: l’ipotetica azienda www.company.com può essere raggiunta quasi universalmente e i suoi servizi usati da qualsiasi parte del mondo. Un qualsiasi OTT ha nativamente il mondo come mercato potenziale, e non esiste un equivalente tra gli operatori.
In questo articolo analizzeremo il percorso che sta portando gli operatori verso il modello TSP (Two-Sided Platform) e TIM verso una Platform Company attraverso la consapevolezza strategica che sia necessario superare il modello Service Provider verso un modello più moderno di “abilitatore” qualificante e qualificato di shared business sia verso il mondo OTT sia dei Service e Content Provider a partire dagli asset tecnologici di cui dispone.

 

L’apertura della rete tramite Network API

Le API (Application Programming Interface, in italiano Interfaccia di Programmazione di un'Applicazione) sono da tempo note agli sviluppatori come una modalità di interazione tra componenti software, ossia uno strumento tecnico attraverso il quale semplificare e risolvere il problema dell’interoperabilità tra moduli o piattaforme.
Le Network API (o NetAPI, [1]), ovvero API che descrivono funzionalità di rete erogate da una infrastruttura di un operatore Telco, sono nate a fine degli anni ’90 nell’ambito dell’iniziativa Parlay, un consorzio guidato da BT. L’obiettivo iniziale di Parlay era la definizione di meccanismi ed interfacce per “aprire” la Rete Intelligente dell’operatore verso applicazioni di provider esterni, al fine di soddisfare una richiesta elaborata dall’authority britannica per le telecomunicazioni. Si trattava quindi di una imposizione proveniente dall’authority per permettere l’ingresso nella catena del valore di nuovi attori, tramite una “API-zazione” di scenari di apertura del call control: tali nuovi attori erano comunque omogenei al sistema “telco”.
Seguendo l’evoluzione tecnologica delle API, dalla metà degli anni 2000 nell’ambito di lavoro congiunto tra 3GPP e Parlay sono state standardizzate le API OSA (Open Service Architecture) Parlay X Web Services, attività poi confluita nel 2008 in OMA (Open Mobile Alliance).
Il sistema telco tradizionalmente e inizialmente chiuso ha dovuto aprirsi a partire da stimoli regolatori, ma senza molta convinzione, l’apertura della rete intelligente infatti non si è mai veramente concretizzata, ma è rimasto un timido e scettico tentativo.

 

Il Web 2.0 ed il mercato bilaterale degli OTT

L’espressione “Web 2.0” apparve per la prima volta nel giugno 2004 come titolo di una conferenza organizzata da O’Reilly Media, editore statunitense di libri sulle tecnologie informatiche. Il numero 2.0 – aggiunto come fosse la seconda versione, aggiornata e migliorata, di un software – fu introdotto per indicare la “nuova onda” del Web, non più baricentrata sul browser, ma basata su un insieme più ampio di applicazioni software, che “rende possibile una nuova generazione di servizi e opportunità di business”.
L’espressione Web 2.0 fa riferimento a comunità e servizi basati sul Web, ospitati in remoto e percepiti come di seconda generazione, che mirano a facilitare la collaborazione e condivisione fra utenti. Anche se il termine suggerisce una nuova versione del World Wide Web, non si riferisce a un aggiornamento di specifiche tecniche, ma a cambiamenti nel modo in cui gli sviluppatori di software e gli utenti finali usano il Web come piattaforma.
Pensare il Web in questi termini vuol dire che, nel passaggio dal Web 1.0 al 2.0, gli sviluppatori progettano e gli utenti usano tecnologie web per compiti e funzioni che prima si basavano su altre piattaforme, il che comporta per gli utenti accedere sempre più spesso a software e dati che stanno in rete, mentre prima risiedevano sul proprio laptop o comunque su server presenti nella propria azienda. È la differenza che c’è fra un servizio di posta elettronica che scarica le mail sul Pc e uno che permette di archiviarle e gestirle via web sul server del fornitore di servizio: nel secondo caso siamo già nel Web 2.0, perché usiamo la rete per archiviare, organizzare e gestire i dati.
Nel giugno del 2007, un comunicato ufficiale di Apple ([2]) recitava:

 

Il Web 2.0 era appunto un approccio tipico del mondo web che in quel momento era nettamente separato dal mondo telco, due mondi separati e paralleli; il mondo web era visto come il luogo dei servizi best effort, senza qualità garantita, servizi che gli utenti finali (questo era il pensiero degli operatori) non avrebbero mai considerato seriamente. L’annuncio di Apple quindi non ha inizialmente preoccupato. Ma da quell’annuncio emerge una novità che avrebbe cambiato le carte in tavola: Apple si propone come intermediaria in un cosiddetto “mercato a due versanti” o “mercato bilaterale” (two-sided markets).
I mercati a due versanti sono mercati caratterizzati dalla presenza di una piattaforma (chiamata piattaforma bilaterale o TSP two-sided platform), gestita da un mediatore, che svolge la funzione di luogo di incontro o collegamento sia fisico sia virtuale fra due gruppi di utilizzatori distinti ma interdipendenti (ciascuno appartenente ad un versante) e consente loro di realizzare delle transazioni o, più in generale, delle interazioni, minimizzandone i costi e traendone mutuo beneficio. In sintesi, il mediatore vende due prodotti differenti ai due gruppi di utilizzatori, dipendendo la domanda di un gruppo dalla domanda dell’altro e, possibilmente, viceversa. L’interdipendenza tra i diversi gruppi di utilizzatori crea network effects (o “positive feedback loop” come li chiama Bill Gates [nota 2] in [4]), per i quali il valore della piattaforma per un gruppo aumenta con il numero di utilizzatori sull’altro versante.
Il modello two-sided markets era già conosciuto e applicato in alcuni contesti tradizionali già prima dell’avvento del Web 2.0: pensiamo ad esempio alle carte di credito (dove si sommano gli interessi delle banche a quelli dei titolari delle carte di credito), o delle Pagine Gialle (inserzionisti e fruitori).
La TSP per il contesto Web 2.0 rappresenta quindi un abilitatore tecnologico in cui due gruppi di soggetti si scambiano direttamente prodotti, informazioni e/o contenuti traendone un mutuo beneficio recato agli utenti nel primo ambito influisce sulla relativa disponibilità di questi a pagare - derivante dalla partecipazione al sistema da parte dell’altro gruppo di utenti, nell’altro lato.
Social network e motori di ricerca sono due esempi di applicazione dell’approccio Two-Sided Markets nell’ambiente Web 2.0. Nel caso delle Social network, uno dei due gruppi di utilizzatori è rappresentato dagli utenti, i quali vogliono entrare in contatto con altri utenti, non vogliono entrare in contatto con gli inserzionisti, se non in casi speciali di “supporto” a marchi graditi (per gli inserzionisti è comunque un valore avere accesso ad una larga base di utenti). Nel caso dei motori di ricerca, gli inserzionisti preferiscono piattaforme con un maggior numero di contatti, ma anche gli utenti ricercano attivamente gli inserzionisti che offrono i prodotti oggetto della ricerca o comunque di interesse per l’utente.
L’applicazione di una TSP alle piattaforme OTT, pur sembrando quasi banale, in realtà è assolutamente disruptive, poiché sconvolge il concetto di offerta: non si tratta infatti di offrire un singolo prodotto, ma di una piattaforma che si caratterizzerà sempre per una velocità d'innovazione incredibilmente superiore al singolo prodotto. Il singolo prodotto è destinato a soccombere rispetto ad una TSP efficiente, come successo a Blackberry (il miglior prodotto di mobile mailing sul mercato) rispetto ad applicazioni mobili create su TSP come iOS e Android.

 

Il “modello” OTT

Gli OTT (Apple in testa) hanno dimostrato quindi come il modello di business two-sided funzionava (e anche molto bene) nel contesto Web 2.0, adiacente a quello telco tradizionale. Queste due industry hanno avuto poi punti di contatto, fino a diventare una sorta di contaminazione tra di essi; i cosiddetti OTT sono entrati prepotentemente nel business degli operatori, non c’era più una separazione netta dei servizi (cosa è OTT e cosa no), perché alla fine gli OTT hanno dimostrato di essere in grado di dominare il mercato in cui servizi, applicazioni e contenuti sono forniti su reti IP. Questa contaminazione ha stimolato alcuni tentativi di imitazione da parte degli operatori delle dinamiche del mondo Web 2.0: gli operatori hanno imitato (e non intercettato e fatto proprio) il modello di business Web 2.0 che però non ha funzionato. All’inizio degli anni 2000 c’è stata una wave verso l’“apertura” della rete: alcuni operatori ci hanno provato perché obbligati, altri si son detti interessati (con annunci di roadmap che di anno in anno venivano rimandati), molti operatori hanno creato delle iniziative di developer program anche su base internazionale (es. GSMA One API), ma in realtà evidenziavano uno scetticismo basato sul modo tradizionale di pensare fino a quel momento ossia “sono un Service Provider e ogni iniziativa deve essere coerente con questo mio modello”. In questa fase molti operatori hanno iniziato ad utilizzare per il Service Layer l’approccio SOA (Service Oriented Architecture), "un paradigma per l'organizzazione e l'utilizzo di funzionalità distribuite, che possono essere sotto il controllo di diversi domini amministrativi", utilizzato per la progettazione di sistemi software. I tentativi di apertura delle reti e l’applicazione dell’approccio SOA possono essere definiti come la “prima generazione” dell’evoluzione degli operatori.
La “seconda generazione” si colloca all’inizio degli anni 2010, e si focalizza sul tema del decommissioning (ossia la dismissione delle tecnologie legacy), cui si affiancano quelli della razionalizzazione e della semplificazione delle reti (riduzione dei livelli di rete – delayering, riduzione degli apparati di rete - deboxing), si è posto all’attenzione delle telco in tutto il mondo, soprattutto degli ex monopolisti, chiamati a razionalizzare e semplificare le reti per investire al meglio in reti e servizi innovativi. Le Telco si son trovate pertanto obbligate da strategie di efficienza ad ammodernare le loro reti, sia per ridurre in maniera drastica i costi operativi sia per stare al passo coi tempi e rendere più competitiva la loro offerta di servizi.
Nel frattempo gli OTT hanno dominato il mercato dei servizi all’utente finale, e questo è successo non solo grazie al modello two-sided platform, ma anche e soprattutto perché OTT hanno continuato nel far evolvere le loro piattaforme, adottando tecnologie Agile [nota 3] di sviluppo, spingendosi fino a DevOps.
Con il termine DevOps (dalla fusione delle parole “development” e “operations”, [1]) si intende una metodologia di lavoro che punta alla comunicazione, collaborazione e integrazione tra sviluppatori e addetti alle operations, in cui tutti condividono rischi e benefici di un processo di innovazione rapido. In questo modo il flusso di lavoro pianificato è ad elevato tasso di deployment, e si ha un controllo e una visibilità maggiori sullo stato di avanzamento delle applicazioni nella pipeline di rilascio. La prima esigenza da cui trae origine il successo di questa metodologia è la necessità di ridurre il time-to-market nel processo di produzione e messa in esercizio del software, ossia il tempo che intercorre tra l’idea di business e la soluzione in produzione, tenendo conto che tradizionalmente la separazione tra l’area dello sviluppo e quella del deployment creava numerose inefficienze. Il secondo aspetto è poi la necessità di incrementare l’affidabilità e stabilità degli ambienti di produzione e la qualità del software. Con questo approccio, gli OTT son riusciti a ridurre il time-to-market nel processo di produzione e messa in esercizio del software, ossia il tempo che intercorre tra una richiesta del business e la soluzione in produzione, e allo stesso tempo incrementando l’affidabilità e stabilità degli ambienti di produzione e la qualità del software. DevOps è in qualche modo legato alla metodologia di Agile, molto diffusa in ambito sviluppo che ha portato a interazioni più frequenti e a rilasci intermedi del software in modo da ottenere un migliore e più rapido allineamento con le richieste del business. Con DevOps si avvicinano gli sviluppatori alle operations, con obiettivi di maggiore collaborazione e condivisione dei risultati finali, ottenendo quindi anche una riduzione del time-to-market. DevOps prevede l’automatizzazione di processi, tipicamente legati alla messa in produzione del software, che tradizionalmente erano manuali; gli sviluppatori hanno possibilità di verificare più rapidamente il funzionamento in ambienti di produzione creati su misura, codificati e riproducibili. Considerando la catena delle attività che partono dai bisogni dei clienti e terminano con il rilascio di nuovi prodotti/servizi, DevOps si posiziona al centro e non solo coinvolge sviluppo e operations, ma finisce indirettamente per influenzare l’intera organizzazione (come cambiamento culturale), che in ultima analisi diventa molto più rapida nella risposta alla domanda del mercato.

 

Figura 1 - Il ciclo della metodologia DevOps

La nascita di DevOps viene fatta risalire al 2009, quando Patrick Debois, programmatore e manager, presenta per la prima volta il concetto alla conferenza Agile di Toronto. Da allora i contributi, le idee, le collaborazioni in questo ambito sono costantemente cresciute, fino a portare a un vero e proprio “movimento DevOps”. I "DevOps Days", iniziati nel 2009 in Belgio, si sono quindi diffusi in ogni parte del mondo, in India, USA, Brasile, Australia, Europa e anche in Italia.
I maggiori OTT (ad esempio Flickr, Spotify, Netflix, Facebook) sono state le aziende che hanno tratto maggiori benefici da un orientamento DevOps: avevano come condizione imperativa per la stessa sopravvivenza in mercati a fortissima crescita la necessità di rilasci molto frequenti del software. La disponibilità di servizi Platform as a service in Cloud, che hanno realizzato un’automazione che riduce i tempi di messa in produzione del software, insieme a ulteriori contributi metodologici, come Lean IT, la filosofia del Continuous Integration & Release, Agile Infrastructure Thread, Infrastructure-as-a-code, sono stati tutti fattori che hanno portato all’affermazione di DevOps presso gli OTT.
Ecco che arriviamo quindi alla “terza generazione”, quella attuale e che guarda al prossimo futuro: vediamo in cosa consiste. Nel mondo telco, dal punto di vista dell’evoluzione tecnologica, assistiamo al fenomeno della “softwarizzazione delle reti”: tecnologicamente anche gli operatori si sono spostati verso il Full IP, e con la softwarizzazione sempre più spinta, anche la rete e i suoi sistemi diventano un software applicativo (ad esempio un nodo GGSN, il sistema di billing, la piattaforma per la gestione delle identità, tutto diventa un applicativo software tanto quando un Web Server). Questo sta portando gli operatori a modificare il modo con cui considerano e progettano i propri sistemi, da un approccio telco a un approccio informatico.
La “softwarizzazione della rete” permette quindi di applicare anche in tutto il contesto telco inclusi i sistemi di rete le tecniche e le metodologie adottate dagli OTT: tecniche DevOps, di Lean IT, del Continuous Integration & Release. Il mondo telco si sta quindi tecnologicamente trasformando (o meglio … ha le potenzialità per farlo), prendendo a modello quello OTT, consentendo anche agli operatori di abbattere i costi e i tempi di sviluppo del software, aumentandone la qualità e la soddisfazione dei clienti.
Ma come in occasione della seconda generazione un allineamento tecnologico non sarà sufficiente: serve un cambiamento anche sulla strategia e sul modello di business per rendere credibile ed efficace la trasformazione.

 

I fattori abilitanti per diventare Platform Company

Ecco quindi che troviamo nella terza generazione tutti i fattori abilitanti per gli operatori per diventare della Platform Company, ossia per istanziare con successo il modello Two-Sided Platform nel mondo telco.
Orientarsi al concetto di “piattaforma” richiede flessibilità, interattività, rapidità, qualità nell’offerta di funzionalità/servizi al mondo dei partner e sviluppatori in modo da seguire adeguatamente le evoluzioni del mercato e le sue dinamiche.
Il primo fattore abilitante è l’Exposure layer, ossia l’esposizione di funzionalità tramite API verso (possiamo dire adesso) gli utilizzatori della piattaforma. Questo livello deve essere un framework per garantire un intermediazione verso tutte le funzionalità Network e IT, deve permettere la realizzazione di modelli di vendita flessibili integrandosi agevolmente con le catene commerciali siano esse Consumer che Business. Il modello di offerta deve essere il più possibile self-service, con procedure di registrazione utenze e di accounting automatiche (self-provisioning) nonché la possibilità di realizzare bundle di offerta API e di fornire all’utente dashboard e console per monitorare l’utilizzo delle stesse.
La “piattaforma” deve essere flessibile nell’abilitare vari modelli di business nell’offerta di API agli utilizzatori della piattaforma (Content Service Provider, Partner/Reseller, MVNO, cliente Business, soggetto Wholesale, OTT), ossia deve abilitare vari modelli di relazione commerciale come ad esempio:

  • ŸModello B2B: l’utilizzatore delle API realizza servizi per i propri clienti utilizzando le risorse dell’operatore;
  • ŸModello B2B2C: l’utilizzatore delle API offre un servizio/contenuto al cliente dell’operatore;
  • ŸModello B2B2B (intermediazione con aggregatore): un soggetto aggregatore raccoglie ed uniforma le API (ed i relativi processi) di più operatori, offrendoli ad utilizzatori esterni che realizzano i servizi;

e nel contempo supportare molteplici modelli di gestione del flusso economico come ad esempio:

  • ŸModello Pay per Use: l’utilizzatore delle API remunera l’operatore per l’uso delle risorse “consumate” (es. su base volume, con o senza canone base);
  • ŸModello Revenue Sharing: l’utilizzatore delle API addebita il servizio offerto sul conto del cliente dell’operatore e l’operatore riconosce una percentuale delle revenue all’utilizzatore delle API, oppure dualmente l’utilizzatore delle API addebita il servizio offerto sul conto del proprio cliente e riconosce una percentuale delle revenue all’operatore;
  • ŸModello Flat/Freemium: consente l’utilizzo di API ad un ecosistema omogeneo di utilizzatori, di medio/piccole dimensioni, su base canone, con limitazioni di utilizzo sui volumi;

lasciando libertà a chi utilizza la “piattaforma” di disegnare in autonomia il modello di business migliore supportandone la massima flessibilità.
Il secondo fattore abilitante è la Network Automation. Le prestazioni di rete devono essere disponibili e configurabili in modo flessibile e automatico. La NA automatizza l'intero ciclo di vita operativo dei dispositivi di rete dal provisioning alla gestione delle modifiche basata su policy, fino alla gestione di protezione e conformità. Abbinandola a una versione evoluta degli OSS, si ottiene una soluzione integrata che unifica disponibilità, prestazioni e fault tolerance della rete, con modifiche, configurazione, conformità e diagnostica automatizza.

 

Figura 2 - Ecosistema di una Two-Sided Platform nel mondo telco

Il terzo fattore abilitante è il Telco Cloud. Telco Cloud prevede la creazione di un'infrastruttura virtualizzata comune per implementare e gestire diverse applicazioni di rete offerte da molteplici fornitori di rete. Ciascuna applicazione diventa un'applicazione virtuale che esegue una specifica funzione di rete, usando abilmente tutte le capability offerte dal Cloud Computing in termini di elasticità, elevata disponibilità e gestibilità. L'evoluzione delle tradizionali applicazioni di rete, inoltre, incoraggia la concorrenza tra i fornitori di Telco e consente l’ingresso di nuovi operatori nel mercato delle telecomunicazioni. L'infrastruttura comune di base può essere realizzata con strumenti di un datacenter COTS (Commercial off-the-shelf), in modo da ottenere vantaggi sugli investimenti iniziali di capitale e sui costi operativi dell'infrastruttura.
Il quarto fattore abilitante è il BSS evoluto ossia la profilatura e la conoscenza dei clienti che sia sempre meno telco e sempre più digitale: superare le barriere dei BSS legati alle tecnologie di accesso fisse o mobili, creare una profilatura unica del cliente sfruttando il cosiddetto “network effect” ossia la conoscenza molto profonda che deriva dall’uso che i clienti fanno dei servizi e della rete degli operatori, nonché procedure sempre più flessibili per l’accounting e il billing.
Il quinto fattore abilitante sono i Big Data. Gli operatori producono una enorme quantità di dati relativamente alla rete e agli utenti, e questa mole di dati può offrire valore aggiunto se la si valorizza e analizza in modo da sfruttarne tutto il potenziale.
Il tutto con metodologie Agile e spingendo verso il DevOps come introdotto in precedenza.
Ma quali sono gli asset che gli operatori possono sfruttare per creare l’ecosistema TSP? Quali sono gli elementi caratterizzanti che permetteranno una monetizzazione e quindi la creazione di un nuovo modello di business?
Il primo è sicuramente la connettività. I contenuti e in particolare il servizio video generano già oggi circa il 70% dei volumi dati che le reti dei Telco trasportano, e la loro incidenza è destinata ad aumentare in modo evidente nei prossimi anni. La fruizione dei contenuti avviene in modo sempre più convergente e trasparente sulle diverse tecnologie di rete fissa e mobile e su diverse tipologie di terminali, il tutto uniformato dal protocollo IP. Ai tradizionali Content Providers (es. broadcaster televisivi) si sono affiancati nuovi soggetti OTT dedicati alla distribuzione sia di contenuti premium che autoprodotti, alimentati dal modello “social”; i contenuti premium inoltre proseguono nel rincorrere qualità sempre maggiore, con il prossimo passaggio dal full HD al 4K. La sfida per gli operatori è quindi quella di monetizzare il delivery dei contenuti all’utente finale, garantendo QoE (Quality of Experience), offrendo ai Content Provider un framework di API che permetta in modalità self-service di effettuare provisioning, billing, autenticazione e anche business intelligence.
Un altro asset particolare che gli operatori possono monetizzare sono le “informazioni” sulla rete e sui clienti. Ad esempio, gli operatori hanno accesso a dati di micro-segmentazione degli utenti-consumatori e a informazioni sull'uso di applicazioni e siti web per dispositivi mobili. Inoltre, hanno il vantaggio di possedere set di dati specifici per l'industria delle telecomunicazioni mobili, come ad esempio dati di localizzazione (dove si trovano gli utenti sul territorio). Gli operatori possiedono molte opportunità per utilizzare questi set di dati unici, sia verso l'interno sia verso l'esterno dell'azienda. Internamente, questi dati possono essere utilizzati per applicazioni di gestione della rete, servizio consumatori e marketing (una forma di monetizzazione indiretta). D’altro canto, gli operatori possono vendere all’esterno dei dati degli utenti (che hanno espresso consenso esplicito), come ad esempio il profilo rispetto a determinati parametri (preferenze), oppure dati aggregati e anonimizzati o pseudo-anonimizzati (es. distribuzione della popolazione sul territorio) verso settori contigui, come la pubblicità, il marketing, i servizi finanziari, la pubblica amministrazione, il settore della mobilità sul territorio.

 

Il ”modello” TIM EasyAPI Framework

La competizione tra operatori e l’erosione delle revenue dovute all’affermarsi degli OTT non lascia tregua, ed è per questo che in Azienda si è iniziato a pensare al TIM Market Place, per facilitare l’on-boarding di Content Service Provider del mercato Multimedia in maniera industriale, efficace, rapida, snella, con meccanismi “alla Amazon”, mentre prima l’on-boarding avveniva con progetti e soluzioni verticali. Per indirizzare questo requisito, il progetto TIM Market Place (avviato nel luglio 2015) ha iniziato lo sviluppo di una infrastruttura abilitante la configurazione e la fornitura di servizi attraverso le Network API.
Il TIM Market Place può considerarsi una piattaforma “two-sided” verso i Content Service Provider del mercato Multimedia da un lato e verso gli utenti “consumer” dall’altro [nota 4].

 

Figura 3 - L’ecosistema del Tim EasyAPI Framework

L’infrastruttura di cui il TIM Market Place è un’istanza è il cosiddetto “Tim EasyAPI Framework” ([6]). Il Tim EasyAPI Framework permette di disaccoppiare la logica delle API Platform dalla modalità di esposizione (separando quindi il back-end dal front-end di esposizione), uniformando le interfacce dal punto di vista tecnico con una erogazione uniforme (REST), con un unico meccanismo di autenticazione (basato su uso di token). In aggiunta alla parte run-time, Tim EasyAPI Framework prevede un catalogo usufruibile online dagli sviluppatori esterni ma usufruibile anche internamente (es. dal dipartimento marketing). Nel catalogo si possono trovare i dettagli tecnici delle API, ma anche esempi di utilizzo (approccio «ready to use»). Un ulteriore aspetto rilevante abilitato da Tim EasyAPI Framework è una rendicontazione omogenea dell’utilizzo delle API: vengono creati degli «event data record» che sono uniformati qualsiasi API del Tim EasyAPI Framework venga utilizzata, e che possono essere forniti ai sistemi di billing, minimizzando quindi gli impatti su questi ultimi. Il catalogo, oltre alla parte documentale, ha anche una funzionalità di “self provisioning”, attraverso la quale lo sviluppatore, una volta registratosi nel portale, può accreditarsi ed accedere al Tim EasyAPI Framework in maniera pressoché istantanea.

 

Figura 4 - Raffronto tra evoluzioni del mondo telco, degli OTT e di TIM

Verso la trasformazione in Platform Company

Vediamo adesso qual è il percorso che porterà TIM a diventare una Platform Company, ossia una company che si propone come una piattaforma abilitante verso i due gruppi di utilizzatori del two-sided market ICT (gli sviluppatori delle terze parti e gli utenti finali).
Il Tim EasyAPI Framework è il Framework architetturale di riferimento (“standard”) per governare l’approccio “one platform” in un contesto di sviluppo cooperativo cross-funzionale.
Il Tim EasyAPI Framework è già nativamente un sistema multi-tenant: questo abilita flessibilità nel segregare istanze dedicate ai diversi modelli di business e canali commerciali, come già succede nel caso del TIM Market Place (si veda Figura 5).

 

Figura 5 - Il Tim EasyAPI Framework come elemento chiave per la trasformazione di TIM in una Platform Company

Tim EasyAPI Framework abilita il disaccoppiamento tra infrastruttura e servizi, passando da silos verticali a un’architettura aperta, unificata e orizzontale, in cui la «one platform» abilita la massima varietà di applicazioni, basate su una base comune di risorse (es. connettività, computing), componenti/servizi (es. autenticazione) ed analytics, e ciò vale sia per applicazioni “TIM-branded” sia per applicazioni erogate da terzi “TIM-enabled only”.
Le risorse con cui il Tim EasyAPI Framework può integrarsi per diventare risorse della “one platform” non sono solo risorse “core” (es. di rete e di home/office), ma anche risorse esterne alla rete application specific (es. parcheggio, sensori di ambiente) per estendere l’orizzontalità della platform.
Infine l’ultimo abilitatore tecnologico per massimizzare la leva del network-effect della «one platform» è la capacità di analytics evoluti, sia sui singoli componenti/contesti/servizi sia cross application/domain, in particolare le correlazioni nascoste e non note a priori (Cross Analytics).

 

Conclusioni

La competizione e le dinamiche di mercato stanno portando anche l’industry telco a ragionare sul modello di core business: il modello Service provider sembra non essere più l’elemento fondante le prospettive di business nel medio periodo. Dopo vari tentativi di imitazione che probabilmente sono stati più un esercizio tecnologico che una scelta strategica sembra essere matura la consapevolezza che serve a svoltare anche strategicamente verso la cosiddetta “two-sided platform” e orientare l’azienda a diventare un abilitatore e facilitatore della relazione di business tra gli sviluppatori e i clienti finali.
Gli OTT ed il Web 2.0 hanno dimostrato che un modello in cui una company crea un ambiente per mettere a disposizione di terzi le proprie infrastrutture è un modello che funziona. Gli operatori hanno asset che sono esclusivi e che possono attrarre partner e sviluppatori. La softwarizzazione delle reti e lo spostamento tecnologico del mondo telco verso l’informatica rende i sistemi e le piattaforme di rete molto più flessibili. L’API-zazione, ossia l’esposizione di funzionalità legate agli asset e ai dati attraverso un framework orientato alle API, rende più semplice e self-service l’accesso alle funzionalità e agli asset. L’applicazione di metodologie di Agile Software Development permette di garantire la rispondenza dei prodotti rispetto alle aspettative di mercato aumentandone la qualità. La Network Automation permette di ridurre il time-to-market nell’erogazione di servizi di rete. Infine i modelli BSS evoluti con al centro il cliente e il suo profilo a prescindere dalle reti o dai servizi che utilizza permettono una conoscenza del cliente che è determinante per fornire capacità di business intelligence evoluta.
Si delinea quindi la Platform Company come modello di business per l’operatore per il prossimo futuro: non più solo la fornitura di servizi all’utente finale, ma l’operatore come fornitore di una piattaforma aperta e flessibile con funzionalità specifiche per abilitare terzi allo sviluppo di servizi B2B e B2B2C siano essi aziende o sviluppatori.
TIM è stata tra i primi operatori ad “aprire” la rete attraverso l’utilizzo di Network API, prima con il Service Exposure ed oggi con la sua prima evoluzione TIM Market Place orientata al mercato Consumer e quelle successive atte ad incorporare anche il segmento Business, si pone in posizione vantaggiosa rispetto all’adozione del modello di business Platform Company.

 

Note

  1. Con il termine Over-The-Top (in acronimo OTT) si intendono le imprese che forniscono, attraverso la rete Internet, servizi, contenuti (soprattutto video) e applicazioni di tipo "rich media" (per esempio, le pubblicità che appaiono “sopra” la pagina di un sito web mentre lo si visita e che dopo una durata prefissata scompaiono). Esse traggono ricavo, in prevalenza, dalla vendita di contenuti e servizi agli utenti finali (ad esempio nel caso di Apple e del suo iTunes) o di spazi pubblicitari, come nel caso di Google e Facebook. Tali imprese, prive di una propria infrastruttura, agiscono al di sopra delle reti degli operatori di telecomunicazioni, da cui il termine over-the-top.
  2. As more products became available and more information could be exchanged, more consumers would be attracted to the platform, which would in turn attract more investment in product development for the platform. Economists call this a “network effect,” but at the time we called it the “positive feedback loop”.
  3. Nell'ingegneria del software, l'espressione “metodologia agile” si riferisce a un insieme di metodi di sviluppo del software emersi a partire dai primi anni 2000 e fondati su insieme di principi comuni, direttamente o indirettamente derivati dai princìpi del "Manifesto per lo sviluppo agile del software" (Manifesto for Agile Software Development) pubblicato nel 2001 da Kent Beck, Robert C. Martin, Martin Fowler e altri. I metodi agili si contrappongono al modello a cascata (waterfall) e altri processi software tradizionali, proponendo un approccio meno strutturato e focalizzato sull'obiettivo di consegnare al cliente, in tempi brevi e frequentemente (early delivery/frequent delivery), software funzionante e di qualità.
  4. Con utenti “consumer” si intendono sia utenti TIM sia utenti non TIM, poiché il TIM Market Place abilita la fruizione dei servizi sia agli utenti TIM, ma anche ad utenti “prospect” ovvero utenti generici dotati di un indirizzo email e che potrebbero non essere utenti TIM. Il valore in questo caso è per i fornitori di contenuti il raggiungimento di una customer base e per gli utenti consumer la possibilità di fruire contenuti.
 

Bibliografia

  1. “Oltre le NetAPI”, Mario Bonnet e Pier Carlo Paltro, Telecom Italia Notiziario Tecnico n° 2 del 2014
    http://www.telecomitalia.com/tit/it/notiziariotecnico/numeri/2014-2/capitolo-08.html
  2. Manifesto per lo Sviluppo Agile di Software,
    http://agilemanifesto.org/iso/it/
  3. “iPhone supporterà gli applicativi Web 2.0 terze parti”, comunicato Apple del 11/06/2007,
    http://www.apple.com/it/pr/library/2007/06/11iPhone-to-Support-Third-Party-Web-2-0-Applications.html
  4. Civil Action No. 98-1233 (CKK), paragrafo 25, DIRECT TESTIMONY OF BILL GATES, http://www.politechbot.com/docs/gates.testimony.042202.pdf
  5. “DevOps Top Trends 2015: Dalla Teoria alla Pratica”,
    http://www.theinnovationgroup.it/wp-content/uploads/2014/12/DevOps-Top-Trends-2015_Dalla-Teoria-alla-Pratica.pdf
  6. “Telco 2.0: da Service Exposure a Service Prosumer”, Alberto Baravaglio e Gianni Canal, NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 1 - Aprile 2008,
    http://www.telecomitalia.com/content/dam/telecomitalia/it/archivio/documenti/Innovazione/NotiziarioTecnico/2008/fd_numero01/p_59_68.pdf
  7. “Easy API: strumento per la monetizzazione degli asset di Telecom Italia”, Francesco Ludovico, Telecom Italia Notiziario Tecnico n° 2 del 2015,
    http://www.telecomitalia.com/tit/it/notiziariotecnico/edizioni-2015/2015-2/capitolo-9/approfondimenti-2.html
 

comments powered by Disqus