MACH: wat betekent dat?

Product marketeers komen soms met de meeste bijzondere afkortingen, namen en product associaties op de proppen. Vandaag bespreek ik een term die je - uit het niets - veelvuldig ziet opduiken: MACH.

Waar staat MACH voor?

MACH is geen product maar een visie op de architectuur van platformen. De afkorting staat voor vier principes:

Microservices
API-first
Cloud-native SaaS
Headless

Het artikel gaat verder onder de architectuurplaat van Plate

De MACH-beweging is ontstaan vanuit bedrijven die digitale transformatie ondergaan. MACH wil deze bedrijven helpen om processen en systemen zo efficiënt en flexibel mogelijk in te richten om een sterkere concurrentiepositie te krijgen. Daarbij wordt gekozen voor best-of-breed technologie om een optimale klantervaring te bieden. Dit wordt ook wel een Happy Flow genoemd. Het resultaat van deze flow is een geïntegreerde aanpak, maar omdat klanten vaak verschillende systemen gebruiken voor een totaalproces moeten deze applicaties geïntegreerd worden. Een simpel voorbeeld om dit duidelijk te maken.

Om een schaalbaar en een meetbaar proces te krijgen, moeten al deze applicaties worden geïntegreerd. Daarbij is de MACH-gedachte een goede meetlat. Als een applicatie niet voldoet aan deze visie wordt het kostbaar en tijdrovend om integraties te maken, te onderhouden en uit te breiden. En met steeds meer applicaties die worden gebruikt voor specifieke doeleinden zoals bijvoorbeeld LeadInfo, Gong en andere tools komt er meer en meer druk te staan op dit proces.

Hieronder licht ik alle verschillende aspecten toe zodat je bij de selectie van je volgende applicatie, bijvoorbeeld je CMS, de juiste keuzes kan maken als digitale transformatie op je agenda staat.

Microservices

In feite zijn er twee manieren om een applicatie te maken. De eerste manier is een monoliet, waarin je vaak één programmeertaal gebruikt en alle onderdelen van de applicatie aan elkaar verbindt. Als een ontwikkelaar begint met het schrijven van een applicatie starten ze dikwijls klein en fijn. Maar zodra de klantwensen en -eisen zich opstapelen worden al deze functionaliteiten rechtstreeks in de totale applicatie gebouwd. Aan de andere kant kun je een applicatie bouwen in allemaal microservices. Als we een CMS even als voorbeeld pakken zou je alle onderdelen in een aparte ‘services’ kunnen zetten. Denk bijvoorbeeld aan versiebeheer, gebruikersbeheer, inline editor, kopieerfuncties, etc. Al deze functies zijn onderdeel van dezelfde applicatie maar zijn los ontwikkeld (wellicht zelfs in andere programmeertalen) en communiceren onderling via een API, vaak een GraphQL.

Bekijk de basics van microservices in deze video

Voordelen microservices

Het grootste voordeel van microservices is dat applicatie niet perse gebruik hoeft te maken van alle services en dat services dus uit te wisselen zijn. Stel dat je als klant liever niet de formulieren builder uit het CMS gebruikt maar wel die uit het CRM pakket wat je hebt kun je deze twee applicaties eenvoudig (via de GraphQL) met elkaar laten communiceren. Zo kies je uit alle applicaties die je hebt de onderdelen waar die applicatie echt goed in is en connect je dit met elkaar tot één happy flow.

Dit zorgt ervoor dat microservices super flexibel en robuust zijn. Ook kun je per microservices ook op zoek naar een programmeertaal die past bij het doel van die applicatie zodat je het meest krachtige ecosysteem krijgt. Ook heb je al klant minder last van het zogenaamde lock in effect, omdat delen van de applicatie eenvoudig uit te wisselen zijn kun je bijvoorbeeld ook de content in je huidige CMS laten zitten maar wel gebruik maken van de inline editor van een ander CMS of een personalisatie feature uit een e-Commerce systeem.

Eerlijk is eerlijk, er zijn ook nadelen die kleven aan microservices. Als je een applicatie ooit gebouwd hebt als een monoliet en je moet deze ombouwen naar een microservices omgeving kost dit enorm veel tijd in refactoring. Ook is het beheer complexer, is testing enorm belangrijk omdat alles onderling moet blijven werken (ook als een losse microservice update). Het laatste potentiële nadeel ligt in performance. Als je de microservices complex met elkaar verbindt wordt de applicatie trager, omdat er tussen de verschillende onderdelen een continue koppeling nodig is. Vaak valt dit mee, maar neem het zeker mee in je overweging.

API first

Een applicatie ‘API first’ bouwen is iets anders dan een bestaande applicatie uitbreiden met een API. API first betekent dat alle functionaliteiten van de applicatie benaderbaar zijn via een API om zo een echte connectie tussen twee applicatie te maken. Vaak zie je bij applicaties dat lang niet alle functies van een applicatie via de API benaderbaar.

Daarnaast zit er ook een verschil in de typen API (REST, GraphQL, etc) en is het ook belangrijk dat een API goed gedocumenteerd is. Zonder dat is het lastig om zonder hulp van iemand met specifieke kennis van dat product om een koppeling te maken.

Cloud-Native Saas.

Een mond vol, maar het komt er bij ‘Cloud-Native Saas’ op neer dat de applicatie echt een Cloud-product moet zijn. Niet een ‘on-premise’ product dat geïnstalleerd wordt op een server die in de cloud staat. Cloud-Native’ is meer dan een internet stekker in een oldskool applicatie. Denk aan hosting, opslag, schaalbaarheid, provisioning (ik weet hier geen Nederlands woord voor) en centrale updates waardoor upgrade beheer per klant overbodig is). Als een applicatie niet cloud-native is, is het lastig om met die applicatie te connecten. Je moet dan eerst verbinding maken met een lokale server, met authenticatie issues en meer.

Headless

In een ander artikel ga ik uitgebreid in op een Headless CMS. Het woord ‘headless’ komt op het volgende neer: de front-end gebruikerservaring (bijvoorbeeld een site die je ziet) is volledig losgekoppeld van de back-end logica, wat volledige ontwerpvrijheid mogelijk maakt bij het creëren van de gebruikersinterface en voor het verbinden met andere kanalen en apparaten (bijv. bestaande applicaties, IoT, A / R, automaten, sensoren, enzovoort.).

Zo kun je vanuit één headless database je producten beheren en op verschillende applicaties verschillend tonen. Een sportshirt op nike.com ziet er anders uit (lees: er staat andere informatie, red.) dan in de Nike-app, of op de touch-displays in de Nike-store. Hoe meer kanalen een merk heeft - omnichannel - des te groter de meerwaarde van headless is omdat je device onafhankelijk een digitale experience kunt bouwen voor een specifiek kanaal en bijbehorende doelgroep.

Conclusie, waarom moet je weten wat MACH inhoudt?

Lang niet ieder bedrijf hoeft persé zijn oren te laten hangen naar de MACH-visie. Voor sommige bedrijven is de meerwaarde gewoon niet zo heel erg groot of is de impact van de digitale transformatie niet erg sterk.

Maar ik zie nog zeer regelmatig bedrijven die ingaan op een gelikte demo van een product dat nog gewoon op een server geïnstalleerd staat, of een applicatie waarmee niet te connecten is via een API. Ga maar eens na hoeveel verschillende applicaties jij gebruikt binnen een proces en dan zie je de impact van hoe jouw bedrijf moet scoren op de MACH-scorekaart.

Met Plate zijn we hard bezig om de volle 100% score te behalen op de MACH-visie met ons Content Management Platform. Dit jaar hopen we het volledige platform in microservices opgedeeld te hebben, inclusief API's waarmee alle services benaderbaar zijn.

Plate is vanaf de start Cloud-Native SaaS geweest en ook de Headless component hebben we intern al gereleased. Het is mogelijk om met een modern front-end framework als Vue.js een website of webapp in Plate te maken en nog steeds gebruik te maken van de inline editor en het gebruiksvriendelijke CMS van Plate.

Wil je meer weten over dit onderwerp of een keer brainstormen over de digitale transformatie van jouw organisatie? Boek dan gerust een afspraak met mij. Eerst de kat uit de boom kijken? Volg ons op LinkedIn en blijf op de hoogte van alle ontwikkelingen waar we mee bezig zijn.