Architektura monolityczna czy oparta na zdarzeniach?

W sklepie internetowym zamówienie jest przyjmowane, a następnie ktoś ręcznie wprowadza dane do systemu zarządzania. Magazyn otrzymuje osobne powiadomienie, a fakturowanie rozpoczyna się dopiero po sprawdzeniu zapasów przez pracownika. W takim przypadku pytanie nie jest teoretyczne: monolit czy architektura sterowana zdarzeniami naprawdę by pomogła? Zanim jednak udzielimy odpowiedzi technologicznej, warto zrozumieć, gdzie informacja się zatrzymuje i które ręczne kroki nadal służą prawdziwemu celowi biznesowemu.

W wielu rozwijających się firmach to nie system sam w sobie jest problemem. Problemem jest to, że przekazywanie danych między systemami, zespołami i obszarami odpowiedzialności odbywa się ręcznie. Jest to powolne, podatne na błędy i trudne do śledzenia. Zadaniem architektury nie jest wyglądać nowocześnie, ale zapewnić przewidywalne działanie procesów biznesowych, nawet gdy rośnie liczba zamówień, rozszerza się asortyment produktów lub zmienia się organizacja.

Co oznacza monolit w praktyce?

W aplikacji monolitycznej główne funkcje biznesowe działają w jednym systemie. Na przykład ta sama aplikacja obsługuje zamówienia, klientów, informacje o zapasach, uprawnienia i przygotowanie faktur. Baza danych, zasady biznesowe i interfejs użytkownika są zazwyczaj ściśle powiązane.

To nie jest błąd ani synonim przestarzałego podejścia. Dobrze zaprojektowany monolit może być doskonałym wyborem dla wielu firm. Zasady są w jednym miejscu, zarządzanie jest prostsze, mniej jest błędów między systemami, a proces można obsłużyć w kilku krokach w jednej transakcji. Jeśli przy rejestracji zamówienia trzeba jednocześnie zarezerwować zapasy, sprawdzić limit kredytowy i utworzyć zadanie realizacji, monolit może zapewnić jasne działanie.

Problem zaczyna się, gdy system nie obsługuje już jednoznacznie oddzielonych obszarów biznesowych, a wszystkie nowe wymagania trafiają do tego samego miejsca. Mała zmiana w fakturowaniu może nieoczekiwanie wpłynąć na proces magazynowy. Z powodu wydania deweloperskiego trzeba wdrożyć całą aplikację. Jeśli kilka zespołów pracuje nad tą samą bazą kodu, koordynacja może sama spowolnić zmiany.

Jest to jednak również kwestia projektowania i organizacji. Nie każdy duży monolit jest nie do opanowania, i nie każdy mniejszy system zasługuje na natychmiastowe rozdzielenie.

Jak działa architektura sterowana zdarzeniami?

W działaniu sterowanym zdarzeniami zdarzenie biznesowe wysyła sygnał do innych zaangażowanych systemów. Takim zdarzeniem może być na przykład „zamówienie złożone”, „towar przyjęty”, „operacja produkcyjna zakończona” lub „faktura opłacona”. System tworzący zdarzenie niekoniecznie wykonuje wszystkie kolejne zadania. Zamiast tego publikuje, co się stało, a inne systemy reagują w ramach swoich obszarów odpowiedzialności.

Weźmy prosty przykład. Sklep internetowy rejestruje nowe zamówienie. System zarządzania zapasami rezerwuje towar, system logistyczny tworzy zadanie kompletacji, rozwiązanie do komunikacji z klientem wysyła potwierdzenie, a raportowanie aktualizuje dzienne dane sprzedaży. Nie jest konieczne, aby sklep internetowy znał wszystkie szczegółowe zasady.

Jest to szczególnie korzystne, gdy wiele systemów o różnych cyklach życia musi reagować na tę samą zmianę biznesową. Produkcja, magazyn, organizacja transportu, obsługa klienta i finanse niekoniecznie działają z tą samą prędkością lub w tej samej aplikacji. Zdarzenia mogą pomóc w uniknięciu przekazywania informacji przez e-mail, arkusze kalkulacyjne lub telefon.

Architektura sterowana zdarzeniami nie oznacza jednak, że wszystko jest aktualizowane natychmiast i w każdych warunkach. W niektórych procesach akceptowalne jest, że status zamówienia pojawia się w widoku magazynowym po kilku sekundach. W innych przypadkach, takich jak rezerwacja zapasów czy zatwierdzenie płatności, potrzebne są bardziej rygorystyczne zasady. Oba przypadki nie powinny być traktowane jednakowo.

Monolit czy architektura sterowana zdarzeniami: to nie jest prawdziwe pytanie tak-nie

Oba podejścia są często traktowane jako fałszywy wybór. Jakby firma mogła mieć tylko jedną dużą aplikację lub wiele usług połączonych zdarzeniami. W rzeczywistości większość dobrze działających środowisk jest hybrydowa.

Centralny system zarządzania lub produkcji może pozostać monolityczny, jednocześnie przekazując określone zdarzenia biznesowe do innych systemów. Dzięki temu podstawowe procesy działają w jednym miejscu, w kontrolowany sposób, ale sklep internetowy, połączenie z przewoźnikiem, powiadomienia dla klientów czy platforma danych nie stają się więźniami wewnętrznej logiki centralnego systemu.

Jest to zazwyczaj bezpieczniejsza ścieżka rozwoju niż nagłe rozdzielenie całego systemu. Jeśli firma ma obecnie niezawodny, ale trudny do zintegrowania system, najpierw należy wyjaśnić, jakie zdarzenia biznesowe są istotne. Nie zmiany danych w sensie technicznym, ale prawdziwe stany biznesowe: partia produkcyjna została ukończona, paczka została przekazana kurierowi, upłynął termin zatwierdzenia, wystąpiła różnica w zapasach.

Kiedy warto zachować monolit?

Monolit jest uzasadniony, gdy procesy są ściśle powiązane, zmiany są rzadkie, a biznes nie potrzebuje wielu systemów rozwijających się niezależnie. W przypadku wewnętrznej aplikacji zarządzania, używanej przez niewiele, dobrze zdefiniowanych ról, mniejsze obciążenie operacyjne często jest bardziej wartościowe niż obietnica technologicznego rozdzielenia.

Może to być również uzasadnione, jeśli organizacja nie ma zdolności do zarządzania złożonymi integracjami. Obsługa zdarzeń wymaga więcej niż tylko wprowadzenia pośrednika wiadomości. Potrzebne są monitorowanie, logowanie, zarządzanie uprawnieniami, strategia ponownego wysyłania, tolerancja błędów i jasna odpowiedzialność. Jeśli przetwarzanie się nie powiedzie, trzeba wiedzieć, kto zostanie powiadomiony, jak poprawić dane i co się stanie z zależnymi procesami.

Monolit nie jest dobry dlatego, że nazywamy go prostym, ale dlatego, że jego granice są jasne. Funkcje, dane i odpowiedzialności nie mieszają się w sposób niekontrolowany.

Kiedy architektura sterowana zdarzeniami przynosi wartość biznesową?

Podejście sterowane zdarzeniami jest silne, gdy w firmie jest wiele przekazywania i powtarzającej się koordynacji. Typowym sygnałem jest sytuacja, gdy o tej samej zmianie musi wiedzieć wiele zespołów, ale obecnie jest to rozwiązywane ręcznie. Na przykład dział zakupów wysyła osobny e-mail do magazynu, magazyn prowadzi osobny arkusz kalkulacyjny, a dział sprzedaży dowiaduje się później, że zamówienie nie może być zrealizowane.

Jest to również przydatne tam, gdzie oczekiwane są nowe powiązane systemy. Firma dzisiaj używa tylko sklepu internetowego i ERP, ale w przyszłym roku może wprowadzić portal klienta, zautomatyzowane drukowanie etykiet, integrację z przewoźnikami lub platformę danych dla menedżerów. Jeśli podstawowe zdarzenia biznesowe są dobrze zdefiniowane, nowe możliwości można dodać z mniejszym ryzykiem.

Najważniejszą zaletą nie jest jednak elastyczność technologiczna. Jest nią to, że widoczne staje się, co się wydarzyło w procesie. Na podstawie dobrze zaprojektowanego łańcucha zdarzeń można prześledzić, kiedy zamówienie zostało złożone, kiedy dokonano rezerwacji zapasów, dlaczego realizacja się zatrzymała i w którym systemie wystąpiła różnica. To daje lepszą podstawę do podejmowania decyzji przez kierownictwo i zmniejsza obciążenie pracowników, którzy dzisiaj próbują złożyć historię z pamięci.

Ukryty koszt: złożoność i odpowiedzialność

Architektura sterowana zdarzeniami nie jest darmową elastycznością. System może się opóźniać, zdarzenie może przyjść dwa razy, odbiorca może być tymczasowo niedostępny, lub zasada biznesowa może się zmienić w trakcie procesu. Na te sytuacje trzeba się przygotować.

Na przykład nie wystarczy powiedzieć, że przy składaniu zamówienia zapasy powinny się zmniejszyć. Trzeba określić, co się stanie, jeśli płatność zostanie odrzucona, jeśli zamówienie zostanie zmienione, jeśli magazyn znajdzie mniej towaru lub jeśli to samo zdarzenie zostanie przetworzone dwa razy z powodu błędu technicznego. Takie pytania to w rzeczywistości pytania o kontrolę biznesową. Technologia może je prawidłowo obsłużyć tylko wtedy, gdy proces i zasady są jasne.

Dlatego niebezpieczne jest podejmowanie decyzji wyłącznie na podstawie trendów deweloperskich. W zbyt wcześnie rozdzielonym systemie wcześniejsza wewnętrzna złożoność po prostu przenosi się na połączenia między systemami. Błąd nie będzie już wewnątrz jednej aplikacji, ale między dwoma lub trzema zespołami, źródłami danych i granicami odpowiedzialności.

Jakie pytania warto zadać na początku?

Przed wyborem architektury warto prześledzić konkretny proces od zdarzenia wywołującego do zakończenia. Kto rejestruje dane? Gdzie ta sama informacja jest tworzona ponownie? Który krok wymaga e-maila, telefonu lub osobnego arkusza kalkulacyjnego? Kto potrafi powiedzieć, dlaczego sprawa się zatrzymała? I którą zasadę zna tylko jeden doświadczony pracownik?

Jeśli na podstawie odpowiedzi widocznych jest niewiele systemów i silnie powiązane procesy, uporządkowany monolit może być odpowiednią podstawą. Jeśli pojawia się wiele oddzielnych systemów, częste przekazywanie i rosnące potrzeby integracyjne, połączenie oparte na zdarzeniach może być uzasadnione. Pomiędzy tymi dwoma podejściami istnieje wiele przejściowych, stopniowo wprowadzanych rozwiązań.

Dobra architektura nie jest wartościowa dlatego, że składa się z wielu usług. Jest wartościowa dlatego, że droga zamówienia, zadania produkcyjnego czy faktury istnieje nie w głowach ludzi, ale w kontrolowanym procesie. Jeśli to uda się wyjaśnić, decyzja technologiczna nie będzie już kwestią wiary, lecz ukierunkowanym rozwojem biznesowym.