Hva pokker er EN NGOSS? Jeg har brukt begrepet mye, knyttet til «NGOSS-Kontrakten», men for de som ikke er kjent MED OSS / BSS-rommet eller TMF, kan det være mystisk. Tata Consultancy Services, et stort og aktivt profesjonelt tjenestefirma, gjorde nylig et papir OM» reimagining » OSS / BSS, ET TMF-papir som spør om det er liv utover tilkoblingstjenester. Det er interessante kontraster og likheter mellom de to dokumentene, vel verdt å utforske.
NGOSS står for «Neste Generasjons Driftsstøttesystem». DET er et begrep som har vært mye brukt i minst 15 år, og det er ofte brukt AV TMF i sine spesifikasjoner. MYE AV TMF ting er medlemmer-bare skjønt, og så jeg kan ikke sitere det (eller, hvis jeg ikke er medlem på den tiden, kan ikke engang få tilgang til det) unntatt ved å oppsummere. TMF-papiret er spesielt nyttig på grunn av dette; det er et offentlig sammendrag av måten kroppen ser fremtiden for «transformasjon». Tata-papiret er interessant fordi det gjenspeiler en profesjonell tjenestesyn på samme transformasjonsprosess.
åpningen Av Tata-papiret har de vanlige platitudene om båndbredde. «Etter hvert som bedrifter i økende grad tilpasser seg en overveiende online modell i tråd med den nye virkeligheten, øker behovet for høy båndbredde og pålitelige nettverkstjenester. Følgelig opplever kommunikasjonstjenesteleverandører (CSPs) eksponentiell etterspørsel etter tjenester og er avhengige av fremgang i virtualiseringsteknologier for å fortsette å skalere til dagens priser.»
problemet med dette, foruten det er platitude status (en mer «eksponentiell» etterspørsel uttalelse og jeg vil spy), er at det virkelige problemet er ikke etterspørsel vekst, det er profitt krymping. Ingen operatør ville være misfornøyd med veksten i etterspørselen etter båndbredde, hvis de kunne lade trinnvis for veksten. De kan ikke, så de må enten finne noe annet enn båndbredde for å selge, eller kutte kostnadene ved å produsere båndbredde for å kompensere for at høyere båndbreddetjenester ikke genererer proporsjonalt høyere priser.
det samme problemet farger neste avsnitt, som kalles «Rethinking OSS-Funksjonen». DET siterer TMF mål FOR oss modernisering, ingen som selv innebærer å håndtere at profitt komprimering problem. Faktisk er den delen av dokumentet hvorfor mange operatørstrateger er for å skrape hele OSS / BSS-tingen og starte over. Det er ikke at ingen nyttige mål er satt (automatisering er en av egenskapene til en fremtidig OSS / BSS), men at ingenting mye er sagt om å oppnå dem.
som kommer i neste avsnitt, som kalles «Kjører Godt Orkestrerte Oss-Funksjoner». Denne delen gir endelig en anbefaling som er nyttig; OSS / BSS må gjøres hendelsesdrevet. JEG hadde håp her, FORDI TMF faktisk var kilden til nøkkelbegrepet I OSS og driftsautomatisering—DEN NGOSS-Kontrakten jeg nevnte i starten av denne bloggen. Dessverre, verken begrepet eller konseptet er hevet I Tata papir. «Fremtidige OSS-funksjoner må opprettes og tilbys som tjenester som består av mikrotjenester for å støtte automatisert ende-til-ende-orkestrering av hybride (fysiske, logiske og virtuelle) nettverksressurser.»
TMF papir, derimot, åpner med uttalelsen om at «tilkobling er med rette sett på som en lav margin virksomhet og er raskt commoditizing videre.»Målet med operatørene er» å få sin indre verden rett med en smidig teknologifundament og driftsmodell.»TMF inkluderer åpenbart sitt primære OSS / BSS-mål i denne indre verden, men like åpenbart må agile technology foundation utvide til infrastruktur.
mekanismen for å få sin «indre verden i orden» er, ved implikasjon, 5G. TMF sier AT det er kritisk for «å få mest mulig ut av det enormt dyre skiftet TIL 5G.» Men det ser ut til å bli motsagt av neste avsnitt, der den tidligere ADMINISTRERENDE DIREKTØREN i forumet sier «for forbrukere og smarte hjemmepersoner har ’tilkobling’ en tendens til å ha en egenverdi og er en gyldig ting å kjøpe. Når du går opp skalaen, men inn i bransjen transformasjon riket, tilkobling er bare verdsatt i så langt som det er knyttet til løsningen: «De ønsker ikke å kjøpe tilkobling fra deg, de ønsker å kjøpe en løsning.»5G er helt klart en tilkoblingsstrategi for forbrukerne, som all massemarkedsinfrastruktur er. Hvis vi antar at å «gå opp skalaen i bransjen transformasjon riket», som betyr forretningstjenester, er nøkkelen til å selge løsninger.
dette synes å argumentere for operatørene å fokusere sin «digital service provider» virksomhet på bedrifter, og for å gi løsninger er Det å være En SaaS-leverandør. Er det virkelig en smart tilnærming, gitt at det er en svært aktiv og konkurransedyktig offentlig skyvirksomhet som allerede selger løsninger til disse kundene? Spesielt når flertallet av profit-per-bit problemer operatører har kommer fra alt-du-kan-spise forbrukertjenester?
oppløsningen, sier Et Vodafone-sitat og andre kommentarer i TMF-papiret, er at » det vi nå kaller ‘tjenester’, vil ikke involvere telco alene, men vil omfatte en rekke partnere, inkludert telcos.»Dermed er telcos egentlig ikke digitale tjenesteleverandører i det hele tatt, men digitale tjenesteintegratorer eller forhandlere. Kan en bedrift som ser på transformasjon som et middel til å unnslippe profittpress, ha råd til å være forhandler av en annen spillers tjenester?
DET ser ut TIL AT TMFS visjon egentlig ikke sikter utover OSS / BSS i det hele tatt, men tyder på at operasjoner og tjenester utvikler seg til noe over tilkobling ved å samarbeide med de som leverer tjenester der oppe. Det kan være å beseire hele hensikten med «digital transformasjon», låse telcos i ikke bare deres nåværende nivå av disintermediation og commoditization, men også på et helt nytt nivå.
Begge papirene synes å antyde AT oss / BSS transformasjon er viktig, og i det minste antyde at en hendelsesdrevet tilnærming er svaret. Det er faktisk en god ide, men det savner utfordringen med » hvordan?»For å være hendelsesdrevet må et system gjenkjenne både begrepet hendelser (åpenbart) og begrepet «stat» eller kontekst. Alle som noen gang har sett på en protokollbehandler vet at den samme meldingen, i forskjellige sammenhenger / stater, må behandles annerledes. For eksempel er det klart en feil å få en «datapakke» – melding i «orderable» – tilstanden for en tjeneste, mens det er greit i «dataoverføring» – tilstanden. For at det skal være stater og hendelser og relaterte prosesser, trenger du en stat / hendelsestabell.
Stats – /hendelsestabeller er beskrivelser av de kollektive sammenhenger i et samarbeidssystem, og å tenke på å bygge dem er nyttig ved at det tvinger programvarearkitekter til å vurdere alle mulighetene, i stedet for å ha noe skje som faller gjennom sprekkene. Det er imidlertid en potensiell konflikt mellom verdien av tilstands – / hendelsestabeller og antall mulige tilstander og hendelser. Hvis du ser på et komplekst nettverk som et enormt, flatt system, vil du ha altfor stort bord til å implementere. TMF og mitt Eget ExperiaSphere-arbeid behandlet dette ved å dele komplekse systemer i «intensjonsmodeller» som hver hadde sine egne stat/hendelsesforhold. Hierarkisk sammensetning, kort sagt. DET er HVA NGOSS Kontrakt beskrevet.
poenget her er at begge papirene savner det som burde være sitt eget sterkeste punkt, som er at datamodelldrevet styring av hendelser til prosesser via komponentjusterte tilstandstabeller er måten å skape både hendelsesdrevet oppførsel og microservice-kompatibel design. Hvis en tjenestedatamodell driver en hendelse til en prosess, kan prosessen få den informasjonen den trenger fra tjenestedatamodellen alene, noe som betyr at den er statsløs og kan distribueres som en mikroservice eller til og med i serverløs form.
hvis DU trekker NGOSS-Kontraktstilnærmingen ut AV oss / BSS-moderniseringshistorien, er du igjen med det som har plaget hele forestillingen OM oss/BSS—modernisering fra de første platitudene. Vi kan snakke om bottom-up og top-down så lenge vi fokuserer på prosjektmetodologier, men en prosjektmetodikk driver et prosjekt, det skriver ikke programvare. En programvarearkitektur bør dukke opp fra metodikken. Det er et eget element, et resultat av den rette prosessen, men det er ikke den automatiske konsekvensen av å vri en tryllestav over en haug med data og chanting «top-down, top-down!»
som oppsummerer problemet mitt Med Tata-papiret. Prosjektmetodologier I IT og nettverk fører til applikasjons-eller tjenestearkitekturer, som deretter rammer kravene til komponentene i løsningen og måten de integreres og administreres på. Prosjektet er ikke utgangen, det er banen til utgangen. Problemet Med Tata-papiret er at Det er enda en beskrivelse av en prosjektmetodikk( en god, men ikke en transformativ), på et tidspunkt da vi lenge har søkt etter en vei TIL oss-modernisering og i stedet leter etter bestemte produkter, eller i det minste arkitekturer. TMF ser ut til å være på vei til samme sted ved en annen vei—forvandle ved partnerskap med dine tidligere fiender.
Tata-papiret kaller, i avsnittet «Industristandardens Rolle», et viktig problem, en så viktig at det faktisk kan være barrieren for fremgang mot oss-moderniseringsmålet. Papiret citerer TMF-og ONF-modellene for topp-down-design, men i hele papiret er det klart at DEN «moderniserte» OSS/BSS må være tettere integrert med resten av nettverks-og tjenesteøkosystemet. Vi har standarder for alle mulige deler av enhver mulig nettverksstrategi, og i noen tilfeller konkurrerer standardene selv. Vi har nylig hort applaus for forening av to forskjellige operations API-spesifikasjoner, for eksempel. Vi bør spørre hvordan vi kom til å ha dem i utgangspunktet.
TMF-papiret ser ut til å ikke bare akseptere denne fragmenteringen av fremtiden, men er avhengig av den. Cede mekaniseringen av ting utover OSS / BSS, og fokus på å utnytte det «utover» ting for å skape tjenester som en pseudo-integrator. OK, det kan ikke være et urimelig syn FOR TMF (EN OSS/BSS-dominert kropp) å ta, men det er en formel for å holde seg uorganisert mens du står overfor det som nesten må være en enhetlig initiativtransformasjon.
DET er min oppfatning AT TMF var den logiske kroppen til å modernisere OSS / BSS, og AT TMF (MED NGOSS-Kontrakt) utviklet det sentrale paradigmet for hendelsesstyring til prosesser via en datamodell, som er kritisk for denne moderniseringen. Alt annet papirene beskriver, HVER API noen utvikler eller harmoniserer, hver standardaktivitet rettet mot ethvert aspekt av drift og ledelse, bør passe inn i NGOSS-Kontraktsrammen. Hvis det skulle gjøres, ville resultatet være akkurat hva «NGOSS» står for.
MODELLEN TIL TMF NGOSS-Kontrakten er like verdifull, eller enda mer verdifull, hvis du går inn i nettverksdomenet. En ekte» kontrakt » tilstand / hendelsesprosess kunne klare alt om tjenestens livssyklus, inkludert nettverksstykket. Det følger at en nettverkssentrisk løsning lett kan utvides til tjenesten, oss / BSS, domenet. Universaliteten til tilnærmingen er bra for bransjen, fordi service lifecycle automation bør være universell for å være nyttig.
Det bør også være basert på state-of-the-art cloud-think. Begge papirene synes å være enige med det, og likevel begge skjørt spørsmålet om hvordan å få det til. Hvis du planlegger å bruke nåværende verktøy for å oppnå noe, må du ramme din tilnærming når det gjelder disse verktøyene. Du kan ikke akseptere ideen om at du kan skrive spesifikasjoner for alt, eller bare oversette mål øverst til vilkårlige funksjoner nederst. Det er spesielt sannsynlig å bite deg gitt at standardprosessene tar år å komme til en konklusjon. VI implementerer 5G i dag og standardene er ikke ferdige, og vil sannsynligvis ikke være før 2022. Jeg lurer på om det er tid for det, gitt at operatørene allerede står overfor fallende infrastruktur ROIs som nærmer seg det kritiske punktet.
NGOSS-Kontrakten har eksistert i ca 13 år nå, OG TMF fortalte meg en gang at den hadde fått svært begrenset trekkraft. Det ser ikke ut til å bli spilt i dagens TMF-materiale, men som jeg har sagt, har jeg ikke tilgang til medlemmenes eneste ting. Spørsmålet er da om TMF er forberedt på å fremme sin egen (blendende og unike) innsikt, først innenfor det smale oss/BSS-domenet og deretter i det bredere livssyklusautomatiseringsoppdraget. HVIS DEN gjør DET, TAR TMF sin rettmessige rolle I NGOSS evolusjon og definerer grunnlaget for service lifecycle automation generelt. Hvis DEN ikke gjør det, det vil være opp til noen andre standarder kroppen eller åpen kildekode-gruppe for å plukke opp fakkelen, OG TMF vil da måtte kjempe for relevans i sin egen plass.
