De laatste tijd wordt er veel gesproken en geschreven over het digital experience platform (DXP) in het algemeen, en meer specifiek over het bouwen van een DXP op basis van een MACH- of composable-architectuur, waarbij MACH voor Microservices, API-first, Cloud-native SaaS en Headless staat.
Het is echter de vraag of er een echt verschil bestaat tussen deze twee architecturen. En des te meer ik hierover lees, des te meer ik geneigd ben te zeggen dat dit niet het geval is. Er zijn wel degelijk verschillen, maar het probleem dat beide architecturen aanpakken blijft hetzelfde. Omdat klanten hier steeds vaker vragen over stellen, licht ik dit onderwerp graag toe.
Composable DXP: Oude wijn in nieuwe zakken
Het voelt een beetje als een oude IT-gewoonte. Zodra er iets nieuws wordt bedacht, wordt het door allerlei leverancier(s) of onderzoeksbureaus zoals Forrester of Gartner, geclaimd. Na wat kleine aanpassingen, gebruiken ze hiervoor vaak een eigen naam. Dit maakt het soms verwarrend en onduidelijk of het nu over hetzelfde of toch over iets anders gaat.
Digital Experience Platform (DXP)
Over het digital experience platform is men het in grote lijnen eens, namelijk dat we niet in een tijdperk leven waarin één enkel, monolith, digital experience platform kan zorgen voor een volledige end-to-end ervaring van een customer journey. Met een customer journey bedoel ik: branding, targeting, engagement, het leveren van producten, diensten en aftersales aan een bepaalde klant, het behoud van de klant en hem een ambassadeur van je merk maken. Daarnaast omvat een DXP de implementatie van digitale mogelijkheden die nodig zijn om je te helpen bij dat deel van de customer journey dat je op geïntegreerde wijze wilt ondersteunen zodat je klanten een probleemloze en waardevolle ervaring krijgen.
Maar er is niet één alles omvattende definitie van een DXP; het gaat om de breedte van de customer journey dat je wilt ondersteunen evenals de diepte en gepersonaliseerde intensiteit, waarmee je dat wilt doen.
We kunnen een DXP dus beschouwen als een soort referentiearchitectuur die je kunt gebruiken en waarvan je weet dat de manier waarop je die toepast in de loop van de tijd zal veranderen, bijvoorbeeld wanneer je je bedrijfsmodel verandert. Of zodra klanten bijvoorbeeld een nieuwe technologie gaan gebruiken.
MACH en je composable DXP
Dus, als je flexibiliteit nodig hebt in je DXP-architectuur, zowel nu als in de toekomst, en bovendien overzicht en grip wilt houden op je investeringen, dan is een DXP – dat alleen bestaat uit een functionaliteit die op een bepaald moment nodig is – de ‘way to go’.
Specifieke functionaliteitsbehoeften (bijvoorbeeld naar aanleiding van de overgang van een indirect kanaal naar een meer hybride direct kanaal in de detailhandel) kunnen in de loop van de tijd veranderen. Dit betekent dat je de mogelijkheid moet hebben om die functionaliteit vrij snel te kunnen isoleren en te vervangen om gelijke tred te houden met veranderende bedrijfsbehoeften.
Hetzelfde geldt voor nieuwe functionaliteitsbehoeften, bijvoorbeeld wanneer je groeit naar een meer geautomatiseerde manier van werken op basis van hyperpersonalisatie door gebruik te maken van een Customer Data Platform in combinatie met AI.
Dit gebruik van een composable DXP is alleen mogelijk als je DXP, naast de samenstelbare DXP-functies, over twee basiselementen beschikt:
- Een tussenlaag tussen de composable DXP-functionaliteit bestaande uit API’s die verbonden kunnen worden met een DXP-functionaliteit (zoals je commerce- of CRM-applicatie) en een set van (micro)services.
- Een headless-benadering. Alles draait om klantinteractie, waardoor elke app die nodig is op basis van headless-principes ontwikkeld dient te worden, waardoor ze in principe technisch onafhankelijk zijn van elke onderliggende composable DXP-functionaliteit. Vanuit architecturaal oogpunt geeft dit je de flexibiliteit om zowel headless klantinteractie apps en/of composable DXP-functionaliteit uit te wisselen wanneer nodig.
Communicatie met klanten in een digitale wereld, en met de benodigde ondersteuning van een DXP dat uit meerdere samenstelbare DXP-functies bestaat, vraagt vanuit een technisch oogpunt mijns inziens om een cloudplatform.
Bij het noemen van microservices (voor koppelingen), API’s naar composable DXP-functionaliteiten, de cloud en headless apps om met klanten op een flexibele manier te communiceren, en om te voldoen aan klantgedreven behoeften en verwachtingen komen we automatisch uit bij een MACH-omgeving.
Het implementeren van een succesvol en duurzaam composable DXP leidt automatisch naar ‘MACH by design’. Een composable DXP-functionaliteit is veel meer dan een composable conventional DXP-functionaliteit zoals content management, commerce, campaigning, (e-mail) marketing, etc. Data (via een customer dataplatform) zal altijd de belangrijkste succesfactor van een DXP zijn. En met als bij een MACH-ontwerp, moet je customer dataplatform vanaf het begin deel uitmaken van je DXP-oplossing.
Waar een MACH-ontwerp de mogelijkheid biedt om elementen (composable DXP-functionaliteit) binnen je digital experience platform te verbinden om met je klanten te communiceren, geeft je customer data platform inzicht in hoe je deze in de juiste volgorde kunt zetten.
Microservices, API’s, cloud – komt dat bekend voor?
We hebben microservices, API’s en cloudtechnologie nodig om elk systeem binnen je DXP met elkaar te verbinden. Hoe meer ‘breedte en diepte’ je wilt en nodig hebt van je DXP om de customer journey te ondersteunen, hoe meer het andere systemen, zoals je CRM- SCM-, ERP-systeem of je zakelijke apps, raakt.
Mits je geen platform hebt om je dagelijkse activiteiten te ondersteunen, beschik je over een hybride set van systemen: van gestandaardiseerd tot maatwerk. In feite is dit ook een soort van een composable architectuur, hoewel het minder dynamisch is dan binnen het DXP-domein.
Om deze systemen met elkaar te verbinden gebruiken we al tientallen jaren een middle-layer-architectuur. Ergens in de tijd is dat geëvolueerd tot een enterprise service bus en vervolgens uitgegroeid tot een API/(micro)services-laag, die we vandaag de dag nog steeds toepassen.
Maar ook in de meer klassieke backend-wereld is er behoefte aan meer flexibiliteit. Denk bijvoorbeeld aan een low-code enterprise applicatie waardoor medewerkers meer agile kunnen reageren op de veranderende behoeften en het veranderend gedrag van klanten. Deze trend versterkt de behoefte aan een volwassen middenlaag, die door zijn structuur meer en meer een cloud-setting vereist om te kunnen bestaan. We hebben dus een parallel met een van de basiselementen van het DXP. Deze ‘digital operations setting’ wordt door de onderzoekbureaus momenteel aangeduid als een Digital Operations Platform.
Dit is in principe goed nieuws. Want wanneer je jouw DXP uitbreidt naar je operationele digitale systemen, zul je merken dat (inter)verbinden vanuit architecturaal oogpunt niet veel anders is dan binnen een composable DXP-setting.
Haal maximale waarde uit je DXP-platform
Wanneer je eenmaal de eerste stappen hebt gezet naar een DXP heb je een flinke ‘milestone’ bereikt. Maar, dan ben je nog niet klaar. Want hoe zorg je ervoor dat het platform op de lange termijn waarde blijft toevoegen? Daarvoor is een doordachte implementatie nodig en is maximale adoptie noodzakelijk. Daarnaast moet je je afvragen of je de juiste competenties in huis hebt en hoe het binnen een flexibel applicatielandschap past. In dit whitepaper gaan we in op de uitdagingen van een DXP voor de CTO en de CMO en bieden we je 4 handvatten om maximale waarde uit je platform te halen.
