IT-arkitektur har stor betydning for din forretning

Når man skal snakke om IT-arkitektur, kan det blive en smule kedeligt, men det er også meget vigtigt. Det er nemlig der, de skjulte fordele med et headless CMS findes.

Når vi ser tilbage på samarbejdet med vores kunder, så bliver det tydeligt, at IT-arkitekturen har stor indflydelse på, hvor effektivt der udvikles på et IT-projekt. De fordele, du opnår i denne effektivitet, har ofte langt større praktisk betydning for virksomheden, end de fordele headless CMS ellers reklamerer med (fx nemmere at genbruge indhold, nemmere at skalere sit website, genbrug af indhold på tværs af indholdskanaler, bedre sikkerhed og bedre ydeevne).

De fordele, du kan opnå ved at forbedre din IT-arkitektur, kan deles i to kategorier: effektiv udvikling og tekniske fordele.

Effektiv udvikling:

• Mindre og oftere deploy til produktion

• Nemmere at teste

• Nemmere at vedligeholde

• Bedre adskillelse af komponenter reducerer kompleksitet

Tekniske fordele:

• Bedre mulighed for skalering af applikationen

• Forbedret sikkerhed

• Nemmere at lave integrationer til andre systemer

• Større fleksibilitet, hvilket gør det nemmere at opdatere eller udskifte dele af løsningen
  
  

Vil headless CMS ændre hele vores IT-arkitektur?

Både ja og nej.

Når du har valgt at skifte til headless CMS, skal du tage stilling til, hvordan det skal passe ind, og hvordan du vil arbejde med det. Det kan fx være, at i det tidligere CMS-system var alt samlet i en stor klump. Her vil headless CMS have det i små bidder. Det er her, det kan begynde at påvirke it-arkitekturen, da arbejdet med et nyt CMS-system kan få svagheder i bagvedliggende systemer frem til overfladen.

Fordi headless CMS ofte ændrer den måde, du bygger din frontend, er det typisk det første område, du vil tage fat på. Derfra ser vi ofte, at det breder sig til andre systemer, som så også vil blive bygget med en mere moderne IT-arkitektur.

Headless CMS vil forsøge at skubbe din IT-arkitektur i en bestemt retning, fordi headless systemer har en holdning til IT-arkitektur. Det er også, hvad vi oplever hos vores kunder. Man starter med headless CMS, fordi det er det mest håndgribelige sted at starte, og det viser vejen til en bedre IT-arkitektur.

Så nej, det ændrer som udgangspunkt ikke hele IT-arkitekturen, men da headless CMS har en holdning til, hvordan du arbejder med din IT, og eksisterende svagheder bliver tydelige, vil det brede sig til en ændret, men bedre og mere effektiv IT-arkitektur over tid.

Microservices giver en forbedret IT-arkitektur

Fordi et headless CMS er fuldstændig afkoblet fra frontend, presser den udvikleren til at splitte sin applikation op i flere microservices, der er mere eller mindre uafhængige af hinanden. Dette skyldes, at der allerede er et naturligt skel mellem, hvor dataene kommer fra (et headless CMS som fx Contentful), og hvor dataene bruges (i frontend-applikationen).

Når applikationerne er delt op i microservices, kan de forskellige services udvikles og udgives uafhængigt af hinanden og dermed give minimale forstyrrelser for redaktører og brugere. Når en service er nem at udskifte i dit CMS-system, er det også nemmere at udskifte eller tilføje de teknologier, din frontend applikation benytter sig af. Teknologien er nemlig ikke nødvendigvis brugt i hele applikationen, men er isoleret for resten af applikationen i en enkelt microservice. Fordi teknologierne i frontend hurtigt skifter, skal du hele tiden udskifte dele af dine systemer, hvis du vil have en løsning, der er moderne og tidssvarende, og undgå at sidde fast i uhensigtsmæssig eller forældet teknologi.

Med den hyppige udskiftning som microservices tillader, ser vi performancemæssige forbedringer i forhold til større og mere sammentømrede applikationer. Det er særligt vigtigt i vores eCommerce samarbejder, hvor en langsom hjemmeside kan betyde, at et salg går tabt.

Denne form for IT-arkitektur, der de seneste år har oplevet en stigende popularitet, kaldes for MACH-arkitektur; Microservices-based, API-first, Cloud-native and Headless. I en IT-arkitektur der følger MACH-principperne, vil den samlede applikation være delt op i microservices som nævnt ovenfor. De forskellige microservices vil udstille API’er, så det er nemt for andre applikationer, interne eller eksterne, at benytte sig af dem. Det kan også være oplagt at have en microservice, der håndterer en eller flere API’er, da det er en funktionalitet, som er nem at afgrænse.

Når de forskellige dele af løsningen er delt op i microservices, vil du i mindre grad opleve, at der opstår fejl i noget, du tilsyneladende ikke har ændret, fordi der var en skjult afhængighed i andre dele af applikationen. Én stor samlet applikation vil oftere give anledning til, at funktioner der fra et forretningsmæssigt synspunkt ikke har noget med hinanden at gøre, vil være tæt knyttet sammen i kodebasen. Disse regressionsfejl (fejl der opstår i en funktionalitet, som tidligere er testet, leveret og accepteret ) kan være svære at finde og rette, fordi der ikke nødvendigvis er en oplagt sammenhæng mellem, der hvor ændringerne er foretaget, og der hvor fejlen opstår. Dem er der betydeligt færre af i de projekter, der bruger headless CMS, og som dermed lægger sig tættere op ad principperne i en MACH-arkitektur.

Med en forbedret arkitektur følger en agil arbejdsproces

Ud over de arkitektoniske fordele oplever vi også, at arbejdsprocessen bliver væsentlig mere smidig og effektiv. Når ens løsning er delt i microservices, kan mindre dele af den samme løsning udskiftes for sig selv, og deploys kan være mindre og ske oftere. De opgraderinger, der er klar, kan udgives uden at vente på, at de andre services bliver opgraderet eller opdateret. Derfor vil det tage kortere tid at udgive en opgradering eller MVP (Minimum Viable Product), fordi tiden, der bruges på at bygge en release og teste den, vil være kortere. Der er derfor heller ikke langt fra at arbejdet med ændringer begynder, til at du kan se forbedringerne hos brugerne. Med færre ting der skal testes i forbindelse med udgivelsen af en ny release, oplever vi, at vores kunder sparer på ressourcerne. Hvis der fx var mange ændringer i en release, som påvirker hinanden på kryds og tværs, ville testfasen blive betydeligt længere.

Derudover er det også en stor fordel for os i vores daglige arbejde, at den konkrete funktionalitet, vi arbejder på, er separeret fra ting, der ikke har noget med det at gøre. Det kan måske lyde åbenlyst, men på store tæt sammenknyttede projekter vil der ofte være omkostninger forbundet med, at udviklerne skal navigere en unødvendig kompliceret IT-arkitektur.

Hvad har vi så fået ud af alle disse fordele?

• Mindre omkostning på nyudvikling – du får mere for pengene, da der ikke skal bruges lang tid på test og release.

• Hurtigere ”time-to-market”.

• Mulighed for flere hurtigere gentagelser på udvikling, hvilket giver højere kvalitet og bedre styring af resultatet fra kundens side.

• Et mere stabilt system med færre nedbrud.

• Fordi koden er adskilt i fx microservices, har nedbrud mindre effekt, da det ofte kun vil være en mindre del af systemet, der går ned.

Der er altså masser af fordele at hente ved at skifte til et headless CMS. Også selvom du ikke umiddelbart har behov for nogle af de åbenlyse fordele et headless CMS kommer med. Det meste af omkostningen ved et IT-system kommer nemlig i udvikling og vedligeholdelse, så den største gevinst, du kan opnå, er ofte at gøre arbejdsprocesserne mere effektive. Når det sker, vil du som en bonus også se færre fejl. Med effektiviteten vil kvaliteten også stige, og du får dermed en løsning, der kører bedre, og det kan mærkes af brugerne af IT-systemet.
Der er altså langt større gevinster at vinde, end det lige umiddelbart ser ud til, når du ved et skifte til et headless CMS både kan forny og forbedre din IT-arkitektur.

Tøv ikke med at række ud til os. Vi er altid klar på en uforpligtende samtale om din virksomheds behov, og hvordan et headless CMS kan bidrage til din forretning. Du kan kontakte os her.