Monolit w B2B e-commerce: system, który działa, ale ogranicza rozwój 

System e-commerce B2B może działać bez większych przeszkód przez lata. Obsługuje zamówienia, wymienia dane z ERP, klienci logują się i kupują. Z pozoru wszystko jest w porządku. Problem zaczyna być widoczny dopiero wtedy, gdy firma chce zrobić kolejny krok. 

Nowy rynek, kolejna integracja, zmiana procesu zakupowego czy rozbudowa samoobsługi klienta wymagają ingerencji w coraz więcej obszarów platformy. Przybywa zależności, testów i uzgodnień. System wciąż działa, ale coraz trudniej rozwijać go w tempie, którego wymaga biznes. Wtedy architektura monolityczna, która przez lata dobrze spełniała swoją rolę, może zacząć ograniczać skalowanie e-commerce B2B.  

Najważniejsze informacje:

• Monolit nie jest z definicji złą architekturą. Może dobrze spełniać swoją funkcję, dopóki odpowiada skali biznesu i tempu zmian. 
• Ograniczenia pojawiają się wraz ze wzrostem liczby integracji, rynków, funkcji i zależności pomiędzy elementami systemu. 
• W silnie powiązanej architekturze nawet lokalna zmiana może wymagać testowania i wdrożenia znacznie większej części platformy. 
• Alternatywą może być composable commerce, czyli podejście oparte na niezależnych komponentach połączonych przez API. Poszczególne elementy platformy można dzięki temu rozwijać, skalować lub wymieniać bez przebudowy całego rozwiązania.  
• Modernizacja nie musi oznaczać jednorazowej wymiany całego systemu. Można ją prowadzić etapami, ograniczając ryzyko dla bieżącej sprzedaży. 

Czym jest monolit w e-commerce B2B? 

W architekturze monolitycznej najważniejsze funkcje platformy są ze sobą ściśle połączone i zwykle wdrażane razem. Zespół nie uruchamia więc osobno nowej wersji koszyka, modułu cenowego czy konta klienta. Publikuje nową wersję całej aplikacji, nawet jeśli zmiana dotyczy tylko jednej funkcjonalności.  

W e-commerce B2B taka aplikacja może obsługiwać m.in.: 

• logowanie klientów oraz role i uprawnienia użytkowników, 

• katalogi i asortyment przypisane do konkretnych firm, 

• indywidualne ceny, rabaty i warunki handlowe, 

• koszyk, limity zakupowe i wieloetapową akceptację zamówień, 

• checkout, składanie zamówień oraz przekazywanie ich do ERP lub OMS. 

Wszystkie te funkcje mogą być podzielone w kodzie na mniejsze moduły. Nadal jednak pozostają częścią jednej aplikacji i mają wspólny cykl wdrażania. Tym klasyczny monolit różni się od architektury composable, w której poszczególne komponenty można rozwijać, publikować i skalować niezależnie. 

Kiedy monolit zaczyna ograniczać rozwój e-commerce B2B? 

Monolit zaczyna być ograniczeniem nie wtedy, gdy przestaje działać, ale gdy koszt kolejnych zmian zaczyna rosnąć szybciej niż ich wartość biznesowa. Release’y trwają dłużej, testy obejmują coraz większą część systemu, a pozornie lokalna modyfikacja wymaga zaangażowania kilku zespołów.  

• Sygnał: Każda większa zmiana wymaga szerokich testów 
• Co może oznaczać w praktyce: Poszczególne funkcjonalności są silnie od siebie zależne 
• Sygnał: Release wymaga koordynacji wielu zespołów 
• Co może oznaczać w praktyce: Trudno rozwijać wybrane części systemu niezależnie 
• Sygnał: Jedna integracja wpływa na kilka procesów 
• Co może oznaczać w praktyce: Rosną zależności pomiędzy komponentami 
• Sygnał: Obciążenie jednego obszaru wymaga skalowania całej aplikacji 
• Co może oznaczać w praktyce: Nie można elastycznie skalować konkretnych komponentów 
• Sygnał: Wdrożenie nowych funkcjonalności trwa coraz dłużej 
• Co może oznaczać w praktyce: Coraz więcej pracy pochłania utrzymanie istniejącego środowiska 
• Sygnał: Wejście na nowy rynek wymaga wielu modyfikacji 
• Co może oznaczać w praktyce: Architektura może nie wspierać dalszego skalowania 

Dlaczego ograniczenia monolitu są szczególnie odczuwalne w B2B? 

E-commerce B2B rzadko działa w izolacji. Platforma sprzedażowa jest częścią większej architektury, która obejmuje systemy odpowiedzialne m.in. za produkty, klientów, ceny, dostępność i realizację zamówień. 

Jednocześnie proces zakupowy może wymagać obsługi indywidualnych cenników, katalogów przypisanych do konkretnych klientów, różnych uprawnień użytkowników, warunków kontraktowych czy wieloetapowego składania zamówień. Wraz ze skalą firmy liczba takich zależności rośnie. 

Dlatego ograniczeniem monolitu często nie jest sama wydajność aplikacji. Dużo ważniejsza staje się zdolność do wprowadzania zmian bez destabilizowania reszty środowiska. 

Jeżeli uruchomienie nowego procesu sprzedażowego wymaga zmian w dużej części platformy, szerokich testów regresji i zaangażowania kilku zespołów, koszt architektury przestaje być wyłącznie pozycją w budżecie IT. Przekłada się również na dłuższy time-to-market: późniejsze uruchomienie nowej funkcjonalności, integracji czy kolejnego rynku.  

Czy każdy monolit trzeba modernizować? 

Nie. Sam fakt, że system jest monolitem, nie jest jeszcze powodem do jego wymiany. Jeśli platforma działa stabilnie, można ją sprawnie rozwijać, a jej architektura odpowiada planom firmy, modernizacja może nie przynieść wartości proporcjonalnej do kosztu i ryzyka. 

Decyzję warto rozważyć wtedy, gdy ograniczenia przestają być pojedynczymi niedogodnościami i zaczynają regularnie wpływać na rozwój biznesu. W takiej sytuacji nie trzeba jednak od razu wymieniać całej platformy. Można zacząć od tych obszarów, które najbardziej ograniczają dalszy rozwój. 

Co zamiast monolitu? Composable commerce 

Jedną z alternatyw architektury monolitycznej jest composable commerce. 

Zamiast opierać cały e-commerce na jednej dużej aplikacji, poszczególne możliwości biznesowe można realizować za pomocą niezależnych komponentów (modułów) komunikujących się przez API. Katalog, wyszukiwarka, checkout czy inne obszary nie muszą wtedy rozwijać się w tym samym tempie ani w ramach jednego cyklu wdrożeniowego. 

To daje większą swobodę, bo jeśli jeden element przestaje odpowiadać potrzebom firmy, można go rozwijać albo zastępić, bez przebudowy wszystkiego dookoła. Łatwiej też włączać nowe rozwiązania do istniejącego środowiska (co ma szczególne znaczenie w firmach korzystających z kilku systemów ERP lub działających na wielu rynkach). 

Nie oznacza to jednak, że composable commerce automatycznie usuwa całą złożoność, wręcz przeciwnie. Większa liczba komponentów zwiększa znaczenie integracji, monitoringu, bezpieczeństwa, zarządzania API i jasno określonej odpowiedzialności zespołów. Dlatego sama modułowość nie wystarczy, potrzebne są również dojrzała architektura i zasady jej rozwoju. 

Celem jest stworzenie środowiska, które można zmieniać w tempie odpowiadającym biznesowi.

Jak modernizować platformę bez jednorazowej migracji? 

Modernizacja platformy B2B nie musi oznaczać jednorazowej wymiany całego systemu. 

Można podejść do tego etapowo, a jednym ze sposobów jest stopniowe wydzielanie funkcjonalności ze starszego rozwiązania i przenoszenie ich do nowych komponentów. Stary system działa równolegle tak długo, jak jest potrzebny, a z czasem jego rola maleje. 

W e-commerce B2B ma to szczególne znaczenie, ponieważ kanał online obsługuje realną, bieżącą sprzedaż. Transformacja technologiczna nie może oznaczać zatrzymania zamówień na czas przebudowy platformy. 

Techstep: modernizacja bez zatrzymywania sprzedaży 

Dobrym przykładem takiego podejścia jest Techstep, firma działająca przede wszystkim na rynkach Szwecji, Norwegii i Danii. 

Punktem wyjścia nie był tutaj jeden klasyczny monolit. Środowisko było bardziej złożone: w organizacji funkcjonowało kilka systemów ERP oraz trzy starsze platformy B2B e-commerce. Część rozwiązań dublowała swoje funkcje, a dalszy rozwój wymagał uporządkowania tej architektury.  

Zespół Univio zbudował platformę B2B opartą na technologii commercetools i architekturze composable commerce. Projekt rozpoczął się od MVP. Pierwszy etap umożliwił wycofanie starszego systemu ERP oraz platformy e-commerce obsługującej jeden z rynków. Migracja została przeprowadzona bez zauważalnego przestoju dla klientów i bez przerwania możliwości składania zamówień. 

Transformacja nie sprowadziła się do zmiany technologii. Nowa architektura stworzyła podstawę do dalszej konsolidacji systemów, obsługi kolejnych rynków i rozwoju nowych modeli sprzedaży. 

„Jednym z kluczowych celów projektu było uporządkowanie naszego środowiska e-commerce i stopniowe odchodzenie od starszych rozwiązań. Dzięki współpracy z Univio udało nam się uruchomić nową platformę zgodnie z planem, bez zakłóceń dla klientów i bez przerwy w obsłudze zamówień. To był ważny krok w naszej transformacji cyfrowej.” – Martin Mellqvist, Head of Product, Techstep 

Przypadek Techstep dobrze pokazuje różnicę między etapową modernizacją a klasycznym, wielkim replatformingiem. Nie trzeba czekać, aż kompletna nowa architektura będzie gotowa w każdym kraju i dla każdego procesu. Można zacząć od jednego rynku i kompletnego procesu sprzedażowego, uruchomić nowe rozwiązanie produkcyjnie, a następnie wykorzystać zdobyte doświadczenia przy kolejnych etapach migracji.

Od czego zacząć modernizację platformy B2B? 

Punktem wyjścia nie powinien być wybór nowej technologii. Najpierw warto ustalić, gdzie obecna architektura rzeczywiście ogranicza biznes. 

Dobrym materiałem do analizy są ostatnie większe zmiany w platformie. Ile trwało ich wdrożenie? Ile zespołów trzeba było zaangażować? Czy modyfikacja jednego procesu wymagała ingerencji w pozornie niezwiązane elementy systemu? Warto też sprawdzić integracje z ERP, PIM, CRM czy OMS oraz obszary, w których utrzymanie istniejących zależności pochłania coraz więcej pracy. 

Drugi punkt odniesienia to plany biznesowe. Ekspansja na nowe rynki, konsolidacja systemów po przejęciach, rozwój samoobsługi klientów B2B czy kolejne modele sprzedaży stawiają przed platformą inne wymagania niż utrzymanie obecnego zakresu. 

Monolit nie musi więc przestać działać, żeby zacząć ograniczać firmę. Wystarczy, że coraz częściej to plany biznesowe trzeba dopasowywać do możliwości systemu, zamiast system do potrzeb biznesu. 

W takiej sytuacji modernizacja etapowa i architektura composable mogą pozwolić odzyskać większą swobodę rozwoju bez jednorazowej wymiany całego środowiska. Przykład Techstep pokazuje, że zmianę można rozpocząć od konkretnego zakresu, zachowując przy tym ciągłość sprzedaży. 

Porozmawiaj z ekspertem Univio o tym, jak zaplanować modernizację e-commerce B2B bez zatrzymywania bieżącej sprzedaży. 

Poniżej zebraliśmy odpowiedzi na najczęściej pojawiające się pytania dotyczące e-commerce B2B i architektury monolitycznej. 

FAQ 

Czy monolit zawsze jest złym rozwiązaniem dla e-commerce B2B? 

Nie. Monolit może dobrze sprawdzać się w organizacji, w której skala, liczba integracji i tempo zmian pozostają stosunkowo stabilne. Problem zaczyna się wtedy, gdy architektura coraz częściej ogranicza rozwój biznesu. 

Jak rozpoznać, że platforma B2B przestała się skalować? 

Najczęstsze sygnały to wydłużający się czas wdrażania zmian, szeroki zakres testów przy niewielkich modyfikacjach, trudności z niezależnym rozwojem poszczególnych funkcji oraz rosnąca liczba zależności pomiędzy systemami i zespołami. 

Czym composable commerce różni się od monolitu? 

Composable commerce opiera platformę na niezależnych komponentach komunikujących się przez API. Dzięki temu poszczególne funkcje można rozwijać, skalować lub wymieniać bez konieczności przebudowy całego systemu. 

Czy przejście z monolitu wymaga jednorazowej migracji? 

Nie. Modernizację można prowadzić etapami, przenosząc kolejne procesy lub funkcje do nowej architektury. Pozwala to ograniczyć ryzyko i utrzymać ciągłość sprzedaży podczas transformacji.