Brudne sekrety bezgłowego handlu: czego niektórzy sprzedawcy celowo nie mówią

Brudne sekrety rozwiązań handlu bez głowy: to, czego niektórzy dostawcy (celowo) nie mówią, może cię kosztować, bardzo długo.

Handel bez głowy – lub po prostu „bez głowy” – jest teraz ulubieńcem świata B2C. Według Google Trends zapytania dotyczące handlu bez głowy wzrosły wykładniczo od początku 2020 r. Z punktu widzenia handlu elektronicznego łatwo zrozumieć, dlaczego.

Podczas pandemii konsumenci byli uwikłani w dom, przywiązani do swoich kanałów w mediach społecznościowych. Marki skierowane bezpośrednio do konsumentów mogą korzystać z mediów, takich jak Instagram, TikTok lub Facebook i dostarczać swoje towary bezpośrednio do docelowych odbiorców. Bezgłowe rozwiązania handlowe są oczywiste.

Architektury bezgłowe zapewniają dużą elastyczność. Ze względu na rozdzielenie frontendu i backendu (oraz dostępność interfejsów API) organizacjom, które chcą wdrożyć handel w nowych kanałach, znacznie łatwiej jest zrobić to za pomocą platformy obsługującej headless.

Rozwiązania Headless Commerce zapewniają również większą elastyczność, ponieważ frontend i backend są wdrażane osobno. Ponieważ zwinność stała się ogromnym wyróżnikiem biznesowym, rośnie zainteresowanie bezgłowym.

Bezgłowe rozwiązania handlowe: przebijanie się przez szum

Ale czym właściwie jest bezgłowy handel? Jak to często bywa w świecie technologii i marketingu, istnieje tendencja do chwytania się najnowszego, błyskotliwego hasła — cofnij się myślami do big data lub sztucznej inteligencji/uczenia maszynowego sprzed kilku lat — i włącz je do jak największej liczby rozmów .

Kiedy jednak ludzie nie potrafią tak naprawdę określić, czym jest rzecz, wody wokół tej rzeczy stają się dość mętne. To jest dokładnie to, co dzieje się z handlem bez głowy.

Nie możemy być zbyt surowi dla marketerów; nie tylko oni zabłocają wody. Wielu dostawców dodaje do tej mieszanki, celowo lub w inny sposób, łącząc funkcje bezgłowe, chmurowe, interfejsy API i mikrousługi. Mają swoje plany, więc zacieranie granic między tymi rzeczami jest dla nich korzystne. I żeby było jasne, żaden z nich nie jest taki sam.

Mówiąc najprościej, bezgłowy handel oznacza:

1. Frontend/storefront/glass są oddzielone od silnika commerce (tj. backendu).
2. Ponieważ jest oddzielony, zużywa możliwości zaplecza, takie jak ceny i promocje za pośrednictwem wywołań interfejsu API.
3. Dlatego z definicji, aby platforma handlowa była w stanie obsługiwać wdrożenia bezgłowe, potrzebuje ona pokrycia API funkcjonalności backendu handlu.

Wskoczmy i przyjrzyjmy się dokładnie, czym jest bezgłowy (a czym nie jest), skąd pochodzi i dla kogo jest przeznaczony.

Handel bez głowy nie jest niczym nowym

Chociaż sam termin mógł zacząć nabierać rozpędu dopiero w ciągu ostatnich kilku lat, koncepcja bezgłowego nie jest ani trochę nowa. Jak wspomniano powyżej, jest to podejście oparte na interfejsie API, w którym przednia warstwa/warstwa prezentacji/szkło są oddzielone od rdzenia (przy użyciu interfejsów API).

Na przykład w firmie SAP (a wcześniej Hybris) od ponad dekady udostępniamy funkcje handlowe za pośrednictwem naszej warstwy Restful API (połączenia Omni-Commerce). Około połowa z ponad 3500 klientów korzystających z SAP Commerce (lokalnie i w chmurze) robi to w sposób bezgłowy, korzystając z systemu CMS innej firmy lub dedykowanego oddzielonego sklepu.

Chodzi o to, aby nie dać się zwieść szumowi; headless nie tylko pojawił się na scenie.

Rozwiązania typu headless commerce nie są dla wszystkich

Headless, jak wszystko inne, nie jest dla wszystkich. Na początek to złożone. Deweloperzy muszą mieć dogłębne i szerokie umiejętności w wielu bazach kodu.

Ale to nie wszystko. Wymagają dojrzałości informatycznej i zdolności programistycznych, ponieważ warstwa prezentacji / witryna sklepowa na zamówienie musi być zbudowana całkowicie od podstaw przy użyciu front-endowych frameworków i bibliotek (takich jak Angular/React/Vue) lub poprzez rozwiązanie partnerskie w absolutnym minimum. Te niestandardowe interfejsy generalnie nie są obsługiwane przez dostawców.

Co więcej, frontendy tworzone na zamówienie zazwyczaj ograniczają możliwości praktyków biznesowych w zakresie projektowania i aktualizowania frontendu bez pomocy działu IT. Jeśli jest to ważne dla Twojej firmy, rozwiązania handlowe typu „headless only” mogą nie być dla Ciebie odpowiednie.

Dobra wiadomość: dostawcy oferują funkcje „bezgłowe i bezpośrednie” ze 100% pokryciem interfejsu API i oddzieloną witryną sklepową bez konieczności budowania jej od podstaw. Takie podejście przyspiesza rozwój frontendu i ogólny harmonogram realizacji projektu.

Headless to nie mikrousługi

Jak wspomnieliśmy na początku, niektórzy sprzedawcy celowo zamulają wody, łącząc bezgłowy z mikrousługami. Ustawmy sprawę jasno.

Nie, mikroserwisy NIE są równoważne z interfejsami API. I nie (mam zamiar użyć tutaj mojego „zewnętrznego” głosu), ARCHITEKTURA OPARTA NA MIKROUSŁUGACH NIE JEST WYMAGANEM DO BEZGŁOWY (z drugiej strony API są).

Według Martina Fowlera „architektoniczny styl mikrousług to podejście do tworzenia pojedynczej aplikacji jako zestawu małych usług, z których każda działa we własnym procesie i komunikuje się z lekkimi mechanizmami, często API zasobów HTTP”.

Dobrze to przeczytałeś – mikrousługi udostępniają swoje możliwości za pośrednictwem interfejsów API i jako takie są komplementarnymi, a nie wymiennymi koncepcjami. Porównaj architekturę opartą na mikrousługach z architekturą monolityczną, w której cała aplikacja składa się z „jednego fragmentu” kodu. W prawdziwym świecie niewiele aplikacji jest w pełni opartych na mikrousługach lub w pełni monolitycznych; zazwyczaj spadają gdzieś pośrodku.

Chociaż mikrousługi mogą robić wiele rzeczy, są również kosztowne (duże koszty ogólne) i w żadnym wypadku nie są srebrną kulą dla zwinności. Nie zagłębiając się w zalety i wady każdego wzorca architektonicznego, warto zauważyć, że główną zaletą architektury opartej na mikrousługach jest szybkość i zwinność, z jaką duże organizacje programistyczne mogą tworzyć oprogramowanie. Koszty ogólne są niewielkie w porównaniu z czasem tworzenia kodu w architekturze monolitycznej.

Jest to więc bardzo cenne dla dostawcy platformy handlowej, takiego jak Amazon, nad którym zwykle pracują setki programistów. Jednak ten rodzaj architektury nie sprawdziłby się dla wszystkich. Jest to szczególnie słabe rozwiązanie dla organizacji, które nie mają zdolności IT i odpowiednich zasobów do rozwoju handlu, aby z niego skorzystać.

Lepiej zastanowić się, jak Gartner nazywa komponowalną architekturą biznesową. Ten model wymiennych elementów konstrukcyjnych umożliwia firmie zmianę układu według potrzeb, w zależności od takich czynników, jak zmiana wartości klienta lub nagła zmiana w łańcuchu dostaw lub materiałach. Te cegiełki lub moduły mogą być usługami mikro, ale także makro.

Według Gartnera architektura ta zapewnia: szybkość dzięki odkrywaniu, większą elastyczność dzięki modułowości, lepsze przywództwo dzięki orkiestracji oraz odporność dzięki autonomii. Nie mogło to być ważniejsze niż podczas pandemii, kiedy organizacje musiały całkowicie przemyśleć i zmienić swoje modele biznesowe w ciągu kilku dni, pod groźbą bankructwa.

Teraz, jeśli zastanawiasz się, dlaczego niektórzy dostawcy bezmyślnie łączą mikrousługi, odpowiedź jest tak stara, jak sam rynek oprogramowania dla przedsiębiorstw. Podkreślając nowe, błyszczące możliwości, wschodzącym dostawcom pozwala odwrócić uwagę od możliwości, w przypadku których są niewystarczające, takich jak platforma i cechują się solidnością.

I chociaż nowoczesna architektura jest zdecydowanie ważnym czynnikiem przy wyborze platformy handlowej, nie może odbywać się kosztem bogactwa funkcjonalnego ani możliwości wzmocnienia pozycji użytkowników biznesowych.

Headless jest tutaj, aby zostać

Ponieważ liczba punktów styku stale rośnie, handel bez głowy nigdzie się nie wybiera. Wybierając platformę, weź pod uwagę wszystkie funkcjonalne i niefunkcjonalne wymagania dotyczące Twojej firmy, nie tylko dziś, ale także jutro.

Wybór platformy, która może dziś wykonać zadanie, ale nie wesprze Twojego rozwoju ( np. międzynarodowej lokalizacji ) jest krótkowzroczna i spowoduje tylko odrzucenie przysłowiowej puszki.

Wreszcie fakt, że niektórzy sprzedawcy chcą, abyś patrzył na jasny, błyszczący obiekt, nie oznacza, że ​​inne wymagania nagle przestają mieć znaczenie. Zarządzanie informacjami o produktach, zarządzanie treścią WWW, zarządzanie zamówieniami, możliwości B2B, możliwości B2C i personalizacja są niezbędne.

Nie wpadaj w pułapkę łączenia solidnej funkcjonalności ze starszą architekturą, pomimo tego, co mówią niektórzy dostawcy.