Szkieletx - Frameworx

Frameworx to struktura architektury korporacyjnej ukierunkowana na dostawców usług komunikacyjnych .

Jest rozwijany przez TM Forum .

Struktura

Frameworx składa się z czterech ram:

Ramy informacyjne

Ramowa Informacja (formalnie Shared Information / Data Model lub SID) jest jednolity referencyjny model danych zapewnienie jednolitego zbioru terminów dla obiektów biznesowych w telekomunikacji . Celem jest umożliwienie ludziom z różnych działów, firm lub lokalizacji geograficznych używania tych samych terminów do opisywania tych samych obiektów, praktyk i relacji w świecie rzeczywistym. Jest częścią Frameworx.

Ramy informacyjne, jako model informacyjny Frameworx, zapewniają model odniesienia informacji/danych oraz wspólne słownictwo informacji/danych z perspektywy biznesowej oraz systemowej. Ramy informacyjne wykorzystują zunifikowany język modelowania, aby sformalizować wyrażanie potrzeb określonego punktu widzenia interesariuszy.

Ramy Informacyjne zapewniają wspólny język do komunikowania obaw czterech głównych grup części składowych (interesariuszy) reprezentowanych przez Punkty widzenia Frameworx - Biznes, System, Wdrożenie i Wdrożenie, zgodnie z definicją w Cyklu Życia Frameworx. Stosowany w połączeniu z opisami procesów biznesowych i działań Business Process Framework (eTOM) oraz mapą aplikacji telekomunikacyjnych, platforma informacyjna umożliwia łączenie grup biznesowych i informatycznych w organizacji poprzez dostarczanie definicji, które są zrozumiałe dla biznesu, ale są również wystarczająco rygorystyczne, aby można je było wykorzystać do tworzenia oprogramowania.

Model Information Framework czerpie inspirację z wielu różnych źródeł branżowych, ale jego głównymi źródłami są Alliance Common Information Architecture (ACIA) stworzona przez zespół kierowany przez Billa Brooka z AT&T i BT Group oraz Directory Enabled Networks - następna generacja (DEN -ng) model stworzony przez Johna Strassnera.

Kiedy został wprowadzony na rynek w 2000 roku, model Information Framework dobrze obejmował obszar biznesowy (BSS), a także obszar zarządzania urządzeniami, ale był niewystarczający w swojej zdolności do reprezentowania sieci logicznych i pojemności. Te braki są usuwane poprzez rewizję modelu w celu uwzględnienia takich pojęć, jak topologie, ale historia doprowadziła do słabego wykorzystania modelu w niektórych dziedzinach telekomunikacji, takich jak zarządzanie zapasami.

Zasady

Frameworx opiera się na tych kluczowych zasadach.

Oddzielenie procesu biznesowego od wdrożenia komponentu

Gdy systemy wsparcia operacyjnego (OSS) są ze sobą połączone, obsługiwane przez nie procesy biznesowe zostają rozproszone w całym obszarze IT. W efekcie dochodzi do sytuacji, w której proces zaczyna się od aplikacji A, która przetwarza pewne dane, a następnie wie, że musi wywołać aplikację B, która również wykonuje pewne przetwarzanie, a następnie wywołuje C itd. W rezultacie niezwykle trudno jest to zrozumieć, gdzie faktycznie znajduje się którykolwiek z tych przepływów (np. jeśli przepływ procesu ma na celu przyjęcie zamówienia klienta, czy to aplikacja A, B lub C aktualnie obsługuje to zamówienie?) i jeszcze trudniej jest zmienić proces ze względu na jego rozproszona natura.

Frameworx proponuje, aby proces był zarządzany jako część scentralizowanej infrastruktury, przy użyciu silnika przepływu pracy, który jest odpowiedzialny za kontrolę przepływu procesu biznesowego między aplikacjami. W związku z tym silnik przepływu pracy zainicjuje proces w aplikacji A, który następnie zwróci sterowanie do silnika przepływu pracy, który następnie wywoła aplikację B i tak dalej. W ten sposób zawsze można dowiedzieć się, gdzie znajduje się pojedynczy przepływ procesu, ponieważ jest on kontrolowany przez centralny silnik przepływu pracy, a modyfikacje procesu można wprowadzać za pomocą narzędzi do definicji procesu silnika. Oczywiście niektóre przepływy procesów niższego poziomu zostaną osadzone w poszczególnych aplikacjach, ale powinno to być poniżej poziomu przetwarzania istotnego z punktu widzenia biznesowego (tj. poniżej poziomu, na którym wdrażane są zasady i reguły biznesowe). Metodologie certyfikacji Frameworx pomagają nam radzić sobie z zakresem preferencji, które nie są rozłożone liniowo, jako otwarcie na ulepszenie przyjętej przez klienta niezaprzeczalnie właściwej metody.

Luźno sprzężony system rozproszony

Główny artykuł: Luźne sprzęgło

„Luźno połączona” oznacza, że ​​każda aplikacja jest względnie niezależna od innych aplikacji w całym systemie. W związku z tym w luźno powiązanym środowisku jedna aplikacja może zostać zmieniona bez konieczności wprowadzania zmian w innych. Doprowadzone do skrajności, może to czasami być postrzegane jako zdolność do „podłącz i używaj” aplikacji, gdzie są one tak niezależne, że można je zmieniać bez wpływu na ogólne zachowanie systemu. Ta skrajność jest obecnie uważana za nieprawdopodobną nirwanę.

„System rozproszony” podkreśla, że ​​Frameworx nie jest oparty na dostawcy usług komunikacyjnych (CSP) używającym pojedynczej monolitycznej aplikacji do zarządzania wszystkimi swoimi działaniami, ale zamiast tego używa zestawu zintegrowanych i współpracujących aplikacji.

Model wspólnych informacji

Integracja OSS oznacza, że ​​dane muszą być współdzielone między aplikacjami. Aby było to skuteczne, każda aplikacja musi rozumieć, w jaki sposób każda inna aplikacja rozumie/interpretuje tę część udostępnianych danych, albo musi istnieć wspólny model udostępnianych danych. Aby to zrozumieć, rozważmy aplikację do obsługi zamówień, która przeszła proces wprowadzania zamówienia klienta i teraz musi wysłać rachunek za pomocą aplikacji B (system bilingowy). Aplikacja A będzie miała zapis adresu klienta i dlatego musi upewnić się, że aplikacja B wyśle ​​rachunek na ten adres. Przekazywanie tych danych między systemami wymaga po prostu wspólnego formatu informacji adresowych – każdy system musi oczekiwać takiej samej liczby linii adresowych, przy czym każda linia ma tę samą długość. To całkiem proste. Ale wyobraź sobie trudność, jaka by się pojawiła, gdyby aplikacja zamawiająca działała na produktach składających się z wiązek podproduktów (np. produkt dostępu szerokopasmowego z linii miedzianej, modem, zestaw filtrów i konwersja szerokopasmowa), podczas gdy rozliczenie aplikacja oczekiwała tylko pojedynczych linii produktów/zamówień. Próba zamiany produktów hierarchicznych na niehierarchiczne bez utraty informacji nie byłaby możliwa. Pojedynczy model informacji dla danych, które są w ten sposób udostępniane między aplikacjami, stanowi rozwiązanie tego problemu. Rozwiązanie TMF do tego celu nazywa się Shared Information/Data-Model (SID).

Wspólna infrastruktura komunikacyjna

W połowie lat 80. komputerowe systemy OSS były rozwijane jako samodzielne aplikacje. Jednak na początku lat 90. stało się jasne, że stosowanie ich jako czysto odizolowanych aplikacji było wysoce nieefektywne, ponieważ prowadziło do sytuacji, w której na przykład zamówienia byłyby przyjmowane w jednym systemie, ale szczegóły musiałyby zostać ponownie wprowadzone do inny w celu skonfigurowania odpowiedniego sprzętu sieciowego. Wykazano, że znaczne zwiększenie wydajności jest możliwe dzięki połączeniu ze sobą samodzielnych systemów OSS, aby umożliwić takie funkcje, jak „przepływowe dostarczanie”, gdzie zamówienie może być składane online i automatycznie skutkować zaopatrzeniem sprzętu bez interwencji człowieka.

Jednak dla dużych operatorów z wieloma setkami oddzielnych OSS, mnożenie się interfejsów stało się poważnym problemem. Każdy OSS musiał „rozmawiać” z wieloma innymi, co prowadziło do wzrostu liczby interfejsów wraz z kwadratem liczby OSS.

Frameworx opisuje wykorzystanie wspólnej infrastruktury komunikacyjnej (CCI). W tym modelu systemy OSS współpracują z CCI, a nie bezpośrednio ze sobą. CCI umożliwia zatem aplikacjom współpracę przy użyciu CCI do łączenia ich ze sobą. W ten sposób każda aplikacja wymaga tylko jednego interfejsu (do CCI), a nie wielu (do innych aplikacji). Złożoność jest zatem zredukowana do jednego rzędu n, zamiast N 2 .

CCI może również świadczyć inne usługi, w tym bezpieczeństwo, tłumaczenie danych itp.

Interfejsy zdefiniowane w umowie

Biorąc pod uwagę powyższy opis sposobu, w jaki aplikacje łączą się z CCI, jasne jest, że potrzebujemy sposobu udokumentowania tych interfejsów, zarówno pod względem zastosowanej technologii (np. Java/JMS czy Web services/SOAP?), ale także funkcjonalności aplikacja, użyte dane, warunki wstępne i końcowe itp. Specyfikacja kontraktowa Frameworx zapewnia środki do dokumentowania tych interfejsów, a zatem są to interfejsy zdefiniowane w umowie.

Kontrakty Frameworx można postrzegać jako rozszerzenia specyfikacji interfejsu programowania aplikacji (API).

Artykuły

Model procesu

ETOM (zwiększona Telecom Operations Map, wyraźne ee-tom) stanowi ramy procesów biznesowych Frameworx.

Model wspólnych informacji

Informacje Frameworx to Shared Information/Data Model (SID).

Model cyklu życia

Model cyklu życia Frameworx [1] ma na celu zdefiniowanie wykorzystania i wdrożenia Frameworx w organizacji i zapewnia ramy do korzystania z architektury SID, eTOM i Frameworx. Model ten opiera się na znacznym wcześniejszych prac, w tym siatka zachmana , Kernighana , Yourdon oraz Object Management Group „s Model Driven Architecture . Cykl życia Frameworx dzieli rozwój systemów na 4 etapy: wymagania, projekt systemu, wdrożenie i działanie.

Specyfikacje umowy

Jak wspomniano wcześniej, kontrakt Frameworx jest podstawową jednostką interoperacyjności w systemie Frameworx. Interoperacyjność jest ważna dla każdego z czterech widoków zdefiniowanych przez cykl życia Frameworx. Na przykład Umowa służy do zdefiniowania usługi, która ma zostać dostarczona, a także do określenia informacji i kodu, które wdrażają usługę. Umowa służy również do monitorowania, administrowania i utrzymania usługi oraz zapewnienia, że ​​wszelkie zewnętrzne zobowiązania wynikające z umowy (np. z umowy SLA (umowa o poziomie usług)) są spełnione oraz do określenia, jakie środki należy podjąć, jeśli zostaną one w jakiś sposób naruszone .

Mapa aplikacji telekomunikacyjnych

Image
TAM

Applications Framework (formalnie Telecom Application Map (TAM)) jest jednym z podstawowych artefaktów Frameworx. Uwzględnia rolę i funkcjonalność różnych aplikacji, które dostarczają możliwości OSS ( System Wsparcia Operacji ) i BSS ( System Wsparcia Biznesu ).

W ten sposób umożliwia pisanie dokumentów zamówienia z odniesieniem do ram, zapewniając w ten sposób jasne, jednoznaczne deklaracje funkcjonalności wymaganej od danej aplikacji, identyfikowanie nakładających się funkcji istniejących aplikacji, ułatwiając tym samym racjonalizację i identyfikowanie luk funkcjonalnych.

Poziom rozkładu funkcjonalnego jest taki, że korzyści te mogą być zrealizowane, ale bez nadmiernego nakazu.

W ramach TM Forum istnieje silna definicja procesu i danych. Applications Framework zapewnia sformalizowany sposób grupowania funkcji i danych w rozpoznawane komponenty, które następnie są uważane za potencjalnie dostępne jako aplikacje lub usługi. Aplikacja lub usługa (na przykład: usługi sieci Web) może być stosunkowo gruboziarnistym oprogramowaniem, które implementuje funkcje/procesy i działa na danych lub wykorzystuje dane. W codziennym życiu widzimy aplikacje, takie jak edytory tekstu lub klienty poczty; w kategoriach OSS uznalibyśmy aplikację za coś takiego jak komponent CRM, system bilingowy czy rozwiązanie inwentaryzacyjne – choć rozumiemy też, że można je w pewnym stopniu zdekomponować – np. system bilingowy będzie zawierał szereg mniejszych aplikacji, takich jak silnik oceny.

„Aplikacja” jest zdefiniowana jako zestaw jednego lub więcej artefaktów oprogramowania obejmujący dobrze zdefiniowane funkcje, dane, przepływy biznesowe, reguły i interfejsy. Obejmuje to model danych dla danych wykorzystywanych do łączenia się z aplikacją i wewnątrz aplikacji, zasady zarządzania zewnętrznymi i wewnętrznymi zasobami aplikacji, model przepływu dla funkcjonalności z aplikacją oraz specyfikacje kontraktu dla zewnętrznie widocznych interfejsów do funkcjonalności w ramach aplikacji

Aplikacje można wdrażać jako pakiety do wdrożenia i można je nabyć na rynku systemów.

Applications Framework nie jest częścią definicji Information Framework ani Business Process Framework (eTOM), ale łączy się z nimi w łatwo zrozumiały sposób, a także zapewnia mapowanie między nimi.

Zewnętrzne linki

Inne informacje

mTOP to program w ramach TeleManagement Forum (TM Forum), który obejmuje definicję interfejsów zarządzania sieciami telekomunikacyjnymi. mTOP obejmuje zarówno zarządzanie zasobami, jak i usługami.

Zobacz też