Drogi do otwartości

Jak wdrażać otwarte systemy klient/serwer, aby wykorzystać szansę, którą daje ta technologia?

Jak wdrażać otwarte systemy klient/serwer, aby wykorzystać szansę, którą daje ta technologia?

Mimo wieloletnich doświadczeń w dziedzinie organizacji przedsięwzięć informatycznych, zjawiska kryzysowe, charakterystyczne dla tego typu działalnści, ciągle dają znać o sobie. Upoważnia to wręcz do mówienia o permanentnym kryzysie branży IT (information technology). Dla użytkownika przejawia się to w postaci niezadowalającej jakości oprogramowania. Niekiedy wydaje się, że pakiety software'owe po prostu wymykają się spod kontroli ich twórcom, którzy - pod presją wymagań rynkowych - za wszelką cenę chcą wprowadzić do sprzedaży nową wersję produktu, by wyprzedzić konkurencję.

Najgorzej jest oczywiście z oprogramowaniem specjalistycznym przeznaczonym dla profesjonalistów bowiem producent zakłada, że:

- użytkownikami jest mała grupa osób, a liczba instalacji jest niewielka

- większa wiedza informatyczna odbiorcy prowokuje niższą jakość produktu

- ludzie z branży szybciej wybaczają kolegom błędy, które sami popełniają

- informatycy "lubią" walczyć z komputerami, bo to jest ich praca

- decyzje o zakupie podejmują menedżerowie, a nie spece od software'u.

Ale nawet aplikacje, które masowo instalowane są na tysiącach komputerów, nie są wolne od "chorób wieku dziecięcego". Dotyczy to zarówno całych "kombajnów" software'owych dużego kalibru (SAP R/3), jak i oprogramowania "biurkowego", dla szarych zjadaczy bitów i bajtów (Windows 95).

Przejawem "grzeczności" ze strony renomowanych firm jest dostarczanie, bez żenady, swoich pakietów wraz z pokaźnymi listami zlokalizowanych błędów (bugs). W przypadku problemów eksperci serwisowi doradzają jak najszybsze przejście na nową wersję programu, która pozbawiona jest oczywiście starych błędów, ma za to masę nowych. A może nawet mechanizm ten bardziej jeszcze zbliżony jest do bezwzględnego prawa Murphy'ego: "Stary program to stare błędy, nowy program to nowe i stare błędy". Żadna aplikacja bowiem nie działa samotnie, a tak się dziwnie składa, że współpraca różnych programów potrafi zaowocować komunikatem o błędzie, po którym nie pozostaje nic innego, jak użyć "małpiego chwytu", czyli kombinacji wiadomych klawiszy CTRL+ALT+DEL.

Z menedżerskiego punktu widzenia problemy tworzenia bądź wdrażania systemów informatycznych rozgrywają się w "trójkącie sił": koszty, czas, jakość (patrz rys.). Czynniki te są wzajemnie zależne, więc wynika stąd, iż jednym z głównych zadań kierownika projektu informatycznego jest uzyskanie wyważonego stosunku między nimi. Proporcje te rzutują na powodzenie całego przedsięwzięcia.

Tak więc podczas tworzenia bądź wdrażania systemów informatycznych, czasy i koszty związane z tymi procesami

przekraczają zakładane wielkości i w tym również objawia się wspomniany kryzys branży IT. Przyczyny tych problemów zestawiono w tabeli. Zestawienie to wskazuje na wagę zagadnień pozatechnicznych, organizacyjnych. Nie trzeba udowadniać, jak bardzo istotny jest ten wymiar projektu podczas wdrażania nowych technologii, a do takich należą otwarte systemy klient/serwer (C/S) - stąd znaczenie poszukiwania "dróg do otwartości".

Błędna interpretacja pojęcia otwartości może prowadzić do drastycznych zmian w strategii wdrażania systemu, co niekorzystnie rzutuje na koszty i czas realizacji projektu. Mimo istnienia wypróbowanych wykładni otwartości, takich gremiów, jak Gartner Group czy Open System Foundation, warto sprecyzować, czym na pewno nie jest system otwarty:

- nie jest to typ architektury informatycznej

- nie jest to spełnienie określonych norm

- nie jest to korzystanie z odpowiednich produktów.

Przede wszystkim otwartość jest cechą systemu, wynikającą ze sposobu jego konstruowania, co wymaga zastosowania adekwatnych metod zarządzania. Oczywiście, zakłada się także oparcie na pewnych standardach, ale proponowane ujęcie otwartości zapobiega powstawaniu nieporozumień, które dają się zgrupować w czterech punktach:

-aspekt software'owy: systemy otwarte związane są ze środowiskiem Unixa (uproszczenie)

-aspekt rynkowy: systemy otwarte pochodzą od wielu wytwórców (nie jest to cel sam w sobie)

-aspekt sprzętowy: systemy otwarte spełniają hardware'owe normy przemysłowe (nie uwzględniona potrzeba integracji systemów)

-aspekt komunikacyjny: systemy otwarte operują zdefiniowanymi złączami (możliwa zależność od jednego producenta).

W jaki sposób może wyglądać przejście od systemu zamkniętego do otwartego? Bez wątpienia zetkniemy się przy tym z wieloma nazwami kończącymi się na "sizing". Jest więc downsizing (schodzimy w dół) i upsizing (nie zapominamy o górze), rightsizing (na prawo, na prawo), smartsizing (byle z elegancją), correctsizing (i akuratnie), a także costsizing (koszty!). Zostawmy trudy tłumaczenia tych określeń na polski hobbistom i zauważmy, że w każdym przypadku mamy do czynienia z m i g r a c j ą określonej aplikacji, ze starego do nowego środowiska informatycznego. Migracja ta może dokonać się na wiele sposobów:

1) Konwersja (convert): zmiany w kodzie aplikacji przy zachowaniu jej funkcjonalności i poprawie parametrów eksploatacyjnych - możliwa częściowa automatyzacja konwersji, np. przy przechodzeniu na inną wersję oprogramowania.

2) Emulacja (emulate): ta sama aplikacja i ta sama funkcjonalność w nowym środowisku - realizacja możliwa na drodze sprzętowej lub programowej.

3) Przepisanie (rewrite): całkowita zmiana kodu aplikacji przy zachowaniu jej funkcjonalności - stwarza możliwość efektywnego rozwoju aplikacji.

4) Zastąpienie (replace): nowe - aplikacja, technologia, funkcjonalność - możliwy wariant "wyspowego", specjalistycznego modułu.

5) Integracja (integrate): rozszerzona, wersja zastępowania dla grup aplikacji - nowa jakość jest czymś więcej niż sumą nowych elementów.

6) Reinżynieria (re-engineering): nowe - aplikacje, procesy organizacyjne, modele danych - wariant idealny, wymuszający relatywne skoki technologiczne.

Ta ostatnia koncepcja jest najdroższa, ale daje też największe korzyści. Bardzo efektywna może być także przeprowadzona na szeroką skalę integracja połączona z zastępowaniem starych aplikacji nowymi. Pozostałe z wymienionych technik mają zdecydowanie bardziej pasywny charakter i na dłuższą metę wnoszą niewiele nowego, choć mogą okazać się dość kosztowne. Zawsze jednak należy pamiętać o pozatechnicznych aspektach projektu. W praktyce bowiem, powszechne jest przekonanie, że wdrożenie nowej technologii sprowadza się do zainstalowania nowego sprzętu i oprogramowania.

Tymczasem nowe technologie wymagają nowych form organizacji w przedsiębiorstwie, w tym również w zakresie zarządzania personelem - HMR (Human Resource Management).

W tym kontekście, podczas projektowania i eksploatacji otwartych systemów C/S, kluczowego znaczenia nabiera podział zadań między użytkownikami a specjalistami - w typowym wariancie - skupionymi wokół działu technologii informacyjnej (IT). Współczesne środki informatyki pozwalają na elastyczne przesuwanie granicy między obiema stronami, co w szczególności pozwala na delegowanie zadań rozwoju systemu do jego użytkowników. Stopień delegowania zależny jest każdorazowo od specyfiki sytuacji, z którą się stykamy.

Jeśli mamy do czynienia z wysoko wykwalifikowanymi użytkownikami, którzy nie boją ˙się ˙komputera, ˙możemy liczyć ˙na znaczne odciążenie działu IT. Wymaga to wprawdzie większych ˙nakładów ˙po stronie ˙klientów,˙ale zmniejsza ˙wydatki na późniejszą pielegnację. W ten sposób powstają systemy odpowiadające oczekiwaniom odbiorców ˙ale o ograniczonym zasięgu (np. wydział marketingu) i niezbyt złożone. Z kolei dla systemów o regularnym trybie przetwarzania danych ze ściśle zdefiniowanym sposobem prezentacji bardziej ˙celowe ˙jest ˙przesuwanie rozwojowych punktów ciężkości w kierunku działu IT. System jest wówczas bardziej bezpieczny, może mieć szeroki zasięg i być bardziej kompleksowy (np. sieć banków).

W każdej aplikacji możemy wyróżnić trzy podstawowe warstwy: danych, logiki przetwarzania i prezentacji. W systemie monolitycznym (monolithic) wszystkie one znajdują się po stronie serwera, system jest "zamknięty" dla użytkowników, choć fizycznie może bazować na rozgałęzionej sieci. W systemach C/S nic nie stoi na przeszkodzie, aby warstwę prezentacji oddać we władanie użytkownikom. Dzieje się tak w aplikacjach bazodanowych, gdzie dział IT przygotowuje dane i metody przetwarzania, natomiast użytkownik określa sposób ich końcowego wykorzystania za pomocą narzędzi typu browser (przeglądarka) czy pakietów graficznych bądź arkuszy kalkulacyjnych.

Kolejnym krokiem może być scentralizowane zarządzanie danymi w połączeniu ze zdecentralizowanymi warstwami logiki przetwarzania i prezentacji. Dział IT odpowiedzialny jest za modelowanie danych wraz z implementacją warstwy dostępu do danych.˙W˙pewnym zakresie dostęp˙ten, wraz możliwością modyfikowania danych, gwarantowany jest także użytkownikom, którzy przejmują zadania z zakresu przetwarzania danych, tzn. implementują funkcje operujące na danych.

System taki jest zabezpieczany centralnie (backup), co gwarantuje mu odpowiednią stabilność, a jednocześnie,˙ze˙względu na swą elastyczność, jest znacznie bliższy potrzebom odbiorców.

Brzmi˙to˙bardzo ładnie, może nawet za ładnie? W końcu chyba nie chodzi o to, by referent uczył się języka C, bo wspomniane "funkcje" trzeba zaprogramować.

W gruncie rzeczy rozwiązanie tego problemu wygląda podobnie jak dla warstwy prezentacji. Owszem, nie tak dawno jedyną szansą na wypozycjonowanie znakowego kursora w lewy górny róg ekranu było GotoXY (1,1) - to akurat Pascal - dzisiaj paroma kliknięciami myszki można generować całe obiekty, za którymi co prawda i tak znajdują się setki takich rozkazów, ale kogo obchodzi, jakimi drogami biegają sobie elektrony w układach scalonych? Cała rzecz w użyciu odpowiednich narzędzi. Wystarczy porównać kolejne generacje CDE (Cooperative Development Environments) Oracle, aby zobaczyć wyraźny trend zwiększania możliwości tworzenia aplikacji po stronie klienta, w tym także przez użytkowników.

Co prawda żaden administrator systemu nie będzie mógł spać spokojnie ze świadomością, że użytkownik "bawi się"

źródłowymi danymi, nie ma jednak powodu, aby zostawić mu agregowanie tych danych w informacje, a w przyszłości pewnie i przekształcanie informacji w wiedzę. Współczesny inżynier także projektuje mosty bezpośrednio na swoim, skomputeryzowanym stanowisku pracy, a nie biega do kapłanów "wiedzy tajemnej", którzy niegdyś, w białych kitlach z obłędem w oczach i taśmą perforowaną na szyi, władali klimatyzowanymi ośrodkami obliczeniowymi.

Kolejnym krokiem na drodze rozwoju otwartych systemów C/S mogłoby być oddanie użytkownikom wszystkich trzech warstw aplikacji (!). Nie jest to utopia, jeśli przyjrzeć się poszczególnym fazom funkcjonowania systemów informatycznych. I tak podczas projektowania, ideałem jest gdy niemal cały system tworzony jest przez jego przyszłych odbiorców.

Dział IT odpowiedzialny byłby jedynie za jego fizyczną implementację, głównie po stronie serwerów i za bezzakłóceniową fazę eksploatacji.

Przy czym informatyk wcale nie musi się w takim wariancie obawiać o swoje perspektywy zawodowe, wręcz przeciwnie: im większy poziom wiedzy informatycznej użytkowników, tym większe możliwości na wdrażanie najnowocześniejszych rozwiązań w tej dziedzinie.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200