5.WYTWARZANIE ARCHITEKTURY KORPORACYJNEJ ŚRODOWISKIEM WERYFIKACJI STRUKTUR BAZ WIEDZY SYSTEMU WIELOAGENTOWEGO

Aby zacytować tę publikację: Orłowski C., Sitek T., Wytwarzanie architektury korporacyjnej środowiskiem weryfikacji struktur baz wiedzy ZARZĄDZANIE systemu wieloagentowego. WIEDZĄ I TECHNOLOGIAMI [w:] Orłowski INFORMATYCZNYMI C., Kowalczuk Z., Szczerbicki E (red.), Zastosowanie technologii Pod informatycznych redakcją C. Orłowskiego, w zarządzaniu Z. wiedzą. Kowalczuka, Pomorskie E. Wydawnictwo Szczerbickiego Naukowo-Techniczne 2009 PWNT, PWNT Gdańsk Gdańsk 2009, s.273-284. ROZDZIAŁ 5 5.WYTWARZANIE ARCHITEKTURY KORPORACYJNEJ ŚRODOWISKIEM WERYFIKACJI STRUKTUR BAZ WIEDZY SYSTEMU WIELOAGENTOWEGO Cezary ORŁOWSKI, Tomasz SITEK 5.1. Wprowadzenie Technologie informatyczne stanowią integralną część współczesnych organizacji i w istotny sposób wpływają na ich funkcjonowanie. Występują jako systemy transakcyjne tych organizacji i wspomagają środowiska wytwarzania. Często są wykorzystywane do wspomagania procesów podejmowania decyzji czego przykładem jest wspomaganie decyzji kierownika przedsięwzięcia poprzez wykorzystanie dedykowanych środowisk do zarządzania projektami. Ich dobór ma kluczowe znaczenie dla efektywności ich wykorzystania. Decydenci niejednokrotnie podejmują tego typu decyzje kierując się dostępną, ale niepełną wiedza. Również wspólne decyzje dotyczące wyboru, zakupu, wdrożenia, eksploatacji czy ewentualnej zmiany są podejmowane wyłącznie w oparciu o przesłanki techniczne i finansowe. Stąd też istnieje potrzeba wykorzystania technologii informatycznych do oceny i doboru odpowiednich dla potrzeb organizacji i projektów technologii informatycznych wspomagających procesy zarządzania [5, s. 5]. Problematyka zarządzania technologiami informatycznymi jest głównym celem badań realizowanych w Zakładzie Zarządzania Technologiami Informatycznymi (ZZTI) Politechniki Gdańskiej od roku 2006. Podstawową misją zespołu jest budowa dedykowanego systemu wieloagentowego do oceny technologii IT (ang. multiagent system for IT evaluation IT_MAS). Jego podstawowym zadaniem ma być wsparcie menedżerów działów informatycznych lub kierowników projektów, którzy stojąc w obliczu zmian potrzebują konkretnej wiedzy o dostępnych narzędziach i metodykach dostosowanych do ich potrzeb. Środowisko wieloagentowe zaprojektowane przez Zespół rozwijane jest w oparciu o technologie inteligentne: agentów, ontologie i systemy ekspertowe wykorzystujące inteligentne systemy gromadzenia i przetwarzania wiedzy. Jego założenia oparte były w pewnej mierze na wcześniejszych doświadczeniach autorów w zakresie analizy i oceny technologii informatycznych przy udziale prostych i niepełnych modeli ocenowych [6, s.153]. Politechnika Gdańska, Wydział Zarządzania i Ekonomii, Zakład Zarządzania Technologiami Informatycznymi, e-mail: cor@zie.pg.gda.pl, tsitek@zie.pg.gda.pl

2 C.Orłowski, T.Sitek Omawiany model systemu agentowego, jakkolwiek przeznaczony w założeniu do wykorzystania w zakresie decyzji związanych z technologiami informatycznymi, zaimplementowany został dla potrzeb prognostycznego systemu technicznego z innej dziedziny. Był to pierwszy etap weryfikacji modelu. Ustaloną strukturę i funkcjonalności agentów systemu zaadoptowano w środowisku do generowania prognoz z dziedziny chemii do wnioskowania poziomu stężenia zanieczyszczeń powietrza w zależności od mierzonych wartości wybranych czynników atmosferycznych. Mimo, iż była to domena dość odległa (system techniczny) od obszaru zarządzania technologiami informatycznymi (system społeczno-techniczny), dla autorów tej pracy wykorzystanie danych systemu technicznego umożliwiło kontrolę poprawności struktury jak i funkcjonalności modelu. Uzyskano przy tym szereg doświadczeń w zakresie jakościowych aspektów projektu np. związanych z przebiegiem konsultacji z ekspertem [7]. Niniejsze opracowanie dokumentuje kolejne doświadczenia w rozwoju tego systemu. IT_MAS wykorzystano do implementacji wyników badań (wiedzy) z zakresu zarządzania przedsięwzięciami informatycznymi. Skupiono się nad specyficzną tematyką wdrażania architektur korporacyjnych w organizacjach. Zaadoptowanie do tego celu modelu wieloagentowego opartego na ontologiach i systemach eksperckich pozwoliło na ponowną weryfikację jego założeń. W kolejnym rozdziale przedstawiony zostanie model, a w rozdziałach późniejszych opis doświadczeń uzyskanych na podstawie oceny procesów wytwarzania architektury korporacyjnej. W podsumowaniu autorzy zaprezentowali najważniejsze wnioski i wskazali na kolejne kroki dla dalszych badań koncentrując się na budowie baz wiedzy i mechanizmach jej przetwarzania. 5.2. Koncepcja systemu wieloagentowego do wsparcia decyzyjnego W poprzednim rozdziale nakreślono cel prac Zespołu, jakim jest zaprojektowanie środowiska, które pozwoli wspomagać procesy decyzyjne kierowników firm IT odnośnie doboru lub zmiany technologii informatycznych dla potrzeb danego przedsięwzięcia. Z technicznego punktu widzenia konstrukcja systemu opiera się na integracji agentów, ontologii oraz baz wiedzy systemu ekspertowego. Dysponując wiedzą ekspertów (specjalistów od zarządzania technologiami) oraz danymi pochodzącymi z badań własnych, system wieloagentowy (określany jako IT_MAS) powinien być w stanie wybrać odpowiednie narzędzie lub metodykę dla określonego przedsięwzięcia. Odpowiedź ta może zawierać zarówno sugestię co do doboru, ale także ocenę technologii IT wygenerowaną na bazie zaprojektowanych w tym celu, algorytmów ewaluacyjnych. Podstawową i logicznie niepodzielną jednostką systemu są agenci programowi. Liczba i rodzaj agentów uwarunkowane zostały poprzez funkcjonalności szczegółowe związanie z działaniem procesów wewnątrz systemu. Wyróżnionym zadaniom przypisano dedykowanych agentów, w taki sposób by jeden agent (lub agenci jednej klasy) realizował jedną funkcjonalność. Należy zwrócić uwagę, iż taki sposób definiowania agentów pozwala uzyskać bardzo klarowną strukturę, w której w razie potrzeby można bardzo łatwo identyfikować zasoby i je lokalizować. Budując system agentowy zgodnie z zasadą wyodrębniona funkcjonalność = dedykowany agent istnieje także możliwość klonowania poszczególnych agentów, w sytuacji replikowania zasobów odpowiedzialnych za daną funkcjonalność. W ten sposób już na etapie założeń skalowalność systemu nie będzie sztucznie ograniczana i pozwoli np. wygenerowanie takiej liczby agentów, która pozwoli obsłużyć równolegle (bez kolejkowania) wszystkie sesje z klientami [10, s. 61]. Ontologia stanowi kolejny istotny element w omawianym systemie. Zasób ten wykorzystywany jest jako repozytorium - słownik danej dziedziny zawierający wszystkie pojęcia oraz relacje zachodzące między nimi. Zawiera opis semantyczny przygotowany na potrzeby bazy wiedzy i pytań kompetencyjnych (tj. takich, na jakie ma odpowiadać system

5. Wytwarzanie architektury korporacyjnej środowiskiem weryfikacji 3 IT_MAS). Oprócz pojęć, w ontologii gromadzone mają być również wartości brzegowe dla parametrów środowiskowych, z wykorzystaniem których system może weryfikować wprowadzaną wiedzę. Może wobec tego eliminować napływające fakty, których kwantyfikowane wartości przekraczają dopuszczalne normy. Zadaniem ontologii jest także weryfikacja poprawności zapytań napływających od użytkownika z jej wykorzystaniem odpowiedni agent tłumaczy zapytanie w języku naturalnym (lub quasi-naturalnym) na postać właściwą do dalszego przetwarzania [2]. Trzecim po agentach i ontologii omawianym komponentem systemu wieloagentowego do oceny technologii informatycznych jest system ekspertowy. Na wstępie trzeba zauważyć, iż w artykule autorzy używają niejednokrotnie także pojęcia bazy wiedzy, lub zasoby wiedzy. Oczywiście nie są to synonimy i pojecie systemu jest szersze (w klasycznym ujęciu system ekspercki korzysta z baz). W realiach niniejszego projektu system agentowy jednak korzysta zarówno z baz wiedzy, ale także ze związanych z nimi mechanizmów wnioskowania. Stąd dla uproszczenia pojęcia te potraktujmy jako zamienne. Podstawowymi zadaniami, które stawia się przed tym komponentem jest gromadzenie wiedzy, przechowywanie jej, udostępnianie na żądania agentów przeszukujących (np. podczas sesji z użytkownikiem) oraz przetwarzanie przy pomocy maszyny wnioskującej. Jak już wspomniano za ten właśnie element bezpośrednio odpowiedzialny jest jeden z autorów niniejszego opracowania. Dlatego też w dalszych rozdziałach zostanie położony nacisk wyłącznie na aspekty związane z projektowaniem, implementacją oraz wykorzystaniem zasobów wiedzy. Uproszczony schemat współpracy agentów, ontologii i zasobów wiedzy został pokazany na rysunku 1. W oparciu o ten algorytm można jednocześnie przedstawić zadania, które ten system realizuje. Rys. 1. Uproszczony schemat współdziałania komponentów systemu wieloagentowego do oceny technologii informatycznych [źródło: opracowanie własne] Działanie systemu sprowadza się do przeprowadzenia sesji z użytkownikiem zainteresowanym odpowiedzią na jedno z predefiniowanych pytań kompetencyjnych. Pytania takie pozwalają przykładowo uzyskać odpowiedz co do doboru konkretnego narzędzia do zarządzania projektem informatycznym opisanym za pomocą kilku faktów wejściowych, czy też porównać dwie konkurencyjne technologie dla danych warunków ich wykorzystania. Sformułowane przez użytkownika pytanie jest odbierane z GUI systemu przez agenta pośredniczącego i konsultowane z zasadami opracowanymi na podstawie ontologii i następnie, w przypadku braku błędów, przekazywane do agenta-menadżera. Jeśli wymagana jest wyłącznie ocena menadżer przekazuje je do dedykowanego agenta oceniającego i oczekuje wyniku, który zwraca do jednostki pośredniczącej w celu prezentacji użytkownikowi. Jeżeli jednak konieczne jest wykorzystanie wiedzy eksperckiej zgromadzonej w bazach faktów i reguł, zapytanie przejmuje odpowiedni agent przeszukujący i korzystając z mechanizmów wnioskowania baz

4 C.Orłowski, T.Sitek wiedzy uzyskuje odpowiedni zakres informacji. Odpowiedź przekazywana jest kolejno każdemu z agentów realizujących daną sesję i ostatecznie zostaje zaprezentowana pytającemu. Trzeba zauważyć iż jest to tylko algorytm związany ze realizowaniem przez system IT_MAS swojej podstawowej roli, czyli serwowania usługi dla wsparcia decyzyjnego decydentów w obszarze IT. Nie uwzględniono tu działań administracyjnych, takich jak akwizycja nowej wiedzy, jej weryfikacja, organizacja itp. Warto równocześnie dodać, iż prowadzone były i są prace których celem jest integracja systemu (budowa rozwiązania hybrydowego) z jednokierunkowymi sieciami neuronowymi a także modelami ekonometrycznymi i statystycznymi. Celem takich działań jest przedstawianie użytkownikowi kilku alternatywnych odpowiedzi (tylko dla pewnej klasy problemów) i pozostawienie ich jego ocenie. Jakkolwiek przedstawiony model funkcjonalny i algorytm działania systemu oparte są na założeniu, iż jest to system do oceny technologii informatycznych, może być on wykorzystany jako framework do wsparcia decyzyjnego w innych dziedzinach. W następnym rozdziale pracy autorzy prezentują projekt jego wykorzystania w środowisku zarządzania projektami IT, a w szczególności dla przedsięwzięcia wytwarzania architektury korporacyjnej. Należy ponownie dodać, iż nacisk zostanie położony wyłącznie na projekt zasobów wiedzy systemu, gdyż obszar funkcjonalny IT_MAS leży w gestii jednego z autorów. 5.3. Weryfikacja modelu w środowisku zarządzania projektami IT Opisana w poprzednim rozdziale struktura funkcjonalna oraz algorytm działania modelu IT_MAS mają charakter generyczny. Mimo, iż model w założeniu zaprojektowany był jako narzędzie wsparcia decyzyjnego w zakresie doboru technologii informatycznych, może być zaadoptowany dla innych obszarów. Dzięki temu każdy case realizowany w oparciu o koncepcję wykorzystania agentów, ontologii i systemów opartych na wiedzy daje autorom możliwość jej weryfikacji. Niniejsza praca dokumentuje część prac nad przygotowaniem systemu IT_MAS dla celu przetwarzania wiedzy z domeny zarządzania projektami informatycznymi. Skupiono się na pewnym specyficznym rodzaju przedsięwzięć IT wdrożeniach architektury korporacyjnej. Badania nad tą właśnie tematyką prowadzone są w Zakładzie równolegle z podstawowym nurtem badań (nad technologiami IT). Stąd postanowiono połączyć doświadczenia i dokonać próby implementacji wiedzy o architekturze korporacyjnej w oparciu o IT_MAS. W ten sposób pojawiła się kolejna możliwość wspomnianej weryfikacji modelu. Z punktu widzenia opisywanego systemu badania nad wytwarzaniem architektury korporacyjnej sprowadzają się do analizy kluczowych czynników wpływających na złożoność takiego projektu. Celem Zespołu jest budowa takiej bazy wiedzy, która wskazałaby najlepszą metodykę prowadzenia projektu wdrażania architektury korporacyjnej w danych realiach projektowych. Docelowo system może nawet sugerować konkretne narzędzia do zarządzania tego rodzaju projektami. By mówić o wiedzy z zakresu architektury korporacyjnej niezbędne jest wyjaśnienie tego pojęcia oraz przedstawienie teorii (metodologii) związanej z jej wytwarzaniem, czego dotyczą kolejne rozdziały. 5.3.1. Architektura korporacyjna podstawowe założenia Należy jasno zdefiniować pojęcie architektury korporacyjnej (ang. enterprise architecture- EA), gdyż u jego podstaw leżą wszelkie założenia projektu. Termin ten może być rozpatrywany w zależności od kontekstu w trzech różnych znaczeniach: znaczenie atrybutowe, znaczenie rzeczowe, znaczenie czynnościowe.

5. Wytwarzanie architektury korporacyjnej środowiskiem weryfikacji 5 Ujęcia nie wykluczają się wzajemnie, są ze sobą silnie powiązane. Przy czym korporacja (ang. enterprise) definiowana jest jako zbiór organizacji, posiadających wspólny zbiór/zestaw celów i/lub wspólne główne właściwości. W ujęciu atrybutowym architektura korporacyjna jest to zbiór właściwości danej korporacji (włącznie ze strukturą), które stanowią o zdolności do realizacji jej misji (oznacza to, że każda korporacja posiada architekturę - przy czym może być ona uświadamiana bądź nie; może być także efektywna lub nie). W znaczeniu rzeczowym architektura korporacyjna to formalny opis struktury i funkcji komponentów korporacji, wzajemnych powiązań pomiędzy tymi komponentami oraz pryncypiów i wytycznych zarządzających ich tworzeniem i rozwojem w czasie. Przy czym komponent korporacji definiowany jest jako dowolny element korporacji, który służy do jej konstruowania; mogą to być ludzie, procesy, fizyczne struktury jak również systemy informatyczne [8]. Wreszcie architektura korporacyjna może być rozumiana jako dyscyplina, praktyka albo działalność w obszarze definiowania, reprezentacji i zarządzania kluczowymi właściwościami korporacji. W tym ujęciu tworzenie architektury korporacyjnej nie jest przedsięwzięciem informatycznym, ale złożonym zespołem działań z zakresu organizacji, zarządzania i informatyki. Te powiązania doskonale ilustruje rysunek 2 poniżej, gdzie strategiczna wizja organizacji symbolicznie przykrywa jak parasol zarówno architekturę (czyli także cele) biznesową oraz architekturę technologiczną [1]. Rys 2. Elementy domeny architektury korporacyjnej [źródło: 1] Standardem, w oparciu o który architektura korporacyjna powinna być w przedsiębiorstwie budowana jest TOGAF. Jako, że całość badań Zespołu oparta jest o wytyczne TOGAFu w kolejnym rozdziale przedstawiono poglądowo tę koncepcję. 5.3.2. Standard TOGAF Prowadząc badania nad Architektura korporacyjną (ang. Enterprise Architecture) konieczne jest odniesienie ich do przewodników i specyfikacji opracowanych w TOGAF. TOGAF (ang. The Open Group Architecture Framework) jest zbiorem zasad dotyczących planowania i wdrażania architektur systemów informatycznych w dużych organizacjach. Dokumentacja TOGAF jest (z nielicznymi wyjątkami) dostępna bezpłatnie do wewnętrznego użytku w przedsiębiorstwach. TOGAF został opracowany przez The Open Group. Jest to konsorcjum przemysłowe, którego członkami jest około 300 firm i instytucji, m.in. IBM, Sun, HP, NEC, Hitachi, Capgemini, Fujitsu, Intel, Microsoft, Symantec, Oracle, SAP i inne [3]. W najogólniejszym pojęciu TOGAF stanowi ramy architektoniczne. Jest narzędziem do tworzenia szerokiego zakresu architektur (w tym: SOA Service Oriented Architecture, czyli

6 C.Orłowski, T.Sitek koncepcja budowy systemów informatycznych, gdzie nacisk stawia się na definiowanie usług), wspomagania ewaluacji architektur czy też wyboru i budowania prawidłowych architektur dla organizacji. Zawiera zbiór usług, standardów i konceptów projektowych, komponentów i konfiguracji. Stanowi wobec tego przewodnik dla tworzenia konkretnych architektur, jego użycie zapewnia tworzenie systemów informatycznych charakteryzujących się lepszą integracją [3]. TOGAF zawiera kilka stałych elementów [9]: ADM (ang. Architecture Development Method) metoda tworzenia architektury, zawierająca serię połączonych faz, które obejmują cały cykl zarządzania architekturą, od planowania do operacyjnego wdrożenia i zarządzania zmianą (najważniejszy moduł TOGAF), TRM (ang. Technical Reference Model) techniczny model referencyjny, jego zadaniem jest wprowadzenie szeroko pojętej taksonomii dla ułatwienia komunikacji podczas przedsięwzięcia; pozwala na stworzenie spójnego sposobu analizowania systemów, ustalenia powszechnie obowiązującego rozumienia terminów (oraz ich hierarchii) z zakresu EA, SIB (ang. Standards Information Base) baza standardów informacyjnych, zawiera otwarte standardy z odnośnikami do dostosowywanych produktów, może być użyta do zdefiniowania poszczególnych usług lub właściwości komponentów; zapewnia zgodność architektury z najbardziej aktualnym stanem wiedzy z zakresu rozwiązań przemysłowych, Enterprise Continuum repozytorium gromadzące wzorce architektur generycznych, wspólnych systemów, przemysłu i przedsiębiorstwa, BBIB (ang. Building Blocks Information Base), III-RM (ang. Integrated Information Infrastructure Reference Model) i inne. 5.3.3. Wytwarzanie architektury korporacyjnej jako przykład złożonego przedsięwzięcia IT - case Realizowane w Zakładzie badania dotyczące architektury korporacyjnej opierają się na założeniu że wdrożenie EA jest traktowane jako specyficzne przedsięwzięcie informatyczne. Projekt taki, w myśl m.in. TOGAFu realizowany jest na poziomie strategicznym organizacji, wpływa na nią globalnie. Jednocześnie wymusza widzenie organizacji całościowo, a nie wyłącznie przez pryzmat technologiczny. Enterprise Architecture jest dzięki temu szansą na wdrożenie spójnych technologii informatycznych łączących istniejące struktury i procesy realizowane w ramach tych struktur. Pojawia się pytanie o metody zarządzania tak złożonym przedsięwzięciem. Czy powinno być to podejście ciężkie? Zapewne nie zawsze. Wydaje się, że najlepszym rozwiązaniem byłoby elastyczne dopasowywanie metodyki do realiów danego planu. Nie mniej ważną pochodną decyzji o użytej metodyce jest wybór narzędzia je wspierającego, a docelowo nawet określenie konkretnych jego funkcjonalności (podejście top-down) [4]. Wobec tego uzasadnione wydaje się takie podejście autorów, które dobór metody zarządzania przedsięwzięciami uzależniać będzie od kilku kluczowych czynników. Tymi, które wyodrębniono, jako najbardziej kluczowe będą: Dojrzałość organizacji realizującej projekt (w szczególności: wytwórczej), Dojrzałość klienta (czy odpowiedni/dopasowany), Złożoność projektu (osadzony, półoderwany, osadzony podobnie jak w COCOMO). Traktując wymienione czynniki jako parametry wejściowe do modelu, można podjąć próbę budowy reguł, które wskazywałby na proponowane metodologie zarządzania projektami.

5. Wytwarzanie architektury korporacyjnej środowiskiem weryfikacji 7 Stworzenie zbioru takich reguł będzie formalnym zapisem wiedzy z tej dziedziny. Jej przetwarzanie (wnioskowanie) ma więc w założeniu odpowiedzieć na pytanie o optymalną metodologię prowadzenia projektu przy oszacowanych poziomach dojrzałości obu partnerów oraz dla określonej złożoności projektu. Możliwymi metodologiami, które może zasugerować system będą: metodyki lekkie (w szczególności: Agile, Scrumm), metodyki ciężkie (RUP, PRINCE). Należy zauważyć, że parametry wejściowe w tak skonstruowanych regułach stanowią opis bardzo różnych aspektów procesu wytwarzania i wdrażania produktów IT. Są one przy tym często niełatwe w oszacowaniu dla danych realiów projektu. Aby określić ich wartości niezbędne jest przeprowadzenie wielu analiz lub odwołanie się do zalecanych w danym obszarze metodyk. Poziom dojrzałości organizacji wytwórczej jest wobec tego wartością, którą można uzyskać korzystając z metodyki CMMI. CMMI jest pewnego rodzaju audytem przedsiębiorstwa (z branży IT), gdzie określa się spełnienie wielu szczegółowych przesłanek skategoryzowanych na kilku poziomach (ang. maturity level). Wypełnienie wytycznych (celów) z odpowiedniego poziomu określa poziom dojrzałości organizacji jako całości. Wyróżnia się 5 poziomów dojrzałości: organizacja na poziomie początkowym (initial), organizacja na poziomie zarządzanym (managed), organizacja na poziomie zdefiniowanym (defined), organizacja na poziomie zarządzanym ilościowo (quantitavely managed), organizacja na poziomie optymalizowanym (optimised). Poprzez charakterystykę klienta (parametr drugi) rozumieć należy określenie odpowiedzi na dwa pytania: czy klient jest odpowiedni tj. czy osoba zaangażowana w projekt ma odpowiednie kwalifikacje, jest merytorycznie przygotowana do udziału w projekcie, zna w wystarczającym stopniu zagadnienie itd., czy klient jest dopasowany do projektu jakie są cechy osobowe przedstawiciela ze strony klienta z punktu widzenia uczestnictwa w zespole projektowym i roli, w której powinien zostać obsadzony (np. ekstrawertyk? analityk?). W odróżnieniu od stosunkowo precyzyjnej, ilościowej metodyki, którą wyznacza CMMI, uzyskanie oszacowania tych dwóch wartości wynikać musi przede wszystkim z metod socjotechniki. Te nierzadko opisują problem jedynie jakościowo. W tym zakresie również prowadzone są badania przez członków Zespołu. Nie wchodzą jednak w zakres tematyczny niniejszego opracowania. Trzecim z wymienionych parametrów decydujących o wyborze metod zarządzania projektem wytwarzania architektury korporacyjnej jest jego złożoność. Pod tym pojęciem rozumie się uporządkowanie projektu, czyli ilość pozostałych zadań do realizacji i jasność wyznaczonych celów. Projekt uważać się będzie za najbardziej złożony w momencie jego rozpoczęcia, kolejne zrealizowane etapy zaś poziom tej złożoności obniżają. Podobnie jak w przypadku innych parametrów, aby móc określać poziom złożoności niezbędne jest wyznaczenie czynników, które mają na niego bezpośredni wpływ. Ten właśnie parametr autorzy uznali za właściwy do dogłębnej analizy. Jego dotyczą wobec tego omawiane w dalszej części założenia do baz wiedzy (kolejny rozdział).

8 C.Orłowski, T.Sitek CMMI 1. RODZAJ ARCHITEKTURY 2. OBSZAR 3. DOKUMENTACJA METODY SOCJOTECHNICZNE DOJRZAŁOŚĆ ORGANIZACJI ZŁOŻONOŚĆ PROJEKTU DOJRZAŁOŚĆ KLIENTA METODOLOGIA ZARZĄDZANIA PROJEKTAMI (+NARZĘDZIE) Rys. 3. Ogólny model przetwarzania wstępnych danych wejściowych [opracowanie własne na podstawie 4] Omówione zależności między zidentyfikowanymi parametrami kluczowymi dla przedsięwzięcia wdrożeń architektury korporacyjnej zostały przedstawione na rysunku 3. Zaznaczony został na nim równocześnie obszar zainteresowań autorów - parametry determinujące poziom złożoności projektu jako zmiennej wpływającej na odpowiednią metodologię zarządzania projektami. 5.3.4. Zapis wiedzy na temat złożoności projektu w modelu wytwarzania architektury korporacyjnej Na podstawie wcześniejszych założeń zweryfikowanych eksperymentami (patrz []) przyjęto, iż w systemie wieloagentowym do oceny technologii informatycznych IT_MAS podstawową metodą reprezentacji wiedzy jest zapis regułowy. W zależności od dziedziny przedmiotowej bazy mogą być zasilane wiedzą rozmytą (gdy brak precyzyjnych, skwantyfikowanych zależności między parametrami) lub ostrą (problemy ilościowe). Wstępne badania autorów wskazały, iż dla potrzeb budowy bazy wiedzy na temat złożoności projektu zasadne będzie wykorzystanie opisu rozmytego. W danej chwili jedynie reguły lingwistycznej pozwalają za zapis zebranej wiedzy w sposób zgodny z rzeczywistością, gdyż wiedza na ten temat nie jest pełna ani precyzyjna. Zmienną wyjściową w regułach bazy wiedzy analizowanej domeny będzie złożoność projektu. Metoda COCOMO, z której zapożyczono taksonomię projektów ze względu na ilościowe miary opisujące różne jego aspekty, wyróżnia poziomy złożoności jak niżej: przedsięwzięcia organiczne (ang. organic projects), - mały zespół, dziedzina, metody i narzędzia dość dobrze znane, przedsięwzięcia półoderwane (ang. semi-detached projects) - członkowie zespołu różnią się doświadczeniem, dziedzina, metody i narzędzia nie do końca rozpoznane, przedsięwzięcia osadzone (ang. embedded projects), - polegają na wytworzeniu systemów o bardzo złożonych wymaganiach, zespół raczej nie ma doświadczenia w wytwarzaniu podobnego oprogramowania, dziedzina problemu, metody i narzędzia nie są zbytnio poznane. Jakiego rodzaju parametry wejściowe będą brane pod uwagę dla projektów wdrożenia architektury korporacyjne? Wyróżniono trzy takie wielkości determinujące złożoność przedsięwzięcia. Według założeń autorów projekt o tej specyfice można opisać z punktu widzenia następujących zmiennych (będących jednocześnie przesłankami do budowy reguł baz wiedzy): architektury, obszary wytwarzania i zarządzania,

5. Wytwarzanie architektury korporacyjnej środowiskiem weryfikacji 9 rodzaj generowanej dokumentacji. Parametr pierwszy architektury to występujące sekwencyjnie po sobie fazy konstruowania architektury korporacyjnej zalecane przez TOGAF. Wyróżnia się cztery takie etapy, które mogą w tego rodzaju przedsięwzięcia zostać osiągnięte: wizja architektury (ang. architecture vision) służy określeniu zakresu przedsięwzięcia, odpowiada zarządczej funkcji planowania, architektura biznesowa (ang. business architecture) tu tworzona jest ogólna koncepcja mającego powstać systemu informatycznego, architektura systemów informatycznych (ang. applications architecture) na tym etapie tworzony jest logiczny model systemu, architektura technologii (ang. technology architecture) produktem tej fazy jest model obrazujący, jak wyglądać będzie fizyczna realizacja architektury w systemie. Zaawansowanie projektu z punktu widzenia osiągniętego etapu (architektury) zmniejsza złożoność całego przedsięwzięcia wdrożenia EA. Tak więc przedsięwzięcia, w których osiągnięto etap architektury technologii z dużym prawdopodobieństwem można zakwalifikować jako organiczne. Drugi brany pod uwagę parametr w opisywanym modelu bazy wiedzy to obszary agregujące procesy zarządzania i wytwarzania. Przyjęto hierarchię ważności tych procesów z punktu widzenia ich wpływu na wytwarzanie architektury korporacyjnej. technologie wytwarzania, dobre praktyki wytwarzania, procesy wytwarzania, dobre praktyki w zarządzaniu, procesy zarządzania, technologie zarządzania. Taki hierarchiczny podział wynika z udziału w procesach wytwarzania procesów zarządzania. Procesy te mogą być wspomagane na pierwszym poziomie dobrymi praktykami lub w przypadku bardziej dojrzałych organizacji zdefiniowanymi procesami wytwarzania. Te z kolei mogą być także wspomagane dobrymi praktykami z zakresu zarządzania, a na wyższym poziomie przyjętymi procesami zarządzania. Poziom najwyższy to wykorzystanie technologii wspomagających procesy zarządzania wytwarzaniem architektury korporacyjnej. Im wyższy poziom zostaje osiągnięty, tym przedsięwzięcie staje się mniej złożone. Trzeci parametr wejściowy to stan przygotowania dokumentacji w projekcie. Uwzględnia się tu wszystkie etapy przygotowywania dokumentacji poczynając od dokumentów wstępnych przygotowywanych na potrzeby wytwarzanych architektur, jak też iteracyjny proces ich przygotowania odniesiony do procesów wytwarzania. Efektem prac nad wytwarzaniem architektur są dokumenty przekazania. Poniżej zaprezentowano hierarchiczny podział wytwarzanej dokumentacji. dokumentacja wstępna, dokumentacja wejściowa, dokumentacja weryfikacji, dokumentacja przekazania. Parametry te są od siebie zależne w sposób proporcjonalny. Przykładowo, stwierdzenie istnienia dokumentacji przekazania wynika z pewnością z dużego zaawansowania całego przedsięwzięcia, czyli jego złożoność na tym etapie będzie już mała. Zaprezentowane parametry wejściowe można zobrazować na trzywymiarowym układzie współrzędnych, jak pokazano na rys. 4. Każdy projekt wdrażania architektury korporacyjnej

WIZJA ARCHITEKTURY ARCHITEKTURA BIZNESOWA ARCHITEKTURA SYSTEMÓW INFORMATYCZNYCH ARCHITEKTURA TECHNOLOGII 10 C.Orłowski, T.Sitek będzie więc punktem w takim układzie odniesienia. Czym bardziej punkt taki będzie oddalony od środka układu współrzędnych (punktu (0,0,0)), tym przedsięwzięcie będzie się charakteryzowało mniejszą złożonością. TECHNOLOGIE ZARZĄDZANIA OBSZARY PROCESY ZARZĄDZANIA DOBRE PRAKTYKI W ZARZĄDZANIU PROCESY WYTWARZANIA DOBRE PRAKTYKI WYTWARZANIA TECHNOLOGIE WYTWARZANIA ARCHITEKTURY WSTĘPNA WEJŚCIOWA WERYFIKACJI PRZEKAZANIA DOKUMENTACJA Rys 4. Warstwowy model złożoności projektu bazujący: przypadek wytwarzania architektury korporacyjnej [źródło: 4] 5.3.5. Formalizacja modelu wiedzy - opis lingwistyczny zmiennych modelu zintegrowanego Dla określenia wartości parametrów w analizowanym modelu przyjęto, że wielkości lingwistyczne reprezentowane są przez wartości ze zbiorów {0,1,2} lub {M, S, D} gdzie: M - małe lub niskie, S - średnie, D - duże lub wysokie. Zaproponowany w model lingwistyczny bazuje na przedstawionej koncepcji przetwarzania z wykorzystaniem funkcji P. Przyjmuje się w pracy że ma ona postać regułową, która możemy przedstawić jako, P : S z S y (1) gdzie: S stanowi iloczyn kartezjański zbiorów wartości lingwistycznych stanów zaś z s 3, 0,1,2, który można opisać jako zbiór trójek z

5. Wytwarzanie architektury korporacyjnej środowiskiem weryfikacji 11 S y opisuje iloczyn kartezjański zbiorów wartości lingwistycznych 3 przyrostów,, S 0,1,2 y Na podstawie opisu lingwistycznego z wykorzystaniem funkcji P przyrostów zmian czynników wpływających na złożoność projektu R możemy opis ten przedstawić w postaci regułowej: P : ( 1 z IS gdzie : oraz A 1 j ) AND ( z 2 IS R 3 m A 2 j ) AND ( z IS A ) ( y IS C mn ) (2) j z - parametry wejściowe wpływające na złożoność projektu A ij, C mn - wartości lingwistyczne będące elementami macierzy A ij A C mn i 1,2; j 1,2,3 ; k 1,2,3,4 ; l 1, 2 ; m 1,2; n 1,2, 3 ij a j i 1, 2 A 1 j 1; A A A 11 21 A A 12 22 A A 13 23 C 1 n 1; m 1, a a mn c n 2 0 0 a a 1 1 a2 0 a 2 0 3 j C (3) 1 1 2 2 C11 C12 C13 c0 c1 c2 0 1 2 C. C21 C22 C23 c0 c1 c2 0 1 2 5.4. Podsumowanie Niniejszy artykuł dokumentuje prace wykonane przez autorów w zakresie przygotowania bazy wiedzy dla systemu wieloagentowego, którego zadaniem ma być dobór odpowiedniej metodyki zarządzania projektami IT. Domenę zawężono do specyficznej grupy przedsięwzięć wdrożenia architektury korporacyjnej. Prezentowana praca stanowi jednocześnie kolejny etap weryfikacji systemu wieloagentowego z punktu widzenia jego architektury oraz zaprojektowanych funkcjonalności. Z uwagi na to, że autorzy zajęli się jedną (z trzech) zmienną wejściowych determinującą rekomendowaną metodykę, nie można mówić o wnioskach z przeprowadzonej weryfikacji całego modelu. Bazując jednakże na badaniach dotyczących jednej zmiennej można już na tym etapie dokonać porównań tego projektu z poprzednimi. System wieloagentowy został wcześniej, jak już wspomniano, użyty do implementacji systemu technicznego (prognozowanie poziomu zanieczyszczeń powietrza). Tamten projekt dostarczył do baz wiedzy danych ilościowych pochodzących z odczytów. Były one w większości poprawne i kompletne, przetwarzanie wiedzy było wobec tego stosunkowo łatwe (oparte na znanych algorytmach). Tym razem ten sam model ma bazować na wiedzy w dużej części jakościowej (np. szacowanie poziomu architektury). Wiedzę taką dość trudno sformalizować. Stąd za konieczne uznano przetwarzanie wstępne (preprocessing) zmiennych wejściowych reguł co dla jednej zmiennej autorzy zrobili. Przy tego typu problemach autorzy zauważyli jeszcze jedno niebezpieczeństwo. Krokiem, który trzeba będzie poczynić jest analiza korelacji wszystkich zmiennych wejściowych modelu (zarówno głównych, jak i tych użytych dla potrzeb preprocessingu). Zasadą zapisu wiedzy regułowej jest bezwzględna niezależność takich parametrów. Istnieje jednak podejrzenie, iż

12 C.Orłowski, T.Sitek podczas analizy innych kluczowych zmiennych takie niebezpieczeństwo będzie realne. Konieczna będzie tu weryfikacja baz wiedzy przez ekspertów właśnie pod tym kątem. Mimo wskazywanych problemów, należy uznać ten etap badań za sukces. Koncepcja baz wiedzy systemu wieloagentowego, mimo konieczności uwzględnienia wielu dodatkowych założeń, jest słuszna także dla systemów nietechnicznych. Plan dalszych działań przewiduje pozyskanie wiedzy z każdego obszaru (dla pozostałych dwóch zmiennych wejściowych) oraz jej integracja w jednej bazie wiedzy. Kolejnym działaniem będzie implementacja kompletnego modelu (w języku Java). Stanowić będzie ona docelowo plug-in dla narzędzia IBM TeamConcert wspomagający użytkownika tego narzędzia do zarządzania projektami w zakresie wyboru najlepszej dla przedsięwzięcia metodyki zarządzania. Bibliografia [1] Architektura korporacyjna: od strategii do skutecznych zmian, http://www- 01.ibm.com/software/pl/itsolutions/enterprisearchitecture/ (10.03.2009) [2] Czarnecki A., Orłowski C.: Możliwości zastosowania ontologii do oceny technologii informatycznych. W: Komputerowo Zintegrowane Zarządzanie. Red. Ryszard Knosala, Tom II. Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją, Opole 2007 [3] Jabłonka R.: Architektura korporacyjna, Wprowadzenie do ram architektonicznych TOGAF. Listopad 2008. http://www.sybase.com.pl/pliki/pdf/wydarzenia/togaf.pdf (10.03.2009) [4] Orłowski C.: Semantyczna specyfikacja procesów ADM dla potrzeb doboru metod zarządzania przedsięwzięciami (w opracowaniu) [5] Orłowski C.: Wprowadzenie. Zarządzanie technologiami informatycznymi. Stan i perspektywy rozwoju, monografia pod red. nauk. Cezarego Orłowskiego. Pomorskie Wydawnictwo Naukowo-Techniczne, Gdańsk 2006 [6] Orłowski C., Sitek T.: Ocena technologii informatycznych - koncepcja wykorzystania systemów inteligentnych. Komputerowo Zintegrowane Zarządzanie. (red.) R. Knosala, Tom II. Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją, Opole 2007 [7] Sitek T., Orłowski C., Namieśnik J.: Weryfikacja struktur baz wiedzy systemu agentowego do oceny technologii informatycznych. XII Konferencja "Komputerowo Zintegrowane Zarządzanie", Tom 2, (red.) R. Knosala. Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją. Opole 2009 [8] Sobczak A.: Dlaczego architektura korporacyjna?. Serwis ArchitekturaKorporacyjna.pl, (10.03.2009) [9] TOGAF dokumentacja, wersja 8.1.1 [10] Ziółkowski A., Orłowski C.: Concept of the agent system for the information technology evaluation. Information systems architecture and technology: information systems and computer communication networks. Red. Adam Grzech. Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław 2007

5. Wytwarzanie architektury korporacyjnej środowiskiem weryfikacji 13 {Odrębna strona streszczeń i adresów} Wytwarzanie architektury korporacyjnej środowiskiem weryfikacji struktur baz wiedzy systemu wieloagentowego C. Orłowski*, T. Sitek** * Politechnika Gdańska, Wydział Zarządzania i Ekonomii, Zakład Zarządzania Technologiami Informatycznymi, cor@zie.pg.gda.pl ** Politechnika Gdańska, Wydział Zarządzania i Ekonomii, Zakład Zarządzania Technologiami Informatycznymi, tsitek@zie.pg.gda.pl Rozdział 5. Wytwarzanie architektury korporacyjnej środowiskiem weryfikacji struktur baz wiedzy systemu wieloagentowego. Rozdział dokumentuje przebieg i wyniki weryfikacji opracowywanego w Zakładzie Zarządzania Technologiami Informatycznymi modelu systemu wieloagentowego do oceny technologii informatycznych. Wykorzystanie tego modelu (zaprojektowanego w oparciu o ontologie i zasoby baz wiedzy) ma docelowo wspomagać procesy decyzyjne z zakresu doboru technologii informatycznych dla danej organizacji. Dla potrzeb weryfikacji rozwiązania w zakresie jego struktur i założonych funkcjonalności baz wiedzy model zaadoptowano do implementacji wyników badań (wiedzy) z zakresu zarządzania przedsięwzięciami informatycznymi. Skupiono się nad specyficzną tematyką wdrażania architektur korporacyjnych w organizacjach i wsparcia decyzyjnego w zakresie doboru optymalnej metodyki zarządzania takim projektem. Autorzy przeanalizowali kluczowe dla budowy reguł baz wiedzy parametry i proces przetwarzania wstępnego dla jednego z nich. Building enterprise architecture as an environment for verification of multiagent system knowledge bases structure C. Orłowski*, T. Sitek** * Gdansk University of Technology, Faculty of Management and Economics, Department of Information Technology Management, cor@zie.pg.gda.pl ** Gdansk University of Technology, Faculty of Management and Economics, Department of Information Technology Management, tsitek@zie.pg.gda.pl Chapter 5. Building enterprise architecture as an environment for verification of multiagent system knowledge bases structure. The chapter documents results of research on model of multi-agent system for evaluation of information technologies (IT_MAS). Such system is being developed in Gdansk University of Technology by Information Technology Management Team. Multi-agent system is supposed to support manager level specialists during decision processes when there is identified need to buy or change any information technology. For the purpose of model knowledge bases structures and functionalities verification, it was adopted for implementing knowledge about managing IT projects. Authors focused on building enterprise architecture projects and decision support in choosing best project managing methodology. Key parameters were analyzed and preprocessing for one of them was done.