Frameworx , dříve NGOSS ( anglicky New Generation Operations Systems and Software ) je koncept telekomunikační průmyslové organizace TM Forum , který popisuje přístup k vývoji , implementaci a provozu aplikačního softwaru pro telekomunikační podniky . Účelem konceptu je definovat standardy pro obchodní procesy operátorů, prezentační formáty používané v systémech správy dat a rozhraní pro interakci s prostředím, do kterého je řešení integrováno.
Koncept je založen na:
Když jsou systémy OSS propojeny, obchodní procesy, které podporují, se rozšíří do celé IT oblasti podniku. Výsledkem je situace, kdy se z aplikace A spustí proces, který zpracovává nějaká data a který „ví“, že má následně zavolat aplikaci B, která zase data zpracuje a zavolá aplikaci C a tak dále. V důsledku toho je extrémně obtížné určit, který z procesních kroků je v tuto chvíli aktuální (například při vystavení faktury klientovi, jak můžete určit, která aplikace (A, B nebo C) aktuálně zpracovává fakturační informace ?). A ještě obtížnější je úkol tento proces změnit kvůli jeho distribuované povaze. NGOSS předpokládá, že proces by měl být řízen jako součást centralizované infrastruktury pomocí nějakého mechanismu, který zajišťuje posloupnost akcí a je odpovědný za sledování postupu obchodního procesu od jedné aplikace k druhé. Tento mechanismus by tedy zahájil proces na aplikaci A, která by pak vrátila řízení zpět. Tento mechanismus by pak zavolal aplikaci B a tak dále. V tomto případě by bylo vždy možné určit, která z fází obchodního procesu se v daném čase provádí, protože kontrola nad jeho průběhem by již byla centralizovaná. Pomocí určitých nástrojů zmíněného mechanismu by přitom mohly být prováděny procesní změny. Je jasné, že některé z procesních komponent nižší úrovně budou zabudovány do samostatných aplikací, ale ty by měly být umístěny pod úrovní, na které se provádějí funkce relevantní pro podnikání, tedy pod úrovní, na které platí platné standardy a podnikové zásady. funkce.
Volné spojení mezi prvky znamená, že každá aplikace je relativně nezávislá na jiných aplikacích v rámci celkového systému. Ve volně propojeném prostředí lze tedy provádět změny v jedné aplikaci, aniž by to ovlivnilo ostatní aplikace, což je v takových případech obvykle nevyhnutelné. Přinejmenším lze tento princip někdy chápat tak, že umožňuje implementaci aplikací způsobem plug and play, protože jsou na sobě natolik nezávislé, že je lze nahradit, aniž by to ovlivnilo systém jako celek. Použití „distribuovaného systému“ znovu zdůrazňuje, že NGOSS není založeno na použití jediné monolitické aplikace telekomunikační společností pro řízení všech operací podniku, ale místo toho se navrhuje používat sadu aplikací. které jsou integrované a vzájemně se ovlivňují.
Integrace systémů OSS znamená, že aplikace si musí „umět“ vyměňovat různé druhy dat mezi sebou. A aby byl tento proces efektivní, musí každá aplikace „vědět“, jak kterákoli jiná aplikace „rozumí“ nebo interpretuje ten či onen blok přenášených dat. Abyste tomu porozuměli, můžete použít příklad poskytování informací o faktuře klientovi: aplikace A přijme požadavek klienta na fakturu a odešle tyto informace pomocí aplikace B (fakturační systém). Aplikace A bude mít informace o adrese klienta a je nutné, aby aplikace B zaslala fakturu na tuto adresu. Aby si systémy mohly vyměňovat data, musí mít standardní formát informací o adrese: počet řádků s informacemi o adrese, počet znaků v každém řádku – to vše by mělo být pro každý systém stejné a každá aplikace ví, který formát, se kterým pracuje jiná aplikace. Vše je zcela zřejmé a jednoduché. Lze si však představit potíže, které by nastaly, kdyby aplikace A pracovala s produkty, které by se skládaly z několika dílčích produktů (širokopásmový přístup po měděných linkách, modem, sada filtrů a širokopásmová konverze) a přenášely by celé spektrum dat do aplikace B, zatímco aplikace B očekávala, že obdrží pouze jeden řádek tohoto produktu/objednávky. Pokoušet se převést hierarchické produkty na nehierarchické bez ztráty informací by bylo nemožné. Řešení tohoto problému poskytuje jednotný informační model pro data vyměňovaná mezi aplikacemi. Řešení od TMF se nazývá Common Information Model.
Zpočátku (asi v polovině 80. let) se systémy OSS vyvíjely jako samostatné aplikace. Počátkem 90. let se však ukázalo, že používání těchto systémů jako samostatných aplikací je vysoce neefektivní, protože to vedlo k situaci, kdy je např. objednávka přijata v jednom systému a následně jsou některé části z této objednávky převedeny do jiný systém za účelem konfigurace odpovídajícího síťového zařízení. Hlavním přínosem z kombinace samostatných systémů OSS je získání takové příležitosti, jako je „průtokové poskytování“ („monitorování průběhu procesu“), kdy by bylo možné zadat objednávku online a výsledek by byl automaticky monitorován bez účast personálu. Pro velké telekomunikační operátory se stovkami samostatných systémů OSS se však rozšíření rozhraní stalo vážným problémem. Každý OSS musel „mluvit“ s mnoha dalšími, což vedlo k exponenciálnímu nárůstu počtu rozhraní s rostoucím počtem systémů OSS. NGOSS popisuje použití společné komunikační infrastruktury (CCI). V tomto modelu OSS systémy komunikují spíše s CCI než přímo mezi sebou. CCI tak umožňuje aplikacím komunikovat pomocí CCI k jejich propojení. Každá aplikace tedy vyžaduje pouze jedno rozhraní (pro CCI) a ne mnoho (pro všechny ostatní aplikace). Tím se výrazně snižuje složitost celého systému. CCI může také poskytovat další služby, včetně zabezpečení, konverze dat a tak dále.
Vzhledem k výše uvedenému popisu toho, jak aplikace interagují s CCI, je jasné, že musí existovat způsob, jak tato rozhraní zdokumentovat, a to jak z hlediska základní technologie (např. Java/JMS nebo webové služby/SOAP), tak z hlediska funkčnosti aplikace. , použitá data, počáteční a konečné podmínky atd. Specifikace NGOSS poskytují schopnost dokumentovat tato rozhraní, a tak se rozhraní stávají dobře definovány a zavedeny. Specifikace NGOSS lze považovat za doplnění specifikací API (Application Programming Interface).
Koncept NGOSS, který zahrnuje modely eTOM , SID , TAM a TNA a také životní cyklus řešení v kombinaci s metodikou SANRR , je komplexní metodikou pro vývoj, implementaci, provoz a rozvoj systémů OSS/BSS . S jeho pomocí je možné integrovat obchodní požadavky a technické aspekty činnosti telekomunikačního operátora do jediné architektury, automatizovat obchodní procesy v heterogenních IT prostředích a budovat jednotnou informační infrastrukturu striktně zaměřenou na plnění obchodních úkolů telekomunikačního operátora. společnost. Využití nástrojů a metodik životního cyklu NGOSS může výrazně přispět k úspěchu efektivního řízení komunikačních společností. Je však třeba chápat, že samotná možnost využití těchto nástrojů do značné míry závisí na připravenosti firmy přijmout změny, připravenosti infrastruktury implementovat komplexní manažerský informační systém, připravenosti personálu implementovat, spravovat a většinu důležité je, aby tyto nástroje využívali při svých činnostech.