Che diamine è un NGOSS? Ho usato molto il termine, relativo al “Contratto NGOSS”, ma per chi non ha familiarità con lo spazio OSS/BSS o il TMF, potrebbe essere misterioso. Tata Consultancy Services, una grande e attiva società di servizi professionali, ha recentemente fatto un documento su” reimmaginare ” l’OSS/BSS, un documento TMF chiedendo se c’è vita oltre i servizi di connettività. Ci sono interessanti contrasti e somiglianze tra i due documenti, vale la pena esplorare.
NGOSS sta per “Next-Generation Operations Support System”. È un termine che è stato ampiamente usato per almeno 15 anni, ed è spesso usato dal TMF nelle loro specifiche. Un sacco di roba TMF è solo membri, e quindi non posso citarlo (o, se non sono un membro al momento, non posso nemmeno accedervi) se non riassumendo. Il documento TMF è particolarmente utile per questo; è una sintesi pubblica del modo in cui il corpo vede il futuro della “trasformazione”. Il documento Tata è interessante perché riflette una visione dei servizi professionali dello stesso processo di trasformazione.
L’apertura della carta Tata ha le solite banalità sulla larghezza di banda. “Poiché le aziende si adattano sempre più a un modello prevalentemente online in linea con la nuova realtà, la necessità di un’elevata larghezza di banda e di servizi di rete affidabili è in aumento. Di conseguenza, i fornitori di servizi di comunicazione (CSP) stanno vivendo una domanda esponenziale di servizi e dipendono dai progressi nelle tecnologie di virtualizzazione per continuare a scalare ai tassi attuali.”
Il problema con questo, oltre al suo stato di banalità (un’altra dichiarazione di domanda “esponenziale” e vomiterò), è che il vero problema non è la crescita della domanda, è il restringimento del profitto. Nessun operatore sarebbe infelice con la crescita della domanda di larghezza di banda, se potessero caricare in modo incrementale per la crescita. Non possono, quindi devono trovare qualcosa di diverso dalla larghezza di banda da vendere, o tagliare il costo della produzione di larghezza di banda per compensare il fatto che i servizi di larghezza di banda più elevata non generano prezzi proporzionalmente più alti.
Questo stesso problema colora la sezione successiva, che si chiama “Ripensare la funzione OSS”. Cita obiettivi TMF per la modernizzazione OSS, nessuno dei quali implica anche affrontare quel problema di compressione del profitto. In effetti, quella sezione del documento è il motivo per cui molti strateghi degli operatori sono favorevoli a rottamare l’intera cosa OSS/BSS e ricominciare da capo. Non è che non siano impostati obiettivi utili (l’automazione è uno degli attributi di un futuro OSS/BSS), ma che non si dice molto sul loro raggiungimento.
Che viene fornito nella sezione successiva, che si chiama “Guida di funzioni OSS ben orchestrate”. Questa sezione finalmente fa una raccomandazione che è utile; OSS/BSS deve essere fatto event-driven. Ho avuto speranze qui, perché il TMF era in realtà la fonte del concetto chiave in OSS e operations automation – quel contratto NGOSS che ho menzionato all’inizio di questo blog. Purtroppo, né il termine né il concetto sono sollevati nel documento Tata. Quello che dice è che ” le future funzioni OSS devono essere create e offerte come servizi composti da microservizi per supportare l’orchestrazione end-to-end automatizzata di risorse di rete ibride (fisiche, logiche e virtuali).”
Il documento TMF, al contrario, si apre con l’affermazione che “la connettività è giustamente vista come un business a basso margine e sta rapidamente mercificando ulteriormente.”L’obiettivo degli operatori è” ottenere il loro mondo interiore con una base tecnologica agile e un modello operativo.”Il TMF include ovviamente il suo obiettivo primario OSS / BSS in questo mondo interno, ma altrettanto ovviamente la agile technology foundation deve estendersi all’infrastruttura.
Il meccanismo di ottenere il loro “mondo interiore in ordine” è, implicitamente, 5G. Il MDF si dice che è fondamentale, al fine di “rendere la maggior parte di estremamente costoso shift a 5G.” Ma che sembra essere contraddetta dal paragrafo successivo, in cui l’ex CEO del forum dice “Per i consumatori e smart home individui, ‘connettività’ tende ad avere un valore intrinseco e un valido cosa per essere l’acquisto. Mentre si sale la scala, tuttavia, nel regno della trasformazione del settore, la connettività è valutata solo nella misura in cui è legata alla soluzione: “Non vogliono acquistare connettività da te, vogliono acquistare una soluzione.”5G è chiaramente una strategia di connettività per i consumatori, come tutte le infrastrutture del mercato di massa è. Se presumiamo che per “salire la scala nel regno della trasformazione del settore”, ovvero i servizi alle imprese, la chiave è vendere soluzioni.
Questo sembra sostenere che gli operatori concentrino la loro attività di “fornitore di servizi digitali” sulle imprese e che per fornire soluzioni ci sia un fornitore SaaS. È davvero un approccio intelligente, dato che esiste un’attività di cloud pubblico altamente attiva e competitiva che già vende soluzioni a quei clienti? Soprattutto quando la maggior parte dei problemi di profitto-per-bit operatori hanno proviene da all-you-can-eat servizi ai consumatori?
La risoluzione, afferma una citazione di Vodafone e altri commenti nel documento TMF, è che “ciò che ora chiamiamo “servizi” non coinvolgerà solo la telco, ma comprenderà una serie di partner, incluse le telco.”Pertanto, le società di telecomunicazioni non sono affatto fornitori di servizi digitali, ma integratori o rivenditori di servizi digitali. Un’azienda che guarda alla trasformazione come mezzo per sfuggire alla compressione del profitto può permettersi di essere un rivenditore dei servizi di un altro giocatore?
Mi sembra che la visione TMF non miri affatto al di là dell’OSS/BSS, ma piuttosto suggerisca che le operazioni e i servizi si evolvano verso qualcosa di sopra della connettività collaborando con coloro che forniscono servizi lassù. Ciò potrebbe sconfiggere l’intero scopo della “trasformazione digitale”, bloccando le telco non solo nel loro attuale livello di disintermediazione e mercificazione, ma anche in un livello completamente nuovo.
Entrambi i documenti sembrano suggerire che la trasformazione OSS/BSS è essenziale e almeno implica che un approccio basato sugli eventi è la risposta. In realtà è una buona idea, ma manca la sfida di ” come?”Per essere event-driven, un sistema deve riconoscere sia il concetto di eventi (ovviamente) che il concetto di” stato ” o contesto. Chiunque abbia mai guardato un gestore di protocollo sa che lo stesso messaggio, in diversi contesti/stati, deve essere elaborato in modo diverso. Ad esempio, ottenere un messaggio “pacchetto dati” nello stato “ordinabile” per un servizio è chiaramente un errore, mentre va bene nello stato “trasferimento dati”. Affinché ci siano stati ed eventi e processi correlati, è necessaria una tabella di stato / evento.
Le tabelle di stato/evento sono descrizioni dei contesti collettivi di un sistema cooperativo, e pensare di costruirli è utile in quanto costringe gli architetti software a considerare tutte le possibilità, invece di far accadere qualcosa che cade attraverso le fessure. Tuttavia, esiste un potenziale conflitto tra il valore delle tabelle stato/evento e il numero di possibili stati ed eventi. Se si guarda a una rete complessa come un sistema enorme, piatto, si avrebbe un tavolo troppo grande per essere mai implementato. Il TMF e il mio lavoro di ExperiaSphere si sono occupati di questo dividendo sistemi complessi in “modelli di intenti” che ognuno aveva le proprie relazioni stato/evento. Composizione gerarchica, insomma. Questo è ciò che NGOSS contratto descritto.
Il punto qui è che entrambi i documenti mancano di quello che dovrebbe essere il proprio punto di forza, ovvero che lo sterzo basato sui modelli di dati degli eventi ai processi tramite tabelle di stato/evento allineate ai componenti è il modo per creare sia un comportamento basato sugli eventi che un design compatibile con i microservizi. Se un modello di dati del servizio indirizza un evento a un processo, il processo può ottenere le informazioni necessarie dal solo modello di dati del servizio, il che significa che è stateless e può essere distribuito come microservizio o anche in forma serverless.
Se estrai l’approccio NGOSS-Contract dalla storia della modernizzazione OSS/BSS, ti rimane la cosa che ha afflitto l’intera nozione di modernizzazione OSS/BSS dalle prime banalità. Possiamo parlare di bottom-up e top-down finché ci concentriamo sulle metodologie di progetto, ma una metodologia di progetto guida un progetto, non scrive software. Dalla metodologia dovrebbe emergere un’architettura software. Questo è un elemento separato, un risultato del giusto processo, ma non è la conseguenza automatica di sventolare una bacchetta su un mucchio di dati e cantare “top-down, top-down!”
Che riassume il mio problema con la carta Tata. Le metodologie di progetto in IT e networking portano a architetture di applicazioni o servizi, che poi inquadrano i requisiti per i componenti della soluzione e il modo in cui sono integrati e gestiti. Il progetto non è l’output, è il percorso dell’output. Il problema con la carta Tata è che è ancora un’altra descrizione di una metodologia di progetto (buona, ma non trasformativa), in un momento in cui siamo da tempo alla ricerca di un percorso per la modernizzazione dell’OSS e invece stiamo cercando prodotti specifici, o almeno architetture. Il TMF sembra dirigersi verso lo stesso posto con un percorso diverso: trasformare in partnership con i tuoi ex nemici.
Il documento Tata fa, nella sezione chiamata “Il ruolo degli standard di settore”, chiamare fuori un problema importante, uno così importante che potrebbe effettivamente essere la barriera per progredire verso l’obiettivo di modernizzazione OSS. Il documento cita i modelli TMF e ONF per la progettazione top-down, ma in tutto il documento è chiaro che l’OSS/BSS “modernizzato” deve essere più strettamente integrato con il resto dell’ecosistema di rete e servizi. Abbiamo standard per ogni possibile pezzo di ogni possibile strategia di rete, e in alcuni casi gli standard anche competere. Recentemente abbiamo sentito applausi per l’unificazione di due diverse operazioni specifiche API, per esempio. Dovremmo chiederci come siamo arrivati ad averli, in primo luogo.
Il documento TMF sembra non solo accettare questa frammentazione del futuro, ma dipendere da esso. Cedere la meccanizzazione delle cose oltre OSS / BSS e concentrarsi sull’utilizzo di quelle cose” oltre ” per creare servizi come pseudo-integratore. OK, potrebbe non essere una visione irragionevole per il TMF (un corpo dominato da OSS/BSS) da prendere, ma è una formula per rimanere disorganizzato mentre si affronta quella che deve quasi essere un’iniziativa unificata-trasformazione.
È mia opinione che il TMF sia stato il corpo logico per modernizzare l’OSS/BSS e che il TMF abbia (con il contratto NGOSS) ideato il paradigma centrale di event steering ai processi tramite un modello di dati, che è fondamentale per questa modernizzazione. Tutto il resto che i documenti descrivono, ogni API che qualcuno sta sviluppando o armonizzando, ogni attività di standard finalizzata a qualsiasi aspetto delle operazioni e della gestione, dovrebbe essere inserito in quel quadro contrattuale NGOSS. Se ciò dovesse essere fatto, il risultato sarebbe esattamente ciò che significa “NGOSS”.
Il modello del contratto TMF NGOSS è altrettanto prezioso, o anche più prezioso, se si entra nel dominio di rete. Un vero processo di stato / evento “contratto” potrebbe gestire tutto ciò che riguarda il ciclo di vita del servizio, incluso il pezzo di rete. Ne consegue che una soluzione incentrata sulla rete potrebbe essere facilmente estesa al dominio OSS/BSS del servizio. L’universalità dell’approccio è un bene per l’industria, perché l’automazione del ciclo di vita dei servizi dovrebbe essere universale per essere utile.
Dovrebbe anche essere basato su cloud-think all’avanguardia. Entrambi i documenti sembrano essere d’accordo con questo, eppure entrambi ignorano la domanda su come realizzarlo. Se hai intenzione di utilizzare gli strumenti attuali per realizzare qualcosa, devi inquadrare il tuo approccio in termini di tali strumenti. Non puoi accettare l’idea di poter scrivere specifiche per tutto o semplicemente tradurre gli obiettivi in alto in caratteristiche arbitrarie in basso. Questo è particolarmente probabile che ti morda dato che i processi standard impiegano anni per giungere a una conclusione. Stiamo implementando 5G oggi e gli standard non sono finiti, e probabilmente non sarà fino al 2022. Mi chiedo se c’è tempo per quella roba, dato che gli operatori stanno già affrontando ROI infrastrutturali in calo che si stanno avvicinando al punto critico.
Il contratto NGOSS è in circolazione da circa 13 anni e la TMF una volta mi ha detto che aveva guadagnato una trazione molto limitata. Non sembra essere riprodotto nel materiale TMF corrente, anche se, come ho detto, non ho accesso alle cose solo per i membri. La domanda, quindi, è se il TMF è pronto a promuovere la propria intuizione (abbagliante e unica), prima all’interno del dominio OSS/BSS ristretto e poi nella più ampia missione di automazione del ciclo di vita. In tal caso, TMF assume il suo ruolo legittimo nell’evoluzione di NGOSS e definisce la base per l’automazione del ciclo di vita del servizio in generale. In caso contrario, spetterà a qualche altro organismo di standard o gruppo open-source raccogliere la torcia, e il TMF dovrà quindi lottare per la pertinenza nel proprio spazio.
