mi a fene az az NGOSS? Sokat használtam a kifejezést az “NGOSS szerződéssel” kapcsolatban, de azok számára, akik nem ismerik az OSS/BSS teret vagy a TMF-et, titokzatos lehet. A Tata Consultancy Services, egy nagy és aktív professzionális szolgáltató cég, nemrégiben készített egy tanulmányt az OSS/BSS “újragondolásáról”, egy TMF-papírról, amely azt kérdezi, hogy van-e élet a csatlakozási szolgáltatásokon túl. Érdekes ellentétek és hasonlóságok vannak a két dokumentum között, amelyeket érdemes feltárni.
NGOSS jelentése “Next-Generation Operations Support System”. Ez egy olyan kifejezés, amelyet legalább 15 éve széles körben használnak, és a TMF gyakran használja a specifikációikban. A TMF cuccok nagy része azonban csak tagok, ezért nem tudom idézni (vagy ha akkor nem vagyok tag, akkor még csak nem is férhetek hozzá), kivéve az összefoglalást. A TMF papír különösen hasznos, mert ez egy nyilvános összefoglaló arról, hogy a test hogyan látja az “átalakulás”jövőjét. A Tata dolgozat azért érdekes, mert a szakmai-szolgáltatási szemléletet tükrözi ugyanarról az átalakulási folyamatról.
a Tata papír nyitásakor a szokásos közhelyek vannak a sávszélességről. “Ahogy a vállalkozások egyre inkább alkalmazkodnak a túlnyomórészt online modellhez, összhangban az új valósággal, a nagy sávszélesség és a megbízható hálózati szolgáltatások iránti igény növekszik. Következésképpen a kommunikációs szolgáltatók (CSP-k) exponenciális keresletet tapasztalnak a szolgáltatások iránt, és a virtualizációs technológiák fejlődésétől függenek, hogy a jelenlegi ütemben folytathassák a méretezést.”
a probléma ezzel, amellett, hogy közhely státusz (még egy “exponenciális” kereslet nyilatkozat és hányok), hogy az igazi kérdés nem a kereslet növekedése, hanem a profit zsugorodása. Egyetlen operátor sem lenne elégedetlen a sávszélesség iránti kereslet növekedésével, ha fokozatosan felszámíthatnák a növekedést. Nem tudnak, ezért vagy a sávszélességen kívül mást kell találniuk az eladáshoz, vagy csökkenteniük kell a sávszélesség előállításának költségeit, hogy ellensúlyozzák azt a tényt, hogy a nagyobb sávszélességű szolgáltatások nem generálnak arányosan magasabb árakat.
ugyanez a kérdés színezi a következő részt, amelyet “az OSS funkció újragondolása” – nak hívnak. Idézi a TMF célkitűzéseit az OSS korszerűsítésére, amelyek egyike sem jelenti azt, hogy foglalkoznának ezzel a profittömörítési problémával. Valójában a dokumentumnak ez a része az oka annak, hogy sok operátor stratéga támogatja az egész OSS/BSS dolog megszüntetését és az újrakezdést. Nem arról van szó, hogy nincsenek hasznos célok kitűzve (az automatizálás a jövőbeli OSS/BSS egyik tulajdonsága), hanem arról, hogy ezek eléréséről nem sokat mondanak.
hogy jön a következő részben, amely az úgynevezett “vezetés jól hangszerelt OSS funkciók”. Ez a szakasz végül hasznos ajánlást tesz; az OSS/BSS-t eseményvezéreltvé kell tenni. Reménykedtem itt, mert a TMF valójában az OSS és az operations automation kulcskoncepciójának forrása volt—ezt az NGOSS szerződést említettem a blog elején. Sajnos sem a kifejezés, sem a koncepció nem merül fel a Tata-dolgozatban. “A jövőbeli OSS funkciókat mikroszolgáltatásokból álló szolgáltatásokként kell létrehozni és kínálni, hogy támogassák a hibrid (fizikai, logikai és virtuális) hálózati erőforrások automatizált végpontok közötti összehangolását.”
a TMF papír ezzel szemben azzal a kijelentéssel nyit, hogy “a konnektivitást jogosan tekintik alacsony árrésű üzletnek, és gyorsan tovább árucikké válik.”Az üzemeltetők célja, hogy” megfelelővé tegyék belső világukat egy agilis technológiai alap és működési modell segítségével.”A TMF nyilvánvalóan magában foglalja elsődleges OSS/BSS célját ebben a belső világban, de ugyanúgy, mint az agile technology foundation-nek, az infrastruktúrára is ki kell terjednie.
a “belső világ rendbetételének” mechanizmusa az 5G. a TMF azt mondja, hogy kritikus fontosságú ahhoz, hogy “a legtöbbet hozza ki az 5G-re való rendkívül drága váltásból”. de úgy tűnik, hogy ellentmond a következő bekezdésnek, ahol a fórum korábbi vezérigazgatója azt mondja: “a fogyasztók és az intelligens otthoni egyének számára a “kapcsolat” általában belső értékkel bír, és érvényes dolog, amit vásárolni kell. Ahogy azonban feljebb lépsz a skálán, az ipar átalakulásának birodalmába, az összekapcsolhatóságot csak annyiban értékelik, amennyiben a megoldáshoz kötődik: “nem akarnak tőled kapcsolatot vásárolni, hanem megoldást akarnak vásárolni.”Az 5G egyértelműen csatlakozási stratégia a fogyasztók számára,mint minden tömegpiaci infrastruktúra. Ha feltételezzük, hogy “az ipari átalakulás birodalmába lépünk”, vagyis az Üzleti szolgáltatások, a kulcs a megoldások eladása.
úgy tűnik, hogy ez azt jelenti, hogy az üzemeltetők a “digitális szolgáltató” üzleti tevékenységüket a vállalkozásokra összpontosítják, és a megoldások biztosításához SaaS-szolgáltatót kell létrehozni. Ez valóban okos megközelítés, tekintve, hogy van egy rendkívül aktív és versenyképes nyilvános felhő üzlet, amely már kínál megoldásokat ezeknek az ügyfeleknek? Különösen akkor, ha a bitenkénti nyereséggel kapcsolatos problémák többsége az all-you-can-eat fogyasztói szolgáltatásokból származik?
a Vodafone egyik idézete és a TMF-ben megjelent egyéb megjegyzések szerint az állásfoglalás az, hogy “amit ma” szolgáltatásoknak ” nevezünk, nem csak a telco-t fogja érinteni, hanem számos partnerből áll, beleértve a telcos-t is.”Így a Telco-k valójában egyáltalán nem digitális szolgáltatók, hanem digitális szolgáltatásintegrátorok vagy viszonteladók. Lehet-e egy olyan vállalkozás, amely az átalakulást a profitprés elkerülésének eszközeként vizsgálja, megengedheti magának, hogy egy másik játékos szolgáltatásainak viszonteladója legyen?
számomra úgy tűnik, hogy a TMF jövőképe egyáltalán nem az OSS/BSS-en túlra irányul, hanem inkább azt sugallja, hogy a műveletek és szolgáltatások a kapcsolaton túlra fejlődnek azáltal, hogy együttműködnek azokkal, akik ott szolgáltatásokat nyújtanak. Ez meghiúsíthatja a “digitális átalakulás” teljes célját, bezárva a telcókat nemcsak a közvetítés és a commoditizáció jelenlegi szintjébe, hanem egy teljesen új szintre is.
mindkét tanulmány azt sugallja, hogy az OSS/BSS transzformáció elengedhetetlen, és legalábbis azt sugallja, hogy az eseményvezérelt megközelítés a válasz. Ez valójában jó ötlet, de hiányzik a “Hogyan?”Ahhoz, hogy eseményvezérelt legyen, a rendszernek fel kell ismernie mind az események fogalmát (nyilvánvalóan), mind az” állam ” vagy a kontextus fogalmát. Bárki, aki valaha is megnézett egy protokollkezelőt, tudja, hogy ugyanazt az üzenetet, különböző kontextusokban/állapotokban, másképp kell feldolgozni. Például egy “adatcsomag” üzenet “megrendelhető” állapotban történő megszerzése egy szolgáltatás számára egyértelműen hiba, míg az “adatátvitel” állapotban rendben van. Ahhoz, hogy állapotok és események és kapcsolódó folyamatok legyenek, szükség van egy állapot/esemény táblára.
az állapot – /eseménytáblák a kooperatív rendszer kollektív összefüggéseinek leírása, és az építésükre való gondolkodás hasznos, mivel arra kényszeríti a szoftverépítészeket, hogy mérlegeljék az összes lehetőséget, ahelyett, hogy valami történne, ami átesik a repedéseken. Azonban lehetséges ellentmondás van az állapot/esemény táblák értéke és a lehetséges állapotok és események száma között. Ha egy komplex hálózatot egy hatalmas, lapos rendszernek tekintünk, akkor túl nagy asztalunk lenne ahhoz, hogy valaha is megvalósítsuk. A TMF és a saját tapasztalati Szférám munkája úgy foglalkozott ezzel, hogy a komplex rendszereket “szándékmodellekre” osztotta, amelyek mindegyikének saját állapot/esemény kapcsolata volt. Röviden hierarchikus összetétel. Ezt írta le az NGOSS szerződés.
a lényeg itt az, hogy mindkét dokumentum elmulasztja a saját legerősebb pontját, vagyis azt, hogy az események adatmodell-vezérelt irányítása a folyamatokhoz komponenshez igazított állapot/eseménytáblákon keresztül az eseményvezérelt viselkedés és a mikroszolgáltatással kompatibilis tervezés létrehozásának módja. Ha egy szolgáltatási adatmodell egy eseményt egy folyamathoz vezet, akkor a folyamat csak a szolgáltatási adatmodellből kaphatja meg a szükséges információkat, ami azt jelenti, hogy hontalan, és mikroszolgáltatásként vagy akár kiszolgáló nélküli formában is telepíthető.
ha kihúzza az NGOSS-Szerződéses megközelítést az OSS/BSS modernizációs történetéből, akkor marad az a dolog, amely az OSS/BSS modernizáció egész fogalmát az első közhelyektől kezdve sújtotta. Beszélhetünk alulról felfelé és felülről lefelé, amíg a projekt módszertanára koncentrálunk, de a projekt módszertana vezet egy projektet, nem ír szoftvert. A módszertanból szoftverarchitektúrának kell kialakulnia. Ez egy különálló elem, a helyes folyamat eredménye, de nem automatikus következménye annak, hogy egy pálcát integetünk egy csomó adat felett, és azt kántáljuk ,hogy ” fentről lefelé, fentről lefelé!”
ez összefoglalja a Tata papírral kapcsolatos problémámat. Az informatikai és hálózati projekt módszertanok alkalmazás-vagy szolgáltatásarchitektúrákhoz vezetnek, amelyek ezután keretezik a megoldás összetevőinek követelményeit, valamint azok integrálásának és kezelésének módját. A projekt nem a kimenet, hanem a kimenet elérési útja. A Tata papírral az a probléma, hogy ez egy újabb projekt módszertan leírása (jó, de nem átalakító), egy olyan időszakban, amikor már rég nem keresünk utat az OSS korszerűsítéséhez, hanem konkrét termékeket, vagy legalábbis architektúrákat keresünk. Úgy tűnik, hogy a TMF ugyanarra a helyre tart egy másik úton—átalakul a korábbi ellenségeivel való partnerség révén.
a Tata-tanulmány az “ipari szabványok szerepe” című szakaszban egy fontos problémát hív fel, amely annyira fontos, hogy valójában az OSS modernizációs céljának előrehaladásának akadálya lehet. A tanulmány a TMF és az ONF modelleket idézi a top-down tervezéshez, de az egész dokumentumban egyértelmű, hogy a “modernizált” OSS/BSS-t szorosabban integrálni kell a hálózati és szolgáltatási ökoszisztéma többi részével. Minden lehetséges hálózati stratégia minden lehetséges darabjára vannak szabványaink, és egyes esetekben a szabványok még versenyeznek is. Nemrégiben tapsot hallottunk például két különböző műveleti API specifikáció egyesítéséért. Meg kellene kérdeznünk, hogy hogyan szereztük meg őket.
úgy tűnik, hogy a TMF-papír nemcsak elfogadja a jövő ezen töredezettségét, hanem attól is függ. Engedje át a dolgok gépesítését az OSS/BSS-en túl, és összpontosítson arra, hogy ezeket a “túl” dolgokat felhasználja, hogy pszeudo-integrátorként szolgáltatásokat hozzon létre. Oké, lehet, hogy ez nem ésszerűtlen nézet a TMF (egy OSS/BSS által uralt test) számára, de ez egy képlet arra, hogy rendezetlen maradjon, miközben szembesül azzal, ami szinte egységes kezdeményezésnek kell lennie-átalakulás.
véleményem szerint a TMF volt az OSS/BSS korszerűsítésének logikus testülete, és hogy a TMF (NGOSS-Szerződéssel) kidolgozta az eseményirányítás központi paradigmáját a folyamatokhoz egy adatmodellen keresztül, ami kritikus a modernizáció szempontjából. Minden más, amit a papírok leírnak, minden API-t, amelyet bárki fejleszt vagy harmonizál, minden szabványtevékenység, amely a műveletek és menedzsment bármely aspektusára irányul, illeszkednie kell az NGOSS Szerződéses keretrendszerébe. Ha ez megtörténne, az eredmény pontosan az lenne, amit az “NGOSS” jelent.
a TMF NGOSS szerződés modellje ugyanolyan értékes, vagy még értékesebb, ha belép a hálózati tartományba. Egy igazi “szerződéses” állapot / esemény folyamat mindent kezelhet a szolgáltatás életciklusával kapcsolatban, beleértve a hálózati darabot is. Ebből következik, hogy egy hálózatközpontú megoldás könnyen kiterjeszthető a Szolgáltatásra, az OSS / BSS tartományra. A megközelítés egyetemessége jó az ipar számára, mivel a szolgáltatás életciklusának automatizálásának egyetemesnek kell lennie ahhoz, hogy hasznos legyen.
azt is meg kell alapulnia state-of-the-art felhő-think. Úgy tűnik, hogy mindkét újság egyetért ezzel, mégis mindkettő felveti a kérdést, hogyan lehet ezt elérni. Ha azt tervezi, hogy használja a jelenlegi eszközök elérni valamit, van, hogy a keret a megközelítés szempontjából ezeket az eszközöket. Nem fogadhatja el azt az elképzelést, hogy mindenre írhat specifikációkat, vagy egyszerűen lefordíthatja a célokat a tetején tetszőleges funkciókra az alján. Ez különösen valószínű, hogy megharap, tekintettel arra, hogy a szabványosítási folyamatoknak évekbe telik a következtetés. Ma telepítjük az 5G-t, és a szabványok még nem fejeződtek be, és valószínűleg csak 2022-ben lesz. Kíváncsi vagyok, van-e idő erre a cuccra, tekintettel arra, hogy az üzemeltetők már szembesülnek a kritikus ponthoz közeledő infrastrukturális Roi-kkal.
az NGOSS szerződés már körülbelül 13 éve létezik, és a TMF egyszer azt mondta nekem, hogy nagyon korlátozott tapadást nyert. Úgy tűnik, hogy a jelenlegi TMF anyagban nem játsszák, bár ahogy mondtam, nincs hozzáférésem a csak tagoknak szóló dolgokhoz. A kérdés tehát az, hogy a TMF készen áll-e saját (káprázatos és egyedi) betekintésének előmozdítására, először a szűk OSS/BSS tartományban, majd a tágabb életciklus-automatizálási küldetésben. Ha igen, akkor a TMF betölti jogos szerepét az NGOSS fejlődésében, és meghatározza a szolgáltatás életciklus-automatizálásának alapját. Ha nem, akkor az it egy másik Szabványügyi Testület vagy nyílt forráskódú csoport feladata lesz, hogy felvegye a fáklyát, majd a TMF-nek meg kell küzdenie a relevanciáért a saját terében.
