CMS upgraden of vervangen?

Wie inspeelt op de veranderende klantbehoeften, zal voor elk ‘touchpoint’ de beste technologie willen kiezen. Om die kanalen vervolgens dynamisch inhoud te geven via systemen zoals het CMS, CRM of de API’s van andere specialistisch software. Behalve de juiste klantervaring ontstaat zo ook een samenhangend geheel.

Voor velen is de praktijk nu nog een stuk weerbarstiger. Grote content management suites zijn ontstaan in een tijd dat webshops nog innovatie heetten en de term ‘omnichannel commerce’ nog niet eens bestond. Deze enterprise CMS’en zoals Sitecore, Adobe Experience Manager en Liferay zijn uitgegroeid tot ‘one stop shops’, inmiddels beter bekend als Digital Experience Platforms. Met hun totaalpakket voor front-end technologie, personalisatie, A/B testing, analytics en niet te vergeten content management, wil het een alles-in-één oplossing zijn voor elke ‘digital capability’.  

Naast het feit dat het je als bedrijf niet de volledige vrijheid geeft om kanalen (technisch) zelf vorm te geven, is upgraden na een ‘major release’ kostbaar. Niet zelden is de software in de loop der jaren als een bord spaghetti vervlochten met de code van interne systemen wat de stap bovendien complex maakt. Het roept de vraag op of het CMS nog wel toekomstgericht is.

Een CMS moet je vooruithelpen

Wat dat betreft is elke major release een goed moment om stil te staan en te kijken of de enigszins gedwongen upgrade de enige, en juiste weg is. Daarbij wat de eventuele keuze voor re-platforming naar een nieuw CMS inhoudt. 

Vooropgesteld: zolang de nieuwe versie verbeteringen bevat die in lijn zijn met de belangrijkste bedrijfsbehoeften, en wanneer een upgrade goedkoop en snel is, zijn er weinig redenen om te heroriënteren. Anders is de situatie echter als de support op de gebruikte editie eindigt of upgraden technisch ingewikkeld blijkt terwijl de update weinig tot geen verbeteringen voor de gebruikerservaring meebrengt. In zulke situaties is doorgaan op het hetzelfde pad verspilde energie. Omdat de upgrade het bedrijf niet direct verder helpt in haar digitale ontwikkeling, voelt het eerder als een doodlopende weg: wel de kosten, nooit de baten. 

Toekomstgericht alternatief

Gelukkig bestaat er zoiets als een vluchtroute richting een alternatief, naar wat heet een best-of-breed architectuur. De belangrijkste zet vooraf is om eens een stap achteruit te doen en de eigen digitale behoeften helder te formuleren. En vanaf die stip aan de horizon vervolgens terug te redeneren naar ‘requirements’. Grote kans dat de klantervaring direct om aandacht vraagt en product owners, marketeers en ontwikkelaars de kanalen willen optimaliseren.

Zo’n best-of-breed architectuur bestaat, anders dan bij de genoemde enterprise suites, niet uit een kant-en-klare set oplossingen, maar geeft de onderneming ruimte om eigen bouwblokken te stapelen. Afgeleid van de belangrijkste vereisten worden in alle disciplines specialistische oplossingen geselecteerd en via API’s met elkaar verbonden.

Eén taak

Zo heeft een goed CMS in Touchtribes ogen één taak en moet het zich daar volledig op toeleggen: redacteurs in staat stellen op een gebruiksvriendelijke manier content te beheren en publiceren. En niet meer dan dat. Ontstaat daarop bijvoorbeeld de behoefte om een volgende stap te zetten en content en commerce goed met elkaar te integreren, dan wordt er een software-oplossing gekoppeld die deze functionaliteiten toevoegt. Op die manier plukt de organisatie altijd de vruchten van andermans specialiteit en blijft het flexibel genoeg om uit te breiden of in een later stadium één van de oplossingen weer in te ruilen. De architectuur sluit beter aan op application lifecycle management: de wendbaarheid neemt toe en dus de ruimte om in te spelen op veranderingen.

Gelukkig kent de markt een groeiend aantal spelers die deze koers varen, waarvan Contentful, Contentstack, StoryBlok en Kentico Kontent de bekendste zijn. Elk van deze CMS’en kiest voor een headless opzet waarbij de inhoud en hoe deze eruit komt te zien van elkaar zijn losgekoppeld. Ontwikkelaars zijn daardoor niet langer gebonden aan de technische kaders van een suite en hebben eindelijk de ruimte om per digitaal kanaal de in hun ogen beste programmeertaal te kiezen. Of het nu een webshop, Progressive Web App, native mobiele app, chatbot of voiceapp betreft, vanaf die ene centrale plek is elk denkbaar ‘touchpoint’ in te vullen.

API-first: richting een eigen stack

Een belangrijk kenmerk van deze specialistische CMS’en is dat de leveranciers ze cloud native (SaaS) en API-first hebben ontwikkeld. Het maakt dat de software-oplossingen automatisch, zonder upgraden, worden voorzien van nieuwe features. En dat ze van nature ingericht zijn om met anderen informatie uit te wisselen. Juist daardoor zijn ze geschikt als onderdeel van een grotere technologiestack. Blijkt er als aanvulling behoefte aan commerce, dan ligt bijvoorbeeld de uitbreiding met commercetools of BigCommerce voor de hand. Vraagt de klantervaring om personalisatie, dan bieden bedrijven als Relay42 geavanceerde functionaliteiten. 

Al deze oplossingen zijn cloud native, API-first en headless opgezet. Door ze met elkaar te verbinden, ontstaat stap voor stap een stack - en in feite een zelfgebouwd DXP - dat perfect aansluit op en meegroeit met de digitale volwassenheid van de organisatie.

Resultaat

Eén van de overeenkomsten tussen bedrijven die erin zijn geslaagd hun enterprise suite om te buigen naar een best-of-breed architectuur, is dat ze hebben ingezien klein te moeten beginnen. Ze hebben er bijvoorbeeld voor gekozen om allereerst de content management-functionaliteit van de website te vervangen. Tegelijkertijd is er gewerkt aan een redesign met de belangrijkste features om pas in een later stadium een volgend kanaal te koppelen. Daarmee blijft de replatforming behapbaar en neemt de angst voor een alles omvattende migratie af.

Waartoe die aanpak meteen leidt? Nu ontwikkelaars niet meer gebonden zijn aan de technieken die software-leveranciers voor ze kiezen, creëren ze rijkere ervaringen. En was de website eerder nog een silo, inmiddels zijn de kanalen gemakkelijker vanuit één centraal punt te vullen en komt de omnichannel ervaring weer een stap dichterbij. De vooruitstrevende merken weten zo bijvoorbeeld content en commerce volledig in elkaar over te laten gaan. Onder de motorkap ondersteund door een flexibele architectuur van headless SaaS-tools die helpt om met een hogere snelheid te ontwikkelen.

Nieuwe rol CMS

Het valt niet te ontkennen dat de keuze om klein te beginnen ook noodzakelijk is om alle betrokkenen geleidelijk te laten wennen aan de nieuwe realiteit. Waar traditionele CMS’en zeer visueel zijn en redacteurs mogelijkheden geven om met drag & drop zelf de weergave van hun content aan te passen, voelt een CMS als Contentful mogelijk wat spartaans. 

Het heeft alles te maken met de nieuwe rol dat elk CMS zou moeten innemen. Die wordt namelijk kleiner, de rol van de architectuur als geheel juist groter. Van alle bedrijven die op het kruispunt staan van upgraden of niet, ziet een groeiend aantal in voor die visie te moeten kiezen. Eén waarin een ‘silver bullet’ en alles-in-éénoplossing niet bestaat. En de manier waarop contentgedreven aan klantgemak en -waarde wordt gewerkt leidend is. De uiterlijke vorm ervan en de tools die hier vervolgens voor nodig zijn, veranderen met de tijd mee. Dit uitgangspunt vraagt om tooling die deze wendbaarheid faciliteert. Alleen onze creativiteit is dan nog een mogelijke rem.