hvad pokker er en NGOSS? Jeg har brugt udtrykket meget, der vedrører “NGOSS-kontrakten”, men for dem, der ikke er bekendt med OSS/BSS-rummet eller TMF, kan det være mystisk. Tata Consultancy Services, et stort og aktivt professionelt servicefirma, lavede for nylig et papir om “reimagining” OSS/BSS, et TMF-papir, der spurgte, om der er liv ud over forbindelsestjenester. Der er interessante kontraster og ligheder mellem de to dokumenter, værd at udforske.
NGOSS står for “næste generations Driftsstøttesystem”. Det er et udtryk, der har været meget brugt i mindst 15 år, og det bruges ofte af TMF i deres specifikationer. Meget af TMF-tingene er dog kun medlemmer, og derfor kan jeg ikke citere det (eller hvis jeg ikke er medlem på det tidspunkt, kan jeg ikke engang få adgang til det) undtagen ved at opsummere. TMF-papiret er især nyttigt på grund af dette; det er en offentlig oversigt over, hvordan kroppen ser fremtiden for “transformation”. Tata-papiret er interessant, fordi det afspejler et professionelt syn på den samme transformationsproces.
åbningen af Tata-papiret har de sædvanlige platituder om båndbredde. “Efterhånden som virksomheder i stigende grad tilpasser sig en overvejende online model i tråd med den nye virkelighed, er behovet for høj båndbredde og pålidelige netværkstjenester stigende. Derfor oplever kommunikationstjenesteudbydere (CSP ‘ er) en eksponentiel efterspørgsel efter tjenester og er afhængige af fremskridt inden for virtualiseringsteknologier for at fortsætte skaleringen med de nuværende satser.”
problemet med dette, udover det er platitude status (endnu en “eksponentiel” efterspørgselserklæring og jeg vil kaste), er, at det virkelige problem ikke er efterspørgselsvækst, det er profitkrympning. Ingen operatør ville være utilfreds med væksten i efterspørgslen efter båndbredde, hvis de kunne opkræve trinvist for væksten. De kan ikke, så de skal enten finde noget andet end båndbredde til at sælge eller reducere omkostningerne ved at producere båndbredde for at udligne det faktum, at tjenester med højere båndbredde ikke genererer forholdsmæssigt højere priser.
det samme problem farver det næste afsnit, der kaldes “nytænkning af OSS-funktionen”. Det citerer TMF-mål for OSS-modernisering, hvoraf ingen endda indebærer at håndtere det overskudskomprimeringsproblem. Faktisk er det afsnit af dokumentet, hvorfor mange operatørstrateger går ind for at skrotte hele OSS/BSS-sagen og starte forfra. Det er ikke, at der ikke er sat nyttige mål (automatisering er en af attributterne for en fremtidig OSS/BSS), men at der ikke siges meget om at nå dem.
det kommer i næste afsnit, der kaldes “kørsel af velorganiserede OSS-funktioner”. Dette afsnit giver endelig en anbefaling, der er nyttig; OSS/BSS skal gøres begivenhedsdrevet. Jeg havde håb her, fordi TMF faktisk var kilden til nøglekonceptet inden for OSS og operations automation—den NGOSS-kontrakt, jeg nævnte i starten af denne blog. Desværre er hverken udtrykket eller konceptet rejst i Tata-papiret. Hvad det siger er, at “fremtidige OSS-funktioner skal oprettes og tilbydes som tjenester sammensat af mikroservices for at understøtte automatiseret end-to-end orkestrering af hybride (fysiske, logiske og virtuelle) netværksressourcer.”
TMF-papiret åbner derimod med udsagnet om, at ” forbindelse med rette ses som en forretning med lav margin og hurtigt kommodiserer yderligere.”Målet med operatører er” at få deres indre verden rigtigt med et smidigt teknologifundament og driftsmodel.”TMF inkluderer naturligvis sit primære OSS/BSS-mål i denne indre verden, men lige så åbenlyst skal agile technology foundation udvide til infrastruktur.
mekanismen for at få deres “indre verden i orden” er implicit 5G. TMF siger, at det er kritisk for at “få mest muligt ud af det enormt dyre skift til 5G.” men det ser ud til at være i modstrid med det næste afsnit, hvor den tidligere administrerende direktør for forummet siger “for forbrugere og smarte hjemindivider har ‘forbindelse’ en tendens til at have en egenværdi og er en gyldig ting at købe. Når du går op på skalaen, imidlertid, ind i branchetransformationsområdet, forbindelse værdsættes kun, for så vidt det er bundet til løsningen: “de ønsker ikke at købe forbindelse fra dig, de vil købe en løsning.”5G er helt klart en forbindelsesstrategi for forbrugerne, som al massemarkedsinfrastruktur er. Hvis vi antager, at “gå op i skalaen i branchen transformation realm”, hvilket betyder business services, nøglen er at sælge løsninger.
dette synes at argumentere for, at operatørerne fokuserer deres “digitale tjenesteudbyder” – forretning på virksomheder, og for at levere løsninger skal der være en SaaS-udbyder. Er det virkelig en smart tilgang, da der er en meget aktiv og konkurrencedygtig offentlig skyvirksomhed, der allerede sælger løsninger til disse kunder? Især når størstedelen af profit-per-bit problemer operatører har kommer fra alt-du-kan-spise forbrugertjenester?
beslutningen, siger et Vodafone-citat og andre kommentarer i TMF-papiret, er, at “det, vi nu kalder ‘tjenester’, ikke involverer telco alene, men vil omfatte en række partnere, herunder Telco ‘ erne.”Telcos er således ikke rigtig digitale tjenesteudbydere overhovedet, men digitale serviceintegratorer eller forhandlere. Kan en virksomhed, der ser på transformation som et middel til at undslippe profitpres, have råd til at være forhandler af en anden spillers tjenester?
det forekommer mig, at TMF-visionen virkelig ikke sigter ud over OSS/BSS overhovedet, men snarere antyder, at operationer og tjenester udvikler sig til noget over forbindelse ved at samarbejde med dem, der leverer tjenester deroppe. Det kunne besejre hele formålet med” digital transformation ” og låse telcos ind i ikke kun deres nuværende niveau af disintermediation og commoditisering, men også på et helt nyt niveau.
begge papirer synes at antyde, at OSS/BSS transformation er afgørende, og i det mindste antyde, at en begivenhedsdrevet tilgang er svaret. Det er faktisk en god ide, men det savner udfordringen med “hvordan?”For at være begivenhedsdrevet skal et system genkende både begrebet begivenheder (naturligvis) og begrebet” tilstand ” eller kontekst. Enhver, der nogensinde har set på en protokolhandler, ved, at den samme besked i forskellige sammenhænge/stater skal behandles forskelligt. For eksempel er det helt klart en fejl at få en “datapakke” – meddelelse i tilstanden “orderable” for en tjeneste, mens det er fint i tilstanden “dataoverførsel”. For at der skal være stater og begivenheder og relaterede processer, har du brug for en tilstand/begivenhedstabel.
tilstands – /begivenhedstabeller er beskrivelser af de kollektive sammenhænge i et kooperativt system, og det er nyttigt at tænke på at opbygge dem, idet det tvinger programmelarkitekter til at overveje alle mulighederne i stedet for at få noget til at ske, der falder gennem revnerne. Der er dog en potentiel konflikt mellem værdien af tilstands – /begivenhedstabeller og antallet af mulige tilstande og begivenheder. Hvis du ser på et komplekst netværk som et enormt, fladt system, ville du have alt for stort bord til nogensinde at implementere. TMF og mit eget Oplevelsesarbejde behandlede dette ved at opdele komplekse systemer i “intent models”, som hver havde deres egne forhold mellem tilstand og begivenhed. Hierarkisk sammensætning, kort sagt. Det er, hvad NGOSS kontrakt beskrevet.
pointen her er, at begge papirer går glip af, hvad der skal være sit eget stærkeste punkt, hvilket er, at datamodeldrevet styring af begivenheder til processer via komponentjusterede tilstands-/begivenhedstabeller er vejen til at skabe både begivenhedsdrevet adfærd og mikroservice-kompatibelt design. Hvis en servicedatamodel driver en begivenhed til en proces, kan processen få de oplysninger, den har brug for, fra servicedatamodellen alene, hvilket betyder, at den er statsløs og kan implementeres som en mikroservice eller endda i serverløs form.
hvis du trækker NGOSS-Kontraktmetoden ud af OSS/BSS moderniseringshistorien, er du tilbage med det, der har plaget hele forestillingen om oss/BSS modernisering fra de første platituder. Vi kan tale om bottom-up og top-ned, så længe vi fokuserer på projektmetoder, men en projektmetode driver et projekt, det skriver ikke programmer. En programmelarkitektur skal fremgå af metoden. Det er et separat element, et resultat af den rigtige proces, men det er ikke den automatiske konsekvens af at vifte med en tryllestav over en masse data og synge “ovenfra og ned, ovenfra og ned!”
det opsummerer mit problem med Tata-papiret. Projektmetoder inden for IT og netværk fører til applikations-eller servicearkitekturer, som derefter indrammer kravene til komponenterne i løsningen og den måde, de integreres og styres på. Projektet er ikke output, det er vejen til output. Problemet med Tata-papiret er, at det er endnu en beskrivelse af en projektmetode (en god, men ikke en transformativ), på et tidspunkt, hvor vi længe er på udkig efter en vej til OSS-modernisering og i stedet leder efter specifikke produkter eller i det mindste arkitekturer. TMF ser ud til at være på vej til det samme sted ad en anden vej—transformere ved partnerskab med dine tidligere fjender.
Tata-papiret kalder i afsnittet “Industristandardernes rolle” et vigtigt problem, et så vigtigt, at det faktisk kan være barrieren for fremskridt mod oss-moderniseringsmålet. Papiret citerer TMF-og ONF-modellerne til top-ned-design, men i hele papiret er det klart, at det “moderniserede” OSS/BSS skal integreres mere tæt med resten af netværks-og serviceøkosystemet. Vi har standarder for alle mulige stykker af enhver mulig netværksstrategi, og i nogle tilfælde konkurrerer standarderne endda. Vi har for nylig hørt bifald for forening af to forskellige operationer API specifikationer, f.eks. Vi bør spørge, hvordan vi kom til at have dem i første omgang.
TMF-papiret synes ikke kun at acceptere denne fragmentering af fremtiden, men afhænger af den. Afstå mekanisering af ting ud over OSS/BSS, og fokusere på at udnytte det “ud over” ting for at skabe tjenester som en pseudo-integrator. OK, det er måske ikke et urimeligt syn for TMF (en OSS/BSS-domineret krop) at tage, men det er en formel for at forblive uorganiseret, mens man står over for, hvad der næsten skal være en samlet initiativtransformation.
det er min opfattelse, at TMF var det logiske organ til at modernisere OSS/BSS, og at TMF (med NGOSS-kontrakt) udtænkte det centrale paradigme for begivenhedsstyring til processer via en datamodel, der er kritisk for denne modernisering. Alt andet papirerne beskriver, hver API nogen udvikler eller harmoniserer, enhver standardaktivitet rettet mod ethvert aspekt af drift og ledelse, skal passe ind i den NGOSS Kontraktramme. Hvis det skulle gøres, ville resultatet være præcis, hvad “NGOSS” står for.
modellen af TMF NGOSS-kontrakten er lige så værdifuld eller endnu mere værdifuld, hvis du træder ind i netværksdomænet. En ægte” kontrakt ” – tilstand / begivenhedsproces kunne styre alt om servicelivscyklussen, inklusive netværksstykket. Det følger heraf, at en netværkscentreret løsning let kunne udvides til tjenesten, OSS/BSS, domænet. Universaliteten af tilgangen er god for branchen, fordi automatisering af servicelivscyklus skal være universel for at være nyttig.
det bør også være baseret på state-of-the-art cloud-think. Begge papirer ser ud til at være enige i det, og alligevel skør begge spørgsmålet om, hvordan man får det til. Hvis du planlægger at bruge nuværende værktøjer til at opnå noget, skal du indramme din tilgang med hensyn til disse værktøjer. Du kan ikke acceptere forestillingen om, at du kan skrive specifikationer for alt, eller blot oversætte mål øverst til vilkårlige funktioner i bunden. Det er især sandsynligt at bide dig, da standardprocesserne tager år at komme til en konklusion. Vi implementerer 5G i dag, og standarderne er ikke færdige, og vil sandsynligvis ikke være før 2022. Jeg spekulerer på, om der er tid til de ting, da operatørerne allerede står over for faldende infrastruktur Roi ‘ er, der nærmer sig det kritiske punkt.
NGOSS kontrakt har eksisteret i omkring 13 år nu, og TMF fortalte mig engang, at det havde fået meget begrænset trækkraft. Det ser ikke ud til at blive spillet i det nuværende TMF-materiale, men som jeg har sagt, har jeg ikke adgang til de eneste medlemmer. Spørgsmålet er så, om TMF er parat til at fremme sin egen (blændende og unikke) indsigt, først inden for det smalle OSS/BSS-domæne og derefter i den bredere livscyklusautomatiseringsmission. Hvis det gør det, tager TMF sin retmæssige rolle i NGOSS evolution og definerer grundlaget for servicelivscyklusautomatisering generelt. Hvis det ikke gør det, vil det være op til et andet standardorgan eller open source-gruppe at hente faklen, og TMF bliver derefter nødt til at kæmpe for relevans i sit eget rum.
