Oltre le NetAPI

La maturità dei servizi Web, l’adozione del VoIP nelle reti di telecomunicazioni, la crescita di dispositivi mobili intelligenti costantemente connessi a reti 3G/4G/LTE o WiFI e la proliferazione del cloud computing continuano a cambiare il modo con cui i servizi vengono realizzati ed offerti, accelerando ulteriormente la convergenza tra il mondo Telco ed il mondo IT. In questo articolo si analizza come l’utilizzo dei modelli di Network/Cloud API da parte dall’Operatore sia il veicolo per lo sviluppo di relazioni di cooperazione con i mondi “digitali” contigui al mondo Telco e per l’innovazione continua dei servizi, evidenziando il percorso evolutivo intrapreso da Telecom Italia in questi ambiti.

 

1 - Introduzione

Nella seconda metà degli anni 2000 l’adozione dei principi della SOA e la virtualizzazione hanno contribuito alla trasformazione delle applicazioni: da “monolitiche e residenti su sistemi verticali” a “servizi orizzontali, su infrastrutture general purpose”.

L’avvento del cloud rende, oggi, i servizi applicativi sempre più distribuiti e nativamente fruibili da una molteplicità di dispositivi, per composizione e consumo, oltre i confini di una azienda.
In questo scenario di trasformazione la sfida per gli operatori di Telecomunicazioni è, sul fronte dei servizi, legata all’evoluzione verso un modello di “Digital Service Telco” che deve necessariamente combinare:

  • il consolidamento e l’ottimizzazione dei processi interni;
  • l’adozione di modelli infrastrutturali scalabili e flessibili basati sull’allocazione dinamica delle risorse;
  • il supporto di nuovi modelli di creazione servizi, tramite l’adozione di paradigmi di sviluppo “agile”, che consentano una realizzazione a basso costo di applicazioni, con una modalità “error & trial”, ed una loro “selezione naturale” in funzione del loro successo commerciale;
  • l’introduzione di nuovi servizi digitali, attraverso lo sviluppo di servizi innovativi “attigui” ai business Telco che combinano funzionalità “esterne/cloud” con prestazioni tipicamente Telco-based;
  • nuove forme di proposizione servizi ed offerte.

Per raggiungere questi obiettivi è richiesto un utilizzo intensivo dei modelli di Network/Cloud API da parte dall’Operatore.

 

2 - Il valore strategico e di business delle API

Le API (Application Programming Interface) sono da tempo note agli sviluppatori come una modalità di interazione tra componenti software; uno strumento tecnico attraverso il quale semplificare e risolvere il problema dell’interoperabilità tra moduli o piattaforme, realizzate da vendor o da organizzazioni diverse.
Dall’inizio degli anni 2000 le API sul Web hanno avuto una crescita esponenziale, sia in termini di numerosità delle interfacce esposte, che di varietà dell’ambito applicativo: servizi finanziari/di pagamento (Paypal), social media (Facebook, Twitter), BSS/CRM (IBM, Citrix, Salesforce), distribuzione di contenuti (Netflix), Telco-like (Twilio, Skype, Tropo), Cloud (Amazon AWS, Microsoft Azure, Rackspace), mapping (Google Maps). ProgrammableWeb [1], uno dei portali ed aggregatori più autorevoli di API exposure, ospita ad oggi (giugno 2014) oltre 11.000 API, 13 volte le API ospitate nel 2007.
Un indicatore che aiuta a comprendere il successo delle API come modello di servizio e come tecnologia abilitante è il traffico, ovvero il numero di chiamate che applicazioni, client, servizi e macchine effettuano verso le API. I dati riportati nella Tabella 1, riferiti al 2013, offrono una panoramica dei volumi medi di traffico gestito e servito da alcuni importanti API provider in un giorno.
L’evoluzione tecnologica delle API (v. Box API,WEB SERIVCE e REST), l’affermazione del Web come piattaforma di servizio, l’avvento del Cloud Computing, pubblico e privato, aprono nuove prospettive per la semplificazione dello sviluppo SW distribuito e per l’accesso alle risorse Telco ed IT.

 

Figura 1 - Evoluzione delle API

 

Tabella 1 - Volumi gestiti da API Provider sul Web - 2013 ([2], [3], [4], [5], [6])

 

2.1 - Valore Strategico delle API

Nelle aziende di medie e grandi dimensioni l’ideazione e la realizzazione di servizi ed applicazioni fruibili su diverse piattaforme (web, mobile, M2M, dispositivi connessi) si basa su processi interni che si articolano in fasi distinte: progettazione, sviluppo, collaudo, esercizio e manutenzione.
La competitività dei mercati richiede che queste fasi avvengano, oggi, con estrema rapidità e in una modalità incrementale. Si devono cioè indirizzare da un lato l’evoluzione continua dei prodotti, inseguendo rapidamente le esigenze dei clienti, dall’altro, la riduzione dei costi delle soluzioni sviluppate, consumando in modo “elastico” le risorse e riusando il più possibile funzionalità già sviluppate e stabilizzate in precedenza.
È proprio nell’ambito dell’efficacia e del riuso che le API giocano un ruolo fondamentale perché abilitano la creazione, all’interno delle aziende, di asset riusabili e facilmente accessibili, che possono rendere agile, efficiente e snello il ciclo di vita dei moderni prodotti e servizi.
In quest’ottica tutte le grandi aziende del settore ICT stanno seguendo un percorso evolutivo, riapplicando un trend che ha forti relazioni con quanto già accaduto in alcune delle maggiori realtà OTT che hanno ridisegnato se stesse.
In ambito OTT Amazon è ritenuto uno dei maggiori casi di successo per la sua evoluzione da portale di e-commerce a leader mondiale ed inventore del moderno public cloud. Questa trasformazione ha richiesto ad Amazon, nel 2004, di attuare un significativo cambiamento organizzativo interno ed una radicale trasformazione della stessa cultura aziendale.
In quel periodo venne infatti richiesto con forza a tutti i team dell’azienda di progettare ed utilizzare “service interfaces” come unico mezzo di comunicazione e scambio di informazioni e dati all’interno di Amazon. 

 

Figura 2 - Deployment di Amazon.com

 

Il modo di lavorare venne ridisegnato mettendo al centro l’automation dei processi attraverso le API e l’elasticità dei sistemi in modo da applicare un modello pay-per-use delle piattaforme informatiche interne. Successivamente, consolidato il modello interno, le stesse API vennero messe a disposizione del mondo esterno, dando il via al fenomeno del public cloud che conosciamo oggi.
In sintesi, nel caso di Amazon, questo risultato costò alcuni anni di transformation ma ebbe diversi risvolti di fondamentale importanza:

  • creò progressivamente, all’ interno dell’azienda, un catalogo di API il cui accesso avveniva attraverso processi automatizzati;
  • fu una opportunità di sviluppo di competenze e capacità nuove, che si diffusero come linee guida non solo all’interno dell’azienda ma anche verso fornitori e partners;
  • sviluppò un movimento nella comunità degli sviluppatori mondiali che fece nascere profonde innovazioni nel movimento Agile quale ad esempio il paradigma DevOps innovando le modalità di lavoro tra chi sviluppa e chi esercisce le soluzioni informatiche.

Per dare un’idea della potenza dell’approccio DevOps nel 2013 Amazon ha dichiarato di poter effettuare un rilascio SW per far evolvere o correggere le funzionalità dei propri sistemi di e-commerce ogni 12 secondi su un numero di host compreso tra un minimo di 10.000 e un massimo di 30.000, senza interruzioni del servizio verso gli utenti finali (si veda la Figura 2).
Questi risultati fanno comprendere come un’organizzazione moderna non possa più sottovalutare il valore strategico delle API per trasformare il suo business e rendere efficienti i processi interni.
I modelli sostenuti da Amazon sono senz’altro applicabili come principi guida nell’evoluzione dei processi interni degli Operatori verso un modello di “Digital Service Telco” e questi vedono le API come:

  •  strumento di governo ed automazione di infrastrutture, servizi, processi, tanto nel mondo rete che nel mondo IT, con una visione strategica di medio periodo che faccia evolvere l’organizzazione;
  • entità omogenee e catalogo unificato, con accesso semplice e “self service” alle funzionalità.
  • In questa logica l‘utilizzo delle API serve per promuovere uno sviluppo efficiente e rapido alla realizzazione di servizi mediante l’esposizione di funzionalità riusabili e facilmente accessibili.

In Telecom Italia, partendo da un contesto già molto ricco di servizi e funzionalità esposti attraverso API (più di 200 interfacce di funzionalità di rete ed IT disponibili in oltre 30 aree funzionali), sono in corso progetti che indirizzano l’Azienda verso un trend che renda sempre più organico e facile l’uso delle API per discovery, accesso, pubblicazione, sia per quanto riguarda l’evoluzione delle Network API (NetAPI), sia per quanto riguarda l’innovazione e la realizzazione di servizi applicativi.

 

3 - Business Model per Utilizzo Esterno

Le API rivestono un ruolo rilevante anche come vettore di integrazione tra l’ecosistema che le implementa ed i mondi esterni; dal punto di vista dell’operatore Telco costituiscono lo strumento con cui creare valore, con un approccio cooperativo, con le Terze Parti combinando l’intelligenza e le funzionalità Telco con servizi/contenuti esterni.
La catena del valore delle API offerte pubblicamente può assumere diverse forme, in funzione della tipologia delle API, di chi le utilizza (partner, content provider, sviluppatori) e del modello di business perseguito.
Nel mondo dei Telco Provider, tradizionalmente:

  • le API esposte verso le Terze Parti sono quelle caratteristiche di un operatore (si veda il paragrafo 3.1);
  • gli utilizzatori sono soprattutto soggetti con cui l’operatore ha relazioni di business contrattualizzate e formalizzate (partner, service provider, MVNO, fornitori di contenuti, SME);
  • le API offerte devono, in alcuni casi, essere conformi a vincoli regolatori o normativi;
  • sono anche utilizzate per l’innovazione dei servizi offerti ai propri clienti e per intercettare mercati contigui, quando parte del valore è all’esterno dell’operatore.

La Figura 3 rappresenta, senza pretese di esaustività, i principali business model tradizionali del mondo Telco relativi all’offerta di API da parte di un Telco Provider ad una Terza Parte (Content Service Provider, Partner/Reseller, MVNO, cliente Business, soggetto Wholesale, OTT):

  • B2B (Pay per Use); l’utilizzatore delle API (Terza Parte) realizza servizi per i propri clienti e remunera il Telco Provider per l’uso delle risorse “consumate” (su base volume, con o senza canone base, etc.);
  • B2B2C (Revenue Sharing); l’utilizzatore delle API (Terza Parte) offre un servizio/contenuto al cliente del Telco Provider, addebitando il servizio offerto sul conto del cliente. L’operatore riconosce una percentuale delle revenues alla Terza Parte;
  • Intermediazione con aggregatore (B2B2B); un soggetto aggregatore raccoglie ed uniforma le API (ed i relativi processi) di più Telco Provider, offrendoli alle Terze Parti che realizzano i servizi; l’aggregatore riconosce, poi, ad ogni singolo Telco Provider una certa percentuale, in base alla tipologia di contratto stipulata;
  • 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.
 

Figura 3 - Business Model tradizionali per offerta API da parte di Telco Provider

 

Rispetto a questi business model le API pubbliche offerte sul Web dagli OTT sono invece tipicamente utilizzate per creare nuovi ecosistemi e per supportare offerte digitali su Web Marketplace.
Sebbene sia complesso categorizzare tutte le modalità con cui le API vengono proposte dagli OTT sul Web, i seguenti modelli di creazione del valore sono i più comuni:

  • controllo della catena digitale del valore presidiata;
  • brand extension, crescita ed aumento del valore dell’ecosistema creato;
  • aumento della visibilità e della raggiungibilità dei propri servizi su piattaforme e device diversi;
  • innovazione tramite combinazione di servizi diversi.

La figura 4 riporta la classificazione dei business model delle API OTT, proposta da ProgrammableWeb, che si suddivide in quattro principali “filoni”:

  • Free: è il caso di Facebook che offre le proprie API gratuitamente ai developer per incrementare il proprio ecosistema;
  • Developer Pays: l’utilizzatore dell’API (developer) remunera l’OTT per l’utilizzo della funzionalità (pay per use, freemium ovvero gratuito con limitazioni, su base crediti, in base al valore della transazione generata, etc.);
  • Developer gets paid: il developer è ripagato, con una sorta di “revenue sharing” o pagamento diretto, in base al valore che lo sviluppatore genera per l’OTT tramite l’utilizzo delle API, nelle applicazioni che sviluppa (ad esempio advertising, sottoscrizioni/acquisti/visite indotte dall’applicazione, acquisizione di nuovi clienti, raggiungibilità di nuovi segmenti di mercato, etc.);
  • Indirect: l’utilizzo delle API è utilizzata come leva per facilitare l’upsell di una offerta (incremento livello di licensing), per acquisire ed aumentare il catalogo dei contenuti offerti dall’OTT, per aumentare il parco dei device che possono accedere ai servizi dell’OTT, etc. 
 

Figura 4 - API Business Model secondo ProgrammableWeb

 

Per una analisi più di dettaglio dei vari modelli si può fare riferimento a [7].
Tra le caratteristiche distintive di questi modelli è opportuno evidenziare:

  • l’arricchimento dei modelli basati sulla “willingness to pay” con meccanismi di awarding e lock-in su business innovativi;
  • l’apertura delle API anche a soggetti “digitali” di tipo developers, con un modello di tipo B2C;
  • la possibilità per gli utilizzatori di appartenere ad una community, di avere visibilità world-wide e di creare un proprio micro-business.

Sono sicuramente aspetti a cui un operatore Telco può fare riferimento per la creazione di propri Marketplace Digitali di API e per l’evoluzione delle modalità di esposizione, tenendo comunque in considerazione i relativi rischi, che devono essere opportunamente valutati e bilanciati:

  • possibile cannibalizzazione delle offerte tradizionali;
  • potenziali conflitti di ruolo tra partner tradizionali e “public developers”;
  • implicazioni normative o right infringements.
 

4 - API e Cloud Computing

Le API sono anche alla base del paradigma del cloud computing per il quale viene ormai considerato un riferimento worldwide la definizione data dal NIST [8] di cui la Figura 5 ne riassume le caratteristiche, i modelli di servizio e i modelli di deployment.
Non è oggetto di questo articolo approfondire l’intero schema, ma è importante evidenziare qui il fatto che le moderne cloud devono implementare le “essential behaviours” del modello attraverso un insieme di API attivabili direttamente dagli sviluppatori e dai team di operation. Allo stesso modo devono esistere API per controllare configurazione ed elasticità di tutte le risorse di computing offerte (ad es. nel caso di uno IaaS: computation, storage, networking, security).
Con questo approccio è possibile trasferire i vantaggi del cloud alle applicazioni ed ai servizi costruiti su di esso. 

 

Figura 5 - Le tre dimensioni delle API cloud nell’elaborazione di ProgrammableWeb: modelli di servizio, modelli di deployment e comportamenti essenziali

 

Dal punto di vista di chi sviluppa i servizi, i vantaggi dell’utilizzo del cloud sono sia di tipo tecnico-processivo sia di business:

  • non è più richiesto il dimensionamento up-front dell’infrastruttura, per lanciare un nuovo servizio. Si parte, cioè, con un configurazione minimale e sarà il servizio stesso a ridimensionarsi in modo automatico ed elastico sulla base del numero di utenti registrati. Si possono immaginare i riflessi di questo approccio sul business model dei nuovi servizi dove il dimensionamento iniziale, con il conseguente investimento, non sarà più un fattore critico;
  • gli ambienti di sviluppo, test ed esercizio vengono creati in modo automatico. Questo concetto è chiamato “CloudFormation”, cioè l’architettura fisica del servizio (ad es. computing, il network e lo storage) viene creata automaticamente scrivendo una “parte” di SW che, utilizzando le API della cloud, istanzia, connette e configura le risorse necessarie. Le implicazioni di questo approccio sono disruptive rispetto ai processi di service creation manuali tradizionali.

Facendo un passo ulteriore possiamo immaginare che lo stesso servizio, costruito con questi criteri, diventi esso stesso “erogatore” di API attraverso uno o più dei modelli descritti precedentemente in questo articolo. Appare evidente che una gestione delle API erogate da sistemi che sono essi stessi costruiti sulle API di una cloud moderna sia molto potente flessibile, e “ business effective”.
Un punto di attenzione importante è quindi il percorso di transizione verso queste soluzioni superando, per i nuovi servizi, l’infrastruttura del data center “virtualizzato” tradizionale e muovendosi, in prospettiva, verso quello “private/public cloud”.
Questa sfida è alla base dei principali trend di trasformazione delle infrastrutture e delle modalità di offerta servizi da parte di un operatore Telco, dove è importante citare:

  • Network Function Virtualization per la virtualizzazione e l’ottimizzazione delle infrastrutture di rete;
  • l’evoluzione dei data center IT e dell’offerta Nuvola Italiana verso una cloud completamente self-service e automatizzata;
  • le nuove modalità di erogazione servizi digitali; in quest’ambito Telecom Italia ha lanciato da alcuni mesi la start-up TIDS (Telecom Italia Digital Solution), che ha l’obiettivo di essere protagonista nella trasformazione digitale del business dei propri clienti, tramite offerte di tipo SaaS e IaaS (v. Box Percorso TIDS). 
 

5 - Oltre le NetAPI

Per perseguire il modello di “Digital Service Telco” l’ecosistema dell’Operatore ha la necessità di dotarsi di nuovi processi e servizi, disponibili ed utilizzabili in modo agile ed a basso costo operativo. Ma entriamo più nel dettaglio.

 

5.1 - Easy API: evoluzione delle modalità di consumo

Telecom Italia è impegnata in un profondo percorso di evoluzione delle NetAPI (le API caratteristiche di un operatore Telco - e.g. voce, messaging, billing, user identity, ecc.) e dei processi di erogazione correlati, sia per uso interno che per Terze Parti.
La “nascita” delle NetAPI in Telecomitalia risale alla fine degli anni ‘90 quando, attraverso funzionalità di Gateway verticali si iniziò ad aprire verso terze parti la funzionalità di invio/ricezione SMS Application to Person e Person to Application per l’erogazione dei primi servizi VAS offerti in partnership con Content Service Provider esterni (chat, news, oroscopi, suonerie, musica). Negli anni successivi l’infrastruttura di intermediazione si arricchì di funzionalità di sottoscrizione e verifiche di business, per consentire un’opportuna gestione del caring e del ciclo di vita dei servizi nei confronti dei clienti (ad esempio verifica credito, black list).
Dalla fine del decennio successivo, seguendo i principi SDP (Service Delivery Platform), SOA ed in linea con le indicazioni tecnologiche e di contesto provenienti anche dal mondo dello standard (v. Box L’evoluzione delle NetAPI Telco nel mondo dello Standard), si è proceduto:

  • a sistematizzare l’infrastruttura di esposizione delle funzionalità di servizio, con l’adozione della Service Exposure, punto di pubblicazione e di richiamo delle funzionalità di base presenti nei diversi contesti di servizio (es. messaging, localizzazione, servizi per MVNO, user identity, servizi vocali, provisioning e billing);
  • ad ampliare le funzionalità di rete e di IT/BSS offerte come API, per consumo interno ed esterno;
  • a supportare i nuovi contesti di business e di co-operazione che hanno richiesto un’integrazione tra le funzionalità dell’operatore e le terze parti come, ad esempio, gli MVNO (Mobile Virtual Network Operators).

Tutto questo promuovendo l’orientamento ai servizi, l’astrazione, il riuso delle capabilities, il supporto di interazioni multi-protocollo (basate sia su paradigmi http-based che su protocolli legacy Telco), l’applicazione di Policy Infrastrutturali e di Business sulle capabilities esposte.
Oggi le NetAPI disponibili sono oltre 50, raggruppabili in 11 aree funzionali, 8 mobili e 3 fisse (Figura 6),con un utilizzo complessivo che varia tra 1,6 ed 1,8 Miliardi di invocazioni al mese equamente distribuite tra Terze Parti ed applicazioni interne.

 

Figura 6 - NetAPI Telecom Italia disponibili

 

Partendo da questo contesto, la modalità di erogazione ed esposizione delle NetAPI Telecom Italia sta evolvendo su due principali fronti:

  1. rendere più efficace l’utilizzo delle NetAPI con un modello di utilizzo snello e veloce, “self service”, unico ed omogeneo sia per utilizzo interno che esterno; con questi obiettivi è stata intrapresa la realizzazione della piattaforma EasyAPI (Figura 7);
  2. abilitare l’offerta di una nuova “classe di network API” (e.g. Web RTC, QoS, Big Data) che fanno leva sulla virtualizzazione delle funzionalità di rete Telecom Italia come “piattaforma abilitante” per i nuovi servizi digitali.

Dal punto di vista delle modalità di “consumo” delle NetAPI, l’infrastruttura EasyAPI indirizza, secondo le best practice dell’erogazione servizi sul Web, la semplificazione dei processi di predisposizione ed integrazione delle NetAPI stesse in servizi digitali, sviluppati internamente o da terze parti, e la loro integrazione in web Markeplace e piattaforme “cloud based” per favorire l’esplorazione di nuovi mercati e nuovi modelli di offerta servizi.
In particolare Easy API intende offrire agli utilizzatori:

  • funzionalità on-line di pubblicazione e di consultazione delle API, attraverso un catalogo unificato;
  • API omogenee, uniformate al «linguaggio de facto» del WEB e degli Application Developer (REST), per facilitare ulteriormente l’integrazione delle funzionalità offerte in applicazioni Web e Apps (iOS, Android);
  • un consumo «Self Service» (funzionalità di attivazione, consumo e reporting delle API) on line;
  • una modalità comune di autenticazione ed accesso alle diverse API esposte.

Il tutto secondo un modello multitenancy per cui le stesse funzionalità dispiegate una volta sola sono proposte tramite viste multiple atte ad indirizzare la gestione dei diversi contesti di offerta.
Con il modello Easy API Telecom Italia ha quindi raccolto ed indirizzato i nuovi requisiti di elasticità, semplicità di utilizzo, facilità di integrazione in ecosistemi, intesi come nuovi canale di erogazione e distribuzione di servizi digitali.
È anche in corso la realizzazione di nuove funzionalità che saranno introdotte in rete ed integrate con Easy API come abilitanti per nuove offerte di mercato.
Tra queste è opportuno evidenziare:

  • Network & Service Management API, che consentono una gestione flessibile, self-service, delle caratteristiche di connettività dati (banda, CoS, connettività on – demand) acquistata da un cliente Telecom Italia (tipicamente Business o Wholesale). La realizzazione di queste funzionalità consentirà di innovare le modalità con cui sono erogati, ad esempio, i servizi Carrier Ethernet Access, abilitando nuove offerte commerciali;
  • Mappa presenze API: fornisce la stima, in tempo reale, della distribuzione della popolazione in una determinata area geografica, in base ai dati di utilizzo delle celle radio. Funzionalità rilevante per applicazioni di gestione del territorio e dei servizi/infrastrutture ad esso correlati (gestione eventi, turismo, resti stradali, trasporti), che fa leva sull’elaborazione in tempo reale dei dati di rete, per estrarne il valore in ottica servizio.
  • API WebRTC, in grado di abilitare l’esposizione e l’integrazione di nuove forme di funzionalità di comunicazione realtime e Web based (v. Box Nuovi Canali di esposizione: WEBRTC).
 

Figura 7 - Easy API – architettura e funzionalità

 

5.2 - Build.It: Un approccio per superare i silos verticali di servizio

Guardando in ottica prospettica, il progressivo ma ineludibile percorso di "softwarizzazione dell’IT e della rete” (SDDC, SDN, NFV) rende la trasformazione dei processi di service creation l'elemento centrale per garantire competitività, time to market e cost reduction, in un contesto in cui tutto diventa software e servizio.

In questo contesto Telecom Italia è fortemente orientata ad un percorso di trasformazione mirato al ridisegno e all’ottimizzare dei processi che gestiscono il ciclo di vita del software non solo in ottica tecnologica ma anche dal punto di vista culturale ed organizzativo. L’obiettivo è quello di consolidare, promuovere e far diventare comuni un insieme di best practices e metodologie agili volte alla progettazione e all’erogazione di servizi superando la verticalizzazione e indirizzando la progettazione di soluzioni “modulari e riusabili in modalità as a Service”.
Con questo focus Telecom Italia ha avviato un’attività trasversale: “Build.It”. Si tratta di un progetto che indirizza in modo forte il problema della verticalizzazione delle soluzioni di piattaforma contrapponendo a questo modello una strategia differente che innova sia il processo che il modo di progettare i nuovi servizi.
Come indicato nella Figura 8, i processi agili di sviluppo, deployment, esercizio e improvement dei servizi si contraddistinguono, per la velocità con la quale il life-cycle si attiva sollecitato dai requisiti dell’utente e del mercato interno.

 

Figure 8 - Rapidità e approccio incrementale sono le caratteristiche principali dei moderni life-cycle di prodotto

 

La sfida per le Telco è quindi quella di ottimizzare non solo il primo ciclo, che rappresenta il lancio del nuovo servizio sul mercato, ma anche e soprattutto la velocità dei cicli seguenti che ne rappresentano l’evoluzione incrementale per un miglioramento continuo dell’offerta.
Il progetto Build.IT promuove in questo senso metodologie agili (es. SCRUM) [12] e soluzioni di cloud automation per tutte le fasi. A questo scopo il progetto ha realizzato un ambiente di continuous integration/delivery in grado di introdurre un elevato livello di automazione sul change management, sul controllo di qualità, sul testing e l’operation del software sviluppato. Inoltre si sono investigate a fondo le soluzioni interne/esterne di cloud privata, realizzando l’automazione e il “CloudFormation” delle infrastrutture dedicate allo sviluppo, al collaudo e all’esercizio (Figura 9).

 

Figura 9 - Attraverso le cloud API si possono creare in modo automatizzato e on-demand gli ambienti di sviluppo e operation

 

Sul fronte della progettazione dei nuovi servizi, Build.IT offre un portale e alcuni strumenti che promuovono il design modulare dei servizi in alternativa alla classica realizzazione verticale di tipo “silos oriented”. La Figura 10 illustra il principio di questo approccio.
In Build.IT i servizi non possono avere una natura verticale (silos). Devono invece essere sempre concepiti come un insieme di componenti riusabili (i blocchi quadrati) e con uno strato sovrastante (i triangoli della figura) che “personalizza” questi blocchi aggiungendo funzionalità peculiari del servizio e quindi difficilmente riusabili in altri contesti. In questo modo ogni volta che un servizio innovativo viene sviluppato non avrà solo una dimensione verticale di tipo B2C orientata alle esigenze dell’offerta rivolta agli utenti finali, ma anche una dimensione orizzontale che ne consentirà il riuso in self-service all’interno dell’azienda.
I diversi servizi nel tempo creeranno quindi un ecosistema di API riusabili rivolte ad un B2B interno oppure valorizzabili verso un mercato B2B/wholesale esterno. 

 

Figure 10 - Il sistema Build.It promuove un approccio "no-silos" ai servizi, il riuso e la componentizzazione SW attraverso le API

 

Build.IT in questa sua prima fase raccoglierà e metterà a disposizione dell’azienda le API dei servizi prototipali sviluppati da Telecom Italia e dai partner che operano nel tessuto delle università e sul territorio. I driver del progetto sono riassunti nella Figura 11 dove si evidenziano le caratteristiche assolutamente orientate all’open software, alle cloud API e alla modularizzazione e “apizzazione” dei servizi di Telecom Italia per aumentarne efficacia e riusabilità in tutte le proposizioni di mercato.

 

Figure 11 - Cloud automation, Open SW e architettura modulare dei servizi abilitano la cultura Lean dei processi Agile

 

Conclusioni

Dall’analisi del contesto competitivo di riferimento degli Operatori risulta evidente come, per sfruttare le opportunità legate ai servizi digitali, senza limitarsi alla monetizzazione della sola connettività, sia necessaria una trasformazione che preveda l’utilizzo, sempre più spinto, dei modelli di Network/Cloud API prendendo a modello le evoluzioni dei “best in class” del mondo Web ed IT.
In quest’ottica i principi alla base delle API (semplicità, astrazione, riuso) possono essere utilizzati:

  • Ÿcome guida strategica di evoluzione dell’organizzazione, tanto nel mondo network che IT;
  • Ÿcome governance dei processi per rendere efficiente lo sviluppo di servizi modulari e riusabili, ed ottimizzarne l’intero ciclo di vita con l’obiettivo del miglioramento continuo della qualità;
  • Ÿper potenziare ulteriormente l’integrazione con “ecosistemi esterni” verso i quali gli operatori già da tempo hanno stretto relazioni di partnership per innovare il proprio business;
  • per esplorare nuove modalità di offerta su Marketplace digitali.
 

comments powered by Disqus