Frameworx – pakiet standardów umożliwiający dostawcom usług ocenę i udoskonalenie wydajności biznesowej przez zastosowanie podejścia zorientowanego na usługi wobec operacji i integracji. Właścicielem Frameworx jest TM Forum (wcześniej – TeleManagement Forum), którego celem jest dostarczenie sposobów pomocy dostawcom usług w zarządzaniu ich działalnością. Frameworx obejmuje zestaw zasad i techniczne produkty cząstkowe (ang. technical deliverables). Frameworx wcześniej znany był jako NGOSS (ang. New Generation Operations Systems and Software).
CHARAKTERYSTYKA
Właścicielem Frameworxu, który go jednocześnie wspiera, jest TM Forum. Jest to dojrzały standard, który został opracowany w 1998 roku i jest regularnie aktualizowany zgodnie z rozwijającymi się potrzebami biznesowymi. Aktualna wersja 11.5 została opublikowana w listopadzie 2011.
Frameworx umożliwia zorientowane na usługi, wysoce zautomatyzowane i efektywne podejście do prowadzenia działalności dostawcy usług na podstawie czterech komponentów:
- eTOM – framework procesu biznesowego (ang. Business Process Framework) – dostarcza obszerne, zgodne z praktyką, wielowarstwowe postrzeganie kluczowych procesów biznesowych wymaganych przez dostawcę usług do prowadzenia działalności. Skrót eTOM pochodzi od enhanced Telecom Operations Map.
- SID – framework informacyjny (ang. Information Framework) – dostarcza obszerne, zgodne z praktyką definicje informacji, które przepływają przez firmę oraz między dostawcą usług, a jego partnerami biznesowymi. Skrót SID pochodzi od Shared Information/Data model.
- TAM – framework aplikacji (ang. Application Framework) – dostarcza model grupowania procesów oraz skojarzonych z nimi informacji w łatwe do rozpoznania aplikacje. Zapewnia wspólny język oraz system identyfikacyjny między kupującym, a dostawcą dla wszystkich obszarów aplikacji. Skrót TAM pochodzi od Telecom Application Map.
- TIP – framework integracji (ang. Integration Framework) – definiuje, w jaki sposób procesy oraz informacje ukryte za danymi systemami mogą być zautomatyzowane przez zdefiniowanie zestandaryzowanej architektury zorientowanej na usługi (ang. Service Oriented Architecture, SOA) – interfejsów nazywanych usługami biznesowymi (ang. Business Services), a wcześniej znanymi jako “NGOSS Contracts”. Skrót TIP pochodzi od TM Forum Integration Program.
ZASADY
Frameworx jest oparty na pięciu kluczowych zasadach:
- Oddzielenie procesu biznesowego od implementacji komponentów (ang. Separation of Business Process from Component Implementation)
- System rozproszony luźno powiązany (ang. Loosely Coupled Distributed System)
- Wspólny model informacji (ang. Shared Information Model)
- Infrastruktura wspólnej komunikacji (ang. Common Communications Infrastructure)
- Interfejsy zdefiniowane kontraktowo (ang. Contract Defined Interfaces)
Oddzielenie procesu biznesowego od implementacji komponentów
Kiedy OSS-y (ang. Operations Support Systems) są ze sobą połączone, wówczas wspierane przez nie procesy biznesowe stają się rozproszone w całej strefie IT. W rezultacie, dochodzi do sytuacji, w której proces rozpoczyna się aplikacją A, która przetwarza część danych i następnie wie, że musi wywołać aplikację B, która również wykonuje część przetwarzania, później wywołuje aplikację C, itd. Wynikiem jest to, że zrozumienie, jaki dokładnie jest przebieg (ang. flows) jest niesamowicie trudne (np. jeżeli celem przebiegu procesu jest przyjęcie zamówienia klienta, to która aplikacja – A, B, czy C – obsługuje to zamówienie?), a jeszcze trudniej jest zmienić proces ze względu na jego rozproszony charakter.
Propozycja Frameworxu jest taka, aby proces był zarządzany jako część scentralizowanej infrastruktury, z użyciem modułu sterowania kolejnością zadań (ang. workflow engine), który jest odpowiedzialny za kontrolowanie przebiegu procesu biznesowego między aplikacjami. Dlatego moduł sterowania kolejnością zadań rozpocząłby proces od aplikacji A, która później oddałaby kontrolę modułowi sterowania kolejnością zadań, który następnie wywołałby aplikację B, itd. W taki sposób zawsze można dowiedzieć się, jak przebiega proces, ponieważ jest on kontrolowany przez moduł sterowania kolejnością zadań i można dokonywać modyfikacji na podstawie narzędzi definiujących procesy. Oczywiście, przebiegi pewnych procesów niższego rzędu będą wbudowane w pojedyncze aplikacje, ale to powinno odbywać się poniżej poziomu przetwarzania istotnego biznesowo (np. poniżej poziomu wdrażania polityki i zasad biznesowych). Metody certyfikacji Frameworxu pomagają nam w radzeniu sobie z zakresem preferencji, które nie są rozproszone liniowo jako początek udoskonalenia zaakceptowanej przez klienta, niewątpliwie odpowiedniej metody.
System rozproszony luźno powiązany
Luźno powiązany oznacza, że każda aplikacja jest stosunkowo niezależna od innych aplikacji w systemie ogólnym. Dlatego w luźno powiązanym środowisku, jedna aplikacja może zostać zmieniona i niekoniecznie wpłynie to na pozostałe aplikacje. Ze skrajnego punktu widzenia może to być czasem postrzegane jako tworzenie możliwości dla aplikacji typu „plug and play” (dosł. podłącz i używaj), gdzie są tak bardzo niezależne, że mogą być zmienione, nie wpływając na ogólne zachowanie systemu. Taka skrajność jest obecnie uważana jako coś mało prawdopodobnego do wystąpienia.
System rozproszony podkreśla, że Frameworx nie bazuje na dostawcy usług komunikacyjnych (ang. Communication Service Provider, CSP), używającego pojedynczej monolitycznej aplikacji w celu zarządzania wszystkimi jej działaniami, ale używającego zamiast tego zbioru zintegrowanych i współpracujących ze sobą aplikacji.
Wspólny model informacji
Zintegrowanie OSS-ów oznacza, że dane muszą być najpierw podzielone między aplikacjami. Aby było to skuteczne: albo każda aplikacja musi rozumieć, w jaki sposób inna aplikacja rozumie/interpretuje wspólne dane, albo musi istnieć wspólny model współdzielonych informacji. Aby to zrozumieć, proszę pomyśleć o aplikacji zajmującej się zamówieniami, która przeszła przez proces, aby wprowadzić zamówienie i musi teraz wysłać fakturę, używając aplikacji B (system fakturowania – ang. billing system). Aplikacja A będzie posiadała rekordy adresu klienta i dlatego musi zapewnić, że aplikacja B wyśle fakturę na ten adres. Rozdzielanie tych danych między systemy wymaga po prostu wspólnego formatu dla informacji adresowej – każdy system musi oczekiwać takiej samej liczby wierszy adresowych (ang. address lines), przy czym każdy wiersz adresowy musi mieć taką samą długość. To bardzo proste. Ale proszę sobie wyobrazić, że pojawiają się trudności, jeżeli aplikacja zamawiania działa na produktach, które składają się z pakietów podproduktów (ang. sub-products) (np. produkt dostępny szerokopasmowo – ang. broadband access product – utworzonych z przewodu miedzianego, modemu, zbioru filtrów i konwersji szerokopasmowej), podczas gdy aplikacja fakturowania oczekiwała tylko pojedynczych linii produktów/zamówień (ang. product/order lines). Próba konwersji hierarchicznych produktów w produkty niehierarchiczne, bez utraty informacji, nie byłaby możliwa. Pojedynczy model informacji dla danych, które są współdzielone przez aplikacje, wprowadza w ten sposób rozwiązanie tego problemu. Rozwiązanie TMF to Shared Information/Data Model (SID).
Infrastruktura wspólnej komunikacji
Pierwotnie (w połowie lat 80. XX wieku), OSS-y oparte na komputerach były opracowane jako autonomiczne aplikacje. Jednak, we wczesnych latach 90., stało się oczywiste, że zastosowanie tych odizolowanych aplikacji było bardzo nieefektywne, ponieważ prowadziło do sytuacji, w której, np. zamówienia mogły być przyjmowane przez jeden system, ale szczegóły musiałyby być wówczas wpisane ponownie w inny system, aby skonfigurować odpowiedni sprzęt sieciowy. Wykazano, że największy przyrost wydajności był możliwy przez połączenie niezależnych OSS-ów, aby dopuścić elementy takie jak „dostarczanie przepływowe” (ang. Flow-through provisioning), w którym zamówienie byłoby składane online i automatycznie skutkowałoby dostarczeniem sprzętu, bez interwencji człowieka. Jednak w przypadku dużych operacji z setkami oddzielnym OSS-ów, proliferacja interfejsów stała się poważnym problem. Każdy OSS musiał „rozmawiać” z wieloma innymi, tworząc określoną liczbę interfejsów, zwiększających do kwadratu liczbę OSS-ów.
Frameworx opisuje stosowanie infrastruktury wspólnej komunikacji (ang. Common Communications Infrastructure, CCI). W modelu tym, OSS-y sprzęgają się raczej z CCI niż bezpośrednio ze sobą nawzajem. Stąd, CCI pozwala aplikacjom na wspólną pracę z użyciem CCI, aby łączyć się ze sobą. W taki sposób, każda aplikacja wymaga raczej tylko jednego interfejsu (dla CCI) niż wielu (dla innych aplikacji). Dlatego złożoność zostaje zredukowana to jednego zamówienia n, a nie do n2. CCI może dostarczać również inne usługi, łącznie z bezpieczeństwem, translacją danych, itp.
Interfejsy zdefiniowane kontraktowo
Biorąc pod uwagę powyższy opis tego, jak aplikacje sprzęgają się z CCI, staje się oczywiste że potrzebujemy sposobu na udokumentowanie tych interfejsów, zarówno pod względem zastosowanej technologii (np. czy jest to Java/JMS, czy usługi Web/SOAP?), ale również funkcjonalności aplikacji, używanych danych, warunków przed i po, itd. Specyfikacja kontraktów Frameworx zapewnia środek do udokumentowania wspomnianych interfejsów, które z tego powodu można nazwać interfejsami zdefiniowanymi kontraktowo.
Kontrakty Frameworx mogą być postrzegane jako przedłużenie specyfikacji Application Programming Interface (API).
MODEL CYKLU ŻYCIA
Model cyklu życia Frameworx zmierza do zdefiniowania zastosowania i wdrożenia Frameworx’u w organizacji i dostarcza frameworku przez użycie SID, eTOM i architektury Frameworx. Model jest oparty w znacznej mierze na wcześniejszych opracowaniach, włączając Zachman Framework, Kernighan, Yourdon oraz Object Management Group’s Model Driven Architecture. Cykl życia Frameworx dzieli rozwój systemów na 4 etapy: wymagania, projektowanie systemu, implementacja i operacje.
Specyfikacje kontraktu
Frameworx Contract jest fundamentalną jednostką interoperacyjności w systemie Frameworx. Interoperacyjność jest ważna dla każdego z czterech punktów widzenia zdefiniowanych przez cykl życia Frameworx. Przykładowo, kontrakt jest używany w celu zdefiniowania usługi, która ma zostać dostarczona, jak również do określenia informacji i kodu, które implementują usługę. Kontrakt jest również stosowany w celu monitorowania, zarządzania i utrzymywania usług oraz zapewniania, że jakiekolwiek zewnętrzne zobowiązania kontraktu (np. że SLA są wypełnione, jak również zdefiniowania, jakie środki należy przedsięwziąć, jeżeli w pewnym stopniu zobowiązania są naruszane).
Telecom Application Map
Telecom Application Map (TAM) łączy sposoby postrzegania procesów ze sposobami postrzegania danych/informacji, aby opisać aplikacje typu IT, którymi mogą się zajmować dostawcy usług.
ZAKRES I OGRANICZENIA
Frameworx znajduje zastosowanie do dowolnych organizacji, będących dostawcami usług. Frameworx jest związany z najlepszymi praktykami Architektury Korporacyjnej (ang. Enterprise Architecture). Jest dopasowany do standardów SOA i TOGAF, jak również do COBIT i ITIL.
Mocne strony:
- lepsze zrozumienie klientów przez wspólny model informacyjny zarządzania klientami;
- innowacja i obniżenie TTM (ang. time-to-market) wraz z usprawnionym zarządzaniem usługami typu E2E (ang. end-to-end);
- obniżenie kosztów operacyjnych poprzez umożliwienie wysoce efektywnych, zautomatyzowanych, standardowych operacji przemysłowych.
Ograniczenia:
- nieodpowiedni architekt wiodący (główny architekt), który nie będzie skutecznym liderem, spowoduje „wykolejenie” inicjatywy;
- skupianie się na dziedzinie technicznej, czyli wyłącznie na „skrzynkach” architektury indywidualnej – standardy integracji i interoperacyjności stanowią najwyższe priorytety dla architektury korporacyjnej.
