Eximee Team
Wsparcie dla Camunda 7 Community Edition zakończyło się w październiku 2025 roku wraz z wydaniem wersji 7.24 – od tej pory system nie otrzymuje poprawek bezpieczeństwa. Dla banków i ubezpieczycieli w Unii Europejskiej to poważny problem: rozporządzenie DORA, obowiązujące od 17 stycznia 2025 roku, zakazuje utrzymywania krytycznych procesów na oprogramowaniu bez aktualizacji CVE. Migracja na Camunda 8 wymaga jednak przebudowy architektury na rozproszony silnik Zeebe i akceptacji licencji source-available. EximeeBPMS to alternatywa skrojona na potrzeby branży finansowej utrzymująca architekturę silnika osadzonego oraz pełną licencję open source Apache 2.0/MIT – bez konieczności migracji architektonicznej.
Co warto wiedzieć:
Chcesz poznać szczegóły techniczne? Sprawdź dokumentację EximeeBPMS, gdzie znajdziesz pełny opis silnika, API i migracji z Camunda 7.
Koniec wsparcia dla Camunda 7 CE dotyczy każdej branży, ale w sektorze finansowym ma dodatkowy, regulacyjny wymiar. Od 17 stycznia 2025 roku w Unii Europejskiej w pełni obowiązuje DORA (Digital Operational Resilience Act) – rozporządzenie, które wprost obejmuje banki, ubezpieczycieli, firmy inwestycyjne i pozostałe podmioty finansowe wymogiem zarządzania ryzykiem ICT, w tym ryzykiem związanym z dostawcami technologii. DORA nakłada m.in. obowiązek prowadzenia rejestru umów z dostawcami ICT, oceny ryzyka koncentracji u pojedynczego dostawcy oraz posiadania strategii wyjścia (exit strategy) z takiej relacji.
W tym kontekście silnik procesowy, na którym opiera się krytyczna infrastruktura banku czy ubezpieczyciela, przestaje być wyłącznie decyzją technologiczną zespołu IT – staje się elementem oceny ryzyka operacyjnego, którą trzeba udokumentować i uzasadnić przed audytem czy regulatorem. Utrzymywanie systemu opartego na zarchiwizowanym, niewspieranym już kodzie (Camunda 7 CE) jest z perspektywy DORA trudne do obrony. Ale wybór kolejnego kroku – pełna migracja na Camunda 8 czy ścieżka ewolucyjna – powinien być świadomą decyzją architektoniczną, nie automatycznym wyborem “nowszej wersji tego samego dostawcy”.
| Cecha istotna dla sektora finansowego | EximeeBPMS | Camunda 8 | Dlaczego to ma znaczenie w regulowanym środowisku |
|---|---|---|---|
| Silnik osadzony (embedded engine) w aplikacji JVM | Tak | Nie | Wspólna transakcja ACID między logiką biznesową a stanem procesu ułatwia audytowalność i spójność danych w procesach kredytowych, reklamacyjnych czy KYC. |
| Standardowa relacyjna baza danych dla danych operacyjnych | Tak | Częściowo | RDBMS daje przewidywalność, spójność transakcyjną i możliwość archiwizacji danych operacyjnych zgodnie ze znanymi zespołom bezpieczeństwa politykami. Wsparcie RDBMS w Camunda 8 pojawiło się dopiero w wersjach 8.8/8.9 jako alternatywa dla ES/OpenSearch i wciąż dojrzewa. |
| Pełna licencja open source (zgodna z definicją OSI) | Tak (Apache 2.0 / MIT) | Nie | Camunda License v1 (dawniej Zeebe Community License) jest przez samą Camundę opisywana jako “source-available”, nie open source – to różnica istotna przy ocenie ryzyka dostawcy pod DORA. |
| Narzędzia operacyjne darmowe na produkcji | Tak | Nie | Od wersji 8.6 cała dystrybucja Self-Managed, łącznie z Zeebe, wymaga klucza licencyjnego na produkcji – koszt utrzymania trzeba uwzględnić w budżecie operacyjnym, nie tylko projektowym. |
| Wdrożenie w chmurze / wsparcie Kubernetes | Tak | Tak | Oba produkty można wdrożyć w środowisku chmurowym z orkiestracją Kubernetes - sama chmura nie jest tu obszarem jednoznacznej przewagi; decyduje architektura konkretnego wdrożenia. |
| Model zdarzeniowy (event-driven) | Tak (Enterprise; OSS od wersji 1.4.0) | Tak | Zeebe zbudowano od podstaw wokół architektury zdarzeniowej i może obejmować szerszy zakres wzorców niż obecna implementacja EximeeBPMS - warto zweryfikować dopasowanie do konkretnego projektu. |
| Dedykowane narzędzie do migracji kodu z Camunda 7 | Tak | - | Narzędzie EximeeBPMS oparte na OpenRewrite automatyzuje zmianę pakietów i zależności org.camunda → org.eximeebpms, skracając czas migracji krytycznych procesów. |
| Aktualny stack: Java 25 LTS, Spring Boot 4.x | Zależnie od wersji | Zależnie od wersji | Aktualny stack technologiczny wpływa na cykl wsparcia i zgodność z politykami bezpieczeństwa banku – warto zweryfikować wersje wspierane przez oba produkty przed decyzją. |
| Certyfikacje i mechanizmy bezpieczeństwa dla sektora regulowanego | Zależnie od wdrożenia | Zależnie od wdrożenia | Camunda Enterprise oferuje własne certyfikaty zgodności. To nie jest obszar jednoznacznej przewagi żadnej ze stron – decyduje konkretna architektura wdrożenia i wymagania audytowe danej instytucji. |
EximeeBPMS powstał jako architektoniczna kontynuacja Camunda 7, a nie nowy produkt budowany od zera – to ma znaczenie praktyczne dla banków i ubezpieczycieli, które przez lata inwestowały w modele procesów, integracje i wiedzę zespołów wokół tej architektury. To dziś szeroko stosowane rozwiązanie dla większości polskich banków – dzięki temu znamy wymagania i priorytety sektora finansowego przy wyborze silnika BPMS nie z teorii, a z wdrożeń produkcyjnych.
Decyzja o zachowaniu architektury embedded w EximeeBPMS nie była krokiem wstecz, ale pragmatyczną odpowiedzią na potrzeby rynków regulowanych. W bankowości transakcyjnej przepisanie setek procesów pod architekturę rozproszoną – wymuszoną razem ze zmianą strategii i licencji dostawcy – to gigantyczny, nieuzasadniony biznesowo koszt, niezależnie od tego, czy docelowo oznaczałoby to pełną orkiestrację w modelu mikroserwisowym, czy wzorce takie jak Saga. Nasi klienci oczekiwali ciągłości działania i pełnego bezpieczeństwa – i to im dostarczyliśmy.
– Robert Mastalerek, Senior Fullstack Developer w zespole EximeeBPMS
Różnica pomiędzy oprogramowaniem prawdziwie otwartym (open source) a kodem o ograniczonym dostępie (source-available) staje się kluczowa podczas audytu zgodności z DORA, gdy zespół ds. zgodności (compliance) musi zarejestrować silnik procesowy w strukturach ryzyka ICT. Wybór licencji Apache 2.0 lub MIT, na których opiera się edycja Community EximeeBPMS, zdejmuje z organizacji ryzyko nagłej zmiany polityki cenowej dostawcy. Camunda License v1 to inna sytuacja: skoro sam producent określa ją jako “source-available”, a nie open source, organizacja musi to wyraźnie uzasadnić w dokumentacji zgodności.
Co więcej, wprowadzony od wersji 8.6 obowiązek posiadania komercyjnej licencji produkcyjnej dla wydań Self-Managed stawia przed bankiem realne ryzyko biznesowego uzależnienia u jednego dostawcy (vendor lock-in). Ewentualna zmiana warunków finansowych przez producenta w przyszłości zmusza instytucję do poniesienia gigantycznych kosztów migracji wstecznej, co audytorzy badający odporność operacyjną banku muszą obligatoryjnie odnotować jako podwyższone ryzyko finansowo-operacyjne.
Brak wspólnej transakcji bazodanowej (ACID) to główna różnica architektoniczna między EximeeBPMS a Camunda 8. Ma to bezpośredni wpływ na spójność danych w procesach bankowych (np. kredytowych czy AML).
Najbardziej czasochłonna część migracji z Camunda 7 rzadko dotyczy samego BPMN. Chodzi o niskopoziomowe elementy integracji – listenery Java oraz wyrażenia JUEL – czyli mechanizmy, które w kodzie odwołują się bezpośrednio do komponentów Springa. W Camunda 8 nie mają one prostego odpowiednika i wymagają przepisania integracji, nie tylko podmiany zależności. Narzędzie migracyjne EximeeBPMS oparte na OpenRewrite automatyzuje mechaniczną część (zmianę pakietów org.camunda → org.eximeebpms) – pozwala to w znaczny sposób zredukować czas mechanicznej refaktoryzacji kodu w porównaniu do migracji ręcznej, zostawiając zespołowi czas na to, co faktycznie wymaga uwagi: logikę biznesową i integrację.
Warto odnotować mocną stronę architektury rozproszonej. Zeebe zaprojektowano pod bardzo wysoką przepustowość zdarzeń i skalowanie horyzontalne ponad pojedynczy węzeł – w scenariuszach ekstremalnego obciążenia transakcyjnego to realna przewaga, której architektura oparta o pojedynczą bazę relacyjną nie odtworzy w ten sam sposób. To właśnie ten wąski scenariusz – a nie ogólne hasła „chmura" czy „model zdarzeniowy", które EximeeBPMS oferuje równie dobrze – powinien realnie decydować o wyborze Camunda 8.
Można przypuszczać, że wieloletni brak wsparcia dla RDBMS bywał źródłem realnych problemów z przewidywalnością utrzymania i odtwarzalnością (disaster recovery) we wdrożeniach bankowych – to mogło skłonić producenta do zmiany strategii i wprowadzenia RDBMS jako opcji w wersjach 8.8/8.9.
To rodzi też pytanie o logikę samej zmiany: skoro fundamentem wydajności Zeebe jest właśnie ominięcie wąskich gardeł klasycznych baz relacyjnych, wprowadzenie RDBMS jako alternatywy w wersjach 8.8/8.9 nasuwa pytanie, na ile ta opcja nie ogranicza częściowo tej samej przewagi wydajnościowej, która miała odróżniać Zeebe od architektur takich jak EximeeBPMS. Camunda nie opublikowała szczegółowego wyjaśnienia motywacji tej zmiany.
Poza tym jednym, wąskim scenariuszem – ekstremalną przepustowością zdarzeń i skalowaniem ponad pojedynczy węzeł – decyzja o wyborze platformy powinna wynikać z konkretnych wymagań projektu i tego, jak łatwo uzasadnić ją w rejestrze ryzyka ICT wymaganym przez DORA, a nie z ogólnych skojarzeń typu „chmura" czy „model zdarzeniowy".
EximeeBPMS to uniwersalne rozwiązanie dla każdej instytucji finansowej, która szuka bezpiecznej alternatywy po zakończeniu wsparcia dla Camunda 7 i chce bez stresu spełnić wymogi DORA. Jednak system ten pokazuje swoją absolutną przewagę tam, gdzie organizacja nie może pozwolić sobie na najmniejszy kompromis architektoniczny.
Doskonałym przykładem takiego środowiska – i zarazem idealnym scenariuszem dla EximeeBPMS – jest organizacja, która przenosi do chmury (np. Microsoft Azure) masowe, niezwykle krytyczne usługi, takie jak obsługa bankowych wniosków w programach 800+ czy 300+.
Wyobraźmy sobie architekturę o rygorystycznych wymogach bezpieczeństwa, gdzie nowa infrastruktura musi spełniać bezkompromisowe warunki:
To właśnie w takich, wyśrubowanych warunkach próba wdrożenia Camunda 8 generuje największy opór.
Dlaczego? Zbudowanie powyższego modelu na Camunda 8 oznacza konieczność utrzymywania rozproszonego klastra (Zeebe, Gateway, Operate, Tasklist oraz komponent Identity). Dla bankowych zespołów ds. bezpieczeństwa i infrastruktury każdy z tych nowych mikroserwisów to osobny element do zaplanowania procedur Disaster Recovery, osobny cykl hardeningu oraz odrębny obiekt do kosztownych pentestów. Z kolei EximeeBPMS sprowadza się do pojedynczej, osadzonej aplikacji Java współdziałającej z klasyczną relacyjną bazą danych (np. PostgreSQL).
W przypadku tak wrażliwych operacji gigantyczną przewagą jest również podejście do audytowalności. W Camunda 8 stan procesu zapisywany jest w logu zdarzeń Zeebe, a to, “co widać” w narzędziach analitycznych, przechodzi przez Elasticsearch, co wiąże się z tzw. spójnością ostateczną (eventual consistency). W EximeeBPMS stan procesu i dane biznesowe współdzielą jedną relacyjną transakcję (ACID). Dla audytora i compliance’u oznacza to trwały, spójny i niezaprzeczalny ślad: kto, kiedy i w ramach jakiego żądania podjął daną akcję w systemie.
Czym jest silnik osadzony (embedded engine) w systemach BPMS?
Silnik osadzony to architektura, w której mechanizm zarządzania procesami (np. EximeeBPMS) uruchamiany jest bezpośrednio w przestrzeni pamięci samej aplikacji (np. maszyny wirtualnej Java – JVM), dzieląc z nią zasoby obliczeniowe i transakcje bazodanowe. W przeciwieństwie do silników zewnętrznych, nie wymaga on wywołań sieciowych.
Czy Camunda 8 jest open source?
Nie, w rozumieniu definicji Open Source Initiative. Zeebe i pozostałe komponenty Camunda 8 są objęte Camunda License v1, którą sama Camunda opisuje jako “source-available” – kod jest jawny, ale licencja nakłada ograniczenia niezgodne z definicją OSI, m.in. dotyczące oferowania Zeebe jako usługi w chmurze.
Kiedy kończy się wsparcie dla Camunda 7 Community Edition?
Ostatnie wydanie CE, wersja 7.24, ukazało się 14 października 2025 roku. Od tego momentu repozytorium jest zarchiwizowane, a użytkownicy nie otrzymują już oficjalnych poprawek bezpieczeństwa ani wsparcia.
Jak koniec wsparcia dla Camunda 7 wiąże się z DORA?
DORA, obowiązująca w pełni od 17 stycznia 2025 roku, wymaga od instytucji finansowych zarządzania ryzykiem ICT, w tym prowadzenia rejestru dostawców technologii i oceny ryzyka koncentracji. Utrzymywanie krytycznych procesów na niewspieranym, zarchiwizowanym silniku jest trudne do uzasadnienia w takim rejestrze, co przyspiesza presję na decyzję migracyjną.
Czym różni się architektura EximeeBPMS od Camunda 8?
EximeeBPMS kontynuuje model osadzonego silnika (embedded engine) działającego w aplikacji JVM i opiera się na standardowej relacyjnej bazie danych dla danych operacyjnych – historia procesów jest docelowo wynoszona do osobnej bazy poza silnikiem, zasilanej zdarzeniowo. Camunda 8 działa jako zdalny, rozproszony komponent (Zeebe) i przez większość swojej historii wymagała Elasticsearch lub OpenSearch jako magazynu wtórnego – wsparcie dla RDBMS pojawiło się dopiero w nowszych wersjach i wciąż dojrzewa.
Powered by Consdata
hello@eximeebpms.org
+48 614 151 000
Consdata S.A.
Krysiewicza 9/14
61-825 Poznań
Polska
Download
Source Code
Documentation