STARTOM OSSLEDIGA JOBBPROJEKTAKTUELLTKONTAKT
FRAMKANTEN AV WEBBENHEADLESS CMSPET PROJECTS

MACH Arkitektur

2020-11-16 - Kristoffer Fredriksson

Det kan vara svårt att sälja in nya koncept, särskilt när det handlar om något så flyktigt som principer för hur system skall formas på ett konceptuellt plan. Jag gissar att det var bakgrunden till den nya marknadsföringstermen MACH Arkitektur.

MACH är en förkortning som består av fyra grundprinciper som fungerar väldigt bra tillsammans för den som vill ligga i framkant inom digitaliseringen. De är: Microservices, API First, Cloud native, och Headless.

Syftet med att ha dessa i åtanke vid digitala projekt är att skapa lösningar som är flexibla, framtidssäkra och skapar möjligheter istället för inlåsning i tungrodda system.

Microservices

LEGO är alltid en bra analogi, och så även i detta fallet. Istället för att köpa en färdiggjuten plastdrake så innebär microservice principen att draken byggs av flera individuella LEGO bitar. Bitar som sedan kan återanvändas till att bygga en orm, ett grottroll eller en skorpion. Förutom att saker går att återanvända i nya projekt så är en stor fördel att enskilda bitar kan förändras, förbättras, eller bytas ut.

Till exempel kan kundvagnen, betalsystemet eller videospelaren på en webbplats ersättas med nya, bättre lösningar, utan att hela webbplatsen byggs om.

API-First

Så, vad är det som ser till att informationen från kundvagnsservicen når betalservicen? Det är här APIet kommer in. Ett API är bara en samling överenskommelser om hur olika system skall kunna kommunicera med diverse lösningar. Hur kan Apoteket låta folk logga in med BankID, när Apoteket inte är med i gruppen av banker som står bakom BankID? Enkelt! Bankerna har skapat ett API som berättar för utvecklare hur de kan integrera BankID i alla möjliga tjänster som kräver inloggning.

En API First lösning utgår från att lösningen behöver ett “meta API” som håller reda på alla olika services som ingår. Både de som byggs specifikt för lösningen, och eventuella externa.

Cloud Native

Idag läggs alla våra nya projekt i “molnet” vilket har många fördelar. Jag skulle dock vilja dra Cloud Native lite längre än vad MACH Alliansen gör, och uppmana till ett Web First tänk. Det passar så väl in med både API First och nästkommande punkt att det blir lite baklänges att avsluta en så pass plattformsoberoende lösning genom att bygga en app-app med alla risker det innebär. Värt att tänka på är valet av molnleverantör.

Headless

Det här har vi pratat om i åratal. Låt inte ditt CMS diktera frontend. (Eller vad som skall ingå i lösningens backend heller för den delen.) En MACH lösning kan serva hur många gränssnitt du önskar genom att tillhandahålla innehållet som data.

TL;DR

MACH är fyra väldigt vettiga principer som alla borde ta till sig när de planerar, och bygger, system i Enterprise-skala. Mycket är även applicerbart i mindre sammanhang, men med tanke på att det krävs erfarna utvecklare, och arkitekter, så är kostnaden högre än om man bara valt ett snyggt tema till WordPress. Det är viktigt att göra en avvägning.

Ett väldigt starkt argument för MACH arkitektur är att det inte blir någon extrakostnad att lansera projekt stegvis. Det är inbyggt i själva DNA:t. Företag behöver inte vänta två år på en jättelansering som riskerar att träffa snett i vilket fall. Bygg och lansera delmål på månadsbasis, och rikta in siktet, eller målet, under resans gång istället.

Vill du läsa vad branschkollegorna på Valtech har att säga om MACH arkitektur, så kan du göra det här.


Vad är API First?
BLOGG
Vad är API First?
Den logiska utvecklingen av Headless CMS
Vad är Headless CMS?
BLOGG
Vad är Headless CMS?
Ett bättre sätt att hantera content.
Planera ett Digitaliserings -projekt.
BLOGG
Planera ett Digitaliserings -projekt.
En grundplan för digitalisering
Vad gäller på webben? #057
PODCAST
Vad gäller på webben? #057
The Web Remains #035
PODCAST
The Web Remains #035
Page Builders & Headless 2.0 – #041
PODCAST
Page Builders & Headless 2.0 – #041