Headless: Trend of Breekpunt?
Gepubliceerd op 14 augustus 2019
Auteur: Tim Hanse
Contentmanagement consultant bij Crossphase
Headless. Decoupled. Hybrid. Agile.
Allemaal cms varianten die je NU moet hebben. Eigenlijk gisteren al.
Want iedereen is er mee bezig. En dus moet jij ook meedoen.
Klopt dit? Ik geef het een 50/50 kans dat je binnen je bedrijf wel eens bezig bent geweest met het idee van een headless cms. Of dat dit op z'n minst een keer besproken is met de IT afdeling. Of je bent het tegengekomen op een congres. Of je las een zeer duidelijk “voor-en nadelen” artikel rond afgelopen juni.
De korte definitie van een headless cms is simpelweg: De inhoud van de vorm scheiden. Of, om het anders te verwoorden, de data scheiden van de front-end code.
In de praktijk is dit een database, die door middel van een API data zendt naar een front-end module, die op zijn beurt de vorm en functie van de content bepaalt voor het kanaal. Een API is een Application Programming Interface, feitelijk een set regels die bepalen hoe en welke content er opgeroepen mag worden per kanaal.
Ik vergelijk het vaak met een regenton met water, waar je verschillende kraantjes op kunt zetten.
Een variant is het zogenoemde decoupled, of hybride, cms. Hierbij zit er aan de database reeds een front-end module gekoppeld via een interne API, binnen de infrastructuur van het contentmanagementsysteem. Dus je hebt direct een werkend systeem zonder nog een front-end module te hoeven koppelen. Maar dit kan wel waar nodig, want er is een API aanwezig. Op deze wijze kun je dus alsnog meerdere kanalen koppelen aan je database.
De meeste enterprise cms'en hebben dit meegenomen in recente updates en claimen dus een headless optie te bieden.
Headless en decoupled hebben beiden eigenlijk nog een vorm van het traditionele cms, waarbij het content concept nog steeds in een eindproduct wordt gepresenteerd: een webpagina, een email, of een app.
Ja en nee. Volgens Forrester (lees het artikel hier) komt er snel een nieuwe variant van het web-cms aan: het agile cms. Zij presenteren dit als een nieuwe generatie cms, die de daadwerkelijke behoeftes van de gebruiker kan voorzien. Maar als je die uitleg leest, vermoed ik dat de meeste cms gebruikers nog niet zo ver zijn. Waar ik het wel mee eens ben, is dat headless geen blijvende optie is. Hoewel het technisch zeer goed mogelijk is en strak in te richten, zijn er nog te veel haken en ogen.
En een daarvan is dat je content organisatie er ook klaar voor moet zijn. Want hoewel headless als oplossing moet dienen voor de grote hoeveelheden content in je organisatie, is juist schaalbaarheid ook de achilleshiel van het geheel. Op het moment dat het om grote hoeveelheden content gaat, is het niet langer de techniek, maar de mens en zijn werkwijzen die roet in het eten gooit. Want er zal veel data moeten worden beheerd, en wie controleert er of er dubbelingen zijn? Het zou jammer zijn als er door naamgeving of verkeerde metadata een verkeerd stuk content wordt opgeroepen in een verkeerd kanaal. En hoe groter de hoeveelheid content, hoe groter de kans op een dubbeling of fout.
Moet ik nu meedoen aan de headless hype? Besef dat een headless qua techniek misschien makkelijk in te richten is, maar ook dat je opnieuw mag gaan kijken naar software, naar werkwijze van je content organisatie en naar je content zelf. En vooral dat laatste is belangrijk, gezien de basis bij veel bedrijven echt nog niet helemaal in orde is. Mijn advies is het volgende: verlies je kop niet. Hou headless in de gaten en pas het toe als je het echt nodig denkt te hebben. Maar los eerst de silo’s binnen je bedrijf op, vorm één visie op communicatie en bedenk een goede werkwijze voor de opslag van je content.
Je vindt het artikel hier op LinkedIn.