Aplikacja BPM to funkcjonalność w całości oparta o proces BPM zdeployowany na platformie BPM.
Aplikacja Customowa to funkcjonalności w całości oparta o wybrany framework developerski.
Paradoksalnie owa różnica wynika z największej zalety BPM, jaką jest elastyczność.
Gdy piszemy aplikację customową, to następuję wyraźny rozdział pomiędzy formą a treścią.
Forma ukryta jest w kodzie, treść zapisana jest w bazie danych.
Tak osiągnięta niezależność sprawia, że można zmieniać formę bez wpływu na historyczne dane.
Dzięki czemu zmiana wynikająca ze dynamiki zakresu, czy też zmiana wynikająca z naprawy błędu,
ma niewielki wpływ na już zgromadzone dane.
Powyższa obserwacja może kłócić się z pojęciem testów regresji.
Jednak:
"Regresja – zjawisko niezamierzonej utraty jakiejś funkcjonalności powstałe w nowej wersji programu i zwykle skutkujące komunikatem o błędzie lub brakiem działania. Do regresji dochodzi wskutek wprowadzania zmian w jakiejś części kodu programu. Skutkiem tych zmian jest błędne działanie innej funkcji programu, która w poprzednich wersjach działała prawidłowo."
Zatem regresja dotyczy tylko formy.
Inaczej jest w aplikacjach BPM. Tutaj forma i treść zawarta jest w instancji procesu. Można by powiedzieć, że 200 instancji to 200 aplikacji customowych. Nawet gdy obiekt biznesowy utrzymujemy w zewnętrznej bazie danych, to kluczowe informacje BPM, czyli maszyna stanów zawarte są w instancji.
Można tego uniknąć, poprzez stosowanie krótkich procesów kartotekowych, czyli takich które sterują odczytem i zapisem w zewnętrznej bazie danych, czyli przenieść maszynę stanów poza BPM, tylko po co wtedy stosować BPM?
No i dochodzimy do wspomnianego w tytule dramatu, którym jest migrowanie instancji procesów.
Gdy używana platforma BPM tego nie oferuje, to przy każdej zmianie, stajemy przed krytyczną decyzją:
Jak dokończyć trwające instancje procesów, jak w procesie jest błąd techniczny lub biznesowy?
Mamy dwie opcje:
1. Zamykamy instancje i zmuszamy użytkowników do ponownego uruchomienia procesu w nowej wersji (wzrost czarnego PR gwarantowany)
2. Piszemy aplikację customową, która po kolei każdą instancję skopiuje do nowszej wersji procesu z użyciem API REST (lub zrobi to administrator ręcznie w ramach konserwacji)
Oczywiście Vendorzy BPM zauważyli ten problem i tworzą mechanizmy migracji, ale nie potrafią one:
1. Zmienić danych w migrowanej instancji
2. Zmienić przebiegu w tej części instancji, która jest historyczna
3. Gubią się, gdy usuniemy lub przesuniemy zadanie, w którym oczekuje instancja
Prędzej niż później aplikacja BPM wymaga opracowania mechanizmu migracji w modelu BPM (a nie na platformie BPM), który wesprze i uzupełni wbudowane w platformę BPM mechanizmy migracji, tak by było możliwe skopiowanie instancji z jej historią, obiektem biznesowym oraz dokonanie w nich stosownych wymaganych przez nową wersję zmian.
Jeżeli tego nie zrobimy, każda zmiana stanie się koszmarem, którego i Biznes i Wykonawca będą za wszelką cenę unikać, a patos elastyczności stanie się praktycznym mitem.
