vad sjutton är en NGOSS? Jag har använt termen mycket, relaterat till ”NGOSS-kontraktet”, men för dem som inte är bekanta med OSS/BSS-rymden eller TMF kan det vara mystiskt. Tata Consultancy Services, ett stort och aktivt professionellt tjänsteföretag, gjorde nyligen ett papper om” reimagining ” OSS/BSS, ett TMF-papper som frågar om det finns liv bortom anslutningstjänster. Det finns intressanta kontraster och likheter mellan de två dokumenten, väl värda att utforska.
ngoss står för”Next-Generation Operations Support System”. Det är en term som har använts i stor utsträckning i minst 15 år, och det används ofta av TMF i deras specifikationer. Många av TMF-sakerna är dock bara medlemmar, och så kan jag inte citera det (eller, om jag inte är medlem vid den tiden, kan inte ens komma åt det) förutom genom att sammanfatta. TMF-papperet är särskilt användbart på grund av detta; det är en offentlig sammanfattning av hur kroppen ser framtiden för ”transformation”. Tata-papperet är intressant eftersom det återspeglar en professionell servicevy av samma omvandlingsprocess.
öppningen av Tata-papperet har de vanliga plattityderna om bandbredd. ”När företag i allt högre grad anpassar sig till en övervägande onlinemodell i linje med den nya verkligheten, ökar behovet av hög bandbredd och pålitliga nättjänster. Följaktligen upplever leverantörer av kommunikationstjänster (CSP) exponentiell efterfrågan på tjänster och är beroende av framsteg inom virtualiseringsteknik för att fortsätta skala till nuvarande priser.”
problemet med detta, förutom att det är platitude status (en mer ”exponentiell” efterfrågan uttalande och jag puke), är att den verkliga frågan är inte efterfrågan tillväxt, det är vinst krympning. Ingen operatör skulle vara missnöjd med tillväxten i efterfrågan på bandbredd, om de kunde ta betalt stegvis för tillväxten. De kan inte, så de måste antingen hitta något annat än bandbredd att sälja eller sänka kostnaden för att producera bandbredd för att kompensera det faktum att högre bandbreddstjänster inte genererar proportionellt högre priser.
samma fråga färgar nästa avsnitt, som kallas ”ompröva OSS-funktionen”. Det citerar TMF-mål för oss-modernisering, varav ingen ens innebär att hantera det vinstkomprimeringsproblemet. Faktum är att den delen av dokumentet är varför många operatörsstrateger är för att skrota hela OSS/BSS-saken och börja om. Det är inte så att inga användbara mål sätts (automatisering är en av attributen för en framtida OSS/BSS), men att inget mycket sägs om att uppnå dem.
som kommer i nästa avsnitt, som kallas”kör väl orkestrerade OSS-funktioner”. Det här avsnittet ger slutligen en rekommendation som är användbar; OSS / BSS måste göras händelsestyrd. Jag hade förhoppningar här, för TMF var faktiskt källan till nyckelbegreppet i oss och operations automation—det Ngoss-kontraktet jag nämnde i början av denna blogg. Tyvärr, varken termen eller konceptet tas upp i Tata-tidningen. Vad det säger är att ”framtida OSS-funktioner måste skapas och erbjudas som tjänster som består av mikrotjänster för att stödja automatiserad orkestrering av hybrid (fysiska, logiska och virtuella) nätverksresurser.”
TMF-papperet öppnar däremot med uttalandet att ” anslutning ses med rätta som en lågmarginalverksamhet och snabbt kommoditiseras ytterligare.”Operatörernas mål är” att få sin inre värld rätt med en smidig teknikgrund och verksamhetsmodell.”TMF inkluderar uppenbarligen sitt primära OSS / BSS-mål i denna inre värld, men lika uppenbart måste agile technology foundation sträcka sig till infrastruktur.
mekanismen för att få sin ”inre värld i ordning” är implicit 5G. TMF säger att det är kritiskt för att” få ut det mesta av det enormt dyra skiftet till 5G. ”men det verkar motsägas av nästa stycke, där forumets tidigare VD säger” för konsumenter och smarta hemindivider tenderar ”anslutning” att ha ett inneboende värde och är en giltig sak att köpa. När du går upp i skalan, men in i branschens omvandlingsområde, värderas anslutningen bara i den mån den är bunden till lösningen: ”de vill inte köpa anslutning från dig, de vill köpa en lösning.”5G är helt klart en anslutningsstrategi för konsumenterna, som all massmarknadsinfrastruktur är. Om vi antar att ”gå upp i skalan i branschomvandlingsområdet”, vilket betyder företagstjänster, är nyckeln att sälja lösningar.
detta verkar argumentera för operatörerna att fokusera sin ”digital service provider” – verksamhet på företag, och för att tillhandahålla lösningar ska det finnas en SaaS-leverantör. Är det verkligen ett smart tillvägagångssätt, med tanke på att det finns en mycket aktiv och konkurrenskraftig Offentlig molnverksamhet som redan säljer lösningar till dessa kunder? Speciellt när majoriteten av vinst-per-bit problem operatörer har kommer från allt-du-kan-äta konsumenttjänster?
resolutionen, säger ett Vodafone-citat och andra kommentarer i TMF-papperet, är att ”det vi nu kallar ”tjänster” inte kommer att involvera telco ensam, men kommer att bestå av en rad partners, inklusive telcos.”Således är telekom inte riktigt digitala tjänsteleverantörer alls, utan digitala tjänsteintegratörer eller återförsäljare. Kan ett företag som tittar på omvandling som ett sätt att undkomma vinstpressning ha råd att vara återförsäljare av en annan spelares tjänster?
det verkar för mig att TMF-visionen verkligen inte syftar utöver OSS/BSS alls, utan snarare föreslår att operationer och tjänster utvecklas till något över anslutning genom att samarbeta med dem som tillhandahåller tjänster där uppe. Det kan besegra hela syftet med” digital transformation”, låsa telekom till inte bara deras nuvarande nivå av disintermediation och commoditization, men också i en helt ny nivå.
båda uppsatserna tycks föreslå att oss / BSS-transformation är väsentlig, och innebär åtminstone att ett händelsestyrt tillvägagångssätt är svaret. Det är faktiskt en bra ide, men det missar utmaningen ”hur?”För att vara händelsestyrd måste ett system känna igen både begreppet händelser (uppenbarligen) och begreppet” stat ” eller sammanhang. Den som någonsin tittat på en protokollhanterare vet att samma meddelande, i olika sammanhang/stater, måste behandlas annorlunda. Att till exempel få ett ”datapaket” – meddelande i ”orderbart” tillstånd för en tjänst är helt klart ett fel, medan det är bra i ”dataöverföring” – läget. För att det ska finnas tillstånd och händelser och relaterade processer behöver du en stat/händelsetabell.
stat / händelsetabeller är beskrivningar av de kollektiva kontexterna i ett kooperativt system, och att tänka på att bygga dem är användbart genom att det tvingar mjukvaruarkitekter att överväga alla möjligheter, istället för att något händer som faller genom sprickorna. Det finns dock en potentiell konflikt mellan värdet på stat/händelsetabeller och antalet möjliga tillstånd och händelser. Om du tittar på ett komplext nätverk som ett enormt, platt system, skulle du ha alldeles för stort bord för att någonsin implementera. TMF och min egen ExperiaSphere arbete behandlas detta genom att dela komplexa system i” avsikt modeller ” att var och en hade sina egna tillstånd/händelse relationer. Hierarkisk sammansättning, kort sagt. Det är vad Ngoss kontrakt beskrivs.
poängen här är att båda papper saknar vad som borde vara sin egen starkaste punkt, vilket är att datamodelldriven styrning av händelser till processer via komponentjusterade tillstånd/händelsetabeller är sättet att skapa både händelsestyrt beteende och mikroservicekompatibel design. Om en tjänstedatamodell driver en händelse till en process kan processen få den information den behöver från tjänstedatamodellen ensam, vilket innebär att den är statslös och kan distribueras som en mikroservice eller till och med i serverlös form.
om du drar ngoss-kontraktets tillvägagångssätt ur oss / BSS moderniseringshistoria, är du kvar med det som har plågat hela begreppet oss/BSS modernisering från de första platituderna. Vi kan prata om bottom-up och top-down så länge vi fokuserar på projektmetoder, men en projektmetodik driver ett projekt, det skriver inte programvara. En mjukvaruarkitektur bör komma från metodiken. Det är ett separat element, ett resultat av rätt process, men det är inte den automatiska konsekvensen av att vifta en trollstav över en massa data och sjunga ”top-down, top-down!”
det sammanfattar mitt problem med Tata-papperet. Projektmetoder inom IT och nätverk leder till applikations-eller servicearkitekturer, som sedan ramar in kraven för komponenterna i lösningen och hur de integreras och hanteras. Projektet är inte utgången, det är vägen till utgången. Problemet med Tata-papperet är att det är ännu en beskrivning av en projektmetodik (en bra, men inte en transformativ), i en tid då vi länge letar efter en väg till oss-modernisering och istället letar efter specifika produkter, eller åtminstone arkitekturer. TMF verkar vara på väg till samma plats med en annan väg—omvandla genom partnerskap med dina tidigare fiender.
Tata-papperet kallar i avsnittet ”Industry Standards Roll” ett viktigt problem, en så viktig att det faktiskt kan vara hindret för framsteg mot OSS-moderniseringsmålet. Papperet citerar TMF-och ONF-modellerna för top-down-design, men i hela papperet är det tydligt att det ”moderniserade” OSS/BSS måste integreras mer tätt med resten av nätverks-och tjänsteekosystemet. Vi har standarder för alla möjliga delar av alla möjliga nätverksstrategier, och i vissa fall konkurrerar standarderna till och med. Vi hörde nyligen applåder för enandet av två olika API-specifikationer för operationer, till exempel. Vi borde fråga hur vi kom för att få dem i första hand.
TMF-dokumentet verkar inte bara acceptera denna fragmentering av framtiden utan beror på den. Cede mekaniseringen av saker bortom OSS / BSS, och fokusera på att utnyttja de ”bortom” sakerna för att skapa tjänster som en pseudo-integrator. OK, det kanske inte är en orimlig syn för TMF (en oss/BSS-dominerad kropp) att ta, men det är en formel för att hålla sig oorganiserad medan man står inför vad som nästan måste vara en enhetlig initiativtransformation.
det är min åsikt att TMF var den logiska kroppen för att modernisera OSS/BSS, och att TMF gjorde (med NGOSS-kontrakt) utforma det centrala paradigmet för händelsestyrning till processer via en datamodell, som är avgörande för denna modernisering. Allt annat som papper beskriver, varje API som någon utvecklar eller harmoniserar, varje standardaktivitet som syftar till någon aspekt av verksamheten och ledningen, bör passa in i den NGOSS-Kontraktsramen. Om det skulle göras skulle resultatet bli exakt vad” NGOSS ” står för.
modellen för TMF NGOSS-kontraktet är lika värdefull, eller ännu mer värdefull, om du går in i nätverksdomänen. En sann” kontrakt ” tillstånd/händelse process kunde hantera allt om livscykeln, inklusive nätverket Bit. Av detta följer att en nätverkscentrerad lösning lätt kan utökas till tjänsten, OSS/BSS, domänen. Universaliteten i tillvägagångssättet är bra för branschen, eftersom Service lifecycle automation bör vara universell för att vara användbar.
det bör också baseras på state-of-the-art cloud-think. Båda tidningarna verkar vara överens med det, och ändå ställer båda frågan om hur man ska få det till stånd. Om du planerar att använda nuvarande verktyg för att uppnå något, måste du rama in ditt tillvägagångssätt när det gäller dessa verktyg. Du kan inte acceptera tanken att du kan skriva specifikationer för allt, eller helt enkelt översätta mål högst upp till godtyckliga funktioner längst ner. Det är särskilt troligt att bita dig med tanke på att standardprocesserna tar år att komma till en slutsats. Vi distribuerar 5G idag och standarderna är inte färdiga, och kommer sannolikt inte att vara förrän 2022. Jag undrar om det finns tid för det där, med tanke på att operatörerna redan står inför fallande Infrastruktur Roi som närmar sig den kritiska punkten.
Ngoss-kontraktet har funnits i ungefär 13 år nu, och TMF berättade en gång för mig att det hade fått mycket begränsad dragkraft. Det verkar inte spelas i det aktuella TMF-materialet, men som jag har sagt har jag inte tillgång till medlemmarnas enda saker. Frågan Är då om TMF är beredd att främja sin egen (bländande och unika) insikt, först inom den smala OSS/BSS-domänen och sedan i det bredare lifecycle automation-uppdraget. Om det gör det tar TMF sin rättmätiga roll i ngoss evolution och definierar grunden för Service lifecycle automation övergripande. Om det inte gör det kommer det att vara upp till någon annan standardkropp eller öppen källkodsgrupp att hämta facklan, och TMF måste då kämpa för relevans i sitt eget utrymme.
