W każdej dużej firmie pojawi się prędzej czy później zjawisko heterogeniczności platform systemowych oraz środowisk aplikacyjnych. Jedną skrajnością jest wymiana niektórych systemów i ujednolicenie pozostałych; drugą - inwestowanie w platformę middleware, która połączy tę heterogeniczność. Które podejście jest właściwe i w jakich okolicznościach?

Jednym ze skutków rozwiązań zastosowanych kiedyś przy tworzeniu komputerów osobistych stało się rozmycie, klarownego przedtem, podziału na to, co należy do systemu operacyjnego i to, co jest realizowanym z jego udziałem programem. Nie jest dzisiaj ważne, w jakim stopniu jest to wynikiem prostoty ówczesnych mikroprocesorów, w jakim krótkowzroczności twórców systemu operacyjnego DOS i jego "okienkowych" następców, a w jakim przemożnej chęci utrzymania za wszelką cenę zgodności specyfikacji plików stanowiących programy, tak aby dawały się wykonywać na procesorach różnych generacji.

Wspomniane rozmycie polega na tym, że twórca oprogramowania, w zależności od potrzeb (ale i własnego widzimisię) może pojawiać się ze swym kodem po obu stronach granicy rozdzielającej system operacyjny od programu, a system operacyjny w ogóle coś takiego dopuszcza. Przykład pod tym względem pochodził - niestety - także z góry, czyli od samego twórcy tego systemu, który próbował nawet monopolizować tą drogą niektóre jego możliwości i oparte na nich rozwiązania.

Rozmycie, o którym mowa, było istotnym czynnikiem, który spowodował wykształcenie się modelu (kanonu?) "jeden komputer - jeden system". Uruchamianie więcej niż jednego systemu (aplikacji) na jednym komputerze, powszechnie praktykowane i całkiem bezpieczne na komputerach mainframe, na pochodnych od komputera osobistego serwerach zwiększało prawdopodobieństwo zawieszenia działania całości, z czego jedynym wyjściem było uruchomienie wszystkiego od nowa.

Model ten utrwalało dopasowywanie właściwości eksploatacyjnych komputerów do specyficznych potrzeb działających na nich systemów, co odbywało się w trakcie procesu zwanego strojeniem systemu operacyjnego. Swoisty wkład dalej mnożący liczbę komputerów wniosły techniki klient-serwer, gdzie komputer z bazą danych dla efektywnego działania wymagał często odmiennego "nastrojenia" niż ten, na którym działała tzw. warstwa aplikacyjna.

Na koniec swoje przysłowiowe trzy grosze dodawała sama już służba eksploatacyjna, powielając gotowy system w kilku odrębnych wersjach: produkcyjnej, zapasowej, testowej i rozwojowej. Tym sposobem jeden system wprowadzał do stosowania znaczną liczbę oddzielnych serwerów, nawet jeżeli jego wersja testowa i rozwojowa, kosztem efektywności, zostawała wciśnięta na pojedyncze komputery.

Model ten zyskał szczególną popularność w Polsce, gdzie wpływy kultury wyniesionej z komputerów mainframe były niewielkie, a ta kultura była nawet kontestowana jako rzekomy przejaw konserwatyzmu informatycznego.

Próba odwrotu - czy to da się jeszcze złożyć?

Przedstawiona sytuacja dotyczy przede wszystkim systemów zaliczanych do kategorii systemów krytycznych dla funkcjonowania jakiejś organizacji, ale to właśnie te systemy wymagają najbardziej rozbudowanych, a przez to i kosztownych środowisk. W różnych organizacjach, w zależności od ich wielkości i rodzaju działalności, takich szczególnie ważnych systemów jest od kilku do kilkunastu.

Sytuację tę dodatkowo komplikuje fakt, że środowisko działania i istniejąca architektura informatyczna organizacji to kryteria niemal w całości ignorowane przy wyborze nowych systemów. Wprowadza to kolejny czynnik podziału stosowanych środowisk, gdzie kryterium jest system operacyjny, z udziałem którego ono działa, czego dalszą konsekwencją jest odmienność rodzaju (albo chociażby tylko wersji) stosowanych baz danych, monitorów transakcji, oprogramowania zwanego aplikacyjnym i - o ile takie występuje - także portalowego (a w przypadku jego braku - innego, zaliczanego do tzw. warstwy prezentacyjnej).

W efekcie powstaje kilka potencjalnych poziomów integracji, które różnią się istotnie zarówno co do jej istoty, jak i trudności zastosowania. Sytuację taką przedstawia tabela, gdzie występują trzy różne komputery (kolumny), każdy z innym systemem operacyjnym i o innej funkcji. W tabeli tej pokazano cztery możliwe poziomy integracji: sprzętu, danych, oprogramowania aplikacyjnego i oprogramowania prezentacyjnego.

Kolumny w tabeli przedstawiają autonomiczne systemy, które w zasadzie ze sobą nie współdziałają. Zazwyczaj jednak występuje między nimi pewien zakres wymiany danych, co - przy mocno złagodzonych kryteriach - można uznać za jedyny w tym modelu przejaw integracji.

Dane?

Wspomniana wymiana danych, w najprostszym wariancie, odbywa się poprzez pliki, co jednak nie spełnia wymogów przetwarzania na bieżąco (online). W tym ostatnim przypadku stosuje się albo bezpośrednie programowe odwołania wzajemne, albo oprogramowanie pośredniczące (middleware). Oprogramowanie to ma tę przewagę nad innymi rozwiązaniami, że umożliwia tymczasowe buforowanie zarówno odwołań międzysystemowych, jak i odpowiedzi na nie, co sprzyja wyrównywaniu obciążeń uczestniczących w tym systemów i nie wstrzymuje ich działania w przypadku, gdy niektóre z nich są przez jakiś czas niedostępne. Jeszcze inną zaletą oprogramowania pośredniczącego jest umożliwianie współdziałania systemów działających w odmiennych środowiskach sprzętowych i baz danych, z jednoczesnym dokonywaniem niezbędnych konwersji danych, zmian ich formatów, sposobu kodowania itp.

Oprogramowanie pośredniczące jest popularne w dużych organizacjach, które próbują w ten sposób radzić sobie z koniecznością wymiany danych pomiędzy systemami, których liczba ciągle tam rośnie. Na ogół jednak są to rozwiązania, w których wymiana danych odbywa się punktowo w układzie "system do systemu". Rzadkie (a i tak niepełne) bywają przypadki, w których oprogramowanie pośredniczące może szerzej zaprezentować swe możliwości, występując w roli centralnego zwornika (hub), który, kontaktując się ze wszystkimi systemami, obsługuje wszystkie między nimi relacje wymiany danych, zapewniając przy tym niezbędne bufory, kolejki, transformacje, powiadomienia, potwierdzenia, obsługę błędów itd.

W sporadycznych przypadkach i ze zmiennym szczęściem niektóre duże organizacje podejmują próby tworzenia własnego oprogramowania pośredniczącego.

Aplikacje?

Zupełnie innym problemem jest integracja na poziomie oprogramowania aplikacyjnego, czyli zastępowanie szeregu małych systemów jednym większym. Działania prowadzące do takiego celu są złożone, pracochłonne, a przez to - kosztowne. W większości przypadków nie daje się znaleźć gotowego systemu o identycznych funkcjach i właściwościach, co oznacza konieczność napisania całości od nowa w nowy sposób, a to pociąga za sobą żmudny proces cyzelowania poprzez testy, co i tak nie chroni nowopowstałego systemu przed odpowiednikami chorób wieku dziecięcego.