De fire viktigste bruksområdene for å gå headless

Med 64 % av virksomhetene som i dag bruker en headless-tilnærming, og 90 % som planlegger å evaluere den, er den økende populariteten til headless-arkitektur ubestridelig. Ja, headless-hypen er reell og kommer med klare fordeler for ingeniørteamet. Men som med alle andre tekniske investeringer er det avgjørende å ta et skritt tilbake og virkelig forstå hvilke problemer organisasjonen prøver å løse, og hvorfor headless er i tråd med disse brukstilfellene.

Så hva er det du prøver å oppnå? Hvis noen av de følgende forretningskravene gir gjenklang hos deg, kan et headless content management-system være den ideelle løsningen.

Forretningskrav nr. 1: Fremtidsrettet, unngå leverandørbinding
"Vi ønsker å være fremtidsrettet og enkelt kunne tilpasse oss endrede krav."

For organisasjoner som ønsker tilpasningsdyktighet og muligheten til å bytte ut komponenter uten problemer, kan et headless CMS være et godt valg. En headless-arkitektur tvinger teamene til å koble CMS-et fra frontend (eller presentasjonslaget) og backend-logikken, i form av mikrotjenester som ligger utenfor CMS-et. Dette gir deg en enorm frihet både i frontend og backend. Du kan bruke ulike frontend-rammeverk som Vue, React eller Angular, eller backend-programmeringsspråk som .NET eller Java, som hostes som mikrotjenester på den skyplattformen du foretrekker. Den fleksible karakteren til en headless-arkitektur sikrer at du opprettholder en løs kobling mellom nøkkelkomponentene, slik at hvis du for eksempel må bytte ut ditt headless-CMS, kan frontend og backend bli værende, og du slipper hodepinen med å dekonstruere en monolitt, hvis det i det hele tatt er mulig.

Spør deg selv: Hvilke komponenter i stakken min vil sannsynligvis bli endret, og hvilke kan jeg koble fra resten av stakken?

Forretningskrav nr. 2: Ett enkelt innholdshub for flere kanaler
"Vi trenger en sentralisert løsning for innholdshåndtering for de ulike digitale eiendommene våre."

Hvis bedriften din har flere nettsteder eller kanaler, som mobilapper, kiosker eller digitale menyer, kan du konsolidere alt innholdet på ett sted ved å samle det i én enkelt innholdshub. National Rugby League bruker for eksempel Optimizely til å administrere innhold for 19 nettsteder, en mobilapp, digitale skjermer og fire andre digitale egenskaper. På samme måte har Electrolux brukt Optimizelys CMS i over ti år for å administrere innhold for flere varemerker. Hvis virksomhetens behov egentlig handler om å ha ett enkelt innholdsdepot, kan et headless CMS gi deg den sentraliserte løsningen for strømlinjeformet innholdsstyring. Dette betyr ikke at et alt-i-ett-CMS ikke kan hjelpe deg med å administrere innhold for flere kanaler. Men markedsførere som bruker et headless CMS, tvinges 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 å bruke React som frontend-rammeverk."

Å koble frontend og backend fra hverandre er ikke nødvendigvis et forretningskrav i seg selv, men snarere en teknisk løsning som enten er drevet av arkitektoniske preferanser eller av strukturen til de interne utviklingsteamene dine. Med separate frontend- og backend-utviklerteam kan hver av dem "holde seg i sitt eget spor" og fokusere på sine respektive kompetanseområder. Dette fjerner unødvendige avhengigheter, forbedrer de ansattes moral og gjør det mulig for virksomheten å komme raskere ut på markedet. Ved å velge en headless-løsning kan du støtte mange ulike arkitekturmønstre. For mye fleksibilitet kan imidlertid bli en belastning, så ingeniørteam som tar i bruk en headless-arkitektur, må være mer disiplinerte når det gjelder strukturering og vedlikehold av koden, slik at de ikke bygger en monolitt av limkoden som kreves for å binde sammen headless-løsninger.

Forretningskrav nr. 4: Applikasjoner med høy interaktivitet
"Vi har et nettsted for e-handel" eller "Kundene våre handler primært med mobilappen vår"

Hvis kanalene du ønsker å administrere innhold for, godtar mange transaksjoner fra kundene dine, for eksempel e-handel eller en mobilapp, er det stor sjanse for at det foregår mye toveis interaktivitet. Å velge en hodeløs løsning for applikasjoner med høye krav til interaktivitet vil være et utmerket valg, gitt at det vil kreve betydelig mer teknisk arbeid både i frontend og backend. Ved å trekke ut begge komponentene fra det hodeløse CMS-systemet, som diskutert i tidligere punkter, får man en effektiv programvareutvikling. Hvis de digitale eiendommene dine består av markedsføringsnettsteder eller mobilapper som bare viser informasjon, kan det imidlertid være for mye å velge et headless CMS. Hvis du velger en hodeløs løsning i stedet for et alt-i-ett-CMS for et enkelt bruksområde, tvinges teamene til å koble fra komponentene unødvendig mye. Ikke bare må du vedlikeholde frontend- og backend-logikken, du må også sørge for hosting for begge, samt tilleggselementer som søkefunksjonalitet, forhåndsvisningsmuligheter, personalisering, skjemaer for leadgenerering, CDN-er, generering av statiske nettsteder og mer. Som bedrift må du administrere flere leverandører, kontrakter og varierende SLA-er, og integrere disse løsningene i hodet ditt.

Spør deg selv: Kan mitt bruksområde rettferdiggjøre det ekstra ansvaret det innebærer å jobbe med mange leverandører, signere og forhandle flere kontrakter, jobbe med ulike SLA-er og vedlikeholde intern limkode?

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 sammen med innholdsprosessen deres, og de kan oppleve at selv om et headless CMS vil hjelpe dem med å strukturere innhold uten et presentasjonslag, vil side-/opplevelsessammensetningen nå enten være drevet av ingeniørarbeid gjennom kode eller gjennom en annen programvare. Som navnet antyder, leveres hodeløse CMS-er vanligvis ikke med funksjoner for opplevelses- og sidebygging. Hvis de gjorde det, er de ikke rene hodeløse. Så hvis du velger et hodeløst CMS, må du sørge for at markedsførerne dine også blir ivaretatt ved å tilby dem en løsning som gjør det mulig å sette sammen en opplevelse/side, slik at markedsførerne også kan jobbe raskt.

Kan Optimizely brukes som et headless CMS?

Absolutt - Optimizely CMS har alltid frikoblet innholdet fra presentasjonslaget. Innholdet ligger i Optimizelys database, og presentasjonslaget ligger i kode, enten det ligger 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 ulike andre digitale egenskaper, for eksempel mobilapper og digitale skjermer.

Med lanseringen av Content Graph har vi styrket vårt headless-tilbud, og gir ingeniører flere muligheter til å 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, noe som sikrer at markedsførere fortsatt kan ha omfattende kontroll over opplevelsen/sidesammensetningen for nettsteder. I stedet for å overlate dette ansvaret til ingeniører, eller anskaffe en annen programvare for å fylle dette hullet som andre rene headless-aktører etterlater deg med, kan Optimizely hjelpe deg med å løse dette ved å aktivere redigeringsfunksjoner på siden, hvis du foretrekker det.

Konklusjon

1. Å velge et hodeløst CMS gir ingeniørene dine en enorm frihet. Dette gjør at du kan komme raskere ut på markedet. For mye fleksibilitet kan imidlertid bli en belastning, så sørg for å ha en virksomhetsarkitektur og en streng prosjekteringspraksis på plass for å unngå å ende opp i en monolitt av tilpasset kode.
2. Headless CMS løser, som navnet tilsier, problemet med innholdsadministrasjon, men ikke med administrasjon av presentasjonslaget. Når du velger et hodeløst CMS, må du sørge for at du også har en opplevelses-/sidebyggerløsning på plass for markedsførere, slik at de har en høy grad av selvstendighet og ikke er avhengige av teknikere i det daglige arbeidet.
3. Ved å velge et headless CMS legger virksomheten til rette for et sammensatt digitalt økosystem, noe som skaper smidighet for virksomheten. Et økosystem med flere programvareleverandører resulterer imidlertid i flere kontrakter, varierende SLA-er og muligens limkode for å integrere dem alle. Ta et skritt tilbake og tenk over om virksomhetens behov rettferdiggjør det ekstra ansvaret som ligger i å administrere flere leverandører, ulike SLA-er og vedlikehold av intern limkode.