Tudsz ajánlani egy jó webáruház motort?
Tegyük fel, hogy eldöntöttük: megújítjuk már kiöregedett webáruházunkat vagy éppen friss beruházással piacra vezetjük vállalatunkat az e-kereskedelem eddig távolról figyelt zűrzavaros tengerében. Mit tesz ilyenkor egy döntéshozó? A composable commerce ismerete hiányában jellemzően azt, amit a józan ész diktál: megpróbálja kiválasztani a számára leginkább megfelelő webáruházmotort és keres egy megbízhatónak tűnő fejlesztő céget. Utóbbi segítségével felépíti a webáruházát a kiválasztott engine-en, vagy ha nem talál ilyet, lefejleszt egy teljesen egyedi, saját rendszert, ami képes lefedni az esetleges különleges igényeit.
Sokszor tapasztaljuk, hogy webáruházak indítása előtt a megrendelők a “mindent egyben tudó” engine-t keresik. Fejlesztőcégek ilyenkor bizonygatják, hogy az általuk szállított platform akár 5-10 évre minden felmerülő igényt ki fog tudni szolgálni. Ez egy vágyálom, és nem is célszerű erre törekedni.
Ezekről a hagyományos monolitikus rendszerekről ugyanis egyre gyakrabban derül ki, hogy blokkolják és lassítják az üzleti növekedést. A kezdetben vonzó platformunk az évek múltán könnyen egy legacy szörnyszülötté válhat. Egy ilyen összetett rendszer önmaga fejlesztésének gátja lesz és lecserélése már túlságosan fájdalmas. Webáruházunk idővel olyan mértékű komplexitást ölt magára, ami kínosan lassúvá és költségessé teszi az új fejlesztéseket. Ezen felül a hibakeresés egy mindennapos fájdalommá válik, a peak szezonok során pedig gyakran izgulhatunk, hogy túléli-e a rendszer a nagy rohamot összeomlás nélkül. Ha van egy webáruház rendszerünk, amelynek fejlesztésébe évi akár több ezer órát fektetünk, akkor – ha tetszik ha nem – ez bekövetkezik.
Amennyiben tényleg időtálló terméket szeretnénk, amelyet várhatóan intenzíven fejleszteni is fogunk a következő években, akkor ideje megismerkednünk a composable commerce fogalmával. Ez nemcsak egy architektúra, hanem sokkal inkább egy gondolkodásmód, ami radikálisan szembemegy azzal, ahogyan a közelmúltig a kereskedelmi szoftver bevezetésekről gondolkodtunk. A koncepció lényege, hogy nem egyetlen rendszerbe fejlesztünk bele minden funkciót, hanem megpróbálunk minél több kész elemből dolgozni, és minden funkcióra a számunkra legjobb megoldást választjuk ki.
Ahány szolgáltatás, annyi alkalmazás
A composable commerce architektúra tehát egy “best of breed” szemléletet követ, ahol arra törekszünk, hogy az egész rendszer minél több, lehetőleg kicsi, független komponensből épüljön fel, és ezek megfelelő kombinációja alkossa a kereskedelmi ökoszisztémánkat. Így egy adott üzleti igényt a piacon elérhető legjobb szolgáltatással valósítunk meg. A rendszerhez sokkal könnyebben adhatunk hozzá újabb szolgáltatásokat, ha pedig el kell távolítani valamit, akkor azt úgy tudjuk megtenni, hogy nem kell az egész digitális kereskedelmi környezetünkből kigyomlálni. A rendszerünk így jövőbiztos lesz, hiszen az egyes elemei nincsenek egybegyúrva, csak lazán kapcsolódnak egymáshoz. Könnyebb az üzemeltetés, hiszen az egyes alkalmazások egymástól független erőforrást kaphatnak és hibatűrő végeredményt is kapunk azáltal, hogy egy komponens meghibásodása nem befolyásolja az egész rendszer működését.
A rendszert ehhez felbontjuk önállóan értelmezhető üzleti csomagokra (pl. kosár folyamat, katalógus, CMS funkciók, árkezelés, kedvezménykezelés) és minden szolgáltatásra a legjobb elérhető megoldást vezetjük be. Valamennyi csomag a fejlesztendő termék egy-egy funkció csoportja, amelyek jellemzően harmadik felektől származó applikációkat jelentenek. Nem egyetlen, mindent magába foglaló kereskedelmi rendszert állítunk hadrendbe tehát (merthogy ilyen nem létezik), hanem több alkalmazást integrálunk egymással össze.
A példa kedvéért az alábbiakban egy komplex webáruház ökoszisztéma szolgáltatásait szemléltetjük. Ennek egyes elemei leképezhetők külön-külön alkalmazások formájában is. Mindezt sokkal könnyebb és ésszerűbb már kész, külön alkalmazások formájában egymással összhangba hozni, mint egyetlen platformba “besűríteni”.
Egy ilyen architektúra nagyfokú rugalmasságot és skálázhatóságot biztosít és kifejezetten ideális akkor, ha gyakran szeretnénk új funkciókat a rendszerbe építeni. Nem kell kompromisszumokat kötnünk, ha egy monolit rendszer valamely beépített modulja számunkra nem megfelelő. Nem elég jó a webáruház kereső engine-je? Nem gond, vezessük be a legjobb hosted search megoldást, amit a piacon találunk! Szeretnénk a webshopot magazin tartalmakkal gazdagítani? Keressük meg a legjobb headless CMS-t és integráljuk! A composable commerce egy ténylegesen inkrementális fejlesztést tesz lehetővé, ahol az egyes funkciók könnyen bővíthetők és cserélhetők.
Open source versus egyedi fejlesztés: Miért ne lehetne mindkettő?
Amikor felmerül egy digitális kiskereskedelmi rendszer építésének az ötlete, az első kérdés ami gyakran előkerül, hogy valamilyen standard, esetleg open-source rendszert vezessünk-e be vagy egyedi fejlesztés formájában lássunk-e neki a projektnek. Kész, szabványos megoldást vásároljunk – és éljünk együtt annak limitációival – vagy egyénileg építsük fel a sajátunkat? Népes tábora van mindkét irányzatnak, amelyek felkent papjai előszeretettel ütköztetik egymással a világképüket. Egy komponensekből szabadon felépített architektúrában az a szép, hogy ezt a vitát értelmetlenné teszi.
Ha van egy olyan rendszerünk, amelynek építőkockái egymástól függetlenek és minden alkotóelem kiszolgáló alkalmazását egyesével válogathatjuk össze, akkor a kész megoldások szabadon kombinálhatók az egyedi fejlesztésekkel. Lesz olyan üzleti funkció, amelyhez megtaláljuk a piacon számunkra leginkább megfelelőt és lesz olyan egyedi igényünk, amit valamilyen alkalmazás formájában magunk fejlesztünk majd hozzá. Ha a rendszerünk platformfüggetlen, akkor nyitva hagytuk az ajtót minden lehetőség előtt. Composable commerce alapú architektúra esetén a hitvitákat le is zárhatjuk.
Alkalmazási területek: mikor éri meg composable commerce architektúrát építeni?
Egy composable architektúra felépítése első lépésben drágább lehet, mint beköltözni egy kész webáruház rendszerbe. A befektetés hosszabb távon térül majd meg. Természetesen szép számmal vannak olyan webáruház projektek, amelyeknél nem racionális composable commerce irányba vinnünk a terméket. Ahol viszont igen, azok jellemzően a következők:
- Intenzív továbbfejlesztések: Érdemes composable commerce architektúrát választanunk olyan webáruházak esetén, amelyek várható továbbfejlesztései elérik majd az évi több ezer munkaórás nagyságrendet. Ez egy olyan funkcióbővítési volumen, aminél már fennáll a veszélye, hogy rövid időn belül egy legacy rendszer megteremtése felé haladunk. Ha ezt látjuk, kezdjünk el gondolkozni a rendszer szolgáltatásainak önálló csomagokra való bontásán!
- Nagyfokú egyediség: A composable szemlélet előnyei olyan rendszerbevezetésekkor is megcsillannak, amik annyira egyediek, hogy már a termék alap változatának felállításakor látszik, hogy bármilyen alapul szolgáló platformot erősen “ki kell facsarni”. Ha már az MVP sem építhető fel egy engine műszaki kiforgatása nélkül, az általában annak csalhatatlan jele, hogy composable architektúrában célszerű gondolkoznunk.
- Speciális e-business: Fontoljuk meg a composable commerce irányt olyan e-business rendszerek fejlesztésekor, amik “nyomokban webáruházat is tartalmaznak”. Vagyis a hagyományos webáruház funkciókon túlnyúló tranzakciós portál fejlesztéskor. Ha egy rendszerről többedik ránézésre sem tudjuk egyértelműen megmondani, hogy inkább webáruház, aggregátor site, piactér vagy esetleg ügyfélportál, akkor jó eséllyel egy composable felépítés áll előttünk.
- Kísérleti termékfejlesztés: Erősen agilis kísérleti fejlesztésekkor – amikor elkezdünk egy terméket piacra vezetni, ám azt még üzletileg validálnunk kell – jellemzően nem látjuk előre, hogy hosszabb távon milyen irányt vesz a termék, a kezdeti vízióból mit tartunk meg és mit dobunk majd ki. Ilyenkor igen nagy a kockázata annak, hogy beköltözünk egy olyan rendszerbe, ami korlátossá válhat vagy kiderülhet róla, hogy nem megfelelő. Ebben az esetben is érdemes composable szemléletet követnünk.
Hogyan épül fel jellemzően?
A composable commerce receptjének egyik összetevője a frontend alkalmazás, amellyel a látogatók érintkeznek. Monolit rendszerek esetén a felhasználói felület jellemzően az engine része, annak elválaszthatatlan, szerves eleme. Ahhoz viszont, hogy a felhasználó számára több háttérrendszerből egy egységes felhasználói élményt nyújtsunk – úgy, hogy a látogató nem is tudja, éppen melyik rendszer komponens szolgálja ki – a frontend felületet is platform függetlenné kell tennünk. Ehhez el kell választanunk egymástól a felhasználói felületet (frontend) az alkalmazási logikától (backend). Ezt hívjuk “headless” megoldásnak: a composable architektúra szétválasztja a prezentációs réteget a kereskedelmi motortól – utóbbi “lefejezésével”.
A prezentációs réteg kialakítására a legjobb megoldás egy PWA (progressive web application) bevezetése. Ez a felület képes REST API vagy GraphQL kapcsolaton keresztül több háttérszolgáltatást egyetlen rendszerként a felhasználói elé tárni. A PWA tehát az az egységes frontend alkalmazás, amelyben például egy webshopból, CMS-ből, CRM-ből, bármilyen third party szoftverből egyszerre futnak össze az adatok.
A composable commerce egy másik fontos összetevője a motorháztető alatt lakik. A sok üzleti funkció backend folyamatainak zökkenőmentes integrációja költséges és fájdalmasan lassú, ha minden egyes alkalmazást egyesével kötünk össze egymással. Viszont előveszünk egy integrációs platformot, amelynek szerepe, hogy központi hubként különböző szolgáltatásokat hozzon szinkronba egymással, akkor sokkal könnyebb dolgunk van. Szükséges egy “single source of truth”, amely az összes adatot zökkenőmentesen szinkronizálja az összes csatorna irányába, ezredmásodperceken belül. Az OANDER-ben többek között ezért fejlesztettünk ki egy olyan automatizációs platformot, ami egymástól radikálisan különböző üzleti alkalmazások integrációjára alkalmas.
Végezetül természetesen szükségünk van magukra az alkalmazásokra. Azokra az egymástól szétválasztott szolgáltatásokra, amelyeket integráció révén egymással összhangba hozunk és a PWA felületen keresztül a felhasználó elé tárunk. Ebben a körben bármi elképzelhető. Jó eséllyel megtalálunk majd itt egy lecsupaszított, headless webáruház motort, amely a katalógust és a vásárlási folyamatokat szolgálja ki. Az sem ritka, hogy a checkout folyamat már egy külön, optimalizált alkalmazásban történik. Jellemző, hogy a tartalommarketing eszköztárat egy ugyancsak headless CMS szolgálja ki és szinte biztos, hogy a marketing automatizációk vagy intelligens ajánlórendszerek is a webshoptól független szoftverek integrációjával futnak. Önálló alkalmazás lehet a termékinformációk kezelése, a különböző payment gateway-ek, hitelkalkulátorok vagy éppen ügyfélszolgálati funkciók. Ahány vállalat és célpiac, annyiféle “kompozíció”.
Hogyan lássunk neki?
Joggal merül fel a kérdés, hogy hogyan tudnánk átállni a meglévő monolitikus rendszerünkről egy composable megoldásra. A két architektúra közötti különbség első ránézésre akár még ijesztő is lehet. Nos, semmiképpen sem úgy, hogy nulláról elkezdjük újrafejleszteni a rendszerünket. A monolitikus struktúráról fokozatosan áttérhetünk egy composable architektúrára anélkül, hogy az évek során megszerzett értékes üzleti logikáinkat kidobnánk. Kezdjük a frontend és a backend szétválasztásával (headless commerce)! Amikor ezzel készen állunk, tegyük meg a következő lépést azzal, hogy lassan, fokozatosan lecseréljük az egyik szolgáltatást a másikra. A composable commerce-re való transzformáció egy folyamat, nem pedig egy időpillanat.
