Med 64 % av bedriftene som for tiden bruker en headless-tilnærming og 90 % som planlegger å evaluere, er den økende populariteten til headless-arkitektur ubestridelig. Ja, hypen rundt headless-arkitektur er reell og kommer med klare fordeler for ingeniørteamet. Men som med enhver teknologiinvestering er det avgjørende å ta et skritt tilbake og virkelig forstå problemene organisasjonen din prøver å løse, og hvorfor det å gå headless er i samsvar med disse brukstilfellene.
Så hva prøver du å oppnå? Hvis noen av følgende forretningskrav resonerer med deg, kan et headless innholdsstyringssystem være den ideelle løsningen.
Forretningskrav nr. 1: Fremtidig beredskap, unngå leverandørbinding
"Vi ønsker å være fremtidsklare og tilpasse oss endrede krav med letthet."
For organisasjoner som søker tilpasningsevne og muligheten til å erstatte komponenter uanstrengt, kan et headless CMS være et godt valg. Å omfavne en headless-arkitektur tvinger team til å frikoble CMS-et fra frontend (eller presentasjonslaget) samt backend-logikken, i form av mikrotjenester som driftes utenfor CMS-et. Dette gir deg enorm frontend- og backend-frihet. Du kan utnytte ulike frontend-rammeverk som Vue, React eller Angular, eller backend-programmeringsspråk som .NET eller Java, driftet som mikrotjenester på din foretrukne skyplattform. Den fleksible naturen til en headless-arkitektur sikrer at du opprettholder løs kobling mellom nøkkelkomponentene, slik at hvis du for eksempel må bytte ut det headless CMS-et ditt, kan frontend og backend forbli, noe som sparer deg for hodebryet med å dekonstruere en monolitt, hvis det i det hele tatt er mulig.
Spør deg selv: Hvilke komponenter i stacken min vil sannsynligvis endre seg som jeg kan frikoble fra resten av stacken?
Forretningskrav nr. 2: Enkelt innholdshub for flere kanaler
"Vi trenger en sentralisert innholdsstyringsløsning for våre ulike digitale eiendommer."
Hvis bedriften din har flere nettsteder eller kanaler som mobilapper, kiosker eller digitale menyer, lar konsolidering til et enkelt innholdshub deg administrere alt innholdet ditt på ett sted. National Rugby League bruker for eksempel Optimizely til å administrere innhold for 19 nettsteder, en mobilapp, digitale skjermer og fire andre digitale eiendommer. På samme måte har Electrolux brukt Optimizelys CMS i over et tiår for å administrere innhold for flere merkevarer. Hvis forretningsbehovet ditt egentlig handler om å ha ett enkelt innholdslager, kan et headless CMS gi deg den sentraliserte løsningen for strømlinjeformet innholdsadministrasjon. Dette betyr ikke at et alt-i-ett CMS ikke kan hjelpe deg med å administrere innhold for flere kanaler. Markedsførere som bruker et headless CMS er imidlertid tvunget til å tenke på innhold på en strukturert måte, og forberede seg på gjenbruk og levering av innhold til flere digitale kanaler.
Forretningskrav nr. 3: Frakoblet frontend og backend
"Vi ønsker å utnytte React som vårt frontend-rammeverk."
Å frakoble frontend og backend er ikke nødvendigvis et forretningskrav i seg selv, men snarere en teknisk løsning drevet enten av arkitektoniske preferanser eller av strukturen til dine interne utviklingsteam. Med separate frontend- og backend-utviklerteam kan hvert enkelt "holde seg i sine egne baner" og fokusere på sine respektive kompetanseområder. Dette fjerner unødvendige avhengigheter, forbedrer de ansattes moral og gjør det mulig for bedriften å komme raskere ut på markedet. Å velge en headless-løsning lar deg støtte mange forskjellige arkitektoniske mønstre. For mye fleksibilitet kan imidlertid bli en belastning, så ingeniørteam som tar i bruk en headless-arkitektur må være mer disiplinerte i strukturering og vedlikehold av koden sin, for ikke å bygge en monolitt av limkoden som kreves for å knytte headless-løsninger sammen.
Forretningskrav nr. 4: Applikasjoner med høy interaktivitet
"Vi har et e-handelsnettsted" eller "Kundene våre bruker primært mobilappen vår"
Hvis kanalene du vil administrere innhold for godtar mange transaksjoner fra kundene dine, for eksempel e-handel eller en mobilapp, er det stor sjanse for at det skjer mye toveis interaktivitet. Å velge en headless-løsning for applikasjoner med høye krav til interaktivitet ville være et utmerket valg, gitt at det vil kreves betydelig mer ingeniørarbeid i både frontend og backend. Å trekke ut begge komponentene fra det headless CMS-et, som diskutert i tidligere punkter, gir effektiv programvareutvikling. Men hvis dine digitale eiendommer består av markedsføringsnettsteder eller mobilapper som bare viser informasjon, kan det være overkill å velge et headless CMS. Å velge en headless-løsning fremfor et alt-i-ett CMS for et enkelt brukstilfelle tvinger team til å unødvendig frakoble komponentene. Ikke bare må du vedlikeholde frontend- og backend-logikken, du må også sørge for hosting for begge, og tilleggselementer som søkefunksjonalitet, forhåndsvisningsmuligheter, personalisering, leadgenereringsskjemaer, CDN-er, generering av statiske nettsteder og mer. Som bedrift må du administrere flere leverandører, kontrakter og varierende tjenestenivåavtaler, og integrere disse løsningene i hodet ditt.
Spør deg selv: Rettferdiggjør mitt brukstilfelle det ekstra ansvaret med å jobbe med mange leverandører, signere og forhandle flere kontrakter, jobbe med varierende tjenestenivåavtaler og vedlikeholde intern kode?
Ikke glem markedsføringsteamet ditt.
Utviklere presser ofte på for headless på grunn av den enorme fleksibiliteten de får. På den annen side trenger markedsførere, innholdsskapere og innholdsredaktører et CMS som enkelt fungerer med innholdsproduksjonsprosessen deres, og de kan oppleve at mens et headless CMS hjelper dem med å strukturere innhold uten et presentasjonslag, vil side-/opplevelseskomposisjonen nå enten bli drevet av ingeniørkunst gjennom kode eller gjennom annen programvare. Headless CMS-er, som navnet antyder, kommer vanligvis ikke med opplevelses-/sidebyggerfunksjoner. Hvis de hadde det, er de ikke helt headless. Så hvis du velger et headless CMS, sørg for at markedsførerne dine også blir ivaretatt ved å tilby dem en løsning som tillater opplevelses-/sidekomposisjon, slik at markedsførere også kan bevege seg raskt.
Kan Optimizely distribueres som et headless CMS?
Absolutt - Optimizely CMS har alltid koblet innholdet fra presentasjonslaget. Innholdet ligger i Optimizelys database, og presentasjonslaget ligger i koden, enten det er hostet i eller utenfor Optimizely. Dette gjør det mulig for organisasjoner som Dolby, National Rugby League og Moco Food Services å gjenbruke innhold på tvers av flere nettsteder og diverse andre digitale eiendommer, som mobilapper og digitale skjermer.
Med lanseringen av Content Graph har vi styrket vårt headless-tilbud, og gir ingeniører flere alternativer for å levere innhold, enten via .NET SDK-er, RESTful API-er eller GraphQL.
Det som gjør Optimizely unikt, er at det også har en valgfri sidebyggerfunksjon, som sikrer at markedsførere fortsatt kan ha omfattende kontroll over opplevelse/sidesammensetning for nettsteder. I stedet for å overlate dette ansvaret til ingeniører, eller anskaffe en annen programvare for å fylle dette gapet som andre rene headless-aktører etterlater deg med, kan Optimizely hjelpe deg med å løse dette ved å aktivere redigeringsfunksjoner på siden, hvis foretrukket.
Konklusjon