De 4 bästa användningsområdena för att gå headless

Med 64% av företagen som för närvarande använder en headless-strategi och 90% som planerar att utvärdera, är den ökande populariteten för headless arkitektur obestridlig. Ja, den headless hype är verklig och kommer med tydliga fördelar för ingenjörsteamet. Men som med alla tekniska investeringar är det viktigt att ta ett steg tillbaka och verkligen förstå de problem som din organisation försöker lösa och varför headless är i linje med dessa användningsfall.

Så, vad försöker du uppnå? Om något av följande affärskrav stämmer in på dig kan ett headless Content Management System vara den perfekta lösningen.

Affärskrav #1: Framtidsberedskap, undvika leverantörslåsning
"Vi vill vara redo för framtiden och enkelt kunna anpassa oss till förändrade krav."

För organisationer som vill ha anpassningsbarhet och möjlighet att byta ut komponenter utan problem kan ett headless CMS vara ett bra val. En headless arkitektur tvingar teamen att decoupled CMS från frontend (eller presentationslager) samt backend-logiken, i form av mikrotjänster som driftas utanför CMS. Detta ger dig en enorm frihet när det gäller frontend och backend. Du kan använda olika ramverk för frontend som Vue, React eller Angular eller programmeringsspråk för backend som .NET eller Java, som driftas som mikrotjänster på den molnplattform du föredrar. Den flexibla karaktären hos en headless arkitektur säkerställer att du bibehåller lös koppling mellan nyckelkomponenterna så att om du någonsin måste byta ut ditt headless CMS, till exempel, kan din frontend och backend stanna kvar, vilket sparar dig huvudvärken 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 och kan jag koppla bort från resten av stacken?

Affärskrav 2: En enda innehållshubb för flera kanaler
"Vi behöver en centraliserad lösning för hantering av innehåll för våra olika digitala innehåll."

Om ditt företag har flera webbplatser eller kanaler som mobilappar, kiosker eller digitala menyer, kan du konsolidera till en enda innehållshubb så att du kan hantera allt innehåll på ett ställe. National Rugby League använder till exempel Optimizely för att hantera innehåll för 19 webbplatser, en mobilapp, digitala skärmar och fyra andra digitala egenskaper. På samma 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ärskrav verkligen handlar om att ha ett enda innehållsförvar kan ett headless CMS ge dig den centraliserade lösningen för strömlinjeformad 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 att tänka på innehåll på ett strukturerat sätt och förbereda sig för återanvändning och innehållsleverans till flera digitala kanaler.

Affärskrav 3: Frikopplad frontend och backend
"Vi vill använda 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 utvecklingsteam för frontend och backend kan varje team "hålla sig på sin egen bana" och fokusera på sina respektive expertområden. Detta tar bort onödiga beroenden, förbättrar medarbetarnas moral och gör det möjligt för företaget att komma ut på marknaden snabbare. Genom att välja en headless-lösning kan du 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 när de strukturerar och underhåller sin kod, så att de inte bygger en monolit av den limkod som krävs för att binda samman headless lösningar.

Affärskrav #4: Applikationer med hög interaktivitet
"Vi har en webbplats för e-handel" eller "Våra kunder gör i första hand affärer 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 krav på interaktivitet 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, ger en effektiv mjukvaruutveckling. Men om dina digitala fastigheter är komponerbara av marknadsföringswebbplatser eller mobilappar som bara visar information, kan det vara överflödigt 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 teamen att i onödan decoupled 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örhandsgranskningsfunktioner, personalisering, formulär för att generera leads, CDN, generering av statiska webbplatser med mera. Som företag måste du hantera flera leverantörer, kontrakt och varierande SLA:er och implementera dessa lösningar i ditt huvud.

Ställ dig själv frågan: Motiverar mitt användningsfall det extra ansvar som det innebär att arbeta med många leverantörer, teckna och förhandla om flera kontrakt, arbeta med olika SLA:er och underhålla egen limkod?

Glöm inte ditt marknadsföringsteam.

Utvecklare förespråkar ofta headless på grund av den enorma flexibilitet de får. Å andra sidan behöver marknadsförare, innehållsskapare och redaktörer ett CMS som enkelt fungerar med deras innehållsskapande process och kan upptäcka att även om ett headless CMS hjälper dem att strukturera innehåll utan ett presentationslager, kommer sidans/upplevelsens sammansättning nu antingen att drivas av teknik genom kod eller genom en annan programvara. Headless CMS, som namnet antyder, har i allmänhet inte funktioner för att bygga upplevelser/sidor. Om de gjorde det, är de inte rena huvudlösa. 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 röra sig snabbt.

Kan Optimizely distribueras som ett headless CMS?

Absolut - Optimizely CMS har alltid decoupled innehållet från presentationslagret. Innehållet finns i Optimizelys databas och presentationslagret finns i koden, oavsett om det driftas 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 olika webbplatser och andra digitala egenskaper, som mobilappar och digitala skärmar.

Med lanseringen av Content Graph har vi stärkt vårt headless API-erbjudande och 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 One unikt är att det också har en valfri funktion för sidbyggare, 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 skaffa en annan programvara för att fylla detta gap som andra rena headless-spelare lämnar dig med, kan Optimizely hjälpa dig att lösa detta genom att aktivera redigeringsfunktioner på sidan, om så önskas.

Slutsats

1. Att välja ett headless CMS ger dina ingenjörer en enorm frihet. Detta gör att du kan komma ut på marknaden snabbare. För mycket flexibilitet kan dock bli en belastning, så se till att en företagsarkitektur och rigorösa tekniska metoder finns på plats för att undvika att hamna i en monolit av anpassad kod.
2. Headless CMS löser, som namnet antyder, innehållshantering, men inte hantering av presentationslager. När du väljer ett headless CMS ska du se till att du också har en upplevelse-/sidbyggarlösning på plats för marknadsförare, så att de har en hög grad av självförsörjning och slipper vara beroende av ingenjörer i sitt dagliga arbete.
3. Att välja ett headless CMS ger företaget förutsättningar för ett komponerbart digitalt ekosystem, vilket skapar agilitet för verksamheten. Ett ekosystem med flera programvaruleverantörer resulterar dock i flera kontrakt, varierande SLA:er och eventuellt limkod för att implementera dem alla. Ta ett steg tillbaka och fundera på om ditt företags användningsområden motiverar det extra ansvaret för att hantera flera leverantörer, varierande SLA:er och underhåll av intern limkod.