För ett par år sedan började vi höra i publikationer och på konferenser om hur lösningar baserade på MACH-arkitektur är det nya paradigmskiftet inom sektorn för tekniska lösningar.
Under det senaste året har MACH-leverantörer erhållit 2,5 miljarder dollar i finansiering och har en global värdering på 20 miljarder dollar (källa MACH Alliance) . Något stort händer i den här sektorn, och det är ingen övergående trend.
Bland MACH-lösningarna hittar vi främst e-handel och innehållshanterare (CMS), men det finns även PIM-lösningar, söksystem, integrationsverktyg och varje dag läggs fler lösningar till denna nya filosofi vars fördelar inte alltid är så enkla att förstå.
Vad betyder MACH??
Förkortningen MACH syftar på tekniska begrepp, som kan vara svåra att förstå för någon i näringslivet som behöver förstå vad som är skillnaden mellan en MACH och en icke-MACH-lösning. Vi kommer nedan att förklara MACH från M till H, med fokus på hur det skiljer sig från andra lösningar och framför allt vad det tillför vår verksamhet.
M som i Microservices
Mikrotjänster avser ett sätt att utveckla lösningar som består av en stor samling små oberoende lösningar med ett enda syfte och som kommunicerar med varandra. Till exempel har en MACH e-handelslösning en mikrotjänst för att lägga till produkter till en beställning, en annan för att kontrollera produkttillgänglighet, en tredje för att beräkna fraktkostnader.
När är det inte mikrotjänster? I ett system som inte är byggt med mikrotjänster är funktionaliteterna intrasslade och starkt beroende av varandra. Att modifiera en del av programvaran innebär att hela programpaketet ändras.
Vad ger det mig? Den största fördelen (det finns fler) med mikrotjänster är hur effektiv och framtidssäkrade lösningen är. Om du hyr mjukvaror som använder mikrotjänster kan du anta att den kommer att utvecklas snabbt och smidigt. Men det riktigt intressanta med mikrotjänster kommer med nästa punkt.
A som i API First
API:er är funktioner som följer en kommunikationsstandard, vilket innebär att alla som har fått tillstånd kan använda dem. Om var och en av de ovan diskuterade mikrotjänsterna tillhandahålls som standard med en kommunikationsstandard (därav First), tillåter detta att olika mjukvaror interagerar med varandra på vilken detaljnivå som helst.
När är det inte API First? När jag exempelvis måste ladda ner en Excel-fil från en programvara för att återimportera den till en annan eller när jag manuellt måste replikera information mellan applikationer.
Vad ger det mig? Om du någonsin har använt verktyg som Zapier vet du redan vad det handlar om. Du kan också ha integrerat ditt webbformulär med MailChimp eller ditt CRM. Dessa integrationer har varit möjlig eftersom båda verktygen har API:er. Föreställ dig nu denna funktionalitet, men på vilken detaljnivå som helst i alla dina affärsapplikationer... alternativen är oändliga. Vi kan ha vår B2B e-handel som matar på produkterna från PIM, som i sin tur tar ut dem från ERP, som personifierar innehållet med hjälp av specifik programvara som matar på ditt CRM och som visar produktkonfigurationen som tar det från din CPQ. Du kommer ofta att se denna funktion beskriven som "composable", åtföljd av metaforen om att bygga lösningar som om de vore legobitar.
Fördelarna med composable finns inte bara i data som färdas mellan applikationer på ett exakt sätt i realtid, utan vi kan när som helst dekomponera vår applikation genom att ersätta en del med en annan utan att påverka helheten. Något som garanterar oss en organisk utveckling av våra digitala lösningar som kan växa isolerat. Aldrig mer kommer vi att höra "om vi ändrar webbplatsen måste vi ändra e-handel, och om vi ändrar e-handel måste vi ändra e-postsystemet, och om ..."
C som i Cloud-native SaaS
Vi vet alla vad Cloud är och SaaS (för Software as a Service, ännu en förkortning!) också, men inte nödvändigtvis med detta namn. En SaaS-mjukvara är en programvara som vi normalt ansluter till via en webbläsare och där leverantören tar hand servrar, underhåll och uppdateringar. Salesforce var den som introducerade konceptet. Många andra verktyg som vi använder dagligen som Gmail, HubSpot eller MailChimp är också SaaS
När är det inte molnbaserat SaaS? Om du måste installera det, som Outlook på skrivbordet, om du måste ladda ner uppdateringar, som Spotify, eller om du måste installera och underhålla servrar, som Jira on premise, så har du inget SaaS-system.
Vad ger det mig? Alla olägenheter ovan försvinner. Ingen installation, ingen versionshantering och underhåll. Dessutom, och detta är en av de viktigaste aspekterna, är komplexiteten i serverhantering, bevakningsteam, hantering av hög tillgänglighet eller geografisk replikering av infrastruktur något du behöver ta ansvar för längre. Saker bara fungerar.
H som i Headless
Huvudet i applikationsutveckling syftar på den visuella delen, till det användargränssnitt som vi arbetar med. En Headless-applikation betyder inte att den inte har ett användargränssnitt, utan att gränssnittet och datadelen är helt frikopplade. En lite mer teknisk beskrivning som du kommer att höra är att back-end och front-end är helt frikopplade.
Precis som vi ovan berättade om applikationer som ansluter till varandra genom API:er, händer något väldigt likt här, och det är att den visuella delen av vår applikation är kopplad av API till delen med affärslogik och data.
När är det inte Headless? Om du till exempel har WordPress, har du inte en Headless-applikation (det kan finnas undantag), det betyder när du gör ändringar i den visuella (eller front-end) delen kan du också behöva göra ändringar i back-end delen.
Vad ger det mig? Om din webbplats utvecklades på ett Headless sätt, kan du byta ut ditt CMS genom och behålla hela den visuella delen vilket ger dig skalbarhet och flexibilitet
Prestanda är en annan stor fördel, eftersom mycket arbete laddas ner från servern och det är också lättare att distribuera din applikation geografiskt, det vill säga dina användare ansluter till den närmaste servern. Slutligen ökar också säkerheten eftersom de mest kritiska delarna av webben (backend-delarna) är mer isolerade och vi bara tillåter åtkomst till det som redan är offentligt, såsom bilder och statiska resurser.
Vad är då ett MACH-ekosystem?
För att sammanfatta, mycket kort, hjälper ett MACH-ekosystem, som vi har sett ovan, dig att förbättra aspekter som hastighet och säkerhet, det ger dig saker som du inte kunde tidigare, som att ha data i realtid och utveckla dina applikationer separat, och det tar ansvaret för serverhantering och uppdateringar.
På Novicell, som medlem i MACH Alliance, är vi glada över att vara en del av detta paradigmskifte och är engagerade i att sprida fördelarna med denna typ av teknik. Om du vill veta mer om hur ditt företag kan dra nytta av dessa teknologier, kontakta oss.