Storyblok: kiezen voor een of voor meerdere spaces

Vanuit Iquality delen wij graag onze kennis en ervaringen. Vaak zien wij dat CMS inrichtingen worden beschouwd als bijzaak en daardoor niet werken. In deze blog leggen wij uit welke afwegingen wij binnen Storyblok maken om content te beheren vanuit één of meerdere spaces.

Binnen de meeste headless CMS systemen is er sprake van twee organisatorische lagen. De eerste laag is vaak het niveau waarop het abonnement is afgesloten en waar de gegevens van de organisatie, die het contract aangaat, vast liggen. Het tweede niveau is het niveau van de content, de zogenaamde ‘space’.

Organisatie
De organisatie is het hoogste niveau of de bovenste laag van een headless CMS. Binnen deze laag liggen de gegevens van de organisatie vast, maar ook bijvoorbeeld de factureringsgegevens en de accounts die toegang hebben tot het CMS. Binnen de organisatie worden ook één of meerdere spaces beheerd.

Space
Een space is een zogenaamde content repository. Een space kan gezien worden als een geïsoleerde omgeving waar content beheerd kan worden. Praktisch gezien dient een space vaak een specifiek doel, bijvoorbeeld content voor de publieke website of content van de services afdeling.

Belangrijke note: als je content aan elkaar wil relateren, bijvoorbeeld een auteur koppelen aan een nieuwsbericht, kan dat binnen Storyblok alleen als de content in dezelfde space aanwezig is. Content of media kan niet gelinkt worden als dit zich in een andere space bevindt.

Waarom meerdere spaces

Allereerst de vraag: waarom zou je überhaupt overwegen om je content onder te brengen in meerdere spaces? Een architectuur waarbij je kiest voor meerdere spaces gaat vooral over ‘governance’ en schaalbaarheid. Hoewel Storyblok behoorlijk wat functies heeft op organisatie niveau, bijvoorbeeld accounts, zijn er ook veel zaken rondom ‘governance’ te configureren binnen een space. Zo kun je binnen een space een specifieke content workflow configureren, het backup plan inrichten, specifieke rollen aanmaken en content types aanmaken om wat belangrijke zaken te noemen. Workflow is een typisch voorbeeld van ‘governance’. Een workflow zorgt er bijvoorbeeld voor dat content via een bepaalde ‘flow’ aangemaakt en goedgekeurd dient te worden alvorens beschikbaar is voor de afnemers, bijvoorbeeld een website.

Schaalbaarheid is belangrijk naarmate het content model groeit. Wanneer je er in dit geval voor kiest om alles af te handelen binnen één space is het risico aanwezig om te eindigen met een groot en onoverzichtelijk content model. Daarnaast zal het beheren van content ook lastiger zijn vanwege het gebrek aan structuur, wat kan leiden tot fouten en een minder fijne omgeving om in te werken. In een dergelijk scenario ligt het meer voor de hand om je content op te splitsen in meerdere spaces.

Nadelen van meerdere spaces

Naast redenen om te kiezen voor een architectuur met meerdere spaces zitten hier ook wel degelijk nadelen aan. Allereerst eentje die eerder genoemd is: het is niet mogelijk om een referentie te leggen naar content buiten de space. Wanneer je kiest voor meerdere spaces en daarmee geïsoleerde content, kies je er dus tevens voor dat deze content herbruikbaar is alléén binnen dezelfde space. Vaak lijkt dit initieel de beste keuze, maar later blijkt content toch vaak relaties met elkaar te hebben. Neem het eerdere voorbeeld van een nieuwsbericht en een auteur. Stel dat de technische documentatie van een organisatie vastligt in een andere space en je ook hier auteurs aan wil koppelen. Op dat moment ligt het risico op de loer dat de auteurs ook toegevoegd gaan worden aan deze space. Vanuit de ‘single source of truth’ gedachte zou je dit niet moeten willen: dezelfde content op meerdere plaatsen beheren is foutgevoelig en zorgt voor extra content management activiteiten.

Een tweede nadeel van meerdere spaces zijn de kosten. Storyblok is een SaaS (software as a service) dienst en daarmee, evenals de meeste headless CMS systemen, een product met een prijsmodel dat gebaseerd is op verbruik. Een extra space betekent meer verbruik en daarmee hogere kosten. De prijs van een extra space (binnen het ‘enterprise’ en ‘enterprise plus’ abonnement zijn standaard 3 spaces inclusief) is significant.

Belangrijke note: deze blogpost laat het concept van meerdere technische omgevingen (bijvoorbeeld development, test en, acceptatie) buiten beschouwing. Sommige headless CMS systemen, zoals DatoCMS en Contentful kennen het concept van omgevingen binnen een space. Binnen Storyblok is het zo dat meerdere technische omgevingen betekent in het algemeen meerdere spaces. Een interessant artikel over dit onderwerp lees je hier (let op: in het Engels).

Multi-space architectuur voor verschillende technische omgeving.

Kiezen voor meerdere spaces

Op basis van bovenstaande lijkt het me duidelijk dat er geen ‘one-size-fits-all’ aanpak is. Wanneer je er voor kiest om voor een multi space aanpak te gaan, op welke manier zou je dan je splitsing kunnen maken?

Spaces per afdeling

In deze opzet kies je ervoor om per afdelingen of 'business units' binnen een organisatie een aparte space aan te maken. In sommige gevallen werken afdelingen autonoom, in dit geval hebben ze hun eigen ‘governance’ en ook de content is erg uniek per afdeling.

Voor één van onze klanten hadden we de use-case waarbij hun global marketing afdeling volledig zelfstandig opereert van de services afdeling. Bovendien hadden ze beide een apart ‘channel’ waarop de specifieke content gepresenteerd werd. Uiteindelijk heeft dit geleid tot een architectuur met verschillende spaces: een space voor global marketing en een space voor de services afdeling:

Multi-space architectuur gebaseerd op verschillende afdelingen.

Spaces per locatie

In deze opzet kies je ervoor om voor iedere markt of locatie een eigen space aan te maken. Wanneer organisaties bijvoorbeeld internationaal georiënteerd zijn kan dit een goede keuze zijn. Zeker wanneer bijvoorbeeld de bedrijfsdoelstellingen erg verschillend zijn en er sprake is van grote autonomie per locatie is het logisch om hiervoor te kiezen. In dit scenario zal er per geografische locatie een aparte space worden aangemaakt waarin content beheerd kan worden, veelal door de locatie zelf.

Spaces per channel

In dit scenario kies je ervoor om de opsplitsing van spaces te doen per channel of experience. Soms komt het voor dat grote organisaties verschillende teams hebben die elk de verantwoordelijkheid dragen voor een eigen channel, of simpelweg een scenario waarbij de channels dusdanig afwijken qua content en ‘governance’, dat dit ook een opsplitsing rechtvaardigt. Stel dat je als organisatie twee grote, belangrijke channels hebt: je alomvattende corporate website en een ‘mijn’ omgeving voor je klanten. Als deze channels ook nog eens door twee aparte, zelfstandige teams worden beheerd is het in een dergelijke situatie een goed idee om een opsplitsing te maken van spaces naar channels.

Onderstaand voorbeeld is zo’n architectuur die we voor één van onze klanten hebben opgezet. Deze klant heeft twee grote belangrijke kanalen: de corporate website en een klantportaal. De corporate website valt onder de verantwoordelijkheid van de sales- en marketingafdeling. Het klantportaal toont vooral informatie over de gekochte producten en dienstverlening daaromheen. De verantwoordelijkheid van het portaal ligt bij de services afdeling.

Multi-space architectuur gebaseerd op verschillende channels.

Globale spaces

Wanneer je kiest voor een opzet met meerdere spaces zal er toch altijd een situatie ontstaan waarbij content gedeeld gaat worden, misschien niet direct maar wellicht wel op een later moment. Uiteraard kan deze content gedupliceerd worden binnen de verschillende spaces maar dit is vanuit het oogpunt van 'single source of truth' geen goed idee. Zaken zoals bedrijfsinformatie, privacy statement zijn goede voorbeelden van type content die je globaal op organisatie niveau zou willen beheren.

Conclusie

Helaas is er geen duidelijke 'one-size-fits-all' aanpak die voorschrijft hoe om te gaan met een opsplitsing in meerdere spaces. Wanneer aan de in deze blog gestelde voorwaarden wordt voldaan is het in principe een goed idee om voor een multi-space architectuur te gaan. Aan de andere kant zijn de nadelen zoals genoemd significant. Ons advies zou zijn om zoveel mogelijk te starten met één space en alleen over te gaan op meerdere spaces als daar duidelijke 'governance' redenen voor zijn of wanneer de content niet aan elkaar gerelateerd is en volledig 'los' staat.

We zien vaak dat de inrichting van een (headless) CMS wordt overgelaten aan onervaren ontwikkelaars. Binnen Iquality zien we dit anders en is de inrichting van een CMS van essentieel belang en vereist dit een doordacht plan. Door onze jarenlange ervaring richten wij een CMS zodanig in dat content managers ook echt goed hun werk kunnen doen.