Frameworx , entinen NGOSS ( englanniksi New Generation Operations Systems and Software ) on tietoliikennealan organisaation TM Forumin käsite , joka kuvaa lähestymistapaa tietoliikenneyritysten sovellusohjelmistojen kehittämiseen , käyttöönottoon ja käyttöön . Konseptin tarkoituksena on määritellä standardit operaattoreiden liiketoimintaprosesseille , tiedonhallintajärjestelmissä käytettävät esitysmuodot ja rajapinnat vuorovaikutukseen sen ympäristön kanssa, johon ratkaisu on integroitu.
Konsepti perustuu:
Kun OSS-järjestelmät linkitetään yhteen, niiden tukemat liiketoimintaprosessit ulottuvat yrityksen koko IT-alueelle. Tuloksena on tilanne, jossa prosessi alkaa sovelluksesta A, joka käsittelee jotain dataa ja joka "tietää", että sen pitäisi sitten kutsua sovellus B, joka puolestaan käsittelee tiedot ja kutsuu sovelluksen C jne. Tästä johtuen on äärimmäisen vaikeaa määrittää, mikä prosessivaiheista on tällä hetkellä ajan tasalla (esimerkiksi asiakkaalle laskua tehtäessä voidaan määrittää, mikä sovellus (A, B vai C) käsittelee parhaillaan laskutietoja ?). Ja vielä vaikeampaa on muuttaa tätä prosessia sen hajautetun luonteen vuoksi. NGOSS olettaa, että prosessia tulisi hallita osana keskitettyä infrastruktuuria jollakin mekanismilla, joka varmistaa toimintojen järjestyksen ja on vastuussa liiketoimintaprosessin etenemisen seurannasta sovelluksesta toiseen. Siten tämä mekanismi käynnistäisi prosessin sovelluksessa A, joka palauttaisi ohjauksen takaisin. Tämä mekanismi kutsuisi sitten sovelluksen B ja niin edelleen. Tällöin olisi aina mahdollista määrittää, mikä liiketoimintaprosessin vaiheista kulloinkin suoritetaan, koska sen etenemisen valvonta olisi jo keskitetty. Samalla voidaan tehdä prosessimuutoksia käyttämällä mainitun mekanismin tiettyjä työkaluja. On selvää, että jotkin alemman tason prosessikomponenteista rakennetaan erillisiin sovelluksiin, mutta ne tulisi sijoittaa sen tason alapuolelle, jolla liiketoiminnan kannalta merkitykselliset toiminnot suoritetaan, eli alle tason, jolla sovellettavat standardit ja yrityskäytännöt toiminto.
Löysä kytkentä elementtien välillä tarkoittaa, että kukin sovellus on suhteellisen riippumaton muista sovelluksista koko järjestelmässä. Näin ollen löyhästi kytketyssä ympäristössä muutoksia voidaan tehdä yhteen sovellukseen vaikuttamatta muihin sovelluksiin, mikä on yleensä väistämätöntä tällaisissa tapauksissa. Ainakin tämän periaatteen voidaan joskus nähdä mahdollistavan sovellusten toteuttamisen plug and play -periaatteella, koska ne ovat niin riippumattomia toisistaan, että ne voidaan vaihtaa ilman, että ne vaikuttavat koko järjestelmään. "Hajautetun järjestelmän" käyttö korostaa jälleen kerran, että NGOSS ei perustu siihen, että teleyritys käyttää yhtä monoliittista sovellusta yrityksen kaikkien toimintojen hallintaan, vaan sen sijaan ehdotetaan sovellussarjan käyttöä. jotka ovat integroituja ja vuorovaikutuksessa keskenään.
OSS-järjestelmien integrointi tarkoittaa, että sovellusten on "pystettävä" vaihtaa erilaisia tietoja keskenään. Ja jotta tämä prosessi olisi tehokas, jokaisen sovelluksen on "tietävä", kuinka mikä tahansa toinen sovellus "ymmärtää" tai tulkitsee tämän tai sen lähetetyn datalohkon. Tämän ymmärtämiseksi voit käyttää esimerkkiä laskun tietojen antamisesta asiakkaalle: sovellus A vastaanottaa asiakkaan laskupyynnön ja lähettää nämä tiedot sovelluksella B (laskutusjärjestelmä). Hakemuksessa A on tiedot asiakkaan osoitteesta ja hakemuksen B on lähetettävä lasku tähän osoitteeseen. Jotta tietoja voidaan vaihtaa järjestelmien välillä, niillä on oltava vakiomuotoinen osoitetietomuoto: osoitetietorivien määrä, merkkien määrä jokaisella rivillä - kaiken tämän pitäisi olla sama jokaisessa järjestelmässä ja jokainen sovellus tietää, mikä muoto, jonka kanssa toinen sovellus toimii. Kaikki on melko selvää ja yksinkertaista. Mutta voidaan kuvitella vaikeuksia, joita syntyisi, jos sovellus A toimisi tuotteiden kanssa, jotka koostuisivat useista alatuotteista (laajakaistayhteys kuparilinjoilla, modeemi, suodatinsarja ja laajakaistamuunnos) ja siirtäisivät koko dataspektrin sovellus B, kun taas sovelluksen B odotetaan saavan vain yhden rivin tätä tuotetta/tilausta. Olisi mahdotonta yrittää muuntaa hierarkkisia tuotteita ei-hierarkkisiksi menettämättä tietoja. Yksi ainoa tietomalli sovellusten välillä vaihdetulle tiedolle tarjoaa ratkaisun tähän ongelmaan. TMF:n ratkaisua kutsutaan yhteiseksi tietomalliksi.
Aluksi (80-luvun puolivälissä) OSS-järjestelmät kehitettiin erillisinä sovelluksina. Kuitenkin 1990-luvun alussa kävi ilmi, että näiden järjestelmien käyttäminen erillisinä sovelluksina oli erittäin tehotonta, koska tämä johti tilanteeseen, jossa esimerkiksi tilaus vastaanotetaan yhteen järjestelmään, ja sitten osa tästä tilauksesta siirretään toiseen järjestelmään vastaavien verkkolaitteiden konfigurointia varten. Suurin tehokkuusetu erillisten OSS-järjestelmien yhdistämisestä on sellaisen mahdollisuuden hankkiminen kuin "Flow-through-provisiointi" ("prosessin etenemisen seuranta"), jolloin tilaus voitaisiin tehdä verkossa ja tulosta seurataan automaattisesti ilman henkilöstön osallistuminen. Suurille teleoperaattoreille, joilla on satoja erillisiä OSS-järjestelmiä, rajapintojen lisääntymisestä on kuitenkin tullut vakava ongelma. Jokaisen OSS:n piti "puhua" monien muiden kanssa, mikä johti eksponentiaaliseen lisäykseen rajapintojen määrässä OSS-järjestelmien määrän kasvaessa. NGOSS kuvaa yhteisen viestintäinfrastruktuurin (CCI) käyttöä. Tässä mallissa OSS-järjestelmät kommunikoivat CCI:n kanssa eikä suoraan keskenään. CCI mahdollistaa siten sovellusten kommunikoinnin käyttämällä CCI:tä niiden yhdistämiseen. Siten jokainen sovellus vaatii vain yhden rajapinnan (CCI:hen) eikä monia (kaikkiin muihin sovelluksiin). Näin ollen koko järjestelmän monimutkaisuus vähenee huomattavasti. CCI voi tarjota myös muita palveluita, mukaan lukien turvallisuus, tietojen muuntaminen ja niin edelleen.
Kun otetaan huomioon yllä oleva kuvaus sovellusten vuorovaikutuksesta CCI:n kanssa, käy selväksi, että on oltava tapa dokumentoida nämä rajapinnat sekä taustalla olevan tekniikan (esim. Java/JMS tai Web-palvelut/SOAP) että sovellusten toiminnallisuuden kannalta. , käytetyt tiedot, alku- ja loppuehdot jne. NGOSS-spesifikaatiot antavat mahdollisuuden dokumentoida nämä rajapinnat ja siten rajapinnat tulevat hyvin määritellyiksi ja vakiintuneiksi. NGOSS-spesifikaatioita voidaan pitää lisäyksinä API (Application Programming Interface) -määrityksiin.
NGOSS-konsepti, joka sisältää eTOM- , SID- , TAM- ja TNA -mallit sekä ratkaisun elinkaaren yhdessä SANRR- metodologian kanssa , on kattava metodologia OSS/BSS -järjestelmien kehittämiseen, toteutukseen, käyttöön ja kehittämiseen . Sen avulla voidaan integroida teleyrityksen liiketoiminnan vaatimukset ja tekniset näkökohdat yhdeksi arkkitehtuuriksi, automatisoida liiketoimintaprosesseja heterogeenisissä IT-ympäristöissä ja rakentaa yhtenäinen tietoinfrastruktuuri, joka keskittyy tiukasti teleyrityksen liiketoimintatehtävien suorittamiseen. yhtiö. Kansalaisjärjestöjen elinkaaren työkalujen ja menetelmien käyttö voi merkittävästi edistää tehokkaan viestintäyritysjohtamisen menestystä. On kuitenkin ymmärrettävä, että itse näiden työkalujen käyttömahdollisuus riippuu pitkälti yrityksen valmiudesta hyväksyä muutokset, infrastruktuurin valmiudesta toteuttaa kattava johtamistietojärjestelmä, henkilöstön valmiudesta toteuttaa, hallinnoida ja eniten tärkeintä on käyttää näitä työkaluja toiminnassaan.