Zdarzyło mi się uczestniczyć ostatnio w dyskusji o kierunkach rozwoju zawodowego analityka. Dyskusja, jak to dyskusja na forum internetowym, nie doprowadziła do żadnych sensownych wniosków, tylko swobodnie odpłynęła. Jednym z kierunków, którym podążyli dyskutanci, były rozważania o wyższości BPMNa nad UML (a właściwie nad czymkolwiek innym). BPMN jest ostatnio w modzie, więc szybko ujawniła się grupa wiernych fanów i kibiców, rzucająca całą litanią zalet tego języka. Dziwnym trafiem prawie wszystkie brzmiały bardzo podobnie do marketingowych haseł, reklamujących BPMNa w różnego rodzaju whitepaperach. W szczególności spodobała mi się takie hasło:
BPMN jest łatwy, prosty i intuicyjny. Każdy go rozumie.
Czyli bierzemy pierwszego lepszego człowieka z ulicy (dobra, niech będzie – dowolnego klienta dla którego robimy system informatyczny), rzucamy mu dowolny diagram BPMNa z procesami, a on na to: "Aha – tak o to chodzi, ten proces idealnie obrazuje wszystkie niuanse naszego sposobu pracy". BPMN odwalił za nas całą robotę – narysowaliśmy diagramik i wszystko już dla każdego jest jasne i oczywiste: doskonałe zrozumienie wymagań i oczekiwań klienta, doskonałe i pełne zrozumienie produktu który wykonawca dostarczy. Analityczna nirvana.
Na pierwszy rzut oka, wszystko się niby zgadza – diagramy BPMN składają się z banalnych prostokątów, rombów, kółek i strzałek. Strzałka wychodzi stąd a wchodzi tam, prostokąty mają słowne opisy. To w zasadzie całość BPMNa – wygląda na to, że jest faktycznie pięknie, prosto i zrozumiale. Tyle że, gdy przyjrzymy się bardziej dokładnie i spróbujemy na poważnie używać tej notacji to zauważymy niuanse, które decydują o sile BPMNa- strzałki reprezentują dwa (w zasadzie trzy) rodzaje przepływów, kółka reprezentują kilkanaście możliwych rodzajów zdarzeń, prostokątów też jest kilka typów, podobnie. Łącznie – ponad sto symboli. I tu tkwi problem z powyższym twierdzeniem – zrozumienie znaczenia poszczególnych symboli, ale przede wszystkim zrozumienie co oznaczają użyte razem.
BPMN. jak każdy inny język, jest zbudowany z dwóch elementów – gramatyki i semantyki. Gramatyka określa, ogólnie rzecz biorąc, sposób powiązania składników języka ze sobą, czyli to jak mogą zostać użyte w konstrukcjach językowych. W przypadku BPMNa gramatyka jest w miarę prosta – sprowadza się do zdefiniowania rodzajów symboli graficznych oraz określenia możliwych powiązań między nimi – czyli jakie symbole są dostępne, w jaki sposób można je łączyć ze sobą oraz w jakim kontekście mogą zostać użyte. Ta część jest faktycznie prosta i intuicyjna, choć już na tym poziomie pojawia się kilka niuansów, na przykład użycie Sequence Flow w kontekście Line oraz Pool. Jednak, w zasadzie każdy kto miał już wcześniej styczność z jakąkolwiek notacją opisu sekwencji czynności/algorytmów, będzie w stanie odczytać konstrukcje w BPMN. Inną sprawą jest jednak zrozumienie takiej konstrukcji. Tu wkracza semantyka. Semantyka definiuje znaczenie poszczególnych symboli, określa jak będą interpretowane lub jakim pojęciom, obiektom rzeczywistym odpowiadają. W skrócie mówiąc – pozwala na zinterpretowanie konstrukcji gramatycznej (diagramu w tym wypadku). I tu leży podstawowy problem dotyczący stwierdzenia z początku tekstu. W mojej opinii reklamowy tekst o "intuicyjności" BPMNa rozbija się o złożoność semantyki tego języka. Nikt, kto nie zna szczegółów interpretacji poszczególnych symboli nie zrozumie szczegółów procesów. Nie będzie w stanie dostrzec różnicy między rombem z X a rombem z + w środku, a różnica między nimi jest znacząca.
Wszystkie składniki diagramów BPMN a także ich wzajemne powiązania mają swoje znaczenie i tylko odpowiednie ich zastosowanie ma sens. Nie da rady ich wrzucić ot tak sobie dowolnie[1. tzn da radę, narzędzie do modelowania pozwoli na wszystko, ale jeżeli ma jeszcze wbudowany walidator, to już nie będzie tak pięknie i tenże będzie się burzył]. Można oczywiście poluzować reguły stosowania BPMNa, nie przywiązywać wagi do specyfiki jego symboli, albo po prostu przestać używać innych rodzajów symboli poza kilkoma podstawowymi (zdaje się siedmioma) i najprostszych konstrukcji. Jednak – po co właściwie wtedy używać takiego języka? Wszystkie zalety zostają wtedy właściwie zignorowane. Wtedy faktycznie twierdzenie o "intuicyjności" BPMNa będzie prawdziwe, tyle że sprawdzi się tylko w trwialnych zastosowaniach.
Na koniec – skąd taki właśnie tytuł? Pythoni mieli bardzo dobry przykład: Rozmówki węgierskie.