5 dingen die je moet weten voordat je met headless aan de slag gaat

Als je deze blog leest, ben je waarschijnlijk bekend met de term ‘headless’. In mijn optiek is headless voor veel organisaties dé manier om digitale oplossingen te bouwen. Hierbij wordt de backend los van de frontend ontwikkeld.

Headless wint aan populariteit. Toch zijn er nog een aantal misvattingen en zaken die nog relatief onbekend zijn over deze technologie. Zaken die bedrijven ervan weerhouden om headless als serieuze optie te zien. Ik heb er 5 op een rijtje:

#1 Misvatting: Headless is alleen voor grote bedrijven met dito (digitale) budgetten
Toen headless systemen nog relatief nieuw waren, was dit zeker waar. Intussen zijn er verschillende softwareleveranciers bijgekomen die zich richten op verschillende use cases en bedrijfsgroottes. Hierdoor is headless nu ook mogelijk en geschikt voor kleinere projecten (<€100k).

#2 Onbekend: Je kan je eigen roadmap bepalen
Monolithische systemen, waarbij de voor- en achterkant van een webplatform ‘coupled’ zijn, hebben een groot nadeel: als het aankomt op product- en platformontwikkeling ben je als gebruiker afhankelijk van de roadmap van de softwareleverancier. Dit betekent dat je voor vernieuwingen en verbeteringen aan jouw platform niet je eigen plan kan trekken. 

Met headless krijg je die controle terug en kan je zelf bepalen wanneer je welke functionaliteit wilt bouwen en uitrollen. En omdat de focus hierbij ligt om specifieke functionaliteiten, componenten of applicaties te vernieuwen, is het mogelijk om tijdens het ontwikkelprocess sneller keuzes te maken, sneller tot een MVP te komen en zorgt headless zo voor een betere time-to-market.

#3 Onbekend: Minder downtime bij systeem reboots en upgrades
Digitale platformen worden continu getweaked en vernieuwd. Bij ‘coupled’ omgevingen betekent dat vaak dat bij een reboot of upgrade het hele systeem offline gehaald moet worden. Tijdens die downtime kunnen klanten geen gebruik maken van het platform en lopen bedrijven potentieel zelfs omzet mis.

In headless omgevingen worden reboots en upgrades gedaan op component-niveau. Hierdoor blijven de andere systemen gewoon draaien en wordt middels caching in de integratielaag transacties en orders opgevangen. Zo gaat er tijdens de downtime van een component (vrijwel) niets verloren.

#4 Misvatting: de TCO van monolithische systemen is gunstiger dan die van headless omgevingen
Op het eerste gezicht zou je verwachten dat monolithische systemen out-of-the-box completer zijn waardoor de TCO, inclusief ontwikkel- en integratietijd, lager is. Bij headless is er immers sprake van relatief veel maatwerk development.

De totale ontwikkelkosten vallen in de meeste gevallen bij headless toch gunstiger uit. Dit is waarom:

• hergebruik: componenten en APIs die je al gebouwd hebt, kunnen worden hergebruikt
• call optimalisatie: vanuit de API driven headless omgeving kan je de calls op applicaties optimaliseren en processen kostenefficiënter inrichten (bijvoorbeeld in het geval van prijsberekeningen en orderverwerking)
• manier van updaten: component-updates vergen minder test-tijd en er hoeft geen intensief migratieplan op te worden gesteld en uit te worden gevoerd

#5 Misvatting: Headless omgevingen zijn minder stabiel
Aangezien de applicaties en functionaliteit bij monolithische systemen bij een en dezelfde softwareleverancier vandaan komen, zou je verwachten dat deze omgevingen stabieler en beter geïntegreerd zijn dan bij headless.

In de praktijk zien we het tegenovergestelde. Met headless verbeteren bedrijven de controle over en betrouwbaarheid van hun IT-landschap. Dit komt doordat er minder aanpassingen (lees: nieuwe code) nodig zijn en gebouwde, stabiele APIs kunnen worden hergebruikt. Best-of-breed applicaties individueel kunnen standalone worden beheerd en getweaked zonder dat het ten koste gaat van de overall performance en stabiliteit van de complete tech-stack.