Bezint eer ge met een composable architectuur begint

Een composable architectuur in combinatie met een headless front-end is al jaren in opkomst en lijkt dé oplossing voor ieder type organisatie te zijn. Het is echter niet altijd de juiste keuze en organisaties zijn zich vaak nog niet bewust in welk avontuur ze zich storten. Het is daarom belangrijk om eerst een positieve business case te maken. 

Een composable architectuur biedt diverse voordelen ten opzichte van een traditionele aanpak, zoals het verhogen van de snelheid van de website en de mogelijkheid om best-of-breed ICT-oplossingen te kiezen. Mede daarom is composable architectuur de afgelopen jaren bij steeds meer organisaties onder de aandacht gekomen.

Toch zijn het lang niet altijd de inhoudelijke voordelen die voor organisaties de reden zijn om over te stappen. Een veel gehoorde onderbouwing is dat organisaties zien dat de concurrent met een composable architectuur aan de slag is en zij dat ook willen. Dat is een verkeerde redenering, want de keuze voor composable architectuur kan naast de voordelen ook de nodige nadelige gevolgen voor je organisatie met zich meebrengen.

Maak een positieve business case

Heel veel grote projecten mislukken omdat ze uiteindelijk niet opleveren wat aanvankelijk bedacht was. Een migratie naar een composable architectuur is bij uitstek zo’n omvangrijk project en heeft een grote impact op je organisatie, waardoor het automatisch een hoog risico met zich meebrengt.

Vaak zien organisaties wel de beloftes, maar kijken ze onvoldoende naar de kosten die gemoeid zijn om de mogelijke baten te realiseren. Meestal kijken deze organisaties nog wel naar de initiële implementatie, maar vergeten ze de impact die beheer, onderhoud en doorontwikkeling hebben in een dergelijke architectuur. Hierdoor kun je nog meer vastlopen dan met het oude systeem het geval zou zijn geweest.

Stort je daarom niet zomaar in het composable/headless-avontuur, maar ga eerst na of je een positieve business case kunt maken.

Waarom een composable architectuur?

Als je een doelstelling hebt die niet past bij wat je met een composable architectuur kunt bereiken, is dat hetzelfde als wanneer je een spijker met een schroevendraaier in de muur probeert te slaan. Het lukt wel, maar er zijn betere gereedschappen om het probleem op te lossen. Naar mijn mening zijn er twee belangrijke drijfveren om wel of niet voor een composable architectuur te kiezen, te weten snelheid en flexibiliteit.

Snelheid

Voor veel bedrijven ligt de focus van ontwikkeling op de snelheid van time to market. In dat geval is een traditioneel alles-in-één-systeem vaak de beste keuze. Een van de kenmerken van alles-in-één-systemen is dat daar grenzen aan zitten, omdat ze zijn gebaseerd op een template.

Binnen de grenzen van een template kun je heel snel ontwikkelen, maar een template zorgt er ook voor dat je als organisatie niet eindeloos digitaal kunt versnellen. Als het template de beperking wordt voor digitale versnelling, kan een composable architectuur de oplossing zijn. Bijvoorbeeld wanneer de traditionele oplossing niet verder verbeterd kan worden met personalisatie, of wanneer de website structureel te langzaam is.

In deze situaties is een composable architectuur de juiste denkrichting en zorgt het ervoor dat je de prestaties van je website en de online klantbeleving naar een volgend niveau brengt.

Flexibiliteit

Organisaties die zich snel willen aanpassen aan nieuwe omstandigheden, doen er ook goed aan om te kijken naar een composable architectuur. Flexibiliteit is namelijk de belangrijkste reden om over te stappen.

Heeft jouw organisatie bijvoorbeeld verschillende kanalen en zoek je de samenwerking tussen deze kanalen in een omnichannel-omgeving, dan kan een composable architectuur interessant zijn. Ook wanneer je als organisatie specifieke touchpoints wilt toepassen, kan een composable/headlless-aanpak uitkomst bieden.

De keuze voor een composable architectuur maak je niet op basis van een enkel probleem. Wanneer meerdere problemen zich opstapelen, zoals het vastlopen binnen het template, meerdere kanalen die worden gebruikt of specifieke touchpoints, neemt met elk extra probleem de rechtvaardiging van een composable architectuur toe en vergroot het de kans op een positieve business case.

Zet de juiste migratiestappen

Heb je eenmaal een positieve business case gemaakt en is de keuze op een composable architectuur gevallen, dan is het van belang om de juiste stappen te zetten.

Wat we regelmatig zien is dat partijen met de implementatie van een composable architectuur aan de achterkant beginnen en bijvoorbeeld een API-laag bouwen. Dit kost veel geld en zolang je daar niks bovenop zet en niet aan de slag gaat met de front-end, leveren die investeringen je niets op. Wat wij daarom adviseren is om kleine stapjes te zetten, waarbij de front-end onderdeel is van iedere stap. Met de front-end wordt namelijk het geld verdiend en op deze manier levert iedere stap ook direct iets op, waardoor de business case vroegtijdig in de praktijk kan worden getoetst.

Als je kleine stapjes zet, betekent dit dat de nieuwe en oude situatie moeten samenwerken. Voor een webshop kan een stap bijvoorbeeld zijn om te beginnen met het optimaliseren van een enkele productlijn. Deze wordt uit de oude webshop gehaald en in een nieuwe omgeving gezet, waarbij alles aan de achterkant (zoals het afrekenen) samenwerkt met de oude omgeving. Door je oude en nieuwe omgeving slim met elkaar te verbinden beperk je risico’s en verhoog je de flexibiliteit van het transitieproces. Deze aanpak noemen wij een hybrid transition (hybride overgang).

De flexibiliteit die deze aanpak biedt is een voordeel in onzekere tijden. Stel dat de economische omstandigheden ervoor zorgen dat je organisatie minder of zelfs geen middelen heeft om de transitie naar een composable architectuur af te maken, dan kun je op ieder moment het traject eenvoudig (tijdelijk) stopzetten zonder dat dit ten koste gaat van de klantbeleving en de gedane investeringen.

Een composable architectuur kan veel voordelen bieden, maar denk vooraf goed na over de ‘waarom’- en ‘hoe’-vraag. Hiermee voorkom je een hoop narigheid en desinvesteringen.

Over de auteur: Dirk Jan van der Pol is Senior Solution Architect bij Emakina (an EPAM company) .

Op de hoogte blijven van het laatste nieuws binnen je vakgebied? Volg Emerce dan ook op sociale media: LinkedIn, Twitter en Facebook.