Lekarstwem na niepowodzenia projektów może stać się wykorzystanie teorii systemów otwartych.

Praktycznie w każdym numerze Computerworld można znaleźć informacje o porażkach przy wdrażaniu wielkich i nieco mniejszych projektów informatycznych. Podobne problemy nie występują tylko w Polsce - potwierdza to choćby lektura książki "Wielkie projekty informatyczne - czyli marsz ku klęsce". Gdzieś więc musi leżeć przyczyna, dla której od 1991 r. budujemy np. pracowicie system obsługi służby zdrowia (interesujące kalendarium zamieszczono w CW nr 42/2006) oraz inne systemy (omówienie wyników kontroli NIK w tym samym numerze), a rezultaty w wielu przypadkach są delikatnie twierdząc "niezbyt zadowalające". Warto więc przyjrzeć się bliżej, jak z podobnymi problemami próbują radzić sobie inni.

System otwarty

Wbrew pozorom pojęcie to nie narodziło się w informatyce, lecz w biologii, w której zdefiniowano jako system otwarty, taki który może wymieniać energię, materiały oraz informacje ze swym środowiskiem w sposób ciągły. Istotą systemu otwartego jest wykorzystywanie wielu interfejsów, które umożliwiają ciągłość takiej wymiany.

Definicja systemu otwartego sformułowana przez Instytut Inżynierii Oprogramowania Carnegie-Mellon University (www.sei.cmu.edu/opensystems) jest następująca:

"System otwarty jest zbiorem współpracujących między sobą oraz ze środowiskiem zewnętrznym składników sprzętowych, programowych oraz ludzkich:

• zaprojektowany w celu spełniania określonych potrzeb

• zawiera specyfikację interfejsów swych komponentów, która:

  - jest w pełni zdefiniowana

  - udostępniona publicznie

  - zarządzana na zasadzie konsensusu zainteresowanych grup

• w którym implementacja komponentów odpowiada w pełni specyfikacji interfejsów".

Tak zdefiniowany system otwarty stał się podstawą opracowania strategii MOSA (Modular Open System Approach) opracowanej przez Ministerstwo Obrony (DoD) USA. MOSA jest to strategia inżyniersko-biznesowa wykorzystywana zarówno przy budowie nowych, jak i modernizacji już istniejących systemów obronnych. Wydaje mi się, że warto zapoznać się z jej elementami, które w pełni mogą być zastosowane przy budowie systemów informacyjnych.

Pięć zasad MOSA

• Określ swoje potrzeby i przeprowadź analizę możliwości,
• w wyniku otrzymasz pełny obraz interesującego cię środowiska.
• Przygotuj się na nieuniknione zmiany technologiczne i biznesowe, rezultatem powinien być przemyślany podział systemu na dobrze zdefiniowane moduły.
• Określ interfejsy oraz sposób zarządzania ich specyfikacją, szczególną uwagę poświęć zarówno wyborowi kluczowych interfejsów pomiędzy modułami projektowanego systemu, jak i środowisku zewnętrznemu.
• Przeprowadź analizę rynku i wybierz otwarte standardy dla kluczowych interfejsów, wybrane standardy powinny być powszechnie akceptowane oraz szeroko wspierane.

Główną uwagę poświęć kluczowym interfejsom pomiędzy modułami i określeniu ich standardów, a nie implementacji samych modułów. Dla kluczowych interfejsów należy preferować standardy otwarte.

• Przyjrzyj się rezultatom i przeprowadź ich analizę, sprawdź zgodność projektu z założeniami, możliwość swobodnej wymiany modułów w przyszłości oraz spełnienia wymagań strategii MOSA.

Po przeprowadzeniu końcowej analizy oraz wprowadzeniu ewentualnych poprawek możesz już przystąpić do opracowywania SIWZ...

Dlaczego warto?

Strategia MOSA stwierdza jasno - zamawiający koncentruje się na interfejsach - dostawca wybiera implementację (Glen T. Logan). Dzięki takiemu podejściu możliwe jest zachowanie uczciwej konkurencji oraz wyboru najlepszej oferty na wykonanie poszczególnych modułów. Co więcej, ścisłe przestrzeganie tej zasady ułatwia wprowadzanie nowych technologii, które mogą być jeszcze nieznane w chwili projektowania systemu. Moduł może być w każdej chwili wymieniony, pod warunkiem że jego interfejsy spełniają wymagania określone w pierwotnym projekcie.

Znakomitym przykładem może być opona samochodowa. Posiada ona dwa interfejsy - z obręczą oraz z jezdnią. Oba są zdefiniowane (średnica i szerokość osadzenia oraz bieżnik). Zakupując oponę, możemy wybrać wśród propozycji wielu producentów, zarówno w chwili obecnej, jak i w dającej przewidzieć się przyszłości.

Strategia MOSA nieprzypadkowo została wprowadzona przez Ministerstwo Obrony USA. W cytowanym już wystąpieniu G. T. Logan powołuje się na przykład systemu komputerowego samolotu AV-8Bs (znanego także pod nazwą Harrier II+), który zgodnie z planami DoD ma pozostać w służbie do 2023 r. Warto zwrócić uwagę, że model ten opracowano w 1993 r. na bazie słynnej brytyjskiej maszyny Harrier, zaprojektowanej w połowie lat 50. i wprowadzono do służby w USA w 1997 r.! Dzięki strategii MOSA w systemie komputerowym nowej wersji samolotu zastosowano wiele modułów powszechnie dostępnych na rynku (COTS - Commercial of the Shelf).

Ewolucja - droga rozwoju dojrzałych technologii

Burzliwy rozwój jest cechą młodości. Dojrzałe technologie nie rozwijają się metodą wymiany całych rozwiązań. W początkowym okresie rozwoju każda technologia wypracowuje własne standardy, z których niektóre zostają powszechnie zaakceptowane.

Obecnie w sieciach lokalnych praktycznie niepodzielnie króluje Ethernet (różnych odmian). Powszechnie korzystamy także właściwie tylko z jednego protokołu TCP/IP w wersji 4. Aktualnie rozwijają się one już ewolucyjnie - wprowadzane są coraz szybsze wersje Ethernetu oraz IP w wersji 6. XML zwyciężył już w praktyce jako standard dokumentu elektronicznego - dyskusja nad propozycją firmy Microsoft a standardem Open Document Format (OASIS) wydaje się powoli zmierzać do zakończenia.

W tej sytuacji przy projektowaniu nowych systemów (oraz modernizacji starszych) możliwe jest już ścisłe definiowanie interfejsów zarówno pomiędzy modułami, jak i całymi systemami. Wymaga to jedynie (zgodnie ze strategią MOSA) konsekwentnego wykorzystywania otwartych standardów dla kluczowych interfejsów systemu, a wzajemna ich współpraca nie będzie przedstawiać większych problemów.

Rola przemysłu - czyli "dowolny kolor, byle był czarny"

Na ostatnim spotkaniu w Sejmie RP poświęconym otwartym standardom, któremu patronował marszałek Marek Jurek, jeden z uczestników dyskusji stwierdził, że standardy powinien wypracować przemysł komputerowy. Nie mogę zgodzić się z tą opinią. To producenci samochodów dostosowują swe produkty do otwartych i powszechnie zaakceptowanych standardów. Dzięki temu mamy spory wybór, a ruch odbywa się (statystycznie) bez większych zakłóceń.

Na początku lat 90. w sieciach lokalnych w powszechnym użyciu było kilkanaście różnych protokołów - wystarczy tylko przypomnieć IPX/SPX firmy Novell lub NetBEUI (IBM/Microsoft). Zwyciężył jednak standard otwarty (w którego opracowaniu brał także udział Departament Obrony USA - DoD) i każdy dostawca oferuje protokół TCP/IP jako standard.

Organizacje komercyjne dopóki tylko będzie istniała taka możliwość będą usiłowały realizować politykę wyłączności, ponieważ uzależnia ona odbiorcę od dostawcy. Jeśli jednak zaczynają tracić klientów z powodu trzymania się zamkniętych rozwiązań, natychmiast dostosowują się do standardów otwartych. Przemysł informatyczny nie należy tu wcale do wyjątków. Na wspomnianym już spotkaniu w Sejmie przedstawicielka banków stwierdziła, że w tym sektorze nie jest już właściwie problemem zarówno komunikacja elektroniczna pomiędzy bankami, jak i między bankiem i rzeszą użytkowników jego kont internetowych. Proszę zwrócić uwagę, że nawet w ofercie dla firm następuje wyraźny odwrót od stosowania specjalnego, zamkniętego oprogramowania dostarczanego klientom. A przecież banki w Pol-sce eksploatują bardzo różne systemy informatyczne...

Jeżeli klient jest jednak uzależniony od dostawcy produktu i usługi, to rozwiązania zamknięte są stosowane bardzo chętnie - przykładem może być choćby słynny "Płatnik".

Open System to nie open source!

Różnica jest zasadnicza. Open System wymaga ujawnienia jedynie specyfikacji interfejsów, zaś Open Source - ujawnienia implementacji.

Tak więc w systemach otwartych mogą być z powodzeniem stosowane zarówno produkty komercyjne, jak i dostępne na licencjach otwartych. Dzięki publicznemu dostępowi do specyfikacji interfejsów możliwa staje się rzeczywista konkurencja pomiędzy implementacjami.

W organizowanych ponad trzy lata temu przetargach na dostawę kilkunastu tysięcy końcówek sieciowych Ministerstwo Finansów umieściło w SIWZ (między innymi) pełną specyfikację interfejsu klawiatury oprogramowania Poltax, która zajęła ponad 5 stron. Ale to właśnie dzięki temu umożliwiono uczciwe konkurowanie różnym dostawcom, a dostarczone urządzenia wdrożono bez problemów.

Niestety, nie jest to powszechna praktyka - najczęściej spotykane są ogólne stwierdzenia typu "właściwa współpraca z aplikacjami XXX, YYY, ZZZ", a wymagania szczegółowe dotyczą implementacji - np. "Płyta główna - chipset INTEL 915GV lub równoważny". Powód jest najczęściej dość prozaiczny - jednostka eksploatująca te aplikacje najczęściej po prostu nie dysponuje specyfikacją ich interfejsów!

Inną ulubioną metodą jest powoływanie się na względy bezpieczeństwa i rzekomą konieczność np. utajnienia protokołu komunikacyjnego lub formatu przekazywanych danych. A tymczasem współcześnie wykorzystywana w komunikacji komputerowej kryptografia opiera się głównie na protokołach i standardach otwartych, uznając je za znacznie bardziej godne zaufania.

A jaki z tego morał?

• Projektowany system powinien charakteryzować się budową modularną z uwzględnieniem możliwości swobodnej wymiany modułów podczas całego okresu eksploatacji systemu.
• Kluczowe interfejsy systemu (zarówno wewnętrzne, jak i zewnętrzne) powinny wykorzystywać standardy otwarte.
• Przy formułowaniu wymagań należy zwracać uwagę na dokładną specyfikacji interfejsów (łączy), zaś sposób implementacji pozostawić do uznania dostawcy (producenta).
• Standardy zamknięte (propertiary) powinny być wykorzystywane jedynie w interfejsach wewnętrznych i w przypadku niezbędnej konieczności. Zawsze jednak obsługa interfejsu powinna być w pełni udokumentowana oraz dostępna jednostce eksploatującej system.
• W wymianie danych należy wykorzystywać wyłącznie standardy otwarte.
• Mechanizmy bezpieczeństwa powinny być oparte na otwartych protokołach uwierzytelniających, szyfrujących, wymiany kluczy itp., zaś sposób ich wykonania udokumentowany.

Jeśli uda się wprowadzić taką strategię, zwłaszcza w systemach wykorzystywanych w administracji państwowej i samorządowej, życie stanie się piękne...