Med 64 % av företagen som för närvarande använder en headless-strategi och 90 % som planerar att utvärdera den, är den ökande populariteten för headless-arkitektur obestridlig. Ja, hypen kring headless-strategi är verklig och har tydliga fördelar för ingenjörsteamet. Men som med alla teknikinvesteringar är det avgörande att ta ett steg tillbaka och verkligen förstå de problem som din organisation försöker åtgärda och varför headless-strategi passar ihop med dessa användningsfall.
Så, vad försöker du uppnå? Om något av följande affärskrav resonerar med dig kan ett headless-innehållshanteringssystem vara den perfekta lösningen.
Affärskrav #1: Framtidsberedskap, undvika leverantörslåsning
"Vi vill vara framtidsberedda och enkelt anpassa oss till förändrade krav."
För organisationer som söker anpassningsförmåga och möjligheten att enkelt byta ut komponenter kan ett headless CMS vara ett bra val. Att anamma en headless-arkitektur tvingar team att frikoppla CMS:et från frontend (eller presentationslagret) såväl som backend-logiken, i form av mikrotjänster som hostas utanför CMS:et. Detta ger er enorm frihet i frontend och backend. Ni kan utnyttja olika frontend-ramverk som Vue, React eller Angular, eller backend-programmeringsspråk som .NET eller Java, som hostas som mikrotjänster på er föredragna molnplattform. Den flexibla karaktären hos en headless-arkitektur säkerställer att du upprätthåller en lös koppling mellan nyckelkomponenterna så att om du någonsin behöver byta ut ditt headless CMS, till exempel, kan ditt frontend och backend behållas, vilket sparar dig huvudvärken med att dekonstruera en monolit, om det ens är möjligt.
Fråga dig själv: Vilka komponenter i min stack kommer sannolikt att förändras som jag kan frikoppla från resten av stacken?
Affärskrav #2: En enda innehållsnav för flera kanaler
"Vi behöver en centraliserad innehållshanteringslösning för våra olika digitala egenskaper."
Om ditt företag har flera webbplatser eller kanaler som mobilappar, kiosker eller digitala menyer, kan du hantera allt ditt innehåll på ett ställe genom att konsolidera till en enda innehållsnav. National Rugby League använder till exempel Optimizely för att hantera innehåll för 19 webbplatser, en mobilapp, digitala displayer och fyra andra digitala fastigheter. På liknande sätt har Electrolux använt Optimizelys CMS i över ett decennium för att hantera innehåll för flera varumärken. Om ditt affärsbehov verkligen handlar om att ha ett enda innehållsarkiv kan ett headless CMS ge dig den centraliserade lösningen för effektiv innehållshantering. Det betyder inte att ett allt-i-ett CMS inte kan hjälpa dig att hantera innehåll för flera kanaler. Marknadsförare som använder ett headless CMS tvingas dock tänka på innehåll på ett strukturerat sätt och förbereda sig för återanvändning och leverans av innehåll till flera digitala kanaler.
Affärskrav #3: Frikopplat frontend och backend
"Vi vill utnyttja React som vårt frontend-ramverk."
Att frikoppla frontend och backend är inte nödvändigtvis ett affärskrav i sig, utan snarare en teknisk lösning som drivs antingen av arkitektoniska preferenser eller av strukturen hos dina interna utvecklingsteam. Med separata frontend- och backend-utvecklarteam kan var och en "hålla sig i sina egna banor" och fokusera på sina respektive expertområden. Detta tar bort onödiga beroenden, förbättrar medarbetarnas moral och gör att verksamheten kan komma ut på marknaden snabbare. Att välja en headless-lösning gör att du kan stödja många olika arkitektoniska mönster. För mycket flexibilitet kan dock bli en belastning, så ingenjörsteam som använder en headless-arkitektur måste vara mer disciplinerade i att strukturera och underhålla sin kod, för att inte bygga en monolit av den limkod som krävs för att knyta ihop headless-lösningar.
Affärskrav #4: Applikationer med hög interaktivitet
"Vi har en e-handelswebbplats" eller "Våra kunder gör främst transaktioner med vår mobilapp"
Om de kanaler du vill hantera innehåll för accepterar många transaktioner från dina kunder, till exempel e-handel eller en mobilapp, finns det en god chans att det sker mycket tvåvägsinteraktivitet. Att välja en headless-lösning för applikationer med höga interaktivitetskrav skulle vara ett utmärkt val, med tanke på att det kommer att krävas betydligt mer ingenjörsarbete i både frontend och backend. Att extrahera båda komponenterna från det headless CMS, som diskuterats i tidigare punkter, möjliggör effektiv mjukvaruutveckling. Men om dina digitala funktioner består av marknadsföringswebbplatser eller mobilappar som bara visar information, kan det vara överdrivet att välja ett headless CMS. Att välja en headless-lösning framför ett allt-i-ett CMS för ett enkelt användningsfall tvingar team att i onödan frikoppla komponenterna. Du måste inte bara underhålla frontend- och backend-logiken, du måste också tillhandahålla hosting för båda, och ytterligare element som sökfunktioner, förhandsgranskningsmöjligheter, personalisering, leadgenereringsformulär, CDN:er, generering av statiska webbplatser med mera. Som företag måste du hantera flera leverantörer, kontrakt och varierande SLA:er, och integrera dessa lösningar i ditt huvud.
Fråga dig själv: Rättfärdigar mitt användningsfall det extra ansvaret att arbeta med många leverantörer, skriva och förhandla flera kontrakt, arbeta med varierande SLA:er och underhålla intern glue code?
Glöm inte ditt marknadsföringsteam.
Utvecklare driver ofta headless på grund av den enorma flexibiliteten de får. Å andra sidan behöver marknadsförare, innehållsskapare och innehållsredaktörer ett CMS som enkelt fungerar med deras innehållsskapandeprocess och kan upptäcka att medan ett headless CMS hjälper dem att strukturera innehåll utan ett presentationslager, kommer sidans/upplevelsens komposition nu antingen att styras av ingenjörskonst genom kod eller genom annan programvara. Headless CMS, som namnet antyder, kommer i allmänhet inte med upplevelse-/sidbyggarfunktioner. Om de gjorde det är de inte helt headless. Så om du väljer ett headless CMS, se till att dina marknadsförare också tillgodoses genom att ge dem en lösning som möjliggör upplevelse-/sidkomposition så att marknadsförare också kan agera snabbt.
Kan Optimizely distribueras som ett headless CMS?
Absolut - Optimizely CMS har alltid frikopplat innehållet från presentationslagret. Innehållet finns i Optimizelys databas, och presentationslagret finns i kod, oavsett om det är hostat i eller utanför Optimizely. Detta gör det möjligt för organisationer, som Dolby, National Rugby League och Moco Food Services, att återanvända innehåll på flera webbplatser och olika andra digitala tillgångar, såsom mobilappar och digitala skärmar.
Med lanseringen av Content Graph har vi stärkt vårt headless-erbjudande, vilket ger ingenjörer fler alternativ för att leverera innehåll, antingen via .NET SDK:er, RESTful API:er eller GraphQL.
Det som gör Optimizely unikt är att det också har en valfri sidbyggarfunktion, vilket säkerställer att marknadsförare fortfarande kan ha omfattande kontroll över upplevelsen/sidkompositionen för webbplatser. Istället för att lämna detta ansvar till ingenjörer, eller anskaffa en annan programvara för att fylla detta gap som andra renodlade headless-aktörer lämnar dig med, kan Optimizely hjälpa dig att lösa detta genom att aktivera redigeringsfunktioner på sidan, om så önskas.
Slutsats