Modele odniesienia w rozwoju infrastruktury informacyjnej

Józef LUBACZ*
Modele odniesienia
w rozwoju infrastruktury informacyjnej1)
Imponuj¹ce sukcesy Internetu i sieci komunikacji ruchomej
sk³aniaj¹ do uproszczonych ekstrapolacji w sferze ekonomicznej
i technicznej: skoro jest tak dobrze, to w przysz³oœci mo¿e byæ
tylko jeszcze lepiej. Entuzjazm w sferze biznesowej najwyraŸniej
och³ód³ w ostatnim czasie, jednak czas zasadniczych przewartoœciowañ dopiero przed nami. O konsekwencjach uproszczonych
ekstrapolacji w sferze technicznej, szczególnie zwi¹zanej z technik¹ IP, mia³em ju¿ okazjê wypowiedzieæ siê na ³amach PTiWT
[2, 3]. W niniejszym tekœcie wracam do tej kwestii, rozwa¿aj¹c j¹
z innego punktu widzenia: roli abstrakcyjnych modeli konceptualnych – modeli odniesienia – w racjonalnym rozwoju infrastruktury informacyjnej.
ROLA MODELI ODNIESIENIA
Aby wyjaœniæ postulowan¹ tu rolê modeli odniesienia, pos³u¿ê
siê „historyjk¹ obrazkow¹” z rys. 1. Historyjka ta obrazuje wspó³zale¿noœæ aplikacji (us³ug), œrodków technicznych (techniki/technologii) i standardów (normalizacji) w procesie rozwoju infrastruktury informacyjnej, a na dobr¹ sprawê w rozwoju ka¿dej
u¿ytecznej infrastruktury. Rozwój aplikacji, œrodków technicznych i standardów przedstawiono za pomoc¹ obracaj¹cych siê
kó³ zêbatych (analogia, przyznajê, nieco siermiê¿na, proszê jednak zwróciæ uwagê, ¿e ko³a s¹ uœmiechniête).
* Instytut Telekomunikacji Politechniki Warszawskiej,
e−mail: [email protected]
1)
Tekst ten jest przeredagowan¹ wersj¹ referatu plenarnego
wyg³oszonego przez autora na konferencji VITEL 2000 [1]
O Rys. 1. Aplikacje (A), środki techniczne (T), standardy (S), a mo−
dele odniesienia (MO)
Oczywiœcie aplikacje (A), œrodki techniczne (T) i standardy (S)
powinny rozwijaæ siê wspó³zale¿nie („zazêbiaæ siê”), a wiêc sytuacja przedstawiona na rys. 1a nie jest w³aœciwa. Konfiguracja
z rys. 1b nie zadzia³a – ko³a s¹ zablokowane, musimy zatem pomyœleæ o innym rozwi¹zaniu (nota bene tak jak na rys. 1c przedstawiano niegdyœ zalety wspó³pracy miêdzynarodowej w ramach
RWPG). Jedn¹ z mo¿liwoœci przedstawiono na rys. 1c. Jest ona
bardziej sensowna, lecz nadal niezadowalaj¹ca: jedno z kó³ znajduje siê w pozycji uprzywilejowanej (w przyk³adzie z rys. 1c – s¹
to œrodki techniczne), co grozi brakiem harmonijnego rozwoju
uk³adu. Wyjœciem z tej sytuacji jest wprowadzenie czwartego koPRZEGLĄD TELEKOMUNIKACYJNY ! ROCZNIK LXXIV ! nr 1/2001
³a, w uk³adzie jak na rys. 1d. Ko³o to, sprzêgniête z trzema pozosta³ymi, symbolizuje modele konceptualne – modele odniesienia.
Ko³o modeli odniesienia zapewnia zarówno wzajemn¹ harmonizacjê, jak i wirtualn¹ niezale¿noœæ trzech pozosta³ych kó³. Uk³ad
z rys. 1d pozostaje jednak nadal nierealistyczny, a to dlatego, ¿e
ko³o modeli odniesienia musi obracaæ siê szybciej ni¿ pozosta³e
trzy, te zaœ maj¹ jednakow¹ prêdkoœæ obrotow¹. Bardziej realistyczna jest konfiguracja z rys. 1e: wszystkie ko³a s¹ sprzê¿one,
ka¿de obraca siê z inn¹ prêdkoœci¹ (ró¿ne tempo rozwoju aplikacji, œrodków technicznych i standardów), ko³o modeli odniesienia
obraca siê najwolniej (modele konceptualne nie mog¹ zmieniaæ
siê zbyt szybko, jeœli maj¹ byæ stabilizuj¹cym elementem uk³adu).
Istotê roli modeli odniesienia – „czwartego ko³a” – chyba naj³atwiej wyjaœniæ odwo³uj¹c siê do roli, jak¹ odegra³ model odniesienia OSI (Open System Interconnection Reference Model –
OSI RM). Zanim powsta³ model odniesienia OSI, trudno by³o sobie wyobraziæ, ¿e mo¿na wprowadziæ porz¹dkuj¹ce zasady architektoniczne do starej (maj¹cej tysi¹ce lat!) sztuki tworzenia
protoko³ów komunikacyjnych – funkcjonalnoœæ komunikacyjna
wydawa³a siê trudna do usystematyzowania. Idee, które leg³y
u podstaw modelu OSI, by³y pocz¹tkowo doœæ trudne do przyjêcia: wydawa³y siê zbyt abstrakcyjne, arbitralne i ogólnikowe. Minê³o sporo czasu, nim wesz³y one do codziennej praktyki in¿ynierskiej, nim sta³y siê czymœ „naturalnym”. Z dzisiejszej perspektywy jest ju¿ jasne, ¿e rola modelu odniesienia OSI w porz¹dkowaniu coraz bogatszej i bardziej z³o¿onej funkcjonalnie
sfery protoko³ów komunikacyjnych jest trudna do przecenienia.
Trudno nawet wyobraziæ sobie rozwój infrastruktury telekomunikacyjnej bez tego modelu.
Opis wprowadzaj¹cy model odniesienia OSI by³ zwiêz³y i ogólny, ustanawia³ jedynie architektoniczne zasady konstruowania
i dekompozycji protoko³ów w siedmiowarstwowej strukturze hierarchicznej. Nie dotyczy³ ¿adnych konkretnych protoko³ów komunikacyjnych, nie to bowiem by³o jego celem. Wype³nienie modelu treœci¹ aplikacyjn¹ – tworzenie stosów protoko³ów, konkretnych standardów – nadesz³o póŸniej. Podkreœlmy: rola modelu
odniesienia i rola standardów zosta³y wyraŸnie oddzielone (por.
rys. 1).
Pomimo wielkiej roli, jak¹ odegra³, model odniesienia OSI by³,
i nadal jest, doœæ czêsto krytykowany. Najbardziej radykalni
twierdz¹ wrêcz, ¿e „OSI jest martwy”. Krytyka opiera siê zazwyczaj na nastêpuj¹cym rozumowaniu: stworzyliœmy u¿yteczny
protokó³, który nie daje siê dobrze „wpasowaæ” w warstwy modelu OSI, a wiêc model jest nieadekwatny. Rozumowanie tego typu œwiadczy o braku zrozumienia istoty i roli modelu odniesienia
jako takiego.
Model odniesienia OSI przetrwa³, pomimo wielkiej liczby protoko³ów komunikacyjnych stworzonych w ostatnich dekadach,
a zatem licznych okazji do weryfikowania jego przydatnoœci. Nie
zaproponowano dotychczas niczego lepszego. Uzasadnione jest
wiêc podejrzenie, ¿e jest coœ g³êbokiego i fundamentalnego
w zasadach architektonicznych przyjêtych w modelu OSI –
w sposobie modelowania z³o¿onych systemów jako u³o¿onych
hierarchicznie warstw, odpowiadaj¹cych ró¿nym cechom funkcjonalnym systemu. Co wiêcej, mo¿na zgadywaæ, ¿e przyjête
w OSI RM zasady dekompozycji opisu z³o¿onych systemów pozostaj¹ u¿yteczne poza dziedzin¹ protoko³ów komunikacyjnych.
Interesuj¹cych, czysto filozoficznych (ontologicznych) przes³anek wspieraj¹cych taki pogl¹d dostarcza praca niemieckiego filozofa Nicolaia Hartmanna z roku 1942 [4], w której, jak siê ³atwo
domyœliæ, nie ma nawet wzmianki o protoko³ach komunikacyjnych.
Przyk³ady u¿ytecznych modeli odniesienia spoza obszaru protoko³ów komunikacyjnych, skonstruowanych „w duchu OSI”,
przedstawiono w dalszej czêœci tekstu. Przedtem jednak kilka
spostrze¿eñ dotycz¹cych objawów i konsekwencji bagatelizowaPRZEGLĄD TELEKOMUNIKACYJNY ! ROCZNIK LXXIV ! nr 1/2001
nia, czy mo¿e raczej braku zrozumienia, roli modeli odniesienia
w rozwoju infrastruktury informacyjnej; obecnie relacja miêdzy
aplikacjami, œrodkami technicznymi i standardami wydaje siê
uk³adaæ raczej tak jak na rys. 1c, ni¿ tak jak na rys. 1e.
KONSEKWENCJE BRAKU MODELI
ODNIESIENIA
W [2] usi³owa³em przekonaæ Czytelnika, ¿e nazbyt uproszczone ekstrapolowanie dotychczasowych sukcesów techniki internetowej – „IP-centryzm” – mo¿e okazaæ siê hamulcem w³aœciwego rozwoju zarówno œrodków technicznych, jak i aplikacji przysz³ej infrastruktury informacyjnej. Pierwsze objawy zagro¿eñ s¹
ju¿ doœæ widoczne: IETF (Internet Engineering Task Force), po
pierwszych sukcesach, najwyraŸniej utkn¹³ w wysi³kach maj¹cych na celu opracowanie skutecznych standardów technicznych, które umo¿liwi³yby wprowadzenie, w skali masowej i z odpowiedni¹ jakoœci¹, zaawansowanych us³ug multimedialnych,
a w szczególnoœci obs³ugi ruchu wymagaj¹cego zachowania re¿imu czasu rzeczywistego. IETF skupia siê g³ównie na funkcjonalnych aspektach protoko³ów komunikacyjnych, pozostawiaj¹c
na uboczu inne aspekty sztuki budowania du¿ych, efektywnych,
niezawodnych i zarz¹dzalnych sieci. W konsekwencji techniki
sieciowe, takie jak np. DiffServ czy IP/DWDM, s¹ rozwa¿ane
w sposób „jednowymiarowy”, bez odniesienia do szerszej perspektywy mo¿liwych rozwi¹zañ w zakresie dekomponowania zasobów sieciowych, metod multipleksacji i komutacji czy metod
kierowania ruchem. IP-centryzm zawêzi³ pole widzenia IETF, wy³¹czaj¹c z rozwa¿añ ca³y zasób potencjalnych metod i œrodków
radzenia sobie z problemami efektywnoœci, jakoœci obs³ugi, niezawodnoœci czy zarz¹dzalnoœci sieci.
Pole widzenia IETF jednak stopniowo poszerza siê. Jednym
z ostatnich „odkryæ” jest waga problematyki kierowania ruchem,
w sensie takim, w jakim od dawna rozwa¿a siê j¹ w tradycyjnym
nurcie rozwoju sieci telekomunikacyjnych. Powoli zaczynaj¹ siê
te¿ wkradaæ w¹tpliwoœci, czy problemy efektywnoœci wykorzystania zasobów sieciowych i zwi¹zane z nimi problemy jakoœci obs³ugi ruchu rzeczywiœcie dadz¹ siê rozwi¹zaæ po prostu dziêki
zwiêkszaniu mocy przetwarzania ruterów i przep³ywnoœci ³¹czy,
przy stosunkowo niewielkim wzroœcie z³o¿onoœci mechanizmów
sieciowych (jednak w dalszym ci¹gu nietrudno us³yszeæ: „Co za
problem? Wystarczy zastosowaæ wiêcej mocniejszych ruterów
i szybszych ³¹czy. To tylko kwestia pieniêdzy, a tych jest na rynku du¿o”). Równie¿ dopiero od niedawna IETF wydaje siê zdawaæ sobie sprawê z tego, ¿e doprowadzenie do szerokiej aprobaty standardów jest star¹, z³o¿on¹ gr¹, polegaj¹c¹ na ¿mudnym
wypracowywaniu konsensu wœród wielu jej uczestników, maj¹cych nierzadko odmienne punkty widzenia i sprzeczne interesy.
Przekonanie, ¿e entuzjazm i inwencja „fanów Internetu” w tworzeniu nowych aplikacji i rozwi¹zañ technicznych uczyni¹ tê grê
skuteczn¹, zaczyna jawiæ siê jako naiwne. NajwyraŸniej zbli¿a
siê chwila, gdy potrzeba modeli odniesienia, systematyzuj¹cych
i harmonizuj¹cych rozwój standardów, aplikacji i œrodków technicznych, stanie siê jasna równie¿ dla IETF.
Inny przyk³ad konsekwencji braku modeli odniesienia: filozofia
i standardy zarz¹dzania telekomunikacj¹ TMN (Telecommunication Management Network) mog¹ ju¿ wkrótce zostaæ wyparte
przez technikê CORBA (Common Object Request Broker Architecture) lub jej podobn¹, tj. metodologiê i narzêdzia zwi¹zane
z konstruowaniem warstwy poœredniej (middleware) pomiêdzy
aplikacjami a œrodkami ich realizacji. Ale oczywiœcie technika
CORBA jako taka praktycznie nie dostarcza ¿adnych œrodków do
rozwi¹zywania z³o¿onych problemów zarz¹dzania, które s¹ (powinny byæ) zasadniczym przedmiotem normalizacji TMN. CORBA dostarcza efektywnych narzêdzi – „m³otków i œrubokrêtów” –
do budowania aplikacji zarz¹dzania, ale nie rozwi¹zuje istoty
49
problemu, którym jest zapewnienie skutecznoœci wspó³dzia³ania
aplikacji zarz¹dzania tworzonych przez ró¿nych dostawców czy
wspó³pracy systemów zarz¹dzania ró¿nych operatorów. Normalizacja TMN jest podatna na „niekonstruktywne ataki”, gdy¿ nie
zawiera modeli odniesienia dotycz¹cych obszaru zarz¹dzania
us³ugami i aplikacjami. Obszary funkcjonalne zarz¹dzania
(FCAPS – Fault, Configuration, Accounting, Performance, Security) i us³ugi zarz¹dzania TMN (a w konsekwencji równie¿ funkcje zarz¹dzania i modele informacyjne) nie spe³niaj¹ takiej roli,
gdy¿ nie zosta³y wprowadzone w dobrze okreœlonych ramach architektonicznych (s¹ raczej zbiorem „pomys³ów” ad hoc),
a w konsekwencji nie s¹ czynnikiem systematyzuj¹cym proces
tworzenia normalizacji. Jak zwykle, gdy brak jasnoœci co do tego
„co” i „po co”, uwaga skupia siê na tym „jak”, a wiêc otwiera siê
szerokie pole dzia³ania dla „CORBA-izmu”.
Warto w tym kontekœcie tak¿e zwróciæ uwagê na to, ¿e standaryzacja globalnej infrastruktury informacyjnej (GII – Global Information Infrastructure) tworzona przez ITU-T, choæ u¿yteczna,
gdy stara siê pog³êbiæ ogólne koncepcje, w gruncie rzeczy poprzestaje na „delegowaniu” problemu warstwie poœredniej oraz
standaryzacji styków – por. ICA (Information Communication Architecture). Nawiasem mówi¹c, próba „zintegrowania” warstwy
pojêciowej oraz metodologicznej GII, ICA, CORBA i np. TINA
(Telecommunicaton Information Networking Architecture) , które,
jak nale¿y s¹dziæ, s³u¿¹ rozwi¹zaniu tych samych problemów,
jest zadaniem doœæ beznadziejnym. Czy¿by brakowa³o modeli
odniesienia?
O Rys. 2. Architektura Z
Warstwa wirtualna modeluje pó³trwa³e po³¹czenia – œcie¿ki
wirtualne i kana³y wirtualne – w sieciach z komutacj¹ kana³ów
b¹dŸ z komutacj¹ pakietów.
Warstwa rutowania (kierowania ruchu) modeluje drogi przenoszenia ruchu w sieciach z komutacj¹ kana³ów b¹dŸ z komutacj¹ pakietów.
Zasoby ka¿dej warstwy s¹ opisywane za pomoc¹ zbioru generycznych (rodzajowych) obiektów, operacji i atrybutów, których
interpretacja jest zale¿na od warstwy. S¹ to:
obiekty – œcie¿ki, ³¹cza, wêz³y, multipleksery i porty,
operacje – komutacja i multipleksacja,
atrybuty Рkoszt, pojemnoϾ, ruch i jakoϾ.
Œcie¿ka modeluje po³¹czenie typu koniec-koniec pomiêdzy
dwoma wêz³ami koñcowymi. Odpowiada ona albo po³¹czeniu typu punkt-punkt, albo odcinkowi po³¹czenia punkt-wielopunkt.
Œcie¿ka jest zakoñczona par¹ portów w wêz³ach koñcowych.
Tworzenie jej jest modelowane przez operacjê komutacji (rys. 3).
DWA PRZYKŁADY
MODELI ODNIESIENIA
Aby po tej ogólnej dyskusji na temat roli modeli odniesienia nie
pozostawiæ Czytelnika z pustymi rêkami, poni¿ej przedstawiono
(bardzo zwiêŸle) dwa takie modele. Zosta³y one zaproponowane
przez autora i jego wspó³pracowników [5–9] kilka lat temu i by³y
z powodzeniem wykorzystywane w projektowaniu rzeczywistych
systemów i sieci telekomunikacyjnych, a tak¿e w procesie
kszta³cenia m.in. na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej.
Przedstawione modele nie odnosz¹ siê do sfery protoko³ów komunikacyjnych, s¹ jednak utrzymane w duchu modelu odniesienia OSI. Ich istota i rola, podobnie jak w przypadku modelu OSI,
sprowadza siê do systematyzowania „przestrzeni rozwa¿añ” za
pomoc¹ prostych, ogólnych konstrukcji architektonicznych.
Oczywiœcie, przedstawione modele nie s¹ jedynymi mo¿liwymi. Zachêcam Czytelników do podjêcia dyskusji nad ich adekwatnoœci¹ oraz do zaproponowania lepszych koncepcji.
Model odniesienia zasobów sieci
(architektura Z)
Zasoby sieci zdekomponowano na hierarchicznie uporz¹dkowane warstwy. Zasoby odpowiadaj¹ po³¹czeniom sieciowym
i tworz¹cym je elementom. Uporz¹dkowanie warstw odzwierciedla relacjê typu klient-serwer pomiêdzy zasobami s¹siednich
warstw. Wyró¿niono piêæ warstw zasobów. Ka¿da warstwa
okreœla zasoby innego typu i inne sposoby zestawiania po³¹czeñ
– rys. 2.
Warstwa infrastruktury modeluje lokalizacje geograficzne,
w których mo¿e byæ zainstalowany sprzêt telekomunikacyjny
oraz drogi pomiêdzy tymi lokalizacjami.
Warstwa fizyczna modeluje fizyczne po³¹czenia kablowe i radiowe.
Warstwa transmisyjna modeluje po³¹czenia optyczne i cyfrowe w sieciach transportowych, np. WDM, SDH i PDH.
50
O Rys. 3. Operacja komutacji: tworzenie ścieżek w warstwie
O Rys. 4. Operacja multipleksacji: tworzenie łączy warstwy N+1
ze ścieżek warstwy N
Porty kolejnych sekwencji ³¹czy tworz¹cych œcie¿kê s¹ krosowane w wêz³ach poœrednich. W wêz³ach koñcowych œcie¿ki porty
³¹cza s¹ krosowane z portami œcie¿ki.
£¹cza tworzy siê ze œcie¿ek warstwy ni¿szej. Tworzenie ³¹cza
jest modelowane przez operacjê multipleksacji (rys. 4). Wêz³y,
³¹cza i œcie¿ki s¹ obiektami wewn¹trzwarstwowymi, zaœ multiplekser jest obiektem miêdzywarstwowym. Jedn¹ lub wiêcej œcie¿ek
warstwy ni¿szej ³¹czy siê z „dolnymi” portami pary multiplekserów. Jedno lub wiêcej ³¹czy mo¿e byæ dostêpnych w „górnych”
portach multipleksera.
Ka¿da z piêciu podstawowych warstw mo¿e byæ zdekomponowana na podwarstwy. Ustanowienie podwarstw umo¿liwia modePRZEGLĄD TELEKOMUNIKACYJNY ! ROCZNIK LXXIV ! nr 1/2001
O Tabela 1. Interpretacja obiektów w warstwach i podwarstwach
(Pod)warstwa
Węzeł
Łącze
Ścieżka
Infrastruktury
Budynek,
studzienka,
maszt radiowy
Odcinek
kanalizacji
pierwotnej,
kanalizacji
wtórnej, para
masztów
Sekwencja
odcinków
kanalizacji
pierwotnej,
wtórnej lub
masztów
Kabli
Mufa
Odcinek kabla
Po³¹czenie
kablowe
W³ókien
Krosownica
œwiat³owodowa
Krosownica
elektryczna
Odcinek
œwiat³owodu
Odcinek pary
miedzianej
Po³¹czenie
œwiat³owodowe
Po³¹czenie par¹
miedzian¹
Optyczna
Krosownica
optyczna (OXC,
OADM)
Sygna³ optyczny
(pojedyncza λ)
Po³¹czenie
optyczne
Transmisji
cyfrowej
Krosownica
elektryczna,
krosownica
cyfrowa (DXC,
ADM)
Kana³ cyfrowy
Po³¹czenie
cyfrowe
Œcie¿ek
wirtualnych
Komutator ATM
£¹cze VP
Po³¹czenie VP
Kana³ów
wirtualnych
Pole
komutacyjne
TDM 64 kbit/s
Komutator ATM
Grupa kana³ów
n × 64 kbit/s
Po³¹czenie
n × 64 kbit/s
£¹cze VC
Po³¹czenie PVC
Kierowania
pakietów
Komutator
pakietów (SS7,
IP) –
przetwarzanie
pakietów, tablica
kierowania
pakietów
£¹cze pakietowe
Droga
kierowania
pakietów
Kierowania
po³¹czeñ
Wêze³
Wi¹zka kana³ów
komutacyjny
ISDN/BISDN –
obs³uga
po³¹czeñ
i tablica
kierowania ruchu
charakterystyk wydajnoœciowych, takich jak jakoœæ us³ug. Termin
„zastosowania” odnosi siê do sposobu, w jaki funkcjonalnoœæ zasobów jest wykorzystywana, tj. okreœla sposób ich zastosowania.
Warstwy Z, F i S s¹ uporz¹dkowane hierarchicznie: struktura zasobów jest podporz¹dkowana funkcjom wykonywanym przez zasoby, a funkcje zasobów s¹ podporz¹dkowane ich zastosowaniu. St¹d Z jest warstw¹ górn¹, F warstw¹ œrodkow¹, a S warstw¹ doln¹. Przedstawion¹ interpretacjê zilustrowano na rys. 5.
O Rys. 5. Warstwy aspektów zarządzania
Droga
kierowania ruchu
lowanie ró¿nych kombinacji technik sieciowych, takich jak
TDM/SDH, IP/WDM, IP/ATM/WDM itd. W tabeli 1 przedstawiono
interpretacjê obiektów generycznych w warstwach i podwarstwach.
Oprócz faz cyklu ¿ycia i aspektów zarz¹dzania wyró¿niono
trzy podstawowe typy zarządzanych zasobów:
B – zasoby biznesowe,
U – zasoby usługowe,
I – zasoby infrastrukturalne.
Procesy zarz¹dzania zwi¹zane z ka¿dym typem zasobów tworz¹ oddzieln¹ warstwê zarz¹dzania (por. warstwy zarz¹dzania
TMN). Warstwy te s¹ hierarchicznie uporz¹dkowane: zarz¹dzaO Tabela 2. Przestrzeń procesów zarządzania – model odniesienia
P
Planowanie
zastosowañ
biznesu
B
Model odniesienia procesów zarz¹dzania
Wyró¿niono trzy podstawowe fazy cyklu życia zarz¹dzanego
systemu:
P – planowanie,
W – wdra¿anie,
E – eksploatacja.
Ka¿da z tych trzech faz jest modelowana za pomoc¹ trójwarstwowej struktury. Warstwy odpowiadaj¹ ró¿nym aspektom za−
rządzania zasobami:
Z – zarz¹dzanie zastosowaniami funkcji struktury zasobów,
F – zarz¹dzanie funkcjonowaniem struktury zasobów,
S – zarz¹dzanie strukturą zasobów.
Termin „struktura” odnosi siê do strukturalnych cech zarz¹dzanych zasobów, takich jak topologia i konfiguracja wewnêtrzna,
a tak¿e do ich charakterystyk iloœciowych, takich jak pojemnoœæ.
Termin „funkcjonowanie” odnosi siê do funkcji wykonywanych
przez zasoby, np. zwi¹zanych z komunikacj¹ i us³ugami oraz do
PRZEGLĄD TELEKOMUNIKACYJNY ! ROCZNIK LXXIV ! nr 1/2001
U
E
Eksploatacja
zastosowañ
WZB biznesu
EZB
Z
Planowanie
Wdra¿anie
Eksploatacja
funkcjonowania
funkcjonowania
funkcjonowania
biznesu
PFB biznesu
WFB biznesu
EFB
F
Planowanie
stuktury
biznesu
Wdra¿anie
stuktury
PSB biznesu
Eksploatacja
stuktury
WSB biznesu
ESB
S
Planowanie
zastosowañ
us³ug
Wdra¿anie
zastosowañ
PZU us³ug
Eksploatacja
zastosowañ
WZU us³ug
EZU
Z
Planowanie
Wdra¿anie
Eksploatacja
funkcjonowania
funkcjonowania
funkcjonowania
us³ug
PFU us³ug
WFU us³ug
EFU
F
Planowanie
stuktury
us³ug
S
Planowanie
zastosowañ
infrastruktury
I
W
Wdra¿anie
zastosowañ
PZB biznesu
Wdra¿anie
stuktury
PSU us³ug
Eksploatacja
stuktury
WSU us³ug
ESU
Wdra¿anie
Eksploatacja
zastosowañ
zastosowañ
PZI infrastruktury WZI infrastruktury
Z
EZI
Planowanie
Wdra¿anie
Eksploatacja
funkcjonowania
funkcjonowania
funkcjonowania
infrastruktury PFI infrastruktury WFI infrastruktury EFI
F
Planowanie
stuktury
infrastruktury
S
Wdra¿anie
Eksploatacja
stuktury
stuktury
PSI infrastruktury WSI infrastruktury
ESI
51
nie infrastruktur¹ jest podporz¹dkowane zarz¹dzaniu us³ugami,
to zaœ – zarz¹dzaniu biznesowemu.
Z³o¿enie wprowadzonych faz cyklu ¿ycia zarz¹dzania, aspektów zarz¹dzania oraz typów zarz¹dzanych zasobów tworzy „trójwymiarow¹ przestrzeñ” procesów zarz¹dzania, przedstawion¹
w tabeli 2, stanowi¹c¹ proponowany model odniesienia. Ka¿da
komórka tej tabeli jest skojarzona z innym procesem zarz¹dzania. Ka¿dy proces wi¹¿e siê z pewn¹ kategori¹ zadañ zarz¹dzania, okreœlon¹ przez fazê cyklu ¿ycia, aspekt zarz¹dzania oraz
typ zasobów. Nazwa konkretnego procesu jest z³o¿eniem nazwy
fazy cyklu ¿ycia, nazwy aspektu zarz¹dzania i nazwy warstwy
zarz¹dzania, tj. typu zasobów (w tej kolejnoœci). Na przyk³ad:
proces „planowania struktury us³ug” (PSU), proces „wdra¿ania
funkcjonalnoœci infrastruktury” (WFI), proces „eksploatacja zastosowañ biznesu” (EZB) itd.
Ka¿dy z 27 procesów modelu odniesienia z tabeli 2 mo¿e mieæ
rozmaite instancje, tj. mo¿e byæ zwi¹zany z ró¿nymi zbiorami
specyficznych zadañ zarz¹dzania. Nie ma „najlepszego sposobu” definiowania takich instancji, podobnie jak nie ma „najlepszych instancji” protoko³ów komunikacyjnych dla poszczególnych warstw modelu odniesienia OSI. Wybór instancji zale¿y od
kontekstu aplikacyjnego i przyjêtych celów zarz¹dzania. W zastosowaniach praktycznych kilka procesów mo¿e byæ po³¹czonych w wiêksz¹ jednostkê, mo¿na te¿ dzieliæ procesy na podprocesy.
Warto zwróciæ uwagê na próbê wprowadzenia modelu odniesienia dla procesów zarz¹dzania, podjêt¹ przez TeleManage−
ment Forum [10]. Forum to podda³o analizie procesy zarz¹dzania stosowane przez czo³owych operatorów telekomunikacyj-
52
nych, a nastêpnie dokona³o swoistego „uœrednienia”. Oczywiœcie
takie podejœcie nie mo¿e daæ zadowalaj¹cego wyniku w postaci
modelu odniesienia o abstrakcyjnym charakterze.
LITERATURA
[1] Lubacz J.: Is IP-ism Reformable? On the Importance of Reference
Models, Proc. of the International Symposium on Telecommunications – VITEL Ljubljana, 2000
[2] Lubacz J.: Kilka uwag o IP-centryzmie, czyli o uk¹szeniu internetowym, PTiWT, nr 1, 2000 (wersja ang.: The IP Syndrom, IEEE Communications Magazine, Feb. 2000)
[3] Lubacz J.: Problemy rozwoju powszechnej infrastruktury informacyjnej, PTiWT, nr 4, 1998
[4] Hartmann N.: Nowe drogi ontologii, Klasyka Filozofii Niemieckiej,
Wyd. Rolewski, 1998
[5] Lubacz J. et al.: On the ATM Network Architecture and Routing Principles, 7th ITC Seminar, Morristown, 1992
[6] Lubacz J., Tomaszewski A.: Generic architecture and design of core
network. W: Roberts J. (red.): Broadband Network Teletraffic, Lecture Notes in Computer Science, Vol. 1155, Springer Verlag, 1996
[7] Lubacz J., Ostrowski P.: Model przestrzeni zarz¹dzania telekomunikacyjnego przedsiêbiorstwa operatorskiego, KST’98
[8] Tomaszewski A., Lubacz J: A Network Planning Model, First PolishGerman Teletraffic Symposium, Dresden, 2000
[9] Lubacz J: A Reference Model for Management Processes, IEEE
Workshop on IP-oriented Operations and Management, Kraków,
2000
[10] Telecom Operations Map, TeleManagement Forum, April 1999
Artykuł recenzowany
(Artyku³ nades³ano do red. – listopad 2000 r.)
PRZEGLĄD TELEKOMUNIKACYJNY ! ROCZNIK LXXIV ! nr 1/2001