Nawet sami producenci monolitycznych systemów zintegrowanych dochodzą do wniosku, że nie tędy droga. Co jednak dostaniemy w zamian? Czy będzie to otwarta architektura składająca się z wielu specjalistycznych aplikacji różnych producentów? Otóż niekoniecznie.

Coraz więcej firm decyduje się na silne ujednolicenie aplikacji biznesowych, wychodząc z założenia, że systemy pochodzące od jednego dostawcy będą najlepiej zintegrowane. Jest to niestety myślenie życzeniowe. Po pierwsze, w perspektywie najdalej dwóch lat od wdrożenia żaden system zintegrowany nie zapewni firmie 100% interesującej jej funkcjonalności. Po drugie, w dobie przejęć i fuzji myślenie w kategoriach ścisłej integracji przynosi w sumie więcej szkody niż pożytku. Co można z tym zrobić w praktyce i czy na pewno SOA jest najwłaściwszym z właściwych podejść do problemu?

Kilka uwag na początek

Oczekiwanie, że system informatyczny uporządkuje procesy biznesowe, jest tylko częściowo uzasadnione. Owszem, jest to możliwe, ale tylko wtedy, gdy wdrażający wiedzą, co działa niewłaściwie i jak powinno działać docelowo. To wdrażający mają wiedzieć i określić, jak system ma działać. Sytuacji, gdy to system steruje biznesem, tak jak ma to wpisane w ustawieniach domyślnych, a nie tak jak to świadomie określili wdrażający, nie można nazwać właściwą.

Definiowanie procesów wedle uznania wdrażających prędzej czy później prowadzi do konieczności tworzenia zmian programistycznych. W przypadku dużych systemów może to polegać na modyfikacji już istniejącej funkcji, niemniej może się okazać, że z uwagi na założenia przyjęte wcześniej przez producenta systemu modyfikacji nie da się wykonać relatywnie tanio, a być może nawet w ogóle. W takiej sytuacji klient zwykle wybiera pójście na kompromis i akceptuje np. to, że pewne informacje będą powielane "ręcznie".

Czasami też zdarza się, że firma skupia się na jednym, kluczowym module (zwykle finansowym), a resztę funkcjonalności traktuje na zasadzie "jakoś to będzie". Jeden dział, a czasem jedna osoba, zwykle sponsor projektu (dyrektor finansowy), będzie zadowolony, zaś pozostałe grupy będą posiłkować się rozwiązaniami "rzeźbionymi" za pomocą makr i arkuszy kalkulacyjnych. Niestety nie są to przypadki odosobnione.

Często zdarzają się także błędy związane z brakiem zrozumienia dla ergonomii. Interfejs portalowy jest wygodny do przeglądania informacji, ale do ich wprowadzania (np. faktury) czy analiz - raczej niekoniecznie. Gdy wprowadzanie danych do aplikacji ma być częste i ma dotyczyć większości użytkowników, zwykle stosuje się dedykowane, "ciężkie" aplikacje klienckie. Ale tu również nie ma reguły, bo może się okazać, że dane wprowadzane są w większości przypadków offline, np. za pośrednictwem aplikacji PIM czy Outlooka, który kopiuje je do centralnej aplikacji CRM... Z drugiej strony, portal wspierany jakimś mechanizmem wyszukiwania pełnotekstowego jest chyba jedynym sensownym narzędziem do zgromadzenia dokumentów.

W krainie SOA

Definicji architektury SOA (Service Oriented Architecture) jest tyle, ile osób, które o niej słyszały. W zarysie jest to architektura, w której każdy moduł odpowiada za jasno określony zakres operacji zgodnie z określonym kontraktem zapisanym w pliku XML. Taki kontrakt obejmuje nie tylko format danych, ale także operacje, jakie można wykonać w docelowym systemie. Każda usługa SOA jest autonomiczna - do jej działania wystarczy to, co spłynie do niej od innych usług zgodnie z kontraktem, a nie np. informacja, która znajduje się w globalnej zmiennej przypisanej do sesji. Dodatkowo występuje jeszcze wymóg, by usługa definiowała "zasady zgodności", czyli w jaki sposób obsługiwani są klienci usługi używający starszych wersji kontraktu.

Taki sposób konstrukcji aplikacji wymaga zupełnie innego myślenia o systemie niż budowanie silnie zintegrowanych aplikacji-monolitów. Po pierwsze, usługa jest samodzielnym bytem, który można wpleść w pewną całość (system) za pomocą określonego kontraktu. Nie pisze się więc modułu SCM, tylko np. usługę zajmującą się zleceniami przewozu towaru. Równocześnie takie ujęcie systemu informatycznego pozwala w większym stopniu "porozumieć się" z biznesem - firma jest w stanie opisać etapy składające się na dany proces, co pozwala wyróżnić poszczególne usługi. Pierwszym etapem w planowaniu systemu zgodnego z architekturą SOA, np. przy użyciu narzędzi BPM, jest wyrażenie wszystkich procesów na wysokim poziomie abstrakcji.

Usługi SOA mogą działać w firmowej infrastrukturze IT, albo poza nią. Dla aplikacji zgodnej z tym modelem jest całkowicie obojętne, o ile zachowane zostaną założone parametry wydajnościowe. W tym wypadku powstaje pytanie o dostępność, bo jeśli coś co jest poza kontrolą firmy nie działa, oznacza to niedostępność aplikacji. Z punktu widzenia szybkości reakcji na nieprzewidziane problemy, posiadanie wszystkich usług lokalnie wydaje się rozsądne.

Dobrym przykładem są tu ostatnie problemy firmy Salesforce.com, udostępniającej online rozwiązanie CRM. Gdy jej system stał się na kilka godzin niedostępny, większość klientów nie miała żadnej alternatywy i musiała wstrzymać pracę, ponieważ ich systemy były uzależnione od możliwości wywołania zdalnych funkcji API. Umowa SLA, obejmująca gwarancję dostępności rzędu 99%, oznacza zgodę na brak dostępności przez trzy i pół dnia w roku, 99,9% - ok. 8 h, a 99,99% - ok. 51 min. Niby mało, ale to może być najbardziej "krytyczne" 8 h czy 51 min, np. tuż przed zakończeniem promocji czy innego istotnego wydarzenia z punktu widzenia biznesu.

Wydaje się, że można było tego uniknąć przez właściwą konstrukcję systemu. Routing komunikatów między usługami w SOA może wykorzystywać mapowanie na konkretne adresy IP, albo na przestrzeń nazw, w ramach której jednej nazwie odpowiada wiele równorzędnych usług. Gdy jedna nie działa, transakcja może zostać wykonana przez inną instancję. Wirtualizacja może zostać wykonana na różne sposoby, przez równoważenie obciążeń, przez wirtualizację adresów IP, przez klastrowanie lub poprzez definiowanie usług jako zwielokrotnionych, jak ma to miejsce w rozwiązaniach Sonic Software.