De opkomst van het Composable DXP

Ongeveer sinds het begin van dit millenium werd digitale strategie voor veel bedrijven steeds belangrijker. Websites werden meer dan een visitekaartje, groeiden in functionaliteit, complexiteit en hoeveelheid content. Om dit beheersbaar te maken deden Content Management Systemen (CMS) hun intrede. In eerste instantie hadden zij een eenvoudig doel: het beheren van de inhoud van web pagina’s - teksten, afbeeldingen en links. Vaak was het simpelweg een user interface om een database te beheren.

Het opbouwen van de visuele presentatie van websites was in die tijd nog maatwerk. Hier speelde het CMS niet veel later op in: de visuele presentatie (rendering) van web pages werd een functionaliteit van het CMS. Gebruikers waren nu in staat om naast de inhoud ook de visuele opbouw van pagina’s te beheren vanuit hetzelfde systeem.

Naarmate websites steeds complexer werden en rijker aan functionaliteit, werden ook de Content Management Systemen verder uitgebreid. Mogelijkheden voor personalisatie, e-mailmarketing, customer profiling, analytics, A/B testing, multi-channel delivery, noem het maar op. Het CMS werd één systeem dat alle functionaliteiten bood die nodig waren voor het beheren van een complete digitale ervaring: Een Digital Experience Platform (DXP).

Twee voorbeelden van DXP’s waar we bij Human Digital mee werken zijn het Sitecore Experience Platform en Kentico Xperience. Beiden zijn gebaseerd op Microsoft technologie en bieden een alles-in-één oplossing voor een digitaal platform.

Nadelen van een “monolithic” DXP

De alles-in-één oplossing noemen we ook wel een monoliet, een monolithic DXP. Het biedt in veel gevallen een prima oplossing, maar er kleven ook nadelen aan waarvan we er drie toelichten.

Kan veel dingen goed, maar is in geen enkel de beste

Het monolithic DXP is een alleskunner. Het biedt veel functies die ieder een speficiek probleem oplossen. Als totaalpakket vaak een goede oplossing, maar ga je kijken naar de individuele functies dan kunnen deze zich over het algemeen niet meten met een product dat gespecialiseerd is in die ene functie.

Een simpel voorbeeld is de functie voor het beheren van media bestanden (digital assets) zoals plaatjes en filmpjes. Het monolithic DXP biedt hiervoor meestal een Media Library. Een basis oplossing voor het uploaden en structureren van je digital assets. Misschien met nog wat mogelijkheden voor resizing en cropping, maar daar houdt het meestal op.

Hoe verhoudt zich dat tot een gespecialiseerde DAM (Digital Asset Management) oplossing zoals Bynder? Bynder DAM biedt de mogelijkheid om immense hoeveelheden digital assets te beheren, daar meta data aan toe te kennen en daarmee doorzoekbaar te maken en om assets automatisch te transformeren met behulp van bijvoorbeeld filters. Functioneel biedt het vele malen meer mogelijkheden dan de gemiddelde Media Library van een DXP.

In dit voorbeeld is Bynder DAM een Best of Breed systeem; door zich te specialiseren in het oplossen van een gericht probleem kunnen zij zich daar volledig op focussen en komen ze tot de best mogelijke oplossing voor dat specifieke probleem. Iets wat voor een alles-in-één systeem niet opgaat omdat hierin de aandacht moet worden verdeeld.

Beperkt schaalbaar

Omdat alle functies van het DXP onderdeel uitmaken van één systeem is de schaalbaarheid beperkt.

Neem weer het voorbeeld van de Media Library. Wanneer het aantal digital assets groeit naar bijvoorbeeld 100.000 stuks, dan wil je idealiter alleen het Media Library onderdeel van het systeem opschalen, maar dat is alleen mogelijk als ook de rest van het systeem wordt opgeschaald.

De meer complexere platformen zoals Sitecore Experience Platform bieden de mogelijkheid om specifieke onderdelen van het platform los van elkaar op- en af te schalen, maar de granulariteit waarmee dit kan wordt bepaald door het DXP. Ook voor Sitecore XP is het bijvoorbeeld niet mogelijk om alleen de Media Library op te schalen zonder de andere content management functionaliteiten mee te schalen.

Zelfs met de mogelijkheid om speficieke onderdelen onafhankelijk van elkaar te schalen brengt dit nog een uitdaging met zich mee: je moet het zelf gaan opschalen! Meestal ben je zelf verantwoordelijk voor de hosting van het DXP en dus ook voor het opschalen van de infrastructuur. Cloud diensten zoals Azure bieden hiervoor geweldige tools, maar uiteindelijk moet je het nog wel zelf inrichten en het beheren.

Development kaders

De development methodieken en frameworks die je gebruikt voor de ontwikkeling van je digitale platform worden vaak gedicteerd door het DXP. Ontwikkel je een platform in Sitecore Experience Platform dan is het uitgangspunt Microsoft .NET Framework en C# (even heel zwart/wit genomen) en ontwikkel je voor Adobe CXM dan ligt de nadruk op Java.

De visuele presentatie van web pages wordt verzorgd door het DXP, maar daarvoor moet je je wel aanpassen aan de manier waarop dat systeem deze pagina’s opbouwt. Gebruikt het DXP bijvoorbeeld traditionele .NET Framework MVC voor componenten, dan heb je pech als jouw team gebruik wil maken van .NET Core.

Composable DXP

Met een Composable Digital Experience Platform bedoelen eigenlijk een DXP dat is samengesteld uit verschillende losse, best-of-breed en vaak op Software-as-a-Service (SaaS) gebaseerde systemen. Doordat de basis ligt in SaaS systemen is er vaak ook sprake van een cloud-native architectuur. Het uitgangspunt is dat alles in de cloud draait en dat de verantwoordelijkheid voor het functioneren, de beschikbaarheid en het schalen van de onderdelen van het Composable DXP bij de verschillende SaaS leveranciers ligt.

Best of breed

Een van de grootste voordelen van een Composable DXP ten opzichte van een monolithic DXP is dat je voor ieder specifiek doel een product kan uitzoeken wat de best mogelijke oplossing biedt voor dat doel in combinatie met jou organisatie. Het is bijvoorbeeld niet zo dat Bynder DAM perse de beste DAM oplossing is voor iedere organisatie en scenario. Misschien heeft jouw business specifieke wensen waarvoor Sitecore Content Hub DAM een betere oplossing biedt. Met een Composable DXP heb je de vrijheid om zelf te kiezen.

Voorbeeld

De mogelijke combinaties die tot een Composable DXP leiden zijn eindeloos. Hieronder hebben we een voorbeeld uitgewerkt van een combinatie van producten die samen één DXP vormen.

• Content Management: Kentico Kontent
• Digital Asset Management: Bynder DAM
• Personalisation & Testing: Uniform
• Forms Builder: Jotform
• Email Marketing: Sitecore Send
• Search: Elastic Site Search
• Analytics: Google Analytics
• Front-end: Next.js
• Site hosting: Vercel
• Code repository: GitHub

Zoals je ziet zijn we vrij in de keuze van systemen en kun je daardoor kiezen voor precies dat systeem wat het meest geschikt is voor de taak en het best past bij jouw organisatie.

Schaalbaarheid

Wanneer specifieke onderdelen van het systeem meer capaciteit vereisen, bijvoorbeeld een DAM dat groeit door het aantal assets of een CDN omdat er meer verkeer op de site komt, dan wordt hierin voorzien door de SaaS dienst die dit onderdeel verzorgd. Deze horizontale schaalbaarheid is niet langer jouw technisch probleem, maar ligt volledig bij de SaaS leveranciers.

Heeft je organisatie naar verloop van tijd meer wensen? Dan kunnen daar nieuwe systemen voor worden toegevoegd aan het composable platform.

Minder vendor lock-in

In het scenario van een monolithic DXP wordt je snel afhankelijk van één leverancier, namelijk die van het DXP. Wanneer je alle onderdelen van een DXP gebruikt zijn na verloop van tijd al je content items, assets, customer data en email marketing data opgeslagen in één systeem. Alle maatwerk code die nodig was om de backend en frontend van jouw platform te laten functioneren zijn afhankelijk van de frameworks en SDK die door de DXP vendor is geleverd. Hierdoor wordt het je ontzettend moeilijk gemaakt wanneer je (een deel van) het platform wilt migreren naar een ander product van een andere vendor. Er is dus sprake van vendor lock-in.

Doordat de onderdelen van het composable platform uit op zichzelf staande producten bestaat is het veel gemakkelijker om één van die producten te vervangen zonder dat hiervoor het gehele platform op de schop moet. Voldoet de DAM niet meer aan je wensen? Dan vervang je de DAM, maar blijf je gewoon gebruik maken van hetzelfde CMS, dezelfde personalisatie engine en dezelfde e-mail marketing tooling.

Performance

Een Composable DXP gaat hand in hand met de Jamstack architecuur. Zonder er meteen een heel technisch verhaal van te maken (dat bewaren we voor een volgend artikel): dit is een architectuur voor websites die grootendeels vooraf gegenereerd en dus statisch zijn, waardoor ze rechtstreeks vanaf een Content Delivery Network (CDN) kunnen worden geserveerd. Hierdoor wordt de best haalbare performance mogelijk.

Doordat Jamstack sites vooraf gegenereerd worden hoeft er aan de server zijde niets meer te gebeuren wanneer een bezoeker een pagina oproept. Dynamische onderdelen worden aan de browser zijde afgehandeld en ingeladen vanuit API’s.

Niet alleen zijn de reactietijden van je website hiermee laag, ook de kosten voor hosting van Jamstack websites zijn heel laag; je hebt al geografisch gedistribueerde “edge” hosting met 1 TB bandbreedte voor $20 per maand via diensten als Vercel en Netlify.

Technische vrijheid

Als laatste willen we nog even benoemen de technische vrijheid die je geniet bij het ontwikkelen van een composable platform. Alle diensten die het platform vormen worden met elkaar geïntegreerd via API’s waardoor het niet uitmaakt welke techniek er tussen die API’s in zit. Gaat de voorkeur van je ontwikkelteam uit naar Python, dan knoop je alles aan elkaar met Python. Zijn jullie bedreven in .NET Core? Dan gebruik je dat.

Stand van zaken

Dit artikel gaat over de opkomst van het Composable DXP. Wanneer je een beetje bekend bent in de wereld van digital experience zie je de term dagelijks meerdere malen voorbij komen, maar onderaan de streep is het monolithic DXP nog steeds razend populair. Composable is in opkomst, maar nog lang niet de standaard.

Het idee dat je een kant-en-klaar alles-in-één platform afneemt en direct alle tools tot je beschikking hebt blijft een aantrekkelijk idee. Je hebt ook voor dit hele platform met maar één vendor te maken - iets wat een nadeel kan zijn als je er van af wil, maar een voordeel zolang je ermee werkt. Voor de bureaus die het DXP implementeren is het ook aantrekkelijk, want je hebt gemakkelijk alle kennis in huis van dat ene platform in tegenstelling tot dat van alle beschikbaar SaaS diensten.

Er is ook nog een klein stukje van de Composable DXP puzzel dat ontbreekt en waar de meeste monolithic DXP’s wel in voorzien: WYSIWYG (What You See Is What You Get) editing van web pagina’s. Omdat je zelf verantwoordelijk bent voor het bouwen van de front-end, vaak ook gebaseerd op Jamstack wat uitgaat van statisch gegenereerde sites, moet je ook zelf voorzien in een WYSIWYG editing mogelijkheid. Waar we de komende jaren dan ook grote ontwikkelingen kunnen verwachten is op het gebied van Front-end As A Service (FEaaS of FaaS): SaaS diensten waarmee je de opbouw van je web pagina’s beheert en waarmee het “live” ontwerpen van je pagina’s mogelijk is.

Conclusie

Het is duidelijk dat er beperkingen zijn aan het monolithic DXP en hoe het Composable DXP op die punten verbetering kan brengen. Hoewel er nog altijd behoefte is aan het monolithic DXP en daar waarschijnlijk ook nog lang behoefte aan blijft, zal het Composable DXP de komende tijd in populariteit blijven toenemen.

Waar vroeger het DXP vaak het uitgangspunt was, gaan we nu uit van business requirements en business architectuur zoeken naar de beste tools die daarbij aansluiten. We gaan ons minder bezig houden met het zelfstandig omzetten van klantvragen in een technische maatwerk oplossing en meer op zoek naar specifieke SaaS diensten die dit voor ons doen en daarin de beste zijn; Best-of-Breed.

Heb je naar aanleiding van dit artikel vragen of wil je gewoon eens van gedachten wisselen over dit onderwerp? Laat het ons even weten via hallo@humandigital.nl.