Aviva Solutions realiseert al jaren e-commerce oplossingen. We werken vaak met All-in-One platformen zoals Sitecore en Kentico, maar bouwen ook steeds vaker Composable Commerce platformen. Deze type platformen spelen in op verschillende behoeften, waardoor het belangrijk is helder te hebben wat je van je platform verwacht. Een All-In-One wordt vaak gezien als een iets beperkter maar gebruiksvriendelijker platform, terwijl Composable Commerce meer inspeelt op personalisatie en schaalbaarheid. Grote bedrijven, die vaker veranderende behoeften hebben, halen daarom vaak meer voordeel uit een Composable Commerce platform.
Zijn er nog belangrijke verschillen bij een Composable Commerce project, waar je als projectmanager rekening mee moet houden? Het korte antwoord is: ja, er zijn zeker verschillen. We zetten vier belangrijke aandachtspunten op een rij.
1: De juiste vendors selecteren
Het traject om de juiste services uit te kiezen maakt een groot verschil in de projectplanning. In tegenstelling tot de keuze voor een All-in-One platform, waarbij de vendor (en daarmee de architectuur) direct bekend zijn, moet na de keuze voor een Composable platform eerst nog de vendors en services geselecteerd worden en de architectuur bepaald worden. Dit betekent dat deze twee platformen een ander (voor) traject hebben.
De serviceselectie wordt gebaseerd op de functionele en non-functionele eisen die gelden voor het totale commerce platform. Om dat te kunnen doen, worden de eisen verdeeld per service type (zoals commerce of search) en maken we per service type een short list – een selectie van vendors die aan alle eisen voldoen. Daarna bekijken we de shortlist van services in detail en bepalen we in welke mate zij passen bij de eisen van de klant. In dit proces worden ook de interne gebruikers bij onze klant betrokken, zoals marketeers of product managers, zodat we zeker weten dat de services die zij gaan gebruiken ingericht kunnen worden op een manier die zij prettig vinden.
Je hebt zelf dus volledige controle over de inrichting van je platform. Het voordeel is dat deze aanpak tot beter onderbouwde keuzes voor de services leidt, en het platform altijd perfect past bij je unieke wensen.
2: Meer aandacht voor architectuur en integratie
Omdat een Composable architectuur niet vooraf bepaald is, vergt het daarom meer aandacht in het begin. Een Composable platform bestaat over het algemeen uit meerdere headless services, een eigen front-end, en integraties tussen de diverse services. We zullen dus eerst moeten bepalen hoe alle services efficiënt met elkaar geïntegreerd kunnen worden. Dit moet per service geëvalueerd en geïmplementeerd worden, waardoor het belangrijk is om vroeg in het project helderheid te krijgen over de totale architectuur. Om het platform te gaan bouwen, werken we eerst de belangrijkste functionele- en kwaliteitseisen uit. Zodra we die helder hebben, kunnen we dat framewerk gaan invullen. Dat geeft houvast tijdens het project.
3: Meer partijen, meer communicatie
Omdat een Composable platform normaliter uit meerdere services bestaat, hebben we voor de planning en afstemming binnen het project dus te maken met meerdere partijen. Dit heeft voor- en nadelen. Het voordeel is dat deze partijen gespecialiseerd zijn op hun gebied en dat vraagstukken daardoor altijd heel gericht besproken kunnen worden. Tegelijkertijd moet je als projectmanager wel rekening houden met meer partijen, die allemaal een effect op de projectplanning kunnen hebben. Dit vergt afstemming met meerdere support engineers, op verschillende communicatiekanalen, met allemaal een andere werkwijze en support organisatie.
