mikä ihme on NGOSS? Olen käyttänyt termiä paljon, liittyvät ”NGOSS sopimus”, mutta niille, jotka eivät tunne OSS/BSS tilaa tai TMF, se voi olla salaperäinen. Tata Consultancy Services, suuri ja aktiivinen ammatillinen palveluyritys, äskettäin teki paperin ”reimagining” OSS/BSS, TMF paperi kysyy, Onko elämää kuin liitettävyyspalvelut. Näiden kahden dokumentin välillä on mielenkiintoisia kontrasteja ja yhtäläisyyksiä, joihin kannattaa tutustua.
NGOSS tulee sanoista”Next-Generation Operations Support System”. Se on termi, joka on laajalti käytetty vähintään 15 vuotta, ja se on usein käytetty TMF niiden tekniset. Paljon TMF tavaraa on jäseniä-vain vaikka, ja niin en voi mainita sitä (tai, jos en ole jäsen tuolloin, ei voi edes käyttää sitä) paitsi tiivistämällä. TMF-paperi on erityisen hyödyllinen tämän vuoksi; se on julkinen yhteenveto siitä, miten keho näkee tulevaisuuden ”transformation”. Tata-paperi on mielenkiintoinen, koska se kuvastaa asiantuntijapalveluiden näkemystä samasta muutosprosessista.
Tata-lehden avauksessa on tavallisia latteuksia kaistanleveydestä. ”Kun yritykset yhä enemmän sopeutuvat pääasiallisesti verkkomalliin uuden todellisuuden mukaisesti, suuren kaistanleveyden ja luotettavien verkkopalvelujen tarve kasvaa huimasti. Näin ollen viestintäpalvelujen tarjoajat (CSPs) kokevat eksponentiaalista kysyntää palveluille ja ovat riippuvaisia edistymisestä virtualisointiteknologioissa jatkaakseen skaalausta nykyisellä nopeudella.”
Ongelmana tässä on latteuden statuksen lisäksi (vielä yksi ”eksponentiaalinen” kysyntälauseke ja oksennan), että todellinen ongelma ei ole kysynnän kasvu, vaan voiton kutistuminen. Yksikään operaattori ei olisi tyytymätön kaistanleveyden kysynnän kasvuun, jos he voisivat veloittaa kasvua asteittain. He eivät voi, joten heidän on joko löydettävä jotain muuta kuin kaistanleveyttä myytäväksi tai leikattava kaistanleveyden tuotantokustannuksia kompensoidakseen sitä, että korkeammat kaistanleveyspalvelut eivät tuota suhteellisesti korkeampia hintoja.
tämä sama numero värittää seuraavaa osiota, jota kutsutaan ”OSS-Funktion Uudelleenarvioinniksi”. Se mainitsee TMF-tavoitteet OSS: n modernisoinnille, joista yksikään ei edes tarkoita kyseisen voiton puristusongelman käsittelyä. Itse asiassa, että osa asiakirjasta on, miksi paljon operaattorin strategit ovat puolesta romuttaa koko OSS/BSS asia ja alkaa alusta. Kyse ei ole siitä, että mitään hyödyllisiä tavoitteita ei aseteta (automaatio on yksi tulevan OSS/BSS: n ominaisuuksista), vaan siitä, että niiden saavuttamisesta ei juuri puhuta.
, joka tulee seuraavaan osioon, jota kutsutaan ”hyvin Orkestroiduiksi OSS-toiminnoiksi”. Tämä osio tekee lopulta suosituksen, joka on hyödyllinen; OSS/BSS on tehtävä tapahtuma-ajettu. Minulla oli toiveita täällä, koska TMF oli itse asiassa lähde avainkonseptin OSS ja operations automation-että NGOSS sopimus mainitsin alussa tämän blogin. Valitettavasti Tata-lehdessä ei mainita termiä eikä käsitettä. Siinä sanotaan, että ” tulevaisuuden OSS-toiminnot on luotava ja tarjottava palveluina, jotka koostuvat mikropalveluista, jotka tukevat automatisoitua hybridiverkkoresurssien (fyysisten, loogisten ja virtuaalisten) orkestrointia.”
TMF: n paperi sen sijaan alkaa toteamuksella, että ”liitettävyyttä pidetään perustellusti pienen marginaalin bisneksenä ja se on nopeasti tuotteistumassa edelleen.”Operaattoreiden tavoitteena on” saada sisustusmaailmansa kuntoon ketterällä teknologiaperustalla ja toimintamallilla.”TMF sisältää tietenkin ensisijaisen OSS/BSS-kohteensa tässä sisustusmaailmassa, mutta yhtä selvästi agile technology Foundationin on ulotuttava infrastruktuuriin.
mekanismi saada heidän ” sisustusmaailmansa kuntoon ”on implisiittisesti 5G. TMF sanoo, että se on ratkaisevan tärkeää, jotta” voidaan hyödyntää valtavan kallista siirtymistä 5G: hen. ”mutta se näyttää olevan ristiriidassa seuraavan kappaleen kanssa, jossa foorumin entinen toimitusjohtaja sanoo” kuluttajille ja älykotien yksilöille, ”liitettävyydellä” on yleensä itseisarvo ja se on pätevä asia ostaa. Kun mennään asteikkoa ylöspäin, alan murrokseen, liitettävyyttä arvostetaan vain siltä osin kuin se on sidottu ratkaisuun: ”he eivät halua ostaa liitettävyyttä sinulta, he haluavat ostaa ratkaisun.”5G on kuluttajille selvästi liitettävyysstrategia, kuten kaikki massamarkkinoiden infrastruktuuri. Jos lähdemme siitä, että” mennään mittakaavaa ylöspäin teollisuuden murrokseen”, eli yrityspalveluihin, ratkaisuna on myydä ratkaisuja.
tämä näyttää puoltavan sitä, että operaattorit keskittävät ”digitaalisen palveluntarjoajan” liiketoimintansa yrityksiin, ja ratkaisujen tarjoamiseksi on oltava SaaS-tarjoaja. Onko se todella fiksu lähestymistapa, kun otetaan huomioon, että on olemassa erittäin aktiivinen ja kilpailukykyinen Julkinen pilvibisnes, joka myy jo ratkaisuja näille asiakkaille? Varsinkin, kun suurin osa operaattoreiden tuottokohtaisista ongelmista tulee kaikenkattavista kuluttajapalveluista?
Vodafonen lainauksen ja muiden TMF: n paperin kommenttien mukaan päätöslauselma on, että ”se, mitä nyt kutsumme ’palveluiksi’, ei koske pelkästään telcoa, vaan koostuu useista kumppaneista, mukaan lukien telcot.”Telcot eivät siis ole lainkaan digitaalisia palveluntarjoajia, vaan digipalveluintegraattoreita tai jälleenmyyjiä. Voiko liike, joka etsii muutosta keinona paeta voitontuskia varaa olla jälleenmyyjä toisen pelaajan palveluja?
minusta näyttää siltä, että TMF: n visio ei todellakaan tähtää OSS/BSS: ää pidemmälle, vaan pikemminkin viittaa siihen, että toiminnot ja palvelut kehittyvät johonkin liitettävyyden yläpuolelle tekemällä yhteistyötä niiden kanssa, jotka tarjoavat palveluja siellä. Se voisi olla kukistaa koko tarkoitus ”digitaalinen muutos”, lukitsemalla telcos osaksi paitsi niiden nykyinen disintermediation ja commoditization, mutta myös kokonaan uudella tasolla.
molemmat paperit näyttävät viittaavan siihen, että OSS/BSS-muunnos on välttämätön, ja ainakin vihjaavat, että tapahtumakeskeinen lähestymistapa on vastaus. Se on itse asiassa hyvä idea ,mutta se jättää haasteen ” miten?”Ollakseen tapahtumavetoinen järjestelmän on tunnistettava sekä tapahtumien käsite (ilmeisesti) että ”valtion” tai kontekstin käsite. Jokainen, joka on koskaan katsonut protokollan käsittelijää, tietää, että sama viesti, eri yhteyksissä/valtioissa, on käsiteltävä eri tavalla. Esimerkiksi ”datapaketti” – viestin saaminen ”tilattavassa” tilassa palvelulle on selvästi virhe, kun taas ”tiedonsiirto” – tilassa se on hieno. Jotta olisi tiloja ja tapahtumia ja niihin liittyviä prosesseja, tarvitset tila/tapahtumataulukon.
tila – / tapahtumataulukot ovat kuvauksia osuustoimintajärjestelmän kollektiivisista yhteyksistä, ja niiden rakentamisesta on hyötyä, koska se pakottaa ohjelmistoarkkitehdit miettimään kaikkia mahdollisuuksia sen sijaan, että tapahtuisi jotain, joka jää rakoilemaan. Kuitenkin, on olemassa mahdollinen ristiriita arvo valtion / tapahtumataulukot ja määrä mahdollisia valtioita ja tapahtumia. Jos katsoo monimutkaista verkkoa yhtenä valtavana, tasaisena järjestelmänä, olisi aivan liian iso pöytä koskaan toteutettavaksi. TMF ja oma Kokemusphere-teokseni käsittelivät tätä jakamalla kompleksiset systeemit ”intentiomalleihin”, joilla kullakin oli omat tila-tapahtumasuhteensa. Hierarkkinen koostumus, lyhyesti. Niin Ngossin Sopimuksessa kuvailtiin.
pointti tässä on se, että molemmista papereista puuttuu se, minkä pitäisi olla sen oma vahvin kohta, joka on se, että datamallipohjainen tapahtumien ohjaaminen prosesseihin komponenttikohtaisten tila/tapahtumataulukoiden kautta on tapa luoda sekä tapahtumavetoista käyttäytymistä että microservice-yhteensopivaa suunnittelua. Jos palveludatamalli ajaa tapahtuman prosessiksi, prosessi saa tarvitsemansa tiedot pelkästä palveludatamallista, mikä tarkoittaa, että se on valtioton ja voidaan ottaa käyttöön mikropalveluna tai jopa palvelimettomassa muodossa.
jos vedät NGOSS-sopimus lähestymistapa pois OSS / BSS modernisointi tarina, jää asia, joka on vaivannut koko käsite OSS / BSS modernisointi ensimmäisestä latteuksia. Voimme puhua alhaalta ylös ja ylhäältä alas niin kauan kuin keskitymme projektin metodologioihin, mutta projektin metodologia ohjaa projektia, se ei kirjoita ohjelmistoja. Menetelmästä pitäisi syntyä ohjelmistoarkkitehtuuri. Se on erillinen elementti, oikean prosessin tulos, mutta se ei ole automaattinen seuraus taikasauvan heiluttamisesta kasan datan päälle ja huutamisesta ”ylhäältä alas, ylhäältä alas!”
siinä kiteytyy ongelmani Tata-lehden kanssa. Projektimenetelmät tietotekniikassa ja verkostoitumisessa johtavat sovellus-tai palveluarkkitehtuureihin, jotka sitten kehystävät ratkaisun komponenttien vaatimukset sekä niiden integroinnin ja hallinnan. Projekti ei ole tuotos, se on polku tuotokseen. Tata-paperin ongelmana on se, että se on jälleen yksi kuvaus projektimenetelmästä (hyvä, mutta ei transformatiivinen) aikana, jolloin olemme jo kauan sitten etsineet polkua OSS: n modernisointiin ja sen sijaan etsimme tiettyjä tuotteita tai ainakin arkkitehtuureja. TMF näyttää olevan menossa samaan paikkaan eri polkua-muuttaa kumppanuus entisten vihollisten kanssa.
Tata-lehti tuo esiin tärkeän ongelman, joka on niin tärkeä, että se saattaa itse asiassa olla este OSS: n nykyaikaistamistavoitteen saavuttamiselle. Paperi mainitsee TMF-ja ONF-mallit ylhäältä alas-suunnitteluun, mutta koko paperi on selvää, että ”modernisoitu” OSS/BSS on integroitava tiiviimmin muuhun verkko-ja palveluekosysteemiin. Meillä on standardit jokaiselle mahdolliselle osalle jokaista mahdollista verkostostrategiaa, ja joissakin tapauksissa standardit jopa kilpailevat keskenään. Kuulimme äskettäin suosionosoituksia esimerkiksi kahden eri operaatiorajapinnan määrittelyn yhdistämiselle. Meidän pitäisi kysyä, miten ylipäätään saimme ne.
TMF-lehti näyttää paitsi hyväksyvän tämän tulevaisuuden pirstaleisuuden, myös riippuvan siitä. Cede koneellistaminen tavaraa yli OSS/BSS, ja keskittyä valjastaa, että ”beyond” tavaraa luoda palveluja pseudo-integraattori. OK, se ei voi olla kohtuuton näkemys TMF (oss/BSS-hallitseva elin) ottaa, mutta se on kaava pysyä epäjärjestelmällisiä kohdatessaan mitä lähes on oltava yhtenäinen aloite—muutos.
mielestäni TMF oli looginen elin modernisoida OSS/BSS, ja että TMF Ei (kanssa NGOSS sopimus) suunnitella keskeinen paradigma tapahtuman ohjauksen prosessien kautta tietomalli, joka on kriittinen tämän modernisoinnin. Kaikki muu paperit kuvaavat, jokainen API kuka tahansa kehittää tai harmonisoi, jokainen standardien toimintaa, jonka tarkoituksena on millä tahansa osa toimintaa ja hallintaa, olisi sovitettava että Ngoss Sopimuskehys. Jos näin tehtäisiin, tuloksena olisi juuri se, mitä ”NGOSS” tarkoittaa.
TMF NGOSS-sopimuksen malli on aivan yhtä arvokas tai jopa arvokkaampi, jos astuu verkkoalueeseen. Todellinen” sopimus ” tila / tapahtuma prosessi voisi hallita kaikkea palvelun elinkaaren, mukaan lukien verkon pala. Tästä seuraa, että verkkokeskeinen ratkaisu voitaisiin helposti laajentaa palveluun, oss/BSS, verkkotunnus. Toimintamallin universaalisuus on toimialalle hyvä asia, sillä palvelun elinkaaren automaation pitäisi olla universaalia, jotta siitä olisi hyötyä.
sen pitäisi myös perustua huipputekniseen pilviajatteluun. Molemmat lehdet näyttävät olevan samaa mieltä tästä, ja silti molemmat kiertävät kysymyksen siitä, miten se saadaan aikaan. Jos aiot käyttää nykyisiä työkaluja saavuttaa jotain, sinun täytyy kehystää lähestymistapa kannalta näitä työkaluja. Et voi hyväksyä ajatusta, että voit kirjoittaa TEKNISET TIEDOT kaiken, tai yksinkertaisesti kääntää tavoitteet yläosassa mielivaltaisia ominaisuuksia alareunassa. Se on erityisen todennäköistä purra sinua ottaen huomioon, että standardit prosessit kestää vuosia tulla päätökseen. Otamme 5G: n käyttöön tänään ja standardit eivät ole valmiita, ja todennäköisesti vasta vuonna 2022. Onkohan siihen aikaa, kun otetaan huomioon, että operaattoreilla on jo edessään kriittistä pistettä lähestyvät kaatuvat infrastruktuuriroiskeet.
NGOSS-sopimus on ollut olemassa jo noin 13 vuotta, ja TMF kertoi aikoinaan saaneensa hyvin vähän vetoapua. Sitä ei näytä soitettavan nykyisessä TMF-materiaalissa, vaikka kuten olen sanonut, minulla ei ole pääsyä vain jäsenille tarkoitettuihin juttuihin. Kysymys kuuluukin, onko TMF valmis edistämään omaa (häikäisevää ja ainutlaatuista) oivallustaan, ensin kapealla OSS/BSS-osa-alueella ja sitten laajemmassa elinkaaren automaatiotehtävässä. Jos näin käy, TMF ottaa oikeutetun roolinsa ngoss-evoluutiossa ja määrittelee palvelun elinkaaren automaation perustan kokonaisuudessaan. Jos näin ei käy, it saa jonkun muun standardointielimen tai avoimen lähdekoodin ryhmän poimia soihdun, ja TMF joutuu sitten taistelemaan merkityksellisyydestä omassa tilassaan.
