MACH is misschien hip, maar is het ook waardevol?

MACH: Microservices, API-first, Cloud-native SaaS en Headless; een begrip dat opeens volop in de belangstelling staat. Hoewel de losse concepten al geruime tijd bestaan en bekend zijn, wordt er nu, door de in juni opgerichte MACH Alliance, een paraplubegrip op deze technische visie geplakt. Is ‘MACH’ het nieuwe ‘Cloud’? Net zo invloedrijk als ‘SaaS’? Of is dat toch nog te veel eer? Ik voorzie met MACH een complexe uitdaging én ook iets dat veel waarde biedt voor bedrijven die een unieke, omnichannel klantbeleving willen creëren.

Microservices, API-first, Cloud-native SaaS en Headless

MACH is ontstaan als onderdeel van de ‘digitale transformatie’-vloedgolf. Het begon als een manier om grotere webapplicaties, mobiele kanalen en front-end-facing projecten te ontwerpen met de inzet van componenten van verschillende vendors. Nu dringt deze visie steeds dieper het hele IT-landschap binnen.

Componenten architectuur

Kenmerkend voor de MACH-architectuur zijn openheid en interoperabiliteit, geen monolieten maar applicaties die zijn opgebouwd uit beheersbare componenten. Een MACH-architectuur wordt opgebouwd uit (micro)services, die toegankelijk zijn via gestructureerde APIs. Dat kunnen services zijn die je als bedrijf zelf bouwt, omdat ze bijvoorbeeld nog niet in de markt bestaan, of services, en dat zullen veruit de meeste zijn, die je afneemt in de cloud. De benodigde services combineer je vervolgens slim tot je eigen, unieke value chain.

Daarbij komt dat je je met een MACH-landschap nauwelijks druk hoeft te maken over upgrades, schaalbaarheid en flexibiliteit. Het landschap draait grotendeels in de cloud en door de architectuur met microservices en APIs ontstaat er veel flexibiliteit en beheersbaarheid. Services vervangen, verbeteren of verwijderen gaat relatief eenvoudig, zonder dat alles helemaal op de schop moet. En doordat de back-end en systeemintegraties losstaan van de front-end (‘headless’), stapt MACH volledig weg van grote, verticaal geïntegreerde platformen waarin de userinterface gewoonlijk sterk verbonden is met de achterliggende business logica. Kortom, de ‘composable’ MACH-architectuur biedt veel flexibiliteit en vooral ook de mogelijkheid tot een veel hogere verandersnelheid. Dit in tegenstelling tot een klassiek (on-premise) platform dat vooral om een vastomlijnde aanpak vraagt.

Traag releasen

De afgelopen jaren zijn veel bedrijven steeds meer afhankelijk geworden van enorme ‘suites’ van klassieke platform vendors. Een combinatie van grote CMS-systemen of DXP’s, omvangrijke commercepakketten en uitgebreide marketingpakketten zijn eerder de standaard dan een uitzondering. Daarin zit dan wel van alles geïntegreerd: search, analyse, ranking, content, workflow, etc., maar de pakketten zijn ook duur. En upgrades worden alleen maar lastiger, vooral naarmate je er meer gebruik van maakt. De maatwerk extensies, complexe en statische integraties of andere afhankelijkheden vormen een flinke klus als je die moet upgraden. ‘Does it feel like you are upgrading your systems all the time?’ is hier misschien wel één van de belangrijkste vragen.

Veel bedrijven lopen daar tegenaan. ‘We geven intussen meer geld uit om het platform in de lucht te houden dan aan nieuwe businessfunctionaliteiten, is iets wat we vaak horen. Point releases met gedoe zijn echt een ding en het steeds weer opnieuw upgraden naar de nieuwste versie van bijvoorbeeld Sitecore, Adobe Experience Manager, Magento of SAP Commerce brengt gewoon veel kosten met zich mee. En dan hebben we het nog niet eens gehad over de matige innovatiekracht van de klassieke, verticaal geïntegreerde platformen. Innovatie gaat vaak traag. Er is misschien een jaarlijkse feature-release, maar voor je ‘die ene handige feature van Google’ eindelijk hebt, ben je soms jaren verder. Dat moet allemaal veel sneller kunnen.

Unieke klantbeleving met MACH

Ook is het steeds belangrijker om een unieke customer journey te kunnen bieden. En om die snel en effectief te kunnen aanpassen aan veranderende omstandigheden. Eén van de uitdagingen van veel bedrijven is een uniek product versus een unieke beleving. Neem bijvoorbeeld maaltijdbezorgdiensten. Los van het feit dat bijvoorbeeld Thuisbezorgd.nl en Deliveroo een iets van elkaar verschillende doelgroep willen aanspreken, is hun product in essentie hetzelfde: maaltijden bezorgen. Zij zullen dus moeten concurreren op beleving. Daarvoor is onder andere een maatwerk front-end nodig. En misschien wel meerdere zoals een (native) app, conversational commerce en website. Die front-ends wil je koppelen met een reeks van services die op verschillende manieren gecombineerd en uitgebreid moeten kunnen worden, gebaseerd op de unieke propositie van je bedrijf. Dat vraagt dus in plaats van een platform dat een tamelijk strak business format biedt, om een ‘composable architecture’.

Flexibiliteit en schaalbaarheid

Veel bedrijven hebben geprobeerd om dit soort unieke belevingen of complex georganiseerde value chains op de klassieke platformen in te richten. Vaak lopen ze daarbij aan tegen een moeizame configuratie. Maar ook de noodzaak om 100% kennis van een platform te hebben, om uiteindelijk misschien maar 15% van de functionaliteiten te gebruiken. Daarnaast zijn ze afhankelijk van trage release cycles en ook relatief vaak een langdurig, kostbaar upgradetraject. MACH lost veel hiervan op. Omdat je het landschap opbouwt in microservices kun je heel specifiek kiezen wat je nodig hebt. Daardoor kun je ook gerichter investeren in kennis. Een MACH-landschap draait bovendien in de cloud, dus over schaalbaarheid, infrastructuur en eventuele piekbelastingvraagstukken hoef je je geen zorgen te maken. Alle benodigde services binnen de gehele value chain en customer journey kun je zelf kiezen en opbouwen met verschillende componenten en op een uniforme manier verbinden via APIs.

Meer voordelen dan nadelen?

Maar heeft MACH dan alleen maar voordelen? Nee, MACH heeft niet alleen maar voordelen en brengt ook nieuwe en andere uitdagingen met zich mee. Zie het opzetten van een MACH-architectuur als schetsen maken op een lege A4. Zo moet je onder meer in staat zijn om te bedenken hoe je een systeem opbouwt, welke services je kiest en waar je in het selectieproces op moet letten. Een klassiek platform biedt dan meer houvast, omdat er een duidelijke visie is op hoe zaken moeten werken.

Klassieke platformen bieden hulp en richting bij processen als: hoe een order wordt afgehandeld in een commerce-monoliet of hoe het CMS qua edit-flow werkt. In een DXP staat dat grotendeels vast. Variëren kost moeite, maar de default is 80% juist en bruikbaar. Enerzijds geeft dat steun, maar anderzijds biedt het dus soms wel wat minder vrijheid. MACH biedt meer vrijheid. Als je customer journey weinig tot geen unieke aspecten nodig heeft, bijvoorbeeld omdat je product zelf al super uniek of niche is, dan blijft een klassiek platform vaak de betere keuze. Er is dan simpelweg minder behoefte aan een unieke customer journey bij dat product.

Andere kennis nodig

Daarbij brengt MACH meer complexiteit door het totale landschap dat je moet overzien, meer integratiewerk en het vraagt om meer eigen keuzes. De ontwikkeling van technische kennis is eigenlijk de grootste uitdaging om de overstap te kunnen maken naar MACH. Maar je kunt ook kiezen voor een integratiepartner, zoals Isaac, waarmee je die kennis en capabilities in huis haalt. De kennisontwikkeling is eigenlijk één van de spannendste fases in zo’n overstap. Wat je daarom vaak ziet gebeuren is dat één afdeling of business unit relatief klein begint met MACH. Als het succesvol blijkt wordt zo’n nieuwe architectuur daarna stapsgewijs, vertical per vertical, over de hele organisatie uitgerold. Ik geloof er ook in dat dat de beste route is om met zo’n architectuur aan de slag te gaan. Dat is namelijk ook echt het voordeel van zo’n componentenarchitectuur: het is enorm flexibel en je kunt heel klein beginnen.

Selectieproces vendors complex

We moeten vooral ook niet vergeten om stil te staan bij een andere, heel belangrijke, actuele uitdaging: vendor selectie’. Op dit moment zijn er nog geen platformen of communities die hier goed bij kunnen helpen. Cloud Native Computing Foundation (CNCF) of, als je een beetje tussen de marketingsaus door kunt kijken, Gartner en Forrester bieden wel houvast rond cloud infrastructuur en ‘klassieke grote vendors’, maar nog niet echt voor MACH-services. Eind juni werd er dus wel een eerste stap gezet met de lancering van de MACH Alliance.

Het gaat zeker helpen dat een industriegroep van technologiebedrijven een label heeft geplakt op de visie en architectuur met Microservices, API-first, Cloud Native SaaS en Headless. En dat zij die MACH-visie gaan uitdragen en verder laden. Maar daarmee zijn we er nog niet. ‘Bij technische keuzes heb je behoefte aan ‘stewardship’; een écht onafhankelijk, breed overzicht van alle MACH-services, de mogelijkheden en beperkingen dat je kunt raadplegen. Ook van services van bedrijven die niet bij de MACH Alliance zijn aangesloten.

De MACH Alliance zou daarbij kunnen helpen door aan te geven wat de positie is van services qua features en wat USP’s zijn. Maar ook door informatie over de volwassenheid van de services te delen; hoe lang bestaat een service al, hoeveel klanten werken ermee en wat is de mate van tevredenheid? Bijvoorbeeld: welke branches zijn succesvol met dit MACH-CMS of deze MACH-Searchtool? Op dit moment is het nog de vraag of de MACH Alliance een onafhankelijke adviesbaak wordt. Dat is namelijk iets waar bedrijven echt behoefte aan zullen hebben als ze concreet met MACH aan de slag willen.

Overstappen naar MACH: ja of nee?

Het antwoord op de vraag of je (snel) moet overstappen naar MACH is genuanceerd. Het is van behoorlijk veel factoren afhankelijk of het interessant is om met MACH aan de slag te gaan. Als je een ‘green field’ hebt en gaat starten met een nieuw landschap, al dan niet voor een nieuwe doelgroep of markt, zou ik adviseren om MACH altijd te overwegen. Vanwege de flexibiliteit en de schaalbaarheid is het natuurlijk interessant, omdat je alleen betaalt voor het gebruik van de services kan het ook kostenaantrekkelijk zijn. Heb je nu al een platform, bijvoorbeeld Magento, Hybris of Drupal en wil je een unieke beleving neerzetten of een complexe value chain goed in je platform laten samenkomen, dan is het natuurlijk weer een ander verhaal. Het is dan een goed idee een business case te onderzoeken over de middellange termijn, drie jaar is meestal een goed uitgangspunt, voor re-platforming versus upgradekosten. Daaraan voorafgaand is het dan wel weer belangrijk om de business- en digitale strategie helder in kaart te brengen. Op basis daarvan kun je namelijk pas goed bepalen welke services in de nieuwe MACH-architectuur moeten zitten.

Genuanceerder

Ook de klassieke platform vendors zijn inmiddels naar MACH-services aan het bewegen. De vraag of je zou moeten overstappen wordt daarmee nog een stapje genuanceerder. Persoonlijk denk ik dat slechts enkele klassieke platformspelers zich voldoende kunnen heruitvinden. Dat gaat soms ook stap voor stap. Kijk maar naar ‘Drupal Headless’, de APIs van Magento 2 of een PIM als Informatica. Er zullen ook best wat platformspelers de boot gaan missen, omdat ze te lang comfortabel hun bestaande licentiemodellen in stelling blijven brengen en beperkt innoveren. Ze houden uiteraard wel klanten over, naar verwachting de klanten die zelf ook langzaam meebewegen, maar de grote golf van re-platforming onder druk van accelererende digitale transformatie lopen deze spelers echt mis.

Over de auteur: Friso Geerlings is CTO bij ISAAC.