Wat is een NGOs? Ik heb de term veel gebruikt, met betrekking tot de” Ngoss Contract”, maar voor degenen die niet bekend zijn met de OSS/BSS ruimte of de TMF, het kan mysterieus zijn. Tata Consultancy Services, een grote en actieve professionele dienstverlener, deed onlangs een paper over “reimagining” de OSS / BSS, een TMF paper met de vraag of er leven is buiten connectiviteitsdiensten. Er zijn interessante contrasten en overeenkomsten tussen de twee documenten, zeker de moeite waard om te verkennen.
NGOSS staat voor “Next-Generation Operations Support System”. Het is een term die op grote schaal wordt gebruikt voor ten minste 15 jaar, en het wordt vaak gebruikt door de TMF in hun specificaties. Veel van het TMF materiaal is echter alleen leden, en dus kan ik het niet citeren (of, als ik op dat moment geen lid ben, kan ik er zelfs geen toegang toe hebben), behalve door het samen te vatten. Het TMF-document is daarom bijzonder nuttig; het is een publieke samenvatting van de manier waarop het lichaam de toekomst van “transformatie”ziet. De Tata paper is interessant omdat het weerspiegelt een professionele-diensten kijk op hetzelfde proces van transformatie.
het openen van het Tata-papier heeft de gebruikelijke gemeenplaatsen over bandbreedte. “Nu bedrijven zich steeds meer aanpassen aan een overwegend online model in lijn met de nieuwe realiteit, stijgt de behoefte aan hoge bandbreedte en betrouwbare netwerkdiensten. Bijgevolg ervaren aanbieders van communicatiediensten (CSP ‘ s) een exponentiële vraag naar diensten en zijn ze afhankelijk van de vooruitgang in virtualisatietechnologieën om te blijven schalen in de huidige tempo.”
het probleem met dit, naast zijn platitude status (Nog een “exponentiële” vraag statement en Ik zal kotsen), is dat het echte probleem is niet de vraag groei, het is winst krimp. Geen enkele operator zou ontevreden zijn met de groei van de vraag naar bandbreedte, als ze stapsgewijs konden rekenen voor de groei. Dat kunnen ze niet, dus moeten ze ofwel iets anders dan bandbreedte vinden om te verkopen, of de kosten van het produceren van bandbreedte verlagen om het feit te compenseren dat hogere bandbreedte diensten niet proportioneel hogere prijzen genereren.
ditzelfde probleem kleurt de volgende sectie, die “herdenken van de Oss-functie”wordt genoemd. Het citeert TMF-doelstellingen voor Oss modernisering, geen van die zelfs impliceren omgaan met dat winst compressie probleem. In feite, dat deel van het document is de reden waarom veel operator strategen zijn voor het schrappen van de hele OSS/BSS ding en opnieuw beginnen. Het is niet dat er geen nuttige doelen worden gesteld (Automatisering is een van de attributen van een toekomstige OSS/BSS), maar dat er niet veel wordt gezegd over het bereiken ervan.
dat komt in de volgende sectie, die “goed georkestreerde Oss-functies aansturen”wordt genoemd. Deze sectie tenslotte doet een aanbeveling die nuttig is; OSS/BSS moet worden gemaakt event-driven. Ik had hoop hier, omdat de TMF was in feite de bron van de belangrijkste concept in OSS en operations automation—dat NGOSS Contract ik noemde aan het begin van deze blog. Helaas wordt noch de term noch het concept in de Tata paper genoemd. Wat het zegt is dat ” toekomstige Oss-functies moeten worden gemaakt en aangeboden als diensten die bestaan uit microservices ter ondersteuning van geautomatiseerde end-to-end orkestratie van hybride (fysieke, logische, en virtuele) netwerkbronnen.”
het TMF-document opent daarentegen met de verklaring dat ” connectiviteit terecht wordt gezien als een bedrijf met een lage marge en snel verder commoditiseert.”Het doel van de operators is” om hun interieurwereld op orde te krijgen met een agile technologiebasis en bedrijfsmodel.”De TMF heeft uiteraard zijn primaire OSS/BSS-doelstelling in deze interieurwereld, maar net zo vanzelfsprekend moet de agile technology foundation zich uitbreiden naar Infrastructuur.
het mechanisme om hun “interieurwereld op orde te krijgen” is, impliciet, 5G. de TMF zegt dat het van cruciaal belang is om “het meeste te halen uit de enorm dure verschuiving naar 5G.” maar dat lijkt tegengesproken door de volgende paragraaf, waar de voormalige CEO van het forum zegt “voor consumenten en smart home individuals, ‘connectiviteit’ heeft de neiging om een intrinsieke waarde te hebben en is een geldig ding om te kopen. Maar als je de schaal opgaat in de transformatie van de industrie, wordt connectiviteit alleen gewaardeerd voor zover het verbonden is met de oplossing: “ze willen geen connectiviteit van je kopen, ze willen een oplossing kopen.”5G is duidelijk een connectiviteitsstrategie voor consumenten, zoals alle Massa-marktinfrastructuur. Als we ervan uitgaan dat om” de schaal op te gaan in de sector transformatie rijk”, wat Zakelijke diensten betekent, de sleutel is om oplossingen te verkopen.
dit lijkt te pleiten voor de exploitanten om hun “digitale dienstverlener” – activiteiten op ondernemingen te richten en oplossingen aan te dragen voor de oprichting van een SaaS-aanbieder. Is dat echt een slimme aanpak, gezien het feit dat er een zeer actieve en concurrerende public cloud bedrijf al verkopen oplossingen aan die klanten? Vooral als de meerderheid van de winst-per-bit problemen operators hebben komt uit all-you-can-eat consumentendiensten?
de resolutie, zegt een citaat van Vodafone en andere opmerkingen in de TMF paper, is dat “wat we nu noemen ‘diensten’ zal niet de telco alleen betrekken, maar zal bestaan uit een scala van partners, waaronder de telco ‘ s.”De telco’ s zijn dus helemaal geen digitale serviceproviders, maar digital service integrators of resellers. Kan een bedrijf dat op zoek is naar transformatie als een middel om te ontsnappen winst squeeze veroorloven om een reseller van de diensten van een andere speler?
het lijkt me dat de TMF-visie echt niet verder gaat dan de OSS/BSS, maar veeleer suggereert dat operaties en diensten evolueren naar iets boven connectiviteit door samen te werken met degenen die daar diensten leveren. Dat zou kunnen zijn het verslaan van het hele doel van” digitale transformatie”, het vergrendelen van de telco ‘ s in niet alleen hun huidige niveau van desintermediatie en commoditisation, maar ook in een geheel nieuw niveau.
beide papers lijken te suggereren dat OSS / BSS transformatie essentieel is, en in ieder geval impliceren dat een event-driven approach het antwoord is. Dat is eigenlijk een goed idee, maar het mist de uitdaging van ” hoe?”Om event-driven te zijn, moet een systeem zowel het concept van gebeurtenissen (uiteraard) als het concept van “staat” of context herkennen. Iedereen die ooit naar een protocol handler heeft gekeken, weet dat hetzelfde bericht, in verschillende contexten/Staten, anders moet worden verwerkt. Bijvoorbeeld, het krijgen van een” data packet “bericht in de” orderable “status voor een service is duidelijk een fout, terwijl het prima is in de” data transfer ” status. Om er Staten en gebeurtenissen en gerelateerde processen, moet u een staat/gebeurtenis tabel.
staat / gebeurtenistabellen zijn beschrijvingen van de collectieve contexten van een coöperatief systeem, en het nadenken over het bouwen ervan is nuttig omdat het softwarearchitecten dwingt om alle mogelijkheden te overwegen, in plaats van dat er iets gebeurt dat door de mazen valt. Echter, er is een potentieel conflict tussen de waarde van de toestand/gebeurtenis tabellen en het aantal mogelijke toestanden en gebeurtenissen. Als je naar een complex netwerk kijkt als één enorm, plat systeem, dan heb je een veel te grote tafel om ooit te implementeren. Het TMF en mijn eigen Ervaringswerk gingen hiermee om door complexe systemen op te delen in “intent models” die elk hun eigen staat/event relaties hadden. Hiërarchische samenstelling, kortom. Dat is wat NGOSS Contract beschreef.
het punt hier is dat beide papers missen wat zijn eigen sterkste punt zou moeten zijn, namelijk dat data-modelgestuurde sturing van gebeurtenissen naar processen via component-uitgelijnde status/gebeurtenistabellen de manier is om zowel event-driven gedrag als microservice-compatibel ontwerp te creëren. Als een servicedatamodel een gebeurtenis naar een proces stuurt, kan het proces de informatie krijgen die het nodig heeft uit het servicedatamodel alleen, wat betekent dat het statenloos is en kan worden ingezet als een microservice of zelfs in serverloze vorm.
als je de Ngoss-Contract aanpak uit het OSS/BSS—moderniseringsverhaal haalt, blijft er over wat de hele notie van OSS/BSS-modernisering heeft geteisterd vanaf de eerste platitudes. We kunnen praten over bottom-up en top-down zolang we ons richten op projectmethodologieën, maar een projectmethodologie drijft een project aan, het schrijft geen software. Uit de methodologie moet een softwarearchitectuur ontstaan. Dat is een apart element, een resultaat van het juiste proces, maar het is niet het automatische gevolg van het zwaaien met een toverstok over een hoop data en het zingen “top-down, top-down!”
dat vat mijn probleem met het Tata-papier samen. Projectmethodologieën in IT en netwerken leiden tot applicatiearchitecturen of dienstenarchitecturen, die vervolgens de vereisten voor de componenten van de oplossing en de manier waarop ze worden geà ntegreerd en beheerd kaderen. Het project is niet de output, het is het pad naar de output. Het probleem met de Tata paper is dat het nog een beschrijving van een project methodologie (een goede, maar niet een transformatieve), op een moment dat we lang voorbij het zoeken naar een pad naar Oss modernisering en in plaats daarvan zijn op zoek naar specifieke producten, of op zijn minst architecturen. De TMF lijkt op weg naar dezelfde plaats door een ander pad—transformeren door samenwerking met je voormalige vijanden.
in het Tata-document wordt in het hoofdstuk “de rol van industriestandaarden” een belangrijk probleem genoemd, dat zo belangrijk is dat het in feite een belemmering kan vormen voor de verwezenlijking van de OSS-moderniseringsdoelstelling. Het papier citeert de TMF en ONF modellen voor top-down ontwerp, maar in het hele papier is het duidelijk dat de “gemoderniseerde” OSS/BSS moet worden strakker geïntegreerd met de rest van het netwerk en service ecosysteem. We hebben normen voor elk mogelijk onderdeel van elke mogelijke netwerkstrategie, en in sommige gevallen concurreren de normen zelfs. We hoorden onlangs applaus voor de eenmaking van twee verschillende operations API specificaties, bijvoorbeeld. We moeten ons afvragen hoe we ze hebben gekregen.
het TMF-document lijkt niet alleen deze fragmentatie van de toekomst te accepteren, maar er ook van afhankelijk te zijn. Geef de mechanisatie van dingen buiten OSS/BSS, en focus op het benutten van dat” verder ” spul om diensten te creëren als een pseudo-integrator. OK, dat is misschien geen onredelijke visie voor de TMF (een OSS/BSS-gedomineerde instantie) om te nemen, maar het is een formule om ongeorganiseerd te blijven terwijl je geconfronteerd wordt met wat bijna een verenigd initiatief moet zijn—transformatie.
het is mijn mening dat de TMF de logische instantie was om de OSS/BSS te moderniseren, en dat de TMF (met NGOSS Contract) het centrale paradigma bedacht van event sturing naar processen via een datamodel, dat cruciaal is voor deze modernisering. Al het andere dat de papers beschrijven, elke API die iemand ontwikkelt of harmoniseert, elke norm activiteit gericht op elk aspect van de activiteiten en het beheer, moet passen in dat Ngoss Contract framework. Als dat zou gebeuren, zou het resultaat precies zijn waar “NGOSS” voor staat.
het model van het TMF NGOSS-Contract is net zo waardevol, of zelfs nog waardevoller, als u in het netwerkdomein stapt. Een echt” contract ” staat / event proces kan alles over de service levenscyclus te beheren, met inbegrip van het netwerk stuk. Hieruit volgt dat een netwerk-centric oplossing gemakkelijk kan worden uitgebreid naar de service, het OSS/BSS, domein. De universaliteit van de aanpak is goed voor de industrie, omdat automatisering van de levenscyclus van diensten universeel moet zijn om nuttig te zijn.
het moet ook gebaseerd zijn op state-of-the-art cloud-think. Beide kranten lijken het daarmee eens te zijn, en toch gaan beide voorbij aan de vraag hoe dat tot stand kan worden gebracht. Als je van plan bent om de huidige tools te gebruiken om iets te bereiken, moet je je aanpak in termen van die tools frame. Je kunt het idee niet accepteren dat je specificaties voor alles kunt schrijven, of gewoon doelen aan de bovenkant kunt vertalen naar willekeurige functies aan de onderkant. Dat is vooral waarschijnlijk te bijten u gezien het feit dat de normen processen jaren duren om tot een conclusie te komen. We implementeren 5G vandaag en de normen zijn niet klaar, en waarschijnlijk zal niet tot 2022. Ik vraag me af of er tijd is voor dat spul, gezien het feit dat exploitanten al geconfronteerd worden met dalende infrastructuur ROI ‘ s die het kritieke punt naderen.
NGOSS Contract bestaat nu ongeveer 13 jaar, en de TMF vertelde me eens dat het zeer beperkte tractie had opgedaan. Het lijkt niet te worden gespeeld in het huidige TMF materiaal, hoewel, zoals ik al zei, Ik heb geen toegang tot de leden-only spullen. De vraag is dan of het TMF bereid is om zijn eigen (schitterende en unieke) inzicht te promoten, eerst binnen het smalle OSS/BSS domein en vervolgens in de bredere missie van lifecycle automation. Als dat gebeurt, neemt de TMF zijn rechtmatige rol in de evolutie van NGOSS en bepaalt de basis voor service lifecycle automation in het algemeen. Als dat niet het geval is, zal het aan een andere standaard instantie of open-source groep zijn om de fakkel op te pakken, en de TMF zal dan moeten vechten voor relevantie in zijn eigen ruimte.
