Tags: BPMS, ESB, platformy integracyjne, platformy SOA, SOA

W poprzednich artykułach pisałem o rzeczach ważnych, na które należy zwracać uwagę w trakcie wyboru narzędzi do budowy platformy SOA w przedsiębiorstwie. Teraz natomiast chcę powiedzieć kilka słów o rzeczach nieważnych, na które uwagi zwracać nie należy. Dlaczego chcę pisać o rzeczach nieważnych? Ponieważ podchodząc pierwszy raz do tematu najczęściej nie mamy wyrobionego zdania odnośnie tego co jest istotne, a co jest tylko gadżetem.  Sprawa oczywiście nie jest prosta i jednoznaczna (z resztą jakże mogło by paść coś innego z ust konsultanta?), bowiem ważność danej cechy zależy od kontekstu jej użycia. Ale już do rzeczy — przed czym chcę ostrzegać.

Pierwszą cechą nadużywaną marketingowo są graficzne narzędzia do definiowania logiki integracyjnej. Uzasadnieniem używania takich narzędzi jet to, że proste czynności integracyjne, takie jak mapowanie dwóch dokumentów, czy proste definicje routingu rzeczywiście można w elegancki sposób zaprezentować graficznie i w takiej postaci je edytować. Mapowanie to przecież sieć powiązań między dwoma strukturami, więc najłatwiej jest łączyć odpowiadające sobie elementy na zasadzie ich wskazywania w strukturze, a wizualizować poprzez “kreskę” pomiędzy nimi. Podobnie z routingiem: przecież to proste drzewo decyzyjne, gdzie rozgałęziamy przebieg naszego przepływu danych. Z czasem jednak okazało się, że tak proste definiowanie logiki integracyjnej jest niewystarczające. Osobom programującym zaczyna brakować siły wyrazu języków programowania: pętli, obsługi wyjątków, grupowania kodu. W naturze spotyka się więc dwa rozwiązania tego problemu: przez dodanie odpowiednich nowych konstrukcji programistycznych w naszym graficznym “kodzie” lub przez ułatwienie “wyjścia” dla takich przypadków do kodowania w znanym języku, np. w Javie. “Zwykłe” języki programowania są bowiem efektem trwającego wiele lat procesu myślowego i doświadczeń pokoleń informatyków. Wygoda używania wyjątków, dziedziczenia, ograniczania zasięgu obowiązywania zmiennych — to wszystko należy do kanonu warsztatu programisty i pozwala na sprawne pisanie kodu, oraz jego czytanie przez innych ludzi niż autor. Tymczasem pismo obrazkowe często rezygnuje z wspomnianych tutaj cech.

Graficzne narzędzia do tworzenia kodu integracyjnej są jednak bardzo często pokazywane na prezentacjach jako szczyt myśli technicznej. I rzeczywiście, w ramach piętnastominutowego pokazu prezentuje się bardzo dobrze. Pokazanie na slajdach algorytmu w postaci kwadratów połączonych liniami prezentuje się dużo korzystniej niż napisanie kilkunastu linijek kodu. Jednak w życiu okazało się, że dobry edytor tekstowy kodu ma zdecydowanie większą przewagę, nad płachtą obrazków. Łatwiej się wyszukuje fragmentów kodu, łatwiej się robi globalne zmiany (np. nazw struktur danych). Operowanie na tekście będzie oczywiście łatwiejsze, o ile nasz kod integracyjne będzie miał skomplikowane konstrukcje, a nie będzie się sprowadzał do prostego przerzucania komunikatów.

Druga cecha robiąca furorę na prezentacjach, to przedstawianie przebiegu procesów biznesowych. Jako wielkie osiągnięcie pokazane jest, jak można na diagramie wskazać węzły, przez które już przeszło przetwarzanie, czy te w których wystąpił błąd. A wszystko z piękną grafiką, zielonymi “ptaszkami” potwierdzenia, czy czerwonymi wykrzyknikami błędu. Piękne. Tylko do czego tego będziemy używać? Jeżeli do integracji, to mamy tu kompletną pomyłkę i pomieszanie pojęć. Silniki procesów biznesowych są dedykowane dla przetwarzania długotrwałego, więc budowanie na nich usług mija się z celem (pod względem wydajności, zasobożerności, adekwatności narzędzia…) Tym bardziej, że dla krótkich usług to raczej będziemy “łapać” tylko  ślad wykonanej ścieżki, a nie w trakcie jej wykonywania. Możemy oczywiście dać te narzędzia “biznesowi” do kontroli długotrwałych procesów. Trzeba jednak pamiętać o czającej się pułapce: może się okazać, że prezentowany poziom abstrakcji jest zdecydowanie za niski — kroki “techniczne” będą niezrozumiałe np. dla odbiorców z Call Center. I zamiast kompetentnie wyjaśnić klientowi “co się takiego dzieje z moim zamówieniem!!??!” dostanie on odpowiedź “prosimy o cierpliwość, mamy problemy z naszymi systemami komputerowymi”.

A co z wykorzystaniem tych narzędzi dla specjalistów zaś (deweloperów czy administratorów)? Dużo ważniejsza dla nich będzie ergonomia narzędzi do wyszukiwania zadań błędnych czy do ich ponownego uruchomienia (po usunięciu skutków awarii). A te są o wiele mniej efektowne na prezentacji od “zielonych piłeczek turlających się po procesie”.

Wreszcie trzecia rzecz, na którą radzę zwracać pilną uwagę, to zestawy gotowych adapterów. Dopóki nie wchodzi się w istotę budowy rozwiązań integracyjnych, to bardzo zachęcająco brzmi informacja o adapterach do posiadanego przez nas systemu billingowego czy CRM. Prawda jest jednak taka, że bardzo często te nasze systemy nie są wdrożeniami “z pudełka” lecz dopiero po zastosowaniu odpowiednich przeróbek i dostosowania do specyficznych wymagań naszego przedsiębiorstwa. Dlatego dostarczane adaptery nie udostępniają pełnej wymaganej funkcjonalności. Zaraz okazuje się, że zestaw usług jest niekompletny, lub serwuje niepełne dane. I na koniec musimy i tak wykorzystać adaptery technologiczne (JDBC, JMS, HTTP, …) tworząc sami usługi dostępu do systemu.

Wymieniłem trzy najczęstsze “wabiki marketingowe”, ale oczywiście może ich być zawsze więcej — w końcu ograniczeniem jest tylko wyobraźnia i pomysłowość sprzedawców. Musimy więc ostatecznie być bardzo czujni i jeśli to tylko możliwe, to przed dokonywaniem wyboru popróbować trochę. Wykonajmy sami np. jeden, realistyczny, ale niebanalny przykład integracji z własnego podwórka.