Vi får många förfrågningar från företag som upplever att deras e-handelsplattform begränsar deras möjligheter till affärsutveckling. De talar vanligtvis om dålig prestanda, lång implementeringstid för ändringar, låg flexibilitet och skalbarhet och höga kostnader.
Om du också upplever dessa utmaningar är den här artikeln extremt relevant för dig.
Det visar sig ofta att orsaken till problemen är bristande strategi på plattformen – eller att strategin helt enkelt har misslyckats eller helt enkelt inte upprätthålls.
Oftast upplever vi att företaget har valt en relativt standardiserad lösning i början. Med tiden har det varit frestade att kontinuerligt anpassa så stora delar att plattformen blivit dyr att underhålla och skala för tillväxt.
I den här artikeln kommer vi att prata om hur många av våra kunder som övervinner dessa utmaningar genom att införliva det bästa av två världar – den fasta suite-lösningen och en komponerbar lösning.
3 typer av strategier
Låt oss först ta en titt på de tre allmänna kategorierna som vi kan dela in strategierna i: suite (svit), composable (komponerbar) och mellanbarnet som kallas mixed.
Tankegången i suites är, att du genom din licens köper många funktioner från samma leverantör och att du växer din verksamhet inom ramen för 'sviten'. Med denna lösning har du möjlighet att komma igång snabbt och det kan vara en fördel för dig att ansvaret för säkerhet, underhåll och utveckling ligger hos svitens leverantör.
En standardsvit kan till exempel vara Shopify, och av företagssviter kan vi nämna HubSpot och Salesforce, som särskilt fokuserar på leadsgenerering och avancerad marknadsföring.
I andra änden av skalan ligger composable, som är baserad på den bästa metoden. Här väljer du inte en komponent (leverantör) utan en samling komponenter som är integrerade generiskt så att de potentiellt kan bytas ut om de inte längre är tillfredsställande.
Du kan med andra ord välja exakt de komponenter som är mest meningsfulla för ditt företag och sätta ihop en skräddarsydd lösning.
Denna strategi är särskilt relevant för företag med komplexa behov som vill ha en flexibel lösning som kan skalas efter marknadens behov..
I den här artikeln kommer vi att titta på vår Magento-lösning som ett populärt alternativ inom blandade plattformar. Vi visar dig hur denna lösning kan vara ett pragmatiskt alternativ till rent komponerbart och samtidigt använda MACH-principerna.
Vår Magento-lösning riktar sig till medelstora och stora företag som har en viss komplexitet i sin verksamhet (t.ex. kring sitt sortiment) och som vill ha ett stort ägande av sin lösning.
MACH – M för Microservices
Microservices är den första hörnstenen i MACH. Konceptet har uppstått som ett alternativ till den traditionella monoliten (en enhetlig kodbas).
Situationen är att när en kodbas får en viss senioritet och komplexitet ökar risken exponentiellt.
Komplexiteten gör det väldigt dyrt att göra även små ändringar, eftersom det är svårt att se var korrigeringen behöver göras och vilken påverkan den har på resten av kodbasen.
Detta föder en ökad risk för fel, komplext att införa ny funktionalietet och ett högt personberoende
Som ett alternativ började därför funktioner läggas ut i mindre oberoende kodbaser som kan underhållas individuellt. Detta ger en större infrastruktur med krav på resurser och säkerhet, men samtidigt också skalbarhet, smidighet och framtidssäkring som är eftertraktad.
När vi utvecklar Magento-lösningar har vi stort fokus på prestanda och framtidssäkring. Därför råder vi våra kunder att hålla själva Magento relativt standardiserat och att lägga till större kundanpassade funktioner i mikrotjänster utanför Magento.
Det gör att Magento inte ägnar sig åt tunga processer som suger kraften ur plattformen, och det håller nere kostnaderna för Magento-uppgraderingar. Samtidigt minskar det risken, då vi kan distribuera ny kod till en mikrotjänst utan att det påverkar själva webbshoppen.
En mikrotjänst som vi alltid rekommenderar till våra kunder är vår generiska dataimportör, som kan hämta produktdata från vilken källa som helst, konsolidera den och leverera den effektivt till butikens produktkatalog.
Tjänsten hanterar kategorier, produkter, lagernummer, priser, relaterade produkter m.m.
Dessutom har vi bl.a. byggda mikrotjänster för automatiska prisjusteringar, optimering av logistikkapacitet och finkornig orderinsikt för kunder.
MACH – A för API first
Ett API (Application Programming Interface) är ett koncept för hur data kan utbytas mellan olika system (komponenter).
Om du sätter ihop dina komponenter konstruktivt med API:er kan du uppnå en komponerbar arkitektur, där du kan byta ut komponenter när de inte längre är tillfredsställande – även känt som "Best-Of-Breeds".
Det här kan vara ett riktigt sunt förhållningssätt till IT-arkitektur, där du håller dina möjligheter öppna och inte låser dig till specifika leverantörer.
API First är nästa steg. Här ingås de första "kontrakten" för datautbytena, eftersom det är grunden för att funktionaliteten ska uppnås.
Detta påminner lite om rörelsen vi såg för några år sedan, där man gick från "mobil" som funktion till det grundläggande designkonceptet "mobil först".
Magento 2 är inte API First eftersom det kommer med ett fördefinierat API. Vi använder detta för att enkelt och snabbt skapa integrationer för de tjänster som ska komplettera Magento-butiken.
För Novicells projekt gäller det ofta vår datatjänst som vi använder för att hämta produktinformation från exempelvis ERP- och PIM-system och leverera dem via API:t till Magento-katalogen. Det gäller även vår integration med Algolia, som säkerställer att vi kan leverera absurt snabba sökresultat och produktrekommendationer till användarna, samtidigt som vi lastar av Magento-resurser.
Enligt Gartners "Magic Quadrant” är Magento 2 högst upp i toppen bland de mest utbredda e-handelssystemen. Detta återspeglas bland annat i att det finns många leverantörer av tillägg som kan ge dig ett försprång i utvecklingen av funktioner i Magento och i integration med andra system.
Just nu finns det över 4000 tillägg för Magento 2 community-utgåva på Adobes marknadsplats. Det är till exempel standardintegrationer till tredjepartssystem inom betalning, frakt, marknadsföring och rapportering.
MACH – C för Cloud native SaaS
Vi utvecklar de flesta av våra lösningar i den licensfria Magento community-utgåvan (öppen källkod), som du kan välja att hosta traditionellt på premiss eller i molnet.
Som utgångspunkt hostar vi lösningarna hos Amazon Web Services i deras så kallade Serverless setup. Vi gör detta för att komma så nära SaaS-konceptet som möjligt, där hosting och drifttid inte ska vara en daglig utmaning, utan något som helt enkelt stödjer vidareutveckling.
Serverless ska inte tas helt bokstavligt, utan är ett uttryck för att Amazon Web Services (AWS) står för allt grundläggande underhåll av servrarna. Detta har resulterat i imponerande drifttidsstatistik för våra Magento-lösningar och och bra prestanda under trafiktoppar.
Det är också i vår AWS-setup som vi är värd för våra mikrotjänster. De ligger därför i samma infrastruktur som Magento-butiken, men i separata containrar som är oberoende av varandra och som automatiskt skalar upp och ner enligt individuella regler.
Det betyder att du får utmärkt prestanda samtidigt som kostnaden för hosting hålls på en överkomlig nivå, då du bara betalar för aktivt efterfrågade resurser.
MACH – H för Headless
Konceptet Headless handlar om att dela huvudet från kroppen – men oroa dig inte, det är inte alls så blodigt som det låter.
Traditionellt har man haft backend- och frontendkoden i samma kodbas, då man därmed snabbt kan komma igång med ett vanligt frontend-tema.
På vägen upplever man dock många utmaningar eftersom det är svårt att anpassa och optimera standardteman, som ofta är svåra att arbeta med.
Om du har en ambition att skapa dedikerade lösningar för användare på väldigt olika enheter eller med väldigt olika användarresor, så är headless rätt sätt. Här finns möjlighet till hög prestanda och mer frihet från de underliggande systemen.
Magento har under lång tid belastats av en tung och stel standardfront baserad på en gammal teknik. För att möta behovet av en modernare frontend är Magento nu förberedd med ett API som de nya frontends (heads) måste använda när man skapar headless.
Själva fronten är ofta byggd för att passa kunden. Så Magento 2 är därför förberedd för headless, men den kommer med ett ganska högt pris och time to market.
Om headless låter blodigt, så är Hyvä en allvarlig smärtstillande. Hyvä är ett nytt frontend-tema för Magento 2, som är extremt eftertraktat eftersom det ersätter det tunga standardtemat med modern, flexibel och blixtsnabb frontend-teknik.
Anpassningar, lyhördhet, sidhastighet och givetvis underhåll blir nu betydligt enklare för de som hanterar det rätt. På Novicell är vi stolta över att vi är den enda Hyvä-bidragsgivaren i Skandinavien, och vi ser så goda resultat på våra projekt att alla våra Magento-kunder så småningom har valt denna lösning.
Slutsats
Alla företag är olika. Det viktigaste är att hitta rätt strategi, ta vara på de möjligheter den ger och inte minst behålla den.
Våga tacka nej till vissa alternativ om det utmanar strategin på sikt. Du måste ta dig tid att utvärdera din arkitektur innan den blir ett riskabelt kostnadsställe istället för en affärshävstång. Det är viktigt att undvika "köp i tre år och börja om igen"-tendensen, utan välj istället en arkitektur som du kan se din verksamhet i under många år.
Fördelen med Magento 2 jämfört med svitlösningar är att du med öppen källkod får fullt ägande och därmed friheten att anpassa lösningen till din verksamhet. Baksidan av frihet är ansvar och i det här fallet är ansvaret bland annat att hosta och uppgradera Magento-lösningen. Friheten är givetvis inte lika stor som med fullt komponerbar/MACH, men å andra sidan är kraven också betydligt lägre. Magento 2 är en blandad lösning, som för många projekt kommer att ligga i en pragmatisk sweet spot mellan svit och komponerbar.
I vårt Magento-team har vi den nödvändiga kompetensen och erfarenheten för att hantera även de mest komplicerade utmaningarna.
