Ostatnio, podczas nieoficjalnej przerwy kawowej, jeden z moich współpracowników zapytał mnie, dlaczego podczas prac nad systemem, który aktualnie tworzymy nie korzystamy z modelowania procesów biznesowych. Trochę mnie to zdziwiło, bo tworząc analizę, czy też projekt systemu zawsze w jakiś sposób modeluje się rzeczywistość, a dla informatyka modelowanie procesów biznesowych stanowi nieomal chleb codzienny. Modelujemy procesy - więc czegóż nam brakuje, chciałem się zapytać, lecz wtedy właśnie kolega uświadomił mnie, tkwiącego dotąd w błogiej nieświadomości o praktykach Bussiness Process Management, które zdobywają sobie coraz większą liczbę zwolenników wśród menadżerów. Mój współpracownik był zresztą w trakcie zamawiania "biblii BPM" - Business Process Management (BPM): The Third Wave z księgarni internetowej amazon.com.
   Niechcąco dowiedziałem się bowiem w jakim kierunku poszła myśl biznesowa. Procesy biznesowe, dla mnie, informatyka, modelowane jako określone interakcje pomiędzy bytami biorącymi w nich udział, zaczynające i kończące się w określonym miejscu (stanie) i zakładające równoległość podobnych działań i zarazem całkowite określenie ich kolejności wzbudziły we mnie bardzo niepolityczne skojarzenia. Zachowałem jednak trochę umiaru i miast krzyknąć "Król jest nagi" stwierdziłem: przecież to jest ... podejście strukturalne!
   Jakkolwiek by uczenie nie nazwać procesu biznesowego, to jego modelowanie w oparciu o ściśle ustalony przebieg jest niczym innym jak wyobrażaniem sobie rzeczywistości jako "wielkiej procedury", gdzie nawet, jeśli możliwe są nawroty, to także wedle ściśle określonych zasad. Każdy byt (korci mnie żeby napisać „obiekt” ale to byłoby zbyt proste), biorący udział w procesie może zrobić to, czego od niego oczekujemy i tylko to. Klasyczne podejście procedur implementujących przepływy danych jest elementem równie klasycznych metodyk strukturalnych, z którymi informatyka usiłuje się rozwieść od jakiś 20 lat. Rozwód ten by już pewnie nastąpił dawno temu, gdyby nie fakt, że jedno z podstawowych narzędzi informatyki, czyli bazy danych, rządzi się relacjami, które zdecydowanie bardziej należą do świata struktur, niźli świata klas i obiektów.
   Moja złośliwa natura już sugerowała mi, aby powiedzieć że oto menadżerzy odkryli to, do czego informatycy doszli już czterdzieści lat temu, ale aż tak złośliwy być nie chciałem. Dla mnie, człowieka młodszego o dekadę od Simuli świat składa się z współdziałających ze sobą obiektów, które pracując razem wedle jakiegoś ustalonego schematu powodują przepływ danych. Wiara w to, że obiektami można w pełni kierować, zalatuje mi się trochę z Orwellem, gdzie władza decydowała kto ma co robić. Ewentualnie innym skojarzeniem mogą być "bezduszne korporacje" (że użyjemy języka anty(alter)globalistów), gdzie niektórzy kierownicy magicznie wierzą, że dla dobrego wykonania pracy wystarczy jedynie regulamin.
   Zazwyczaj pewne wydarzenie pobudza któryś z obiektów w systemie do działania, ów obiekt przesyła komunikat drugiemu, drugi trzeciemu i tak oto rozpoczyna się wykonywanie pewnej operacji. W razie niepowodzenia którejś z czynności poprawnie zaimplementowane obiekty rozpoczną poszukiwania innych dróg realizacji celu - nawet częściowo zmieniając faktyczny tok wykonania. Im bardziej autonomiczne obiekty - tym większa szansa na powodzenie operacji, i tym bardziej chaotyczny i nieprzewidywalny jej koniec. Uznajemy, że wzajemne współdziałanie obiektów tworzy proces, i to właśnie autonomiczność obiektów czyni go elastycznym. Tymczasem nowe trendy biznesu sugerują, aby wszystko powierzać magicznemu, wszechmogącemu procesowi, którym sam swoją omnipotencją ma wszystkim kierować.
   Całość zaczyna powoli przypominać spór o to co było pierwsze: kura czy jajko? Być może próba opisania świata poprzez procedury wynika z chęci importu do ekonomii metod wypracowanych przez informatykę, a jak to zwykle bywa, interdyscyplinarni poszukiwacze wiedzy zaczynają zazwyczaj od najprostszej strony (wszak zrozumienie metod obiektowych przychodzi jednak trudniej, niźli z metodami strukturalnymi). Być może kłania się tutaj jakieś stare przeświadczenie że pracę można całkowicie opisać za pomocą magicznego workflow, a ludzie ją wykonujący staną się całkowicie wymienialni, efektywność ulegnie zwielokrotnieniu i wszyscy będą szczęśliwi. W takim podejściu można jak najbardziej dopatrzyć się analogi z metodami strukturalnymi, a najbardziej oczywistą analogią jest brak elastyczności.
   Nie chcę krytykować tak do końca modeli procesów biznesowych, a jedynie wskazać że bardzo często modelowanie rzeczywistości w ten sposób przypomina mi powrót do przeszłości. Czy czeka nas swoisty przekładaniec: modelowanie całości systemu proceduralnie, implementowanie obiektowo, zaś manipulowanie danymi - relacyjnie? Być może, biznes miał zawsze silny wpływ na informatykę. Ale czy naprawdę mamy prawo być tacy pyszni i zakładać że w kwestii procesów to my, informatycy, powiedzieliśmy ostatnie słowo? Może to właśnie ekonomiści podejmą "zapomnianą gałąź ewolucji", jaką są metody strukturalne i wprowadzą ją na nowo do panteonu stosowanych metod? Wszak BPM to rozwiązania znacznie nowocześniejsze, niż klasyczny model workflow...
   Warto przy okazji zadać sobie pytanie czy my sami nie zmierzamy w tamtym kierunku. Clemens Szyperski w swej nieco zbyt teoretycznej książce - Component Software - o przyszłości oprogramowania obiektowego pisze już o komponentach i przyszłym rynku komponentów. Co prawda jego wizja jest w większości tylko opisem jak Autor wyobraża sobie przyszłe rynki komponentów, to jednak bardzo ciekawy jest opis "kontraktu" jaki dostarczyciel komponentu zawrze z jego użytkownikiem. Kontrakt ten, to nic innego jak opis interfejsu, który traktowany być może właśnie jako umowa pomiędzy użytkownikiem a komponentem. Dziś wydaje się, że najbliżej definicji Szyperskiego są WebService'y. Podobnież bezstanowe, rozproszone, służą tak naprawdę do używania ich w innych aplikacjach. Najbardziej charakterystyczną ich cechą jest obecność dokumentu specyfikacji stworzonego w języku WSDL, który stanowi ziszczenie wizji kontraktu Szyperskiego. Faktycznym ich zastosowaniem zaczynają być aplikacje tworzone w architekturze SOA - Service Oriented Architecture, czyli systemów nawet nie tyle wielowarstwowych co... wielokomponentowych. Program, który widzi użytkownik jest najczęściej jedynie fasadą, interfejsem, który skrywa za sobą odwołania do przeróżnych, rozproszonych komponentów.
   Tworzenie aplikacji w architekturze SOA pociąga za sobą między innymi konieczność zmiany przyczajeń - powinniśmy zacząć myśleć nie o systemach orientowanych na przepływy sterowania, a na przepływy wiadomości (oczywiście w formacie XML). W tworzeniu tego typu rozwiązań warto bowiem (jak sugeruje Jeffrey Hasan w książce Expert Service-Oriented Architecture in C#: Using the Web Services Enhancements 2.0 będącej ciekawym wprowadzeniem do rozszerzeń Web Services Enhancements 2.0) zacząć od dokładnego określenia wiadomości wymienianych pomiędzy komponentami systemu. Warto dokładnie opisać zawartość każdej wiadomości i ustalić pomiędzy jakimi komponentami ma być ona przekazywana.
   Pomimo, że wiadomości opisane są jako klasy, a diagram je obrazujący jest diagramem języka UML, to nikt nie ma wątpliwości, że schemat zyskałby, gdyby owe wiadomości zastąpić krótkim tylko opisem ze strzałką a komponenty systemu narysować nie jako kwadraty, a jako kółka. W ten sposób kółka komponentów byłyby łączone ze sobą strzałkami opisanymi jako wiadomości. Schemat nowoczesnej architektury SOA stałby się wtedy klasycznym diagramem DFD, opisującym całkowicie strukturalną wymianę danych, pomiędzy procesami...
   Czyli co, wraca stare?
MB

Polemikę do tego tekstu można znaleźć tutaj