Composable commerce w 2024 roku - trend czy standard? Monogo E-commerce News, numer 67
Krótkie wprowadzenie do Composable commerce
Ecommerce opiera się w znacznym stopniu na technologii, która umożliwia kupującym na dostęp do oferty i koszyka 24 godziny na dobę. Eksplozja popularności zakupów internetowych doprowadziła do poszukiwań nowych rozwiązań technologicznych, które miały zapewnić elastyczność i szybkość. Szybkość zarówno wdrożeń jak i działania sklepu.
Zanim na dobre pojawiły się w branży takie pojęcia jak headless commerce, lub composable commerce pracowaliśmy na starym i poczciwym monolicie. To znaczy system ecommerce stanowił spójną całość. Inaczej rzecz ujmując, jeden dostawca dawał wszystkie moduły, od katalogu produktów, CRM, CMS, integrację z bramkami płatności na frontendzie kończąc.
Z czasem zaczęły pojawiać się interesujące rozwiązania np CMS, które mocno wyprzedzały te dostarczane z silnikami ecommerce. Mając monolit nie było łatwo dodawać kolejne systemy, które przewyższały możliwościami te, które już mieliśmy w sklepach. Między innymi z tego powodu została wymyślona architektura composable commerce. Zakłada ona mocno wydzielenie każdej głównej funkcji, lub grupy funkcji od innych, jak również od warstwy prezentacji.
O czym pamiętać przy composable commerce?
Śpiew syren o composable commerce nie zawsze zawiera wersy o tym co należy wiedzieć, lub z czym będziemy się mierzyli kiedy pójdziemy w stronę tej architektury. A to ważne, bo inwestycja jest znaczna.
- Czy na pewno elastyczność ma tak duże znaczenie w Twoim biznesie?
- Czy posiadasz wystarczająco dużo zasobów technicznych do budowy/integracji composable commerce?
- Czy jesteś gotowy/gotowa na współpracę z wieloma dostawcami i czy oni są na tyle dojrzali, że będą współpracować ze sobą?
- Czy badanie problemów z wydajnością albo błędów na wielu poziomach/dostawcach nie stanowi dla Twojej organizacji potężnego wyzwania?
- Czy jesteś gotowy/gotowa na znaczną inwestycję na początku (mając na uwadze czas i budżet)?
Inicjalny koszt composable commerce
Budżet jaki należy przygotować na początku jest znacząco przewyższający rozwiązania monolityczne lub Modular Monolithic Architecture. Wynika to z faktu, że każdy moduł należy zakupić (jego licencję), następnie zintegrować po API z innymi częściami systemu, oraz z frontendem. To oznacza dłuższy time-to-market oraz większy budżet.
Tutaj warto wspomnieć, że często się zdarza, że rozwiązania mają niekompatybilne ze sobą API. To przyniesie sporo pracy i bólu głowy w zespołach technicznych. Pomimo tego, że coraz popularniejszy jest GraphQL, to ciągle mamy do czynienia z brakiem jego implementacji lub implementacją niekompletną. I teraz pytanie, czy robić część tak, a część tak, czy czekać, czy może zdecydować się na brak kompatybilności i użycie REST/SOAP?
Utrzymanie composable commerce
Zakładając, że przejdziesz przez budowę ekosystemu ecommerce w architekturze composable commerce, potem trzeba wziąć pod uwagę koszty utrzymania (run cost lub Total Cost of Ownership). W zależności od wybranej platformy te koszty są ciężkie do przewidzenia, ale możemy podyskutować na temat ciągłego zaangażowania.
To zaangażowanie będzie wynikało z faktu, że każdy moduł osobno jest aktualizowany i praktycznie cały czas będzie coś do poprawienia lub zmiany. Wszystko dlatego, że dostawcy będą zmieniali swoje API, wypuszczali nowe wersje, a stare będą miały datę końca wsparcia. A to wszystko nie licząc implementacji Twoich nowych funkcji biznesowych.
Z drugiej strony monolit aktualizujesz zgodnie z aktualizacjami producenta. Zazwyczaj raz na 3 miesiące lub nawet rzadziej.
A co z zaletami composable commerce?
To nie jest tak, że composable commerce to same koszty i problemy. Wręcz przeciwnie jest też mnóstwo zalet. Weźmy pod uwagę kilka punktów:
- Jeśli wszystkie serwisy i API działają szybko (a zazwyczaj tak jest) to wydajność i CWV (Core Web Vitals) Twojego sklepu na pewno będzie przewyższać monolit. Z naszego doświadczenia wynika, że faktycznie tak jest.
- Mobile first: zdecydowanie composable commerce przewyższa monolit w byciu przyjaznym użytkownikowi mobilnemu. A to dlatego, że wszędzie jest API. Jeśli masz zamiar posiadać aplikację mobilną to dane będą przychodziły natywnie, bo po API. Nie trzeba martwić się o brak pokrycia. Przecież Twój frontend działa już w 100% na API. A dodatkowo nowoczesne rozwiązania frontendu zapewniają sporo możliwości dla użytkowników mobilnych. Od stron świetnie prezentujących się na telefonach do PWA.
- Łatwość wymiany modułu. Z tego względu, że wszystko jest ze sobą zintegrowane, wymiana CMS, np na builder.io, może okazać się dużo prostsza bo integracja nie jest tak głęboka.
Dla kogo composable commerce?
Wybór pomiędzy dostępnymi architekturami, monolitem Modular Monolith czy headless commerce sprowadza się do specyfiki Twojego biznesu i kierunków rozwoju. Inaczej mówiąc priorytetów biznesowych oraz długofalowych celów.
Composable commerce jest świetnym wyborem dla:
- Korporacji z większymi zasobami lub wewnętrznymi działami technicznymi mającymi doświadczenie w tej architekturze.
- Biznesów, dla których priorytetem jest elastyczność i potencjał na dostosowanie ekosystemu do własnych potrzeb lub wymagań.
- Biznesów, które nie mają problemu i odważnie potrafią adaptować nowe technologie.
- Biznesów, które akceptują większy koszt inicjalny w zamian za długofalowe benefity.
Z drugiej strony nie są dla firm, które:
- Chcą mieć rozwiązanie szybko (fast time to market).
- Nie posiadają znacznego budżetu na inicjalne rozwiązanie.
- Nie posiadają dostawców lub własnych zasobów, doświadczonych w nowoczesnych technologiach frontendowych i złożonych integracjach.