CMS

Het aanbod op de markt voor contentmanagementsystemen (cms’en) is enorm. Er is zoveel, dat het onbegonnen werk lijkt uit al die verschillende systemen een geïnformeerde keuze te maken. Het is dan verleidelijk gewoon maar het systeem te kiezen dat je al kent of juist iedere keer voor the next new thing te gaan. Met alle risico’s van dien. Dit is hoe wij bij Enrise bepalen wat het goede cms is voor ons volgende project. 

Hier bij Enrise zitten we uit principe niet vast aan een pakket of technische oplossing. Ieder project verdient het om met een frisse, open blik bekeken te worden, omdat ieder project eigen eisen stelt aan het te gebruiken pakket of framework. Die eisen zijn natuurlijk voor een belangrijk deel technisch, maar techniek is lang niet het belangrijkste.

Keuzegids

In gesprek met de klant vind je de oplossing

Het belangrijkste bij het kiezen van een platform is de klant zelf. Een klantorganisatie heeft meestal al ervaring met een cms en wil daar vaak mee blijven werken. Of juist het omgekeerde: het huidige cms is verouderd en/of levert frustraties op. Hoe dan ook zijn de ervaringen van een bedrijf met een bepaald cms belangrijke input voor het kiezen van een cms voor een nieuw project. We beginnen dus altijd met heel goed luisteren naar de ervaringen en wensen van de klant. We brengen in kaart welke bestaande systemen er zijn en wat daarvan bruikbaar is. Dit vind je alleen uit als je echt met de klant in gesprek bent. Een droog eisen- en wensenlijstje kun je meestal passen op een hele lijst systemen. Als je doorvraagt, komen er altijd allerlei specifieke punten boven die het keuzeproces richting geven.

Soms zijn er gewoon harde eisen en is er een beperkte keuze aan platformen. Dit zien we bijvoorbeeld bij overheidsorganisaties. Helaas passen de voorgeschreven platformen niet altijd bij wat er gebouwd moet worden. Dan is het erg prettig als een systeem een complete api heeft. Daarmee kun je dan het systeem uitbreiden met modules eromheen.

Onze checklist bij het kiezen van een cms

Daarnaast hebben we ook zo onze eigen normen voor het kiezen van een cms. Dit is onze checklist: 

API

Ieder cms heeft zijn beperkingen, maar een cms met een goed bruikbare api zorgt dat je daar veel minder last van hebt. Een goed voorbeeld is het koppelen met een e-commerceplatform. Webwinkelsystemen zijn goed in producten presenteren en aankopen afhandelen. Zodra je een blog of nieuwspagina gaat toevoegen, voel je al gauw de beperkingen. Met goede api’s kun je naast je e-commerceplatform dan een apart cms neerzetten voor je blog, terwijl je dat aan de voorkant perfect integreert. Zo heb je het beste van twee werelden. 

We zien ook steeds meer vraag naar dynamische single-page applicaties. Vooral voor een e-commercesite zijn snelheid en optimale klantervaring heel belangrijk. Je wilt dus dynamisch content kunnen laden en je gebruiker niet op een page refresh laten wachten. De meeste cms’en kunnen dat niet out of the box, dus biedt een api uitkomst. 

Vaak kom je dan uit op een headless cms, waarbij het cms zelf helemaal geen presentatielaag meer heeft. Het bouwen en onderhouden van een site kost dan wat meer werk, maar de voordelen zijn enorm. Je kunt bijvoorbeeld zonder wijzigingen aan het cms de hele frontend vervangen, een nieuwe site of app toevoegen met (gedeeltelijk) dezelfde content of juist data en content uit verschillende systemen combineren in één presentatielaag.

Vendor

Werken met een stuk software betekent ook dat je een relatie aangaat met de maker ervan. Bij het kiezen van een cms kijken we daarom ook naar de vendor. Vooral het update- en patchbeleid van een vendor is een belangrijke overweging bij je cms-keuze. Dit is extra belangrijk bij SaaS-oplossingen, omdat je daar geen controle hebt over het moment van de wijzigingen. Maar ook bij pakketten en frameworks is het belangrijk te weten hoe, hoe snel en hoe vaak er security updates, bugfixes en nieuwe features worden uitgerold.

We kijken ook naar de historie van een product: hoe vaak zijn er nieuwe versies of LTS-releases uitgebracht? Worden roadmaps over het algemeen gehaald of niet? Hoe voorspelbaar lijkt de doorontwikkeling te zijn? 

Onderzoek ook altijd vooraf of je makkelijk weer van een platform af kunt. In sommige cms’en moet je heel veel werk verrichten om je content en metadata te kunnen exporteren. Vaak moet je daarbij een vertaalslag maken van de ene datastructuur naar de andere. Ook hierbij helpt het om een cms te kiezen met een goede api. Je hebt dan immers altijd de mogelijkheid je content via de api te exporteren. Dit voorkomt een vendor lock-in. 

Meertaligheid

Internationalisatie is een factor die al vroeg in het proces bepalend kan zijn. Maar wat er met ‘meertaligheid’ bedoeld wordt, varieert nogal van klant tot klant. Meestal gaat het om 2 of 3 talen, maar het kunnen ook 29 talen zijn, die op verschillende momenten en door verschillende schrijvers of vertaalbureaus worden aangeleverd. Soms moet het uiterlijk van sites en apps voor een taal subtiel anders zijn. Dat heeft allemaal effect op je contentmanagementproces en dus op je pakketkeuze. Bij complexe meertalige sites of apps, met functionele verschillen per taal of regio, kan het heel goed zijn dat je uitkomt bij een oplossing met meerdere cms’en, eventueel via api’s verbonden.

Uitbreidbaarheid

We kiezen het liefst voor systemen die out of the box al voldoen aan de meeste van onze eisen. Maar het is toch prettig als je een cms desgewenst kunt uitbreiden. Vaak heeft een cms daarvoor een plugin-systeem, maar voor het gebruik van een plugin hanteren we bij Enrise strakke criteria. Als je niet kritisch bent op de plugins die je gebruikt, kan het beheer ervan namelijk veel werk worden. Ook kunnen onbetrouwbare plugins een bedreiging zijn voor je security en uptime.

Wij gebruiken een plugin alleen als hij: 

• Actief onderhouden wordt 
• Veel gebruikt wordt 
• Positieve reviews heeft en de makers actief reageren op negatieve reviews 
• De juiste versie(s) ondersteunt van het kernsysteem 
• Regelmatig geüpdatet wordt 
• Alleen doet waar we hem voor willen gebruiken, zonder ongewenste bijeffecten 
• Geen verder maatwerk vraagt, dat in de weg zou kunnen zitten bij updates 
• Voldoet aan de richtlijnen van de makers van het kernsysteem 
• Geen ongewenste aanpassingen doet aan het kernsysteem 

Daarbij geven we de voorkeur aan betaalde plugins waarvoor support beschikbaar is. Zijn er niet genoeg plugins in het ecosysteem die aan deze normen voldoen? Houd er dan rekening mee dat je voor het uitbreiden van een cms zelf code zult moeten (laten) bouwen. 

Maar het uitbreiden van een cms hoeft niet met code of plugins. We hebben ook goede ervaringen met het gebruik van bijvoorbeeld Elasticsearch naast een bestaande site. Elastic biedt veel mogelijkheden voor zoeken en filteren. Daarbij slaat het de content van de site zelf op en presenteert hem vanuit de eigen database, zonder eerst via de api te gaan. Dit verhoogt de performance en vermindert de eisen die we aan het cms moeten stellen. Door systemen naast elkaar te gebruiken kun je hun sterke punten combineren.

Time to market 

Hoewel veel systemen adverteren met korte ontwikkeltijden en snelle time to market, zit ontwikkelsnelheid volgens ons veel meer in het proces dan in de tools. Het allerbelangrijkste daarbij is nauwe samenwerking met de klant. Hoe meer de klant betrokken is bij de ontwikkeling en hoe sneller iemand van de klant nieuwe functies bekijkt, van feedback voorziet en goedkeurt, hoe sneller we live kunnen. Natuurlijk kiezen we wel voor een oplossing waarvan we zeker weten dat er geen technische showstoppers in zitten, die dit proces kunnen verstoren. Ook is het belangrijk een systeem te kiezen dat past bij de organisatie die het moet gaan gebruiken, zodat gebruikers snel ingewerkt zijn en aan het werk kunnen. 

Ecosysteem 

Ecosystemen rondom softwareproducten verschillen enorm. Niet alleen de omvang is belangrijk, maar ook of een ecosysteem jong is en groeit, of juist op zijn einde loopt en krimpt. De ene vendor is ook actiever met het aanjagen en ondersteunen van het ecosysteem dan de andere. Een groot en actief ecosysteem betekent dat een vendor gestimuleerd wordt nieuwe features te ontwikkelen en dat beveiligingslekken snel gevonden én snel opgelost worden. Het betekent bovendien dat een product niet zo snel van de markt zal verdwijnen.

Wij werken het liefst met open source software, juist vanwege de actieve ecosystemen die daarbij horen. We doen ook ons best actief lid te zijn van de communities rondom die producten: we maken issues aan en we sturen code in als we een oplossing hebben gevonden. 

Naast het development-perspectief is er natuurlijk ook het gebruikersperspectief op het ecosysteem. Een klant wil graag zien welke andere bedrijven of organisaties met een systeem werken en of er support of training beschikbaar is. 

Ease of development 

Voor een developer werkt het ene systeem gewoon ‘lekkerder’ dan het andere. Dit komt vooral tot uitdrukking bij het onderhoud van een systeem en hangt dus ook erg af van de ervaring, kennis en voorkeuren van de beheerorganisatie. We kiezen het liefst voor een systeem dat ons de kans geeft een modulaire structuur te bouwen, waarin componenten los van elkaar aangepast of vervangen kunnen worden. Zonder dat het hele systeem last heeft van die veranderingen. Het is duidelijk dat ook hierbij een cms met een goede api erg helpt.  

De keuze van nu voor het cms van straks 

Tot slot nog een paar belangrijke dingen om in je achterhoofd te houden: 

• Als contentbeheer maar een klein onderdeel is van een groter geheel, is het zeker een optie met een zelfgebouwd cms te werken.  
• Kijk niet alleen naar wat je nu nodig hebt, maar houd rekening met wat je in de toekomst wilt doen. Het is jammer als je nu bijvoorbeeld een cms uitzoekt dat een jaar later niet meer bij je internationale ambities blijkt te passen. 
• Een brede blik is belangrijk. Staar je niet blind op één oplossing. Er is niet één weg die je altijd op de juiste plek brengt, of één stuk gereedschap waar je iedere klus mee kunt klaren. Voel je dus een voorkeur voor een bepaalde oplossing? Daag die dan uit en stel je open voor alternatieven. 
• Praat met je partners en vraag ze welke ontwikkelingen en mogelijkheden zij zien. Onze developers volgen bijvoorbeeld de technische ontwikkelingen op de voet, dus we zien vaak ook opties die de klant nog niet in beeld heeft. Zo kunnen wij oplossingen adviseren waar een klant zelf niet aan gedacht zou hebben. 
• Meer lezen? Check ook dit blog van Enriser Vincent.

Uiteindelijk gaat het erom wat past bij het project en bij het bedrijf. En wat er mogelijk is binnen de gegeven randvoorwaarden en op welke manier je het meeste waarde kunt toevoegen. Alles uitgeplozen en zijn alle betrokkenen het met elkaar eens? Dan heb je je cms gevonden.