A Frameworx , korábban NGOSS ( angolul New Generation Operations Systems and Software ) a TM Forum távközlési ipari szervezet koncepciója , amely a távközlési vállalkozások alkalmazásszoftvereinek fejlesztésére , megvalósítására és üzemeltetésére vonatkozó megközelítést írja le . A koncepció célja, hogy szabványokat határozzon meg az üzemeltetők üzleti folyamataira, az adatkezelő rendszerekben használt prezentációs formátumokra és a környezettel való interakcióra, amelybe a megoldást integrálják.
A koncepció alapja:
Az OSS rendszerek összekapcsolásakor az általuk támogatott üzleti folyamatok a vállalat teljes informatikai területére kiterjednek. Az eredmény egy olyan helyzet, amikor egy folyamat az A alkalmazástól indul, amely feldolgoz néhány adatot, és "tudja", hogy ezután meg kell hívnia a B alkalmazást, amely viszont feldolgozza az adatokat, és meghívja a C alkalmazást, és így tovább. Emiatt rendkívül nehéz meghatározni, hogy a folyamat melyik lépése aktuális az adott pillanatban (például amikor számlát állítanak ki egy ügyfélnek, hogyan lehet meghatározni, hogy melyik alkalmazás (A, B vagy C) dolgozza fel éppen a számlainformációkat ?). És még nehezebb a folyamat megváltoztatása, elosztott jellege miatt. A NGOSS azt feltételezi, hogy a folyamatot egy központosított infrastruktúra részeként kell kezelni valamilyen mechanizmus segítségével, amely biztosítja a műveletek sorrendjét, és felelős az üzleti folyamat egyik alkalmazásról a másikra való előrehaladásának nyomon követéséért. Így ez a mechanizmus elindít egy folyamatot az A alkalmazáson, amely azután visszaadja a vezérlést. Ez a mechanizmus ezután meghívja a B alkalmazást és így tovább. Ebben az esetben mindig meg lehetne határozni, hogy egy adott időpontban az üzleti folyamat melyik szakaszát hajtják végre, hiszen a folyamat előrehaladásának ellenőrzése már centralizált lenne. Ugyanakkor az említett mechanizmus egyes eszközeivel folyamatmódosítások is végrehajthatók. Nyilvánvaló, hogy az alacsonyabb szintű folyamatelemek egy része különálló alkalmazásokba kerül beépítésre, de ennek az üzleti szempontból releváns funkciók végrehajtásának szintje alatt kell elhelyezkednie, azaz az alkalmazandó szabványok és vállalati szabályzatok szintje alatt. működtet.
Az elemek közötti laza csatolás azt jelenti, hogy minden egyes alkalmazás viszonylag független a teljes rendszeren belüli többi alkalmazástól. Így egy laza csatolású környezetben egy alkalmazáson változtatások hajthatók végre anélkül, hogy ez más alkalmazásokat érintene, ami ilyen esetekben általában elkerülhetetlen. Ez az elv legalábbis olykor úgy tekinthető, mint amely lehetővé teszi az alkalmazások plug and play módban való megvalósítását, mivel annyira függetlenek egymástól, hogy a rendszer egészének befolyásolása nélkül kicserélhetők. Az "elosztott rendszer" használata ismételten hangsúlyozza, hogy az NGOSS nem azon alapul, hogy egy távközlési vállalat egyetlen monolitikus alkalmazást használ egy vállalat összes műveletének kezelésére, hanem ehelyett egy alkalmazáskészlet használatát javasolják. amelyek integrálódnak és kölcsönhatásba lépnek egymással.
Az OSS-rendszerek integrációja azt jelenti, hogy az alkalmazásoknak „képesnek kell lenniük” különböző típusú adatok cseréjére egymással. És ahhoz, hogy ez a folyamat hatékony legyen, minden alkalmazásnak „tudnia kell”, hogy egy másik alkalmazás hogyan „érti” vagy értelmezi az átvitt adatblokkot. Ennek megértéséhez használhatja a számlával kapcsolatos információk ügyfélnek történő megadásának példáját: az A alkalmazás fogadja az ügyfél számlakérését, és elküldi ezt az információt a B alkalmazás (a számlázási rendszer) segítségével. Az „A” jelentkezésnek lesz információja az ügyfél címéről, és a „B” alkalmazásnak erre a címre kell küldenie a számlát. A rendszerek közötti adatcsere érdekében szabványos címinformációs formátummal kell rendelkezniük: a címinformáció sorainak száma, az egyes sorokban lévő karakterek száma - mindeznek azonosnak kell lennie minden rendszernél, és minden alkalmazás tudja, hogy melyik formátum, amellyel egy másik alkalmazás működik. Minden nagyon egyértelmű és egyszerű. Ám elképzelhető, hogy milyen nehézségek adódnának, ha az A alkalmazás olyan termékekkel dolgozna, amelyek több résztermékből állnak (szélessávú hozzáférés rézvezetékeken keresztül, modem, szűrőkészlet és szélessávú átalakítás), és az adatok teljes spektrumát továbbítanák B alkalmazás, míg a B alkalmazás várhatóan csak egy sort kap ebből a termékből/megrendelésből. Lehetetlen lenne megpróbálni a hierarchikus termékeket nem hierarchikus termékekké alakítani anélkül, hogy elveszítenék az információkat. Az alkalmazások közötti adatcsere egységes információs modellje megoldást nyújt erre a problémára. A TMF megoldását közös információs modellnek nevezik.
Kezdetben (a 80-as évek közepe táján) az OSS rendszereket különálló alkalmazásokként fejlesztették ki. Az 1990-es évek elején azonban nyilvánvalóvá vált, hogy ezeknek a rendszereknek a különálló alkalmazásként való alkalmazása rendkívül nem hatékony, mivel ez olyan helyzethez vezetett, hogy például egy megrendelés érkezik egy rendszerbe, majd ebből a megrendelésből néhány alkatrész átkerül egy másik rendszert a megfelelő hálózati berendezés konfigurálása céljából. A különálló OSS-rendszerek kombinálásának fő hatékonyságnövekedése az olyan lehetőség megszerzése, mint a „Flow-through provising” („folyamat előrehaladásának nyomon követése”), amikor online rendelés leadható, és az eredmény automatikusan monitorozásra kerülne, a személyzet részvétele. A több száz külön OSS rendszerrel rendelkező nagy távközlési szolgáltatók számára azonban komoly problémát jelent az interfészek elterjedése. Mindegyik OSS-nek „beszélnie” kellett sok mással, ami az interfészek számának exponenciális növekedését eredményezte az OSS rendszerek számának növekedésével. A NGOSS leírja a közös kommunikációs infrastruktúra (CCI) használatát. Ebben a modellben az OSS rendszerek a CCI-vel kommunikálnak, nem pedig közvetlenül egymással. A CCI így lehetővé teszi az alkalmazások számára, hogy a CCI segítségével kommunikáljanak egymással. Így minden alkalmazás csak egy interfészt igényel (a CCI-hez), és nem sok (az összes többi alkalmazáshoz). Így az egész rendszer bonyolultsága jelentősen csökken. A CCI egyéb szolgáltatásokat is nyújthat, beleértve a biztonságot, az adatátalakítást stb.
Tekintettel az alkalmazások és a CCI közötti interakció fenti leírására, világossá válik, hogy szükség van egy módra ezen interfészek dokumentálására, mind az alapul szolgáló technológia (pl. Java/JMS vagy webszolgáltatások/SOAP), mind pedig az alkalmazás funkcionalitása szempontjából. , felhasznált adatok, kezdeti és végső feltételek stb. Az NGOSS specifikációk lehetővé teszik ezen interfészek dokumentálását, így az interfészek jól meghatározottak és megalapozottak lesznek. Az NGOSS specifikációk az API (Application Programming Interface) specifikációk kiegészítésének tekinthetők.
Az NGOSS koncepció, amely magában foglalja az eTOM , SID , TAM és TNA modelleket , valamint a megoldás életciklusát, a SANRR módszertannal kombinálva , egy átfogó módszertan az OSS/BSS rendszerek fejlesztéséhez, megvalósításához, üzemeltetéséhez és fejlesztéséhez . Segítségével lehetőség nyílik a távközlési szolgáltató üzleti követelményeinek és tevékenységének műszaki szempontjainak egységes architektúrába történő integrálására, az üzleti folyamatok heterogén informatikai környezetekben történő automatizálására, valamint a szigorúan a távközlési üzleti feladatok ellátására koncentráló egységes információs infrastruktúra kiépítésére. vállalat. A NGOSS életciklus eszközeinek és módszereinek alkalmazása nagyban hozzájárulhat a hatékony kommunikációs vállalatirányítás sikeréhez. Meg kell azonban érteni, hogy ezen eszközök használatának lehetősége nagymértékben függ attól, hogy a vállalat mennyire készen áll a változásokra, az infrastruktúra készen áll-e egy átfogó vezetői információs rendszer bevezetésére, a személyzet felkészültsége a bevezetésre, adminisztrációra és a legtöbb esetben. fontos, hogy ezeket az eszközöket használják tevékenységeik során.