Vad är MACH Arkitektur?
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 ska formas på ett konceptuellt plan. Jag gissar att det var bakgrunden till den nya marknadsföringstermen MACH Arkitektur.
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 ska 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 ska 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.