co to sakra je NGOSS? Použil jsem termín hodně, vztahující se k „smlouvě NGOSS“, ale pro ty, kteří nejsou obeznámeni s prostorem OSS/BSS nebo TMF, může to být záhadné. Tata Consultancy Services, velká a aktivní firma poskytující profesionální služby, nedávno vypracovala dokument o „reimagining“ OSS / BSS, TMF papír s dotazem, zda existuje život mimo služby připojení. Mezi těmito dvěma dokumenty jsou zajímavé kontrasty a podobnosti, které stojí za prozkoumání.
NGOSS je zkratka pro „systém podpory provozu nové generace“. Je to termín, který byl široce používán po dobu nejméně 15 let a TMF jej často používá ve svých specifikacích. Mnoho věcí TMF je však pouze pro členy, a tak to nemohu citovat (nebo, pokud nejsem v té době členem, nemůžu k němu ani přistupovat), s výjimkou shrnutí. Papír TMF je z tohoto důvodu obzvláště užitečný; je to veřejné shrnutí toho, jak tělo vidí budoucnost „transformace“. Příspěvek Tata je zajímavý, protože odráží pohled na stejný proces transformace profesionálními službami.
otevření Tata papíru má obvyklé fráze o šířce pásma. „Vzhledem k tomu, že se podniky stále více přizpůsobují převážně online modelu v souladu s novou realitou, roste potřeba velké šířky pásma a spolehlivých síťových služeb. V důsledku toho poskytovatelé komunikačních služeb (CSP) zažívají exponenciální poptávku po službách a jsou závislí na pokroku ve virtualizačních technologiích, aby pokračovali v škálování při současných sazbách.“
problém s tím, kromě toho, že je to stav fráze (ještě jedno“ exponenciální “ prohlášení o poptávce a budu zvracet), je, že skutečným problémem není růst poptávky, je to smrštění zisku. Žádný operátor by nebyl spokojen s růstem poptávky po šířce pásma, pokud by mohl za růst účtovat postupně. Nemohou, takže musí buď najít něco jiného než šířku pásma k prodeji, nebo snížit náklady na výrobu šířky pásma, aby kompenzovali skutečnost, že služby s vyšší šířkou pásma negenerují úměrně vyšší ceny.
stejný problém vybarví další část, která se nazývá „přehodnocení funkce OSS“. Cituje cíle TMF pro modernizaci OSS, z nichž žádný neznamená řešení tohoto problému komprese zisku. Ve skutečnosti je tato část dokumentu důvodem, proč mnoho stratégů operátorů podporuje vyřazení celé věci OSS / BSS a začátek znovu. Není to tak, že nejsou stanoveny žádné užitečné cíle (automatizace je jedním z atributů budoucího OSS / BSS), ale o jejich dosažení se nic neříká.
který přichází v další části, která se nazývá „řízení dobře řízených funkcí OSS“. Tato část konečně dává doporučení, které je užitečné; OSS / BSS musí být řízen událostmi. Měl jsem zde naděje, protože TMF byl ve skutečnosti zdrojem klíčového konceptu v OSS a automatizaci operací—tuto smlouvu NGOSS jsem zmínil na začátku tohoto blogu. Bohužel, ani termín, ani koncept není vznesen v příspěvku Tata. Říká se, že „budoucí funkce OSS musí být vytvořeny a nabízeny jako služby složené z mikroservisů pro podporu automatizované end-to-end orchestrace hybridních (fyzických, logických a virtuálních) síťových zdrojů.“
papír TMF naproti tomu začíná tvrzením, že “ konektivita je právem považována za obchod s nízkou marží a rychle se dále komoditizuje.“Cílem operátorů je“ napravit svůj vnitřní svět pomocí agilního technologického základu a provozního modelu.“TMF samozřejmě zahrnuje svůj primární cíl OSS / BSS v tomto vnitřním světě, ale stejně tak se agile technology foundation musí rozšířit na infrastrukturu.
mechanismus, jak dostat svůj „vnitřní svět do pořádku“, je implicitně 5g. TMF říká, že je důležité, aby „co nejvíce využil nesmírně nákladný přechod na 5G.“ zdá se však, že to je v rozporu s dalším odstavcem, kde bývalý generální ředitel fóra říká: „pro spotřebitele a inteligentní domácí jednotlivce má „konektivita“ tendenci mít vnitřní hodnotu a je platnou věcí k nákupu. Jak však stoupáte v měřítku, do oblasti transformace průmyslu, konektivita je oceňována pouze tehdy, pokud je vázána na řešení: „nechtějí od vás kupovat konektivitu, chtějí si koupit řešení.“5G je jednoznačně strategií konektivity pro spotřebitele, protože veškerá infrastruktura masového trhu je. Pokud předpokládáme, že „jít nahoru do oblasti transformace průmyslu“, což znamená obchodní služby, klíčem je prodávat řešení.
zdá se, že to argumentuje pro operátory, aby zaměřili své podnikání „poskytovatele digitálních služeb“ na podniky a aby poskytovali řešení, musí existovat poskytovatel SaaS. Je to opravdu chytrý přístup, vzhledem k tomu, že existuje vysoce aktivní a konkurenceschopný veřejný cloudový obchod, který již prodává řešení těmto zákazníkům? Zvláště když většina problémů se ziskem za bit operátoři pocházejí z all-you-can-eat spotřebitelských služeb?
usnesení, říká citát Vodafone a další komentáře v dokumentu TMF, je, že „to, čemu nyní říkáme „služby“, nebude zahrnovat samotné telco, ale bude zahrnovat řadu partnerů, včetně telcos.“Telcos tedy vůbec nejsou poskytovateli digitálních služeb, ale integrátory digitálních služeb nebo prodejci. Může si podnik, který se dívá na transformaci jako na prostředek úniku zisku, dovolit být prodejcem služeb jiného hráče?
zdá se mi, že vize TMF opravdu nemíří za OSS/BSS vůbec, ale spíše naznačuje, že operace a služby se vyvíjejí na něco nad konektivitou tím, že spolupracují s těmi, kteří tam poskytují služby. To by mohlo být porážkou celého účelu „digitální transformace“, zamykání telcos nejen do jejich současné úrovně dezintermediace a komoditizace, ale také do zcela nové úrovně.
zdá se, že oba dokumenty naznačují, že transformace OSS/BSS je nezbytná, a přinejmenším naznačují, že řešením je přístup založený na událostech. To je vlastně dobrý nápad ,ale postrádá výzvu “ jak?“Aby byl systém řízen událostmi, musí rozpoznat jak koncept událostí (samozřejmě), tak pojem „stát“ nebo kontext. Každý, kdo se někdy podíval na obsluhu protokolu, ví, že stejná zpráva v různých kontextech/stavech musí být zpracována odlišně. Například získání zprávy „datový paket“ ve stavu “ objednatelné „pro službu je zjevně chyba, zatímco ve stavu“ přenos dat “ je v pořádku. Aby existovaly stavy a události a související procesy, potřebujete tabulku stavů/událostí.
tabulky stavů / událostí jsou popisy kolektivních kontextů kooperativního systému a přemýšlení o jejich budování je užitečné v tom, že nutí softwarové architekty, aby zvážili všechny možnosti, místo aby se stalo něco, co propadne trhlinami. Existuje však potenciální konflikt mezi hodnotou tabulek stavu/událostí a počtem možných stavů a událostí. Pokud se podíváte na komplexní síť jako na jeden obrovský, plochý systém, měli byste příliš velký stůl, který byste kdy implementovali. TMF a moje vlastní práce ExperiaSphere to řešily rozdělením složitých systémů na „modely záměrů“, z nichž každý měl své vlastní vztahy mezi stavem a událostí. Hierarchické složení, zkrátka. To je to, co NGOSS Contract popsal.
jde o to, že oběma dokumentům chybí to, co by mělo být jeho nejsilnějším bodem, což je to, že řízení událostí řízených datovým modelem k procesům prostřednictvím tabulek stavů/událostí zarovnaných s komponentami je způsob, jak vytvořit jak chování založené na událostech,tak i design Kompatibilní s microservice. Pokud datový model služby řídí událost do procesu, proces může získat informace, které potřebuje, pouze z datového modelu služby, což znamená, že je bez státní příslušnosti a může být nasazen jako mikroservis nebo dokonce ve formě bez serveru.
pokud vytáhnete přístup NGOSS-Contract z příběhu o modernizaci OSS / BSS, zůstanete s věcí, která trápila celou představu o modernizaci OSS / BSS od prvních frází. Můžeme mluvit o zdola nahoru a shora dolů, pokud se zaměřujeme na projektové metodiky, ale projektová metodika řídí projekt, nepíše software. Z metodiky by měla vzejít softwarová architektura. To je samostatný prvek, výsledek správného procesu, ale není to automatický důsledek mávání hůlkou nad spoustou dat a skandování „shora dolů, shora dolů!“
to shrnuje můj problém s papírem Tata. Projektové metodiky v oblasti IT a sítí vedou k architekturám aplikací nebo služeb, které pak rámují požadavky na komponenty řešení a způsob jejich integrace a správy. Projekt není výstup, je to cesta k výstupu. Problém s Tata papírem je, že je to další popis metodiky projektu (dobrá, ale ne transformativní), v době, kdy už dávno hledáme cestu k modernizaci OSS a místo toho hledáme konkrétní produkty, nebo alespoň architektury. Zdá se, že TMF míří na stejné místo jinou cestou-transformací partnerství se svými bývalými nepřáteli.
dokument Tata v části nazvané „Role průmyslových standardů“ volá po důležitém problému, který je tak důležitý, že by ve skutečnosti mohl být překážkou pokroku směrem k cíli modernizace OSS. Článek cituje modely TMF a ONF pro návrh shora dolů, ale v celém článku je jasné, že „modernizovaný“ OSS/BSS musí být těsněji integrován se zbytkem síťového a servisního ekosystému. Máme standardy pro každou možnou část každé možné síťové strategie a v některých případech standardy dokonce konkurují. Nedávno jsme například slyšeli potlesk za sjednocení dvou různých specifikací API pro operace. Měli bychom se ptát, jak jsme k nim přišli.
zdá se, že papír TMF nejen přijímá tuto fragmentaci budoucnosti, ale závisí na tom. Postoupit mechanizaci věci mimo OSS / BSS, a zaměřit se na využití, že“ mimo “ věci vytvořit služby jako pseudointegrátor. OK, to nemusí být nepřiměřený pohled na TMF (orgán ovládaný OSS/BSS), ale je to vzorec pro to, aby zůstal neuspořádaný a čelil tomu, co téměř musí být jednotná iniciativa-transformace.
domnívám se, že TMF byl logickým orgánem pro modernizaci OSS / BSS a že TMF (se smlouvou NGOSS) vymyslel centrální paradigma řízení událostí k procesům prostřednictvím datového modelu, což je pro tuto modernizaci zásadní. Všechno ostatní, co papíry popisují, každé API, které někdo vyvíjí nebo harmonizuje, každá aktivita standardů zaměřená na jakýkoli aspekt provozu a řízení, by měl být v souladu s tímto smluvním rámcem NGOSS. Pokud by to mělo být provedeno, výsledkem by bylo přesně to, co znamená „NGOSS“.
model smlouvy TMF NGOSS je stejně cenný, nebo dokonce cennější, pokud vstoupíte do síťové domény. Skutečný proces stavu/události“ smlouvy “ by mohl spravovat vše o životním cyklu služby, včetně síťového kusu. Z toho vyplývá, že síťové řešení by mohlo být snadno rozšířeno do služby, domény OSS/BSS. Univerzálnost tohoto přístupu je pro průmysl dobrá, protože automatizace životního cyklu služeb by měla být univerzální, aby byla užitečná.
měl by být také založen na nejmodernějším cloudovém myšlení. Zdá se, že s tím oba dokumenty souhlasí, a přesto oba obcházejí otázku, jak to dosáhnout. Pokud plánujete použít současné nástroje k dosažení něčeho, musíte svůj přístup zarámovat z hlediska těchto nástrojů. Nemůžete přijmout představu, že můžete psát specifikace pro všechno, nebo jednoduše přeložit cíle nahoře na libovolné funkce dole. To je obzvláště pravděpodobné, že vás kousne vzhledem k tomu, že normalizační procesy trvají roky, než dospějí k závěru. Dnes nasazujeme 5G a standardy nejsou dokončeny a pravděpodobně nebudou dříve než v roce 2022. Zajímalo by mě, jestli je na to čas, vzhledem k tomu, že operátoři již čelí klesajícím Roi infrastruktury, které se blíží kritickému bodu.
smlouva NGOSS existuje již asi 13 let a TMF mi jednou řekl, že získala velmi omezenou trakci. Nezdá se, že by se hrálo v aktuálním materiálu TMF, i když, jak jsem řekl,nemám přístup k věcem pouze pro členy. Otázkou tedy je, zda je TMF připravena propagovat svůj vlastní (oslnivý a jedinečný) vhled, nejprve v úzké doméně OSS / BSS a poté v širší misi automatizace životního cyklu. Pokud ano, TMF převezme svou oprávněnou roli v NGOSS evolution a definuje základ pro automatizaci životního cyklu služby celkově. Pokud tomu tak není, bude to na nějakém jiném normalizačním orgánu nebo open-source skupině, aby vyzvedl pochodeň, a TMF pak bude muset bojovat o relevanci ve svém vlastním prostoru.
