Niedawno podczas jednej z ciekawych rozmów w gronie specjalistów IT pojawiła się hipoteza, jakoby UML i BPMN to relikty dawnych czasów, przydatne w pracy w systemach monolitycznych i nieprzystające do czasów obecnych: mikrousługowych, heksagonalnych, omnichanellowych. Że obecnie dokumentuje się przy kodzie (opisane słownie, w zakresie adekwatnym do potrzeb) i tego oczekuje dewelopment. Hm.

Dokumentacja (czy to robiona w UML, BPMN, czy pisana językiem naturalnym) w rzeczywistości jest wtórnym produktem tego, co robi analityk. Sednem pracy analityka jest „analiza”, czyli zidentyfikowanie i zrozumienie problemu, stworzenie koncepcji rozwiązania i zestawienie go z problemem, wnioskowanie oraz stworzenie projektu rozwiązania. Patrząc zarówno na problem biznesowy jak i projekt rozwiązania oraz ich naturę, oba aspekty przejawiają cechy SYSTEMU. SYSTEMEM jest ujęty w obiekt fizyczny bądź abstrakcyjny zbiór elementów powiązanych ze sobą i wpływających na siebie, wspólnie realizujących określone funkcje nadrzędne. Analityk pracuje więc nad SYSTEMEM, który jest dziedziną problemu i SYSTEMEM którym jest projekt rozwiązania. Wieloelementowym, powiązanym wewnętrznie tworem.

Jeśli celem jest stworzenie samej dokumentacji tylko dla spełnienia formalnych wymagań organizacji bądź „dla potomnych”, wówczas zespół może traktować ją jako przykry obowiązek (w jakiejkolwiek formie nie byłaby pisana). Cel jej użycia i sposób skorzystania z niej nie będzie przez zespół doceniany. Wówczas UMLe i BPMNy są dodatkowym nakładem pracy (trzeba ich się nauczyć, zrozumieć i jeszcze stosować równo w organizacji). Dlatego słowo pisane jest uznawane za lepsze, bo zapewnia dowolność – niski koszt wejścia. A jeśli jeszcze odbiorcy takiej dokumentacji nie mają sprecyzowanych wymagań co do jej charakteru, możliwości ponownego użycia, wówczas mogą otrzymywać tak naprawdę cokolwiek.

Jeśli natomiast celem użycia UML i BPMN jest model analityczny jako platforma projektowania i komunikacji tego projektu, wyprzedzający prace wytwórcze (lub inaczej – wspierający je), czyli stworzenie abstrakcyjnego uproszczonego opisu rzeczywistości i projektu rozwiązania, a następnie systematyczny jego rozwój i analiza wpływu jednych zmian na drugie, wówczas będzie inaczej. Model taki posiada cechy systemu: będą cele, ograniczenia i ramy wytwórcze dla tworzonej inicjatywy, procesy powiązane z produktami, wymagania powiązane z procesami (bo z nich wynikające), projektowane funkcje systemowe i ich realizacja powiązana z procesami i wymaganiami, struktury danych powiązane z opisem przebiegu funkcji, model infrastruktury informatycznej, sposobu komunikacji i samych komunikatów inicjowanych przez procesy i funkcje… Problem takiego modelu i jego złożoności skomplikuje się jeszcze bardziej, jeśli korzystać się z niego będzie w modelu przyrostowym/ w częstych zmianach, iteracjach (sprintach?), gdzie analizę, dewelopment i testy prowadzi się tylko dla wycinka produktu osadzonego w skomplikowanym świecie i ważna jest regularna ocena wpływu wsparta narzędziem. Czy opisywanie tak złożonego świata w bardzo sposób uproszczony, płaski i rozproszony (np. deponując dokumentację przy kodzie) będzie efektywny do zarządzenia zmianą? Bez kontroli powiązań na poziomie koncepcji całego rozwiązania i jeszcze umiejętności zwizualizowania tej pajęczyny. Dlaczego zatem odrzuca się model na rzecz płaskiego rozproszonego opisu elementów, bez ujęcia ich „z góry”? Hipoteza postawiona na początku powinna dotyczyć więc nie staromodności samej notacji UML, BPMN, czy dowolnej innej, a sensowności modelu jako takiego.

Możemy oczywiście tylko kodować i nie skupiać się na analizie. Po prostu w sposób ciągły prowadzić eksperymenty, weryfikować ich wpływ i modyfikować tak, aby było optymalnie. Przy tym tylko rozmawiać, bo to efektywne. Projekt rozwiązania nie będzie potrzebny, bo pomysł od razu zostanie zaimplementowany w kodzie. Dokumentacja nie będzie potrzebna, bo najlepszą dokumentacją jest kod. Analityk nie będzie potrzebny, bo z jednej strony zespół pogada z klientem, z drugiej od razu zaimplementuje i sprawdzi, i skoryguje. Znów powiem: hm. Koncepcja świetna w założeniach o ile wytwarzam prosty (informatycznie) produkt, niepowiązany z innymi oraz realizuję prosty problem biznesowy. Im infrastruktura komplikuje się, tym rośnie potrzeba przemyślenia i zaprojektowania, a tym samym skomunikowania się z innymi. Druga rzecz to eksperymenty. Często o nich słyszę, nawet Spotify chwali się tym, że nie planuje i nie zobowiązuje się do terminów, zamiast tego eksperymentuje. Niestety model Spotify wdrażany jest szeroko w firmach, natomiast oczekiwania względem terminów pozostają. Czy zatem jest tu jakieś miejsce dla eksperymentowania i korygowania błędów na bieżąco? Przydałaby się więc może jakaś analiza, żeby ograniczyć eksperyment i przemyśleć koncepcję… Po trzecie, koszt zrozumienia wpływu zmiany przy takim sposobie pracy to koszt analizy deweloperskiej. Przychodzi nowe wymaganie, rozmawiam i korzystam z doświadczenia innych deweloperów (muszę oszacować wpływ zmiany na już wytworzone oprogramowanie i zidentyfikować potencjalne miejsca zmian/ rodzaje zmian; gorzej jak specjalista odszedł do innego bardziej intratnego projektu i wiedzy nie mam) i analizuję kod (aby oszacować rodzaj zmian, skalę, typy danych itp) i to często w wielu miejscach (zmiany w jednym miejscu implikują bowiem zmiany w innych). Muszę więc uzgadniać (rozmawiać) z wieloma osobami. Sama rozmowa jest naprawdę ok. Skraca ścieżkę załatwienia sprawy i oczekiwania na odpowiedź. Sama rozmowa jest jednak niedoskonała, bo usłyszane informacje przetwarzane muszą być na wyobrażenie o rozmawianiem temacie, które to wyobrażenie może różnić się między sobą u wszystkich rozmówców. Rysunek/ model może to sprowadzić do wspólnego mianownika. Niestety pominięcie modelu kończy się na długich konsultacjach, interpretacjach i konsyliach deweloperów wpatrzonych w jeden ekran i dyskutujących nad logiką rozwiązania w oparciu o kod. Zamiast na prostszym do zrozumienia i analizy rysunku, który odwzorowuje skomplikowany kod. A do tego należy pamiętać, że wiele zależności jest na poziomie kodu ukrytych i wychodzi dopiero na etapie testów albo na produkcji. Cóż, eksperymentujemy.

I jeszcze jedna kwestia. Zwykle w inicjatywach (które się udają), myślenie wyprzedza działanie. Oznacza to, że muszę przetworzyć w głowie i zestawić wiele faktów, dokonać syntezy, wygenerować pomysł i wdrożyć go w postaci kodu. Im problem jest bardziej skomplikowany, im więcej elementów muszę przewidzieć, tym mam większą potrzebę wesprzeć się czymś. Model wydaje się być naturalnym kandydatem do tego celu. Pozwala dogadać się zespołowi na poziomie danych, struktur, typów i powiązań (np. model klas), funkcji i zależności (model przypadków użycia), powiązań między komponentami i systemami a nawet światem zewnętrznym. I to na abstrakcyjnym, zjadliwym dla człowieka rysunku przedstawiającym skomplikowaną rzeczywistość. Co więcej. Nie znika, a zostaje „dokumentując” zmianę na kolejny przebieg, do skorzystania przez zespół. Przy okazji. Taka jego natura.

Tyle na razie o modelu, o niego tak naprawdę chodziło. Wróćmy na koniec do UMLi i BPMNów, czyli początkowej hipotezy, że są to nieużyteczne już w dzisiejszych czasach notacje. UML jako język zunifikowany daje jednoznaczność oznaczeń, możliwość czytania i jednakowej interpretacji przez wszystkie strony. Czy jednoznaczność przeminęła i jest niepotrzebna w „nowym świecie” dewelopmentu? UML układa opis analityczny w określonym porządku i pozwala planować i analizować wiele wymiarów (dane, funkcje i ich przebiegi). Czy nowy świat nie dzieli problemów rozwiązywanych w wytwarzaniu oprogramowania na dane i logikę rozwiązania? UML wprowadzając rysunek jako formę komunikacji przyspiesza rozumienie problemu i pozwala szybciej uchwycić logikę, potencjalne niespójności itp. Czy szybsze zrozumienie problemu i jego analiza nie jest już w cenie? UML ze względu na rysunkowy i obiektowy charakter notacji pozwala w narzędziach CASE wiązać określonymi relacjami dowolne powiązane aspekty: elementy, obiekty, diagramy itp. Czy panowanie nad złożonością i śledzenie powiązań przed wykonaniem oprogramowania i weryfikacja, że może nie zadziałać bo nie pomyśleliśmy, przestała się liczyć? BPMN pozwala jednoznacznie opisywać przebiegi procesów biznesowych, które i w starym i nowym świecie istnieją i będą istnieć. UML i BPMN ponieważ nie narzucają metodyki pracy, mogą być elastycznie wkomponowane w organizację jako języki opisu zmian. Czy elastyczność też jest już nie ważna? A może chodzi o nadmiar pracy? Bo oprócz kodowania, korzystając z UML i BPMN należy jeszcze rysować; można by tak przecież tylko kodować… Czy analiza (myślenie) przestało wyprzedzać kodowanie?

Pytanie zatem czy to UML i BPMN się przeterminował, czy chodzi o coś innego? Czy słowo pisane (gdziekolwiek nie byłoby deponowane) uzyskało przewagę nad językami stworzonymi do opisu systemów? Czy może przeterminowała się sama koncepcja tworzenia modelu? A może rozmowa i dokumentowanie kodu zastąpi albo już zastąpiło analizę?