Frameworx , tidigare NGOSS ( engelska New Generation Operations Systems and Software ) är konceptet för telekommunikationsbranschens organisation TM Forum , som beskriver ett tillvägagångssätt för utveckling , implementering och drift av applikationsprogramvara för telekommunikationsföretag . Syftet med konceptet är att definiera standarder för operatörers affärsprocesser , presentationsformat som används i datahanteringssystem och gränssnitt för interaktion med den miljö som lösningen är integrerad i.
Konceptet bygger på:
När OSS-system är sammanlänkade sträcker sig de affärsprocesser som de stöder till hela företagets IT-område. Resultatet blir en situation där en process startar från applikation A, som behandlar en del data och som "vet" att den då ska anropa applikation B, som i sin tur också kommer att behandla datan och anropa applikation C osv. Som ett resultat är det extremt svårt att avgöra vilka av processtegen som är aktuella för tillfället (till exempel, när du utfärdar en faktura till en kund, hur kan du avgöra vilken applikation (A, B eller C) som för närvarande behandlar fakturainformation ?). Och ännu svårare är uppgiften att förändra denna process, på grund av dess distribuerade natur. NGOSS antar att processen ska hanteras som en del av en centraliserad infrastruktur med hjälp av någon mekanism som säkerställer sekvensen av åtgärder och ansvarar för att övervaka framstegen i affärsprocessen från en applikation till en annan. Således skulle denna mekanism initiera en process på applikation A, som sedan skulle återföra kontrollen tillbaka. Denna mekanism skulle sedan anropa applikation B, och så vidare. I det här fallet skulle det alltid vara möjligt att avgöra vilka av stegen i affärsprocessen som utförs vid en given tidpunkt, eftersom kontrollen över dess framsteg redan skulle vara centraliserad. Samtidigt kan processändringar göras med hjälp av vissa verktyg av den nämnda mekanismen. Det är uppenbart att några av processkomponenterna på lägre nivå kommer att byggas in i separata applikationer, men dessa bör placeras under den nivå på vilken affärsrelevanta funktioner utförs, det vill säga under den nivå på vilken tillämpliga standarder och företagspolicyer fungera.
Den lösa kopplingen mellan element innebär att varje applikation är relativt oberoende av andra applikationer inom det övergripande systemet. Således, i en löst kopplad miljö, kan ändringar göras i en applikation utan att påverka andra applikationer, vanligtvis oundvikligt i sådana fall. Åtminstone kan denna princip ibland ses som att applikationer kan implementeras på ett plug and play-sätt, eftersom de är så oberoende av varandra att de kan ersättas utan att det påverkar systemet som helhet. Användningen av ett "distribuerat system" understryker än en gång att NGOSS inte är baserad på användningen av en enda monolitisk applikation av ett telekommunikationsföretag för att hantera all verksamhet i ett företag, utan i stället föreslås det att använda en uppsättning applikationer som är integrerade och interagerar med varandra.
Integrationen av OSS-system gör att applikationer måste "kunna" utbyta olika typer av data med varandra. Och för att denna process ska vara effektiv måste varje applikation "veta" hur alla andra applikationer "förstår" eller tolkar det här eller det blocket av överförda data. För att förstå detta kan du använda exemplet att tillhandahålla information om fakturan till kunden: applikation A tar emot kundens begäran om en faktura och skickar denna information med applikation B (faktureringssystemet). Ansökan A kommer att ha information om klientens adress och det är nödvändigt för applikation B att skicka fakturan till denna adress. För att data ska kunna utbytas mellan system måste de ha ett standardformat för adressinformation: antalet rader med adressinformation, antalet tecken på varje rad – allt detta ska vara lika för varje system och varje applikation vet vilken format som ett annat program fungerar med. Allt är ganska självklart och enkelt. Men man kan föreställa sig vilka svårigheter som skulle uppstå om applikation A skulle fungera med produkter som skulle bestå av flera delprodukter (bredbandsaccess över kopparlinjer, modem, filterset och bredbandsomvandling) och skulle överföra hela spektrumet av data till applikation B, medan applikation B förväntas ta emot endast en rad av denna produkt/beställning. Att försöka konvertera hierarkiska produkter till icke-hierarkiska utan att förlora information skulle vara omöjligt. En enda informationsmodell för data som utbyts mellan applikationer ger en lösning på detta problem. Lösningen från TMF kallas Common Information Model.
Inledningsvis (cirka mitten av 80-talet) utvecklades OSS-system som separata applikationer. Men i början av 1990-talet blev det uppenbart att det var mycket ineffektivt att använda dessa system som separata applikationer, eftersom detta ledde till en situation där till exempel en order tas emot i ett system, och sedan överförs vissa delar från denna order till ett annat system för att konfigurera motsvarande nätverksutrustning. Den största effektivitetsvinsten med att kombinera separata OSS-system är förvärvet av en sådan möjlighet som "Flow-through provisioning" ("övervaka processens framsteg"), när en beställning kan göras online och resultatet automatiskt övervakas utan att personalens deltagande. Men för stora telekomoperatörer med hundratals separata OSS-system har spridningen av gränssnitt blivit ett allvarligt problem. Varje OSS var tvungen att "prata" med många andra, vilket resulterade i en exponentiell ökning av antalet gränssnitt när antalet OSS-system ökade. NGOSS beskriver användningen av Common Communications Infrastructure (CCI). I denna modell kommunicerar OSS-system med CCI snarare än direkt med varandra. CCI tillåter alltså applikationer att kommunicera med hjälp av CCI för att ansluta dem. Således kräver varje applikation bara ett gränssnitt (till CCI) och inte många (till alla andra applikationer). Således reduceras komplexiteten i hela systemet avsevärt. CCI kan också tillhandahålla andra tjänster, inklusive säkerhet, datakonvertering och så vidare.
Med tanke på ovanstående beskrivning av hur applikationer interagerar med CCI, blir det tydligt att det måste finnas ett sätt att dokumentera dessa gränssnitt, både när det gäller den underliggande tekniken (t.ex. Java/JMS eller Web Services/SOAP) och när det gäller applikationsfunktionalitet , data som används, initiala och slutliga villkor osv. NGOSS-specifikationerna ger möjlighet att dokumentera dessa gränssnitt och därmed blir gränssnitten väldefinierade och etablerade. NGOSS-specifikationerna kan betraktas som tillägg till API -specifikationerna (Application Programming Interface).
NGOSS-konceptet, som inkluderar modellerna eTOM , SID , TAM och TNA , samt lösningens livscykel, i kombination med SANRR- metoden , är en omfattande metodik för utveckling, implementering, drift och utveckling av OSS/BSS- system . Med dess hjälp är det möjligt att integrera affärskrav och tekniska aspekter av en teleoperatörs verksamhet i en enda arkitektur, automatisera affärsprocesser i heterogena IT-miljöer och bygga en enhetlig informationsinfrastruktur strikt fokuserad på att uppfylla affärsuppgifterna för en telekommunikation företag. Användningen av NGOSS livscykelverktyg och metoder kan i hög grad bidra till framgången för effektiv kommunikationsföretagsledning. Det bör dock förstås att själva möjligheten att använda dessa verktyg till stor del beror på företagets beredskap att acceptera förändringar, beredskapen hos infrastrukturen att implementera ett heltäckande ledningsinformationssystem, personalens beredskap att implementera, administrera och de flesta viktigt, använd dessa verktyg i sina aktiviteter.