Een microservices architecture, wat betekent dat eigenlijk in de praktijk? Wat zijn enkele nieuwe trends binnen dit onderwerp en hoe zien de teams eruit? We bespreken het in het derde (en laatste) deel van onze serie over composable architecture.
Mis ook onze inzichten in deel 1 en deel 2 niet!
Een platform-based aanpak in het digitale tijdperk
Digitale aanwezigheid is vandaag veel meer dan een e-commercewebsite. De volledige klantreis bestaat uit veel touchpoints, zoals selfservice, verkooppunten (POS), schermen in een fysieke winkel, click & collect, een mobiele app, klantenservice, dienst na verkoop en nog veel meer. Elk van deze systemen wordt met de dag geavanceerder. Wanneer één systeem te veel dependencies ondersteunt, zoals je ERP-systeem of je e-commerceplatform, vormt dat een uitdaging voor bedrijven.
Een platform-based aanpak verwijst naar een e-commerceoplossing die rond een bestaand platform wordt gebouwd, met een groot aantal kant-en-klare functies die aangepast worden aan je bedrijf. Technisch gezien kunnen alle oplossingen uitgevoerd worden vanuit één e-commerceplatform. Er is echter een keerzijde. Hoe complexer je e-commerceactiviteiten worden, hoe vaker je te maken krijgt met obstakels:
- Het platform wordt steeds uitgebreid met taken die niet langer strikt met e-commerce te maken hebben.
- Een aanpassing aan een touchpoint vereist altijd een aanpassing aan het e-commerceplatform, wat extra stappen en complexiteit met zich meebrengt.
- Soms moet je informatie naar het e-commerceplatform sturen die anders niet nodig is, waardoor er capaciteit verloren gaat en wat een impact kan hebben op je order management.
- Als het e-commerceplatform uitvalt, werkt geen van je andere systemen. Natuurlijk moet je ook plannen voor een ‘gedeeltelijke uitval’ wanneer je voor een microservices architecture kiest, maar de gevolgen zijn vaak minder groot dan met een platform-based architecture.
Microservices architecture en moderne e-commerceoplossingen
In dit blogartikel verwijzen we naar ‘composable architecture’ en ‘microservices architecture’ door elkaar. Een composable architecture is namelijk gebaseerd op het concept van microservices, waarbij de verschillende services en functies worden opgedeeld in agnostische bouwstenen die onafhankelijk van elkaar kunnen werken.
Met een composable aanpak kun je onafhankelijk van elkaar aan verschillende elementen werken en beter schalen. Een project om je winkelschermen te verbeteren kan bijvoorbeeld gespecialiseerde tools vereisen. Als je een platform-based architecture hebt, kun je voor een uitdaging komen te staan als je e-commerceplatform de benodigde tools niet ondersteunt.
Met een microservices architecture ziet die situatie er helemaal anders uit. Je commerce-engine biedt alleen transactiemogelijkheden voor je winkelschermen, terwijl de rest ontkoppeld blijft. Dit betekent dat content direct naar de schermen in je winkel kan worden gestuurd zonder dat het via je e-commerceplatform moet en je vrij bent om nieuwe tools en functies te implementeren.
Laten we van dichterbij bekijken in welke gebieden van e-commerce een microservices architecture het verschil kan maken.
1. Trends in microservices architecture
Veel bedrijven zijn vandaag minder bang om te experimenteren: denk bijvoorbeeld maar aan ‘magische spiegels’, waarmee je via een scherm digitaal kleding kunt passen, of de vele toepassingen van augmented reality waarmee klanten een product kunnen visualiseren in hun eigen ruimte.
Sommige van deze nieuwigheden kunnen we niet langer ‘trends’ noemen, maar zijn al goed ingeburgerd bij consumenten. Andere zijn dan weer van tijdelijke aard of zijn niet aantrekkelijk genoeg voor consumenten. Eén ding is zeker: elke dag duiken er nieuwe trends op, zeker met het snelle tempo waaraan technologie evolueert. Grote bedrijven, zoals Amazon, zetten de standaard voor gebruiksgemak en klanten verwachten al snel dat ook hun favoriete retailers en merken gebruikmaken van nieuwe functies.
Investeer echter niet alleen in een e-commerceplatform omwille van trends die misschien niet lang populair zullen zijn. Een microservices architecture maakt het eenvoudiger om te experimenteren en houdt componenten licht. Bovendien geeft een aanpak met microservices je bedrijf de nodige ruimte om te groeien en schalen. Niemand kan voorspellen welke e-commercefuncties klanten over tien jaar leuk zullen vinden, maar een microservices architecture zorgt ervoor dat je je oplossing steeds kunt aanpassen aan je klanten.
2. Microservices architecture: PIM, POS en de commerce-engine
Bij een traditionele platform-based aanpak is de commerce-engine het ‘hart’ van de oplossing. Alle andere systemen en componenten, zoals het PIM-systeem en POS-systeem, zijn hieraan gekoppeld. Deze aanpak legt niet alleen onnodige druk op de commerce-engine, maar creëert ook een hechte integratie. Deze koppeling is namelijk moeilijk te ‘ontwarren’ wanneer het tijd is om een component te vervangen.
Een microservices architecture zorgt voor een lichte integratie en vermijdt extra belasting van het e-commerceplatform. Je PIM-systeem kan bijvoorbeeld productinformatie direct in je kassa invoeren, zonder dat het ooit langs de commerce-engine hoeft. Deze methode zorgt ook voor meer flexibiliteit. Als je je PIM, POS of commerce-engine wilt vervangen, kun je elk onderdeel eenvoudiger wijzigen zonder dat je elke integratie opnieuw hoeft op te bouwen.
3. Microservices architecture: prijslogica
Geavanceerde prijslogica brengt vaak complexiteit met zich mee. Wanneer verschillende systemen prijsgegevens vereisen, is het opnieuw implementeren van prijsregels duur uitvallen en is er een groot risico op fouten. Denk bijvoorbeeld maar aan afronding, korting en belastingen: het kan ingewikkeld zijn om alles op een correcte manier te implementeren.
Met een microservices architecture kan de prijslogica een speciale service zijn die door alle andere systemen wordt gebruikt, waardoor het opnieuw implementeren van logica, dubbele gegevens of inconsistenties tussen systemen wordt vermeden.
Teamwork: microservices vs. platform-based
Nu we weten wat de voordelen van een microservices architecture zijn voor e-commercebedrijven, kunnen we bekijken hoe deze aanpak teamwork kan bevorderen.
Hoe teams met een platform-based architecture werken
Bij een klassieke platform-based architecture werkt meestal één team aan het platform en alle functionaliteiten. Op deze manier is het duidelijk is wie verantwoordelijk is. Dat kan echter ook zijn nadelen hebben, omdat er zoveel dependencies zijn.
Bijvoorbeeld: één development-team werkt aan één platform. In dit geval gaat het om een team van zogenaamde ‘generalists’, die kennis moeten hebben van de volledige oplossing en de backlog moeten coördineren, met een grote verscheidenheid aan functies. Omdat de workflow vaak niet het eigendom is van het development-team, prioriteren zij de binnenkomende ‘tickets’ en niet het bedrijfsdomein. Deze voortdurende herprioritering, als gevolg van de eindeloze vraag van bedrijven om zich aan te passen, kan resulteren in veel onvoltooid werk in het systeem. Het is duidelijk dat resources in dit scenario niet optimaal ingezet worden.
In zeer kleine organisaties kan dit team eigenaar zijn van het resultaat, maar zodra dergelijke organisaties beginnen te groeien, is het team meestal niet langer verantwoordelijk voor het bedrijfsresultaat en de technische oplevering. Een organisatie kan ervoor kiezen om meerdere, cross-functionele teams te hebben die werken aan één platform. Dit concept zorgt voor minder brede ervaring op alle gebieden van het platform, waarbij elk team gespecialiseerd is in één gebied.
Hoewel elk team meer controle heeft over hun backlog, vereist dit model nog steeds een sterke coördinatie en afhankelijkheid tussen teams. Releases vinden namelijk nog steeds plaats op één enkel systeem. Het releaseproces moedigt een opeenvolging of bundeling van werk aan, wat er dan weer voor zorgt dat onvoltooid werk zich opstapelt.
Hoe teams met een microservices architecture werken
Met een microservices architecture heb je de vrijheid om je team op te delen in meerdere kleine teams of zelfs samen te werken met meerdere partners. Elk team heeft in dat geval een duidelijke uitlijning van de verantwoordelijkheden. Digitale koplopers, zoals Facebook en Amazon, werken allemaal op deze manier. Je hebt misschien wel van de befaamde ‘two-pizza teams’ van Amazon gehoord. Elk team is niet groter dan het aantal personen dat samen twee pizza’s kan eten.
Bij een microservices architecture leveren meerdere teams elk hun eigen componenten. De teams werken onafhankelijk van elkaar en elk team heeft zijn eigen processen en tempo voor releases. Als een release van één team bijvoorbeeld wordt uitgesteld, heeft dat veel minder impact op andere teams dan met een platform-based architecture.
Dat componenten niet langer afhankelijk zijn van elkaar, betekent echter niet dat verschillende teams niet met elkaar communiceren. Het contentteam moet bijvoorbeeld nog steeds informatie krijgen van het team voor promoties, zodat ze op de hoogte zijn van de huidige promoties. De frontend kan vervolgens content kiezen op basis van promoties die relevant zijn voor een bepaalde webpagina.
Meerdere processen voor releases zijn waarschijnlijk niet ‘goedkoper’ op de lange termijn, maar leiden wel tot meer efficiënte development en betere resultaten. De voordelen wegen op tegen de kosten, want een snellere time-to-market voor nieuwe functionaliteit en diensten is een win-win voor iedereen.
Autonome productteams binnen een microservices architecture
Laten we tot slot een alternatieve manier van werken binnen een microservices architecture bekijken.
Om voort te bouwen op het concept van meerdere teams, kun je met een microservices architecture kiezen voor autonome productteams. Dit is niet de enige manier om je team te organiseren binnen een microservices architecture, maar het is een goed voorbeeld van de mogelijkheden die deze architecture kan bieden.
Autonome productteams hebben geen strikt software- of IT-teams die aan verschillende bedrijfsdoelen werken. Elk team vertegenwoordigt één bedrijfsdoel. In de meeste gevallen wordt een team gevormd door personen die een specifieke zakelijke opportuniteit hebben geïdentificeerd.
Deze teams zijn volledig autonoom, met alle rollen die ze nodig hebben om hun beoogde resultaat te bereiken, zowel technisch als niet-technisch. Ze rapporteren niet aan iemand anders en ze zijn van niemand anders afhankelijk, ook niet voor goedkeuring over het gebied waaraan ze moeten werken of hoe ze hun doelen moeten bereiken. De productteams worden voornamelijk beoordeeld op hun resultaat.
Autonome productteams zijn:
- Cross-functional, in een bredere zin dan wat we vaak zien bij IT-teams. Ze hebben niet alleen technische functies, maar ook logistieke experts, supply chain-experts, productontwerpers en nog veel meer. De teams bevatten iedereen die nodig is om dat bedrijfsonderdeel tot een succes te maken.
- Gespecialiseerd, omdat ze aan specifieke functies werken. Dat kan bijvoorbeeld gaan om last-mile fulfillment, promoties, personalisatie, loyaliteitsprogramma’s en nog veel meer.
- Domeinexperts. Historisch gezien waren de meeste thought leaders op het gebied van softwareontwikkeling eerst domeinexperts. Software was ‘slechts’ de tool die ze gebruikten. Het oplossen van een probleem met het domein was het einddoel. In de IT-wereld van vandaag kennen we het domein meestal niet. We leren zoveel als nodig is, maar het komt op de tweede plaats na technologie en softwareontwikkeling. Het bouwen van teams op basis van domeinexpertise en het samenstellen van hun werk brengt ons dichter bij de klant en het probleem. Zelfs technische rollen, die in het begin misschien geen domeinexperts zijn, hebben een sterke stimulans om experts in het specifieke domein te worden. Dergelijke teams hebben namelijk de neiging om lang rond dat specifieke domein te blijven bestaan. Natuurlijk wordt het team beoordeeld op het resultaat binnen dat domein (in plaats van op technische prestaties).
Conclusie: een microservices architecture geeft bedrijven heel wat flexibiliteit
Een microservices architecture biedt veel meer dan alleen de mogelijkheid om te schalen en de beste tools te gebruiken. Deze aanpak zorgt voor efficiëntie binnen teams en in de manieren waarop teams samenwerken. Autonome teams zijn minimaal afhankelijk van andere teams, zodat ze sneller en efficiënter kunnen werken. Deze methode kost misschien niet minder dan een platform-based architecture, maar het is het waard vanwege de extra snelheid en resultaten.
De overstap naar een microservices architecture lijkt groot, maar het team van Vaimo kan je na de nodige analyse vertellen of deze verandering het waard is. We begeleiden je doorheen het volledige proces en kiezen de beste werkwijze en tools voor je bedrijf.
Als je deskundig advies nodig hebt over microservices architectuur, aarzel dan niet om vandaag nog een kennismaking in te plannen met onze experts. Met meer dan 15 jaar ervaring in digital commerce en het creëren van een briljante klantervaring, hebben we een goed inzicht in alles wat bij e-commerce komt kijken. We hebben al talloze klanten geholpen bij het implementeren van een headless en microservices architecture om hun bedrijf te schalen en hun klanten de best mogelijke klantbeleving te bieden.
Laten we je digital commerce samen naar een hoger niveau tillen!
