ce naiba este un NGOSS? Am folosit mult termenul, referitor la” contractul NGOSS”, dar pentru cei care nu sunt familiarizați cu spațiul OSS/BSS sau TMF, poate fi misterios. Tata Consultancy Services, o firmă mare și activă de servicii profesionale, a făcut recent o lucrare despre „reimaginarea” OSS/BSS, o lucrare TMF care întreabă dacă există viață dincolo de serviciile de conectivitate. Există contraste interesante și asemănări între cele două documente, care merită explorate.
NGOSS standuri pentru”Next-Generation Operations Support System”. Este un termen care a fost utilizat pe scară largă de cel puțin 15 ani și este adesea folosit de TMF în specificațiile lor. O mulțime de lucruri TMF este doar membri, deși, și așa că nu-l pot cita (sau, dacă nu sunt membru la momentul respectiv, nici măcar nu-l pot accesa), cu excepția rezumării. Lucrarea TMF este deosebit de utilă din această cauză; este un rezumat public al modului în care corpul vede viitorul „transformării”. Lucrarea Tata este interesantă deoarece reflectă o viziune a serviciilor profesionale asupra aceluiași proces de transformare.
deschiderea hârtiei Tata are platitudinile obișnuite despre lățimea de bandă. „Pe măsură ce companiile se adaptează din ce în ce mai mult la un model predominant online, în conformitate cu noua realitate, nevoia de lățime de bandă mare și servicii de rețea fiabile crește. În consecință, furnizorii de servicii de comunicații (CSP) se confruntă cu o cerere exponențială de servicii și depind de progresul tehnologiilor de virtualizare pentru a continua scalarea la ratele actuale.”
problema cu acest lucru, pe lângă statutul de platitudine (încă o declarație de cerere „exponențială” și voi vomita), este că adevărata problemă nu este creșterea cererii, ci contracția profitului. Niciun operator nu ar fi nemulțumit de creșterea cererii de lățime de bandă, dacă ar putea percepe incremental creșterea. Nu pot, așa că trebuie fie să găsească altceva decât lățimea de bandă pentru a vinde, fie să reducă costul producerii lățimii de bandă pentru a compensa faptul că serviciile de lățime de bandă mai mari nu generează prețuri proporțional mai mari.
aceeași problemă colorează următoarea secțiune, care se numește „regândirea funcției OSS”. Acesta citează obiectivele TMF pentru modernizarea OSS, dintre care nici măcar nu implică rezolvarea acestei probleme de compresie a profitului. De fapt, acea secțiune a documentului este motivul pentru care o mulțime de strategi operatori sunt în favoarea eliminării întregului lucru OSS/BSS și a reînceperii. Nu este faptul că nu sunt stabilite obiective utile (automatizarea este unul dintre atributele unui viitor OSS/BSS), ci că nu se spune nimic despre atingerea lor.
care vine în secțiunea următoare, care se numește”conducerea funcțiilor OSS bine orchestrate”. Această secțiune face în cele din urmă o recomandare care este utilă; OSS/BSS trebuie să fie făcută bazată pe evenimente. Am avut speranțe aici, deoarece TMF a fost de fapt sursa conceptului cheie în Oss și automatizarea operațiunilor—acel contract NGOSS pe care l-am menționat la începutul acestui blog. Din păcate, nici termenul, nici conceptul nu sunt ridicate în lucrarea Tata. Ceea ce spune este că „viitoarele funcții OSS trebuie create și oferite ca servicii compuse din microservicii pentru a sprijini orchestrarea automată end-to-end a resurselor de rețea hibride (fizice, logice și virtuale).”
lucrarea TMF, în schimb, se deschide cu afirmația că „conectivitatea este văzută pe bună dreptate ca o afacere cu marjă redusă și se comercializează rapid în continuare.”Scopul operatorilor este” obținerea lumii lor interioare cu o fundație tehnologică agilă și un model de operare.”TMF include în mod evident obiectivul său principal OSS/BSS în această lume interioară, dar la fel de evident Fundația agile technology trebuie să se extindă la infrastructură.
mecanismul de a-și face „lumea interioară în ordine” este, implicit, 5G. TMF spune că este esențial pentru „a profita la maximum de trecerea extrem de costisitoare la 5G”. dar acest lucru pare să fie contrazis de paragraful următor, în care fostul CEO al forumului spune „pentru consumatori și persoane fizice inteligente, „conectivitatea” tinde să aibă o valoare intrinsecă și este un lucru valabil pentru cumpărare. Cu toate acestea, pe măsură ce urcați scara în domeniul transformării industriei, conectivitatea este apreciată doar în măsura în care este legată de soluție: „nu vor să cumpere conectivitate de la dvs., vor să cumpere o soluție.”5G este în mod clar o strategie de conectivitate pentru consumatori, așa cum este toată infrastructura de pe piața de masă. Dacă presupunem că pentru a” urca scara în domeniul de transformare a industriei”, ceea ce înseamnă servicii de afaceri, cheia este de a vinde soluții.
acest lucru pare să susțină operatorii să-și concentreze activitatea „furnizorului de servicii digitale” asupra întreprinderilor, iar pentru a oferi soluții trebuie să existe un furnizor SaaS. Este într-adevăr o abordare inteligentă, având în vedere că există o afacere cloud publică extrem de activă și competitivă care vinde deja soluții acestor clienți? Mai ales atunci când majoritatea profit-pe-bit probleme operatorii au vine de la all-you-can-eat servicii de consum?
rezoluția, spune un citat Vodafone și alte comentarii din lucrarea TMF, este că „ceea ce numim acum „servicii” nu va implica doar telco, ci va cuprinde o serie de parteneri, inclusiv Telco-urile.”Astfel, Telco-urile nu sunt deloc furnizori de servicii digitale, ci integratori de servicii digitale sau revânzători. Poate o afacere care se uită la transformare ca un mijloc de a scăpa de profit stoarce permite să fie un revânzător de servicii de un alt jucător?
mi se pare că viziunea TMF nu vizează deloc dincolo de OSS/BSS, ci mai degrabă sugerează că operațiunile și serviciile evoluează spre ceva mai presus de conectivitate prin parteneriatul cu cei care furnizează servicii acolo sus. Acest lucru ar putea învinge întregul scop al” transformării digitale”, blocând Telco-urile nu numai în nivelul lor actual de dezintermediere și comodizare, ci și într-un nivel cu totul nou.
ambele lucrări par să sugereze că transformarea OSS / BSS este esențială și cel puțin implică faptul că o abordare bazată pe evenimente este răspunsul. Aceasta este de fapt o idee bună, dar ratează provocarea „cum?”Pentru a fi condus de evenimente, un sistem trebuie să recunoască atât conceptul de evenimente (evident), cât și conceptul de „stat” sau context. Oricine s-a uitat vreodată la un operator de protocol știe că același mesaj, în contexte/stări diferite, trebuie procesat diferit. De exemplu, obținerea unui mesaj „pachet de date” în starea „ordonabil” pentru un serviciu este în mod clar o eroare, în timp ce este bine în starea „transfer de date”. Pentru a exista stări și evenimente și procese conexe, aveți nevoie de un tabel de stare/eveniment.
tabelele de stare/eveniment sunt descrieri ale contextelor colective ale unui Sistem Cooperativ, iar gândirea la construirea lor este utilă prin faptul că îi obligă pe arhitecții software să ia în considerare toate posibilitățile, în loc să se întâmple ceva care cade prin fisuri. Cu toate acestea, există un potențial conflict între valoarea tabelelor de stare/eveniment și numărul de stări și evenimente posibile. Dacă te uiți la o rețea complexă ca la un sistem enorm, plat, ai avea o masă prea mare pentru a o implementa vreodată. TMF și propria mea lucrare ExperiaSphere s-au ocupat de acest lucru prin împărțirea sistemelor complexe în „modele de intenție” care fiecare avea propriile relații de stare/eveniment. Compoziție ierarhică, pe scurt. Așa a descris contractul NGOSS.
ideea aici este că ambele lucrări ratează ceea ce ar trebui să fie propriul său punct cel mai puternic, și anume că direcționarea bazată pe date a evenimentelor către procese prin tabele de stare/evenimente aliniate la componente este modalitatea de a crea atât un comportament bazat pe evenimente, cât și un design compatibil cu microserviciile. Dacă un model de date de serviciu conduce un eveniment la un proces, procesul poate obține informațiile de care are nevoie numai de la modelul de date de serviciu, ceea ce înseamnă că este apatrid și poate fi implementat ca microserviciu sau chiar în formă fără server.
dacă scoți abordarea NGOSS-Contract din povestea modernizării OSS/BSS, rămâi cu lucrul care a afectat întreaga noțiune de modernizare OSS / BSS din primele platitudini. Putem vorbi de jos în sus și de sus în jos atâta timp cât ne concentrăm pe metodologiile proiectului, dar o metodologie de proiect conduce un proiect, nu scrie software. O arhitectură software ar trebui să iasă din metodologie. Acesta este un element separat, un rezultat al procesului corect, dar nu este consecința automată a fluturării unei baghete peste o grămadă de date și a scandării „de sus în jos, de sus în jos!”
asta rezumă problema mea cu ziarul Tata. Metodologiile de proiect în IT și networking conduc la arhitecturi de aplicații sau servicii, care apoi încadrează cerințele pentru componentele soluției și modul în care acestea sunt integrate și gestionate. Proiectul nu este ieșirea, este calea către ieșire. Problema cu lucrarea Tata este că este încă o descriere a unei metodologii de proiect (una bună, dar nu una transformatoare), într-un moment în care am trecut de mult în căutarea unei căi spre modernizarea OSS și în schimb căutăm produse specifice sau cel puțin arhitecturi. TMF pare să se îndrepte spre același loc printr—o cale diferită-transformarea prin parteneriat cu foștii tăi dușmani.
lucrarea Tata, în secțiunea numită „rolul standardelor industriei”, strigă o problemă importantă, una atât de importantă încât ar putea fi de fapt bariera pentru progresul către obiectivul de modernizare a OSS. Lucrarea citează modelele TMF și ONF pentru proiectarea de sus în jos, dar pe tot parcursul lucrării este clar că OSS/BSS „modernizat” trebuie să fie mai strâns integrat cu restul ecosistemului de rețea și servicii. Avem standarde pentru fiecare piesă posibilă din fiecare strategie de rețea posibilă și, în unele cazuri, standardele chiar concurează. Am auzit recent aplauze pentru unificarea a două operații diferite API specificații, de exemplu. Ar trebui să ne întrebăm cum am ajuns să le avem în primul rând.
lucrarea TMF pare să accepte nu numai această fragmentare a viitorului, ci depinde de ea. Cedați mecanizarea lucrurilor dincolo de OSS / BSS și concentrați-vă pe valorificarea acelor lucruri „dincolo” pentru a crea servicii ca pseudo-integrator. OK, aceasta nu poate fi o viziune nerezonabilă pentru TMF (un organism dominat de OSS/BSS), dar este o formulă pentru a rămâne dezorganizat în timp ce se confruntă cu ceea ce aproape trebuie să fie o inițiativă unificată-transformare.
părerea mea este că TMF a fost organismul logic pentru modernizarea OSS/BSS și că TMF a conceput (cu contractul NGOSS) paradigma centrală a direcționării evenimentelor către procese printr-un model de date, care este esențial pentru această modernizare. Orice altceva descrie documentele, fiecare API pe care oricine îl dezvoltă sau armonizează, fiecare activitate de standarde care vizează orice aspect al operațiunilor și managementului, ar trebui să se încadreze în acel cadru contractual NGOSS. Dacă s-ar face acest lucru, rezultatul ar fi exact ceea ce înseamnă „NGOSS”.
modelul contractului TMF NGOSS este la fel de valoros, sau chiar mai valoros, dacă intri în domeniul rețelei. Un adevărat proces de stare/eveniment „contract” ar putea gestiona totul despre ciclul de viață al Serviciului, inclusiv piesa de rețea. Rezultă că o soluție centrată pe rețea ar putea fi extinsă cu ușurință în domeniul serviciului, OSS/BSS. Universalitatea abordării este bună pentru industrie, deoarece automatizarea ciclului de viață al serviciilor ar trebui să fie universală pentru a fi utilă.
ar trebui să se bazeze și pe gândirea cloud de ultimă generație. Ambele lucrări par să fie de acord cu asta, și totuși ambele fusta întrebarea cum să aducă asta. Dacă intenționați să utilizați instrumentele actuale pentru a realiza ceva, trebuie să vă încadrați abordarea în ceea ce privește aceste instrumente. Nu puteți accepta ideea că puteți scrie specificații pentru orice sau pur și simplu puteți traduce obiectivele din partea de sus în caracteristici arbitrare din partea de jos. Acest lucru este deosebit de probabil să vă muște, având în vedere că procesele de standarde durează ani pentru a ajunge la o concluzie. Implementăm 5G astăzi, iar standardele nu sunt terminate și probabil nu vor fi până în 2022. Mă întreb dacă există timp pentru aceste lucruri, având în vedere că operatorii se confruntă deja cu o scădere a rentabilității investiției în infrastructură, care se apropie de punctul critic.
contractul NGOSS a fost în jur de aproximativ 13 ani, iar TMF mi-a spus odată că a câștigat o tracțiune foarte limitată. Nu pare să fie jucat în materialul actual TMF, deși, așa cum am spus, nu am acces la lucrurile numai pentru membri. Întrebarea, atunci, este dacă TMF este pregătit să-și promoveze propria perspectivă (orbitoare și unică), mai întâi în domeniul îngust OSS/BSS și apoi în misiunea mai largă de automatizare a ciclului de viață. Dacă da, TMF își asumă rolul de drept în evoluția NGOSS și definește baza pentru automatizarea ciclului de viață al serviciilor în general. Dacă nu, it-ul va depinde de un alt organism de standarde sau de un grup open-source pentru a ridica torța, iar TMF va trebui apoi să lupte pentru relevanță în propriul spațiu.
