Composable arkitektur: Hva, hvorfor og når?

Som mange andre bransjer er også verdenen av digitale opplevelser kjent for kompleks teknisk sjargong og motebegreper. Begreper som “WCM”, “DXP”, “monolittisk”, “API”, “headless” og “mikrotjenester” har dukket opp gjennom tiårene – og nå kommer et nytt begrep inn i domenet for CMS, webapper og flere andre nisjer: “composable”.

Hva er det? Hvorfor er det viktig for din bransje og organisasjon? Bør du ta det i bruk eller ikke? Hva løser det? Og hva er utfordringene knyttet til “composable arkitektur”?

Hva er composable arkitektur?

Composable arkitektur er en gammel idé fra en annen nisje som nå blir anvendt på CMS. Vanlige prinsipper fra IT – som tjenesteorientert arkitektur (SOA) og API-er – har gradvis beveget seg fra backend til frontend. Tidligere ønsket organisasjoner å kontrollere alt innenfor sine lokale nettverk og applikasjons-backends, men ikke nå lenger.

Fremveksten av moderne frontend-rammeverk, sammen med web-API-er og mikrotjenester, har ført til en økning av SaaS-løsninger og økt teknologidemokratisering. Dette har igjen gjort det enklere å bygge komplekse løsninger uten bruk av lavnivåintegrasjoner og koding.

Det er i denne konteksten – å gå bort fra kompleksiteten til bevegelige deler – at composable arkitektur trer inn for å ta over. Drevet av moderne API- og SaaS-trender, muliggjør composable arkitektur organisasjoner å bygge rikere, bedre og mer robuste digitale opplevelser raskere og med mindre innsats – sammenlignet med å bruke tradisjonelle stack-tilnærminger.

Composable skifter fokuset fra monolittiske programvaresuiter og drift til følgende: Organisasjonen din velger i stedet de beste løsningene fra en rekke nettjenester og plattformer. Alt dette koker ned til API-er – som skifter fokus fra infrastruktur til en API-først tilnærming.

Det finnes til og med en formell forening som fremmer composable tilnærmingen, i form av MACH Alliance – hvor “MACH” er et akronym for “Microservices based, API-first, Cloud-native SaaS and Headless”.

Med deres egne ord, “er ikke enterprise-suiter lenger det sikreste valget. MACH-økosystemet er det. Det er smidig og fleksibelt, alltid oppdatert.” Alliansen ønsker derfor å “fremtidssikre enterprise-teknologi og drive nåværende og fremtidige digitale opplevelser.”

Når det gjelder composable, identifiserer de det som en arkitektur “der hver komponent er pluggbar, skalerbar, utskiftbar og kontinuerlig kan forbedres gjennom smidig utvikling for å møte utviklende forretningskrav.”

Se også: Hvordan en digital opplevelsessky kan løfte virksomheten din »

Hvorfor bruke composable arkitektur?

Akkurat som en moderne skyskraper bruker du ikke det samme materialet gjennom hele strukturen. Du bruker betong til fundamentet, stål for støtte, glass til vinduer og polert stein til overflaten. Og ikke minst tømmer, aluminium, gipsplater og andre materialer til interiøret.

På samme måte, og av samme grunner, bør du ikke bruke bare ett materiale – ett system – til å bygge dine digitale opplevelser. På grunn av rask teknologisk innovasjon og like raske forbrukeradferdsmønstre i vår omnichannel-tid, holder en ufleksibel monolittisk suite rett og slett ikke mål.

I dag bygger de fleste fremtidsrettede organisasjoner moderne løsninger med rike nettopplevelser, og setter løsningen og brukeropplevelsen i sentrum – der de tidligere hadde en iver etter teknologi som førsteprioritet.

Ifølge Uniform forutsier Gartner, Inc. at innen 2023 vil organisasjoner, som har tatt i bruk en intelligent composable tilnærming, implementere nye funksjoner 80 % raskere enn sine konkurrenter som har tatt i bruk en suite eller en skreddersydd tilnærming.

80 % raskere er et betydelig tall. I tillegg til vesentlig forbedret smidighet og hastighet, tilbyr composable en velkommen ansvarsseparasjon. Nå kan frontend-utviklere fokusere på brukeropplevelsen, og separate team kan dra nytte av den gode gamle arbeidsdelingen for å få ting gjort. Det vil derfor være enklere å oppgradere og skalere ulike deler – uten å involvere andre spesialister hver gang.

Se også: Mikrotjenester: Hva betyr det for ditt digitale prosjekts suksess?

Separasjon av innhold og presentasjon er en naturlig del av composable arkitektur. Som nevnt er omnichannel en pådriver bak composable arkitektur, ettersom forbrukere – dine lesere, besøkende, klienter, kunder og ambassadører – har en tendens til å være overalt. De ryddige dagene med klart definerte kanaler er for lengst forbi. Nå er folk på smarttelefonen mens de jobber på den bærbare datamaskinen, samtidig som de får helseråd og de siste nyhetene fra aksjemarkedet på sine smartklokker.

Hva tror du best imøtekommer dette scenariet? En monolittisk DXP-suite eller en fleksibel, best-of-breed-løsning?

Ta for eksempel moderne e-handel. Nettbutikker legger ikke alle eggene i én kurv, men velger ofte tredjepartstjenester – som Klarna for en smidig betalingsopplevelse. Headless CMS er et annet åpenbart eksempel på composable.

Kjerneidéen er at du bygger løsningen din med flere deler, "best of breed" fra alle sine respektive nisjer – enten det er CMS, e-handel, analyse, frontend-rammeverk, CRM eller markedsføringsautomatisering, ad infinitum.

Når bør du bruke composable arkitektur?

Selv om composable arkitektur har blitt presentert med flagg og faner, er det ikke en enkel sak om organisasjonen din bør ta i bruk et slikt system eller ikke. Så, når bør du bruke composable?

I tillegg til å være på utkikk etter alle fordelene nevnt ovenfor, hvis organisasjonen din ønsker å bygge kundetilpassede digitale opplevelser, er en variant av composable arkitektur mest sannsynlig best egnet for formålet.

Du og dine interessenter i organisasjonen må også stille dere selv følgende spørsmål: Hvilke deler av det bevegelige maskineriet bør du skaffe som tjenester i SaaS-stil, og hvilke bør du ta større ansvar for og bygge selv?

Videre, når bør du ikke bruke en composable arkitektur? Hvis du bare vil ha et enkelt nettsted eller en blogg, er et slikt oppsett smør på flesk. Hvis du vil ha en ferdig løsning rett ut av boksen, og hvis en slik løsning som oppfyller dine krav finnes, så flott! Ingen behov for composable.

Se også: Fremtiden for CMS »

Utfordringer med composable arkitektur

Ingenting i denne verden kommer uten både fordeler og ulemper, og composable er intet unntak. En hovedutfordring med tilnærmingen er sikkerhet. For eksempel når det gjelder GDPR: hvor mye og hvilke data deles med hvilken leverandør i din potensielle “lappeteppe”-løsning?

Risikoen for hacking er også større når du bruker mange forskjellige systemer, noe som betyr at deler av løsningen kan bli brutt individuelt. Du er ikke sterkere enn ditt svakeste ledd, så sørg for å bygge en løsning som kan håndtere én feil blant flere faktorer. For eksempel, hvis en betalingsløsning består av fire faktorer, bør den fortsatt kunne være operativ selv om en av disse svikter eller blir hacket.

Se også: Composable arkitektur: Using the CMS as your director »

Når det gjelder administrasjon, med flere leverandører vil det selvfølgelig være et like stort antall avtaler og kontrakter – noe som i verste fall kan legge til byråkrati og hodepine for deg og din organisasjon. Sørg for å minimere antall leverandører, i samsvar med hva dine team kan håndtere.

Produktene du bruker for å bygge din composable-løsning er selvfølgelig av enorm betydning. Ta headless CMS for eksempel. På grunn av svakheter i flere headless-systemer mister innholdsredaktører kontrollen de tidligere har vært vant til. Mye av funksjonaliteten har blitt flyttet til utviklernes bord, eller har blitt hardkodet inn i løsningen – noe som etterlater redaktørene frustrerte eller til og med rasende.

Hvordan du integrerer ditt CMS med ditt frontend-rammeverk er en av nøkkelfaktorene for fleksibilitet for både redaktører og utviklere, så velg ditt CMS, rammeverk og andre composable-komponenter med omhu.

***

For å oppsummere: Til tross for utfordringene, gjør de overordnede fordelene med composable arkitektur det til den mest sannsynlige tilnærmingen flere og flere organisasjoner vil benytte for å møte omnichannel-virkeligheten.