Is jouw organisatie klaar voor MACH? 7 vragen en antwoorden

Kenmerkend voor de MACH-architectuur zijn openheid en interoperabiliteit, geen monolieten maar applicaties die zijn opgebouwd in beheersbare componenten. Services vervangen, verbeteren, verwijderen en nieuwe releases gaan relatief eenvoudig, zonder dat alles op de schop moet. De ‘composable’ MACH-architectuur biedt veel flexibiliteit en de mogelijkheid tot een veel hogere verandersnelheid. Het Agile-gedachtegoed sluit daar het beste op aan.

‘Beginnen met MACH hoeft op zich niet te betekenen dat het hele bedrijf op voorhand Agile is ingericht, maar wel op z’n minst de afdeling of business unit waar je met MACH gaat beginnen. Het begint met het aanwijzen van een goede, liefst ervaren Product Owner. Idealiter iemand die vanuit de business de belangen en krachten van individuen en teams bundelt. En in het geval van MACH ook goed begrijpt wat er technisch nodig is. Rond de Product Owner vorm je een zelforganiserend team dat met name in staat is om de technische release pipeline optimaal te beheersen’, vertelt Geerlings.

Geerlings vervolgt: ‘Beheersen van het technische release pipeline is zo belangrijk, omdat je vanaf het begin wil profiteren van de hoge verandersnelheid. De eerste teamdoelen zijn daarom het releaseproces en Continuous Deployment (CD) onder controle hebben. Wanneer dat nog niet helemaal lekker loopt, dan is het een goed idee nog vaker te releasen. ‘If it hurts, do it more often’, is niet voor niets een bekende uitspraak rond release processen en CD. Agile is een randvoorwaarde om dit proces goed ingericht te krijgen.’

Een andere reden waarom het belangrijk is om Agile te organiseren, zijn de dynamische, cyclische processen. Geerlings: ‘Bij het opzetten van MACH, gaat het continu over de verhouding tussen services kiezen en het ontwerp van de complete architectuur. Dat hebben wij bij iO ook duidelijk gemerkt in een project waarin we een MACH-architectuur ontworpen. Zo kozen we in eerste instantie voor Contentful als headless CMS. Gedurende het proces kwamen we erachter dat we beter Storyblok konden inzetten. Het bleek namelijk dat Storyblok betere preview mogelijkheden heeft, wat één van de requirements was. Zo’n voorbeeld benadrukt ook echt het belang van het voorbereidingsproces.’

MACH services bieden APIs aan die worden ontsloten in een front-end. Dat is de headless component van de architectuur. Geerlings: ‘De front-ender met een vormgevings- of multimediadesign-achtergrond zal daar niet zo goed mee uit de voeten kunnen. Dat is een belangrijk verschil met een klassiek platform waar het werk zich meer toespitst op visualisatie. Voor een front-end developer die met MACH-services aan de slag gaat, is het veel belangrijker om technische basisvaardigheden en software development kwaliteiten te bezitten. De front-end(s) worden boven op een set van MACH-services gebouwd en verbonden via APIs. Kennis van frameworks als Vue, React en brede ervaring met JavaScript zijn dan noodzakelijk.’

Geerlings vervolgt: ‘Besef dat een MACH-landschap geheel naar eigen inzicht is samen te stellen. De front-ends kunnen uniek zijn en integratie is maatwerk. Het is een ecosysteem dat je optuigt vanuit een eigen, unieke businessbehoefte. En aangezien het succes van producten en diensten staat met eindgebruikers, zijn UX en User Testing daarom nog belangrijker dan anders. Je wil namelijk wel slagen met een unieke beleving én optimale conversie. Tijdig concepten en prototypen toetsen onder eindgebruikers en hun inzichten gebruiken om de ontwerpen weer te verbeteren, is het devies.’

MACH brengt meer technische uitdagingen dan een klassiek platform, omdat je het totale landschap moet overzien, er meer integratiewerk bij komt en kijken en het vraagt om meer eigen keuzes. De ontwikkeling van technische kennis is voor bedrijven verreweg de grootste uitdaging om de overstap naar een MACH-architectuur te kunnen maken. Maar waar hebben we het dan precies over?

‘Afhankelijk van de omvang van het landschap, groeit de complexiteit. Wanneer het MACH-landschap nog klein is en bestaat uit twee tot drie services, dan zijn services in eerste instantie nog wel point-to-point te koppelen. Zodra het landschap groter wordt, ontstaat vaak al gauw de behoefte om een integratie- en ontsluitingslaag, zoals een API Gateway, te introduceren. Deze laag wordt ingezet om dataoverdracht en (API) logica te regelen. Iets dat helemaal van belang wordt wanneer ook externe services van partners aan jouw MACH-landschap worden gekoppeld’, zegt Geerlings.

Geerlings vervolgt: ‘Dat vraagt kennis van gangbare technieken zoals REST, APIs, JSON, JWT en OpenID Connect, maar bij wat meer ingewikkelde set-ups misschien ook kennis van message queueing, AWS of Azure Serverless, Webhooks en GraphQL. Ook de API Gateway is een voorbeeld. Uitdenken en ontwikkelen van een API strategy, inclusief API design, API versioning en bijbehorende developer experience, zijn typische integratieskills die bij een groot MACH-landschap belangrijk zijn om aan boord te hebben. MACH-services zijn nou eenmaal niet zo plug & play: ze zijn bedoeld om door developers gebruikt te worden. Er zit meer ontwikkelwerk aan en wat minder configuratie zoals bij een klassiek platform, waar development teams trouwens vaak wel enthousiast van worden.’

‘Bedrijven die met een complex project als dit aan de slag gaan, sluiten vaak digitale partners aan, zoals iO, om kennis naar binnen te halen. Daarmee geven ze het project een goede kickstart. Ook is het met een digitale partner makkelijker om te beschikken over kennis van complexe, specialistische aspecten en die te laten ontwikkelen en integreren. Als de basis eenmaal goed staat, worden – na uitgebreide kennisoverdracht – de partner resources vaak weer afgeschaald om zelf verder te gaan’, zegt Geerlings.

‘De belangrijkste uitdaging bij MACH is het integreren. Hoewel de services zelf, met hun krachtige en zorgvuldig voor jou ontworpen datamodellen en logica, goede functionaliteiten bieden, kun je met de integratie echt de mist in gaan. Voor die cruciale aspecten moet je gewoon de juiste kennis aan boord hebben, in-house of via een digitale partner.’

In tegenstelling tot een klassiek platform dat een geïntegreerde, centrale login heeft, moet je dat logischerwijs voor een MACH-architectuur zelf inrichten. Soms blijft een MACH-landschap beperkt tot één, twee of misschien drie gekoppelde services. Als dat zo is, zijn security en inloggen vaak afdoende geregeld binnen de afzonderlijke services. Dubbel inlog- en rechtenbeheerwerk is nog te overzien. Als het landschap groter wordt of gebruik gaat maken een integratielaag, wordt het een ander verhaal. Rollen, toegangsrechten en credentials zijn dan over verschillende microservices verspreid en security is ook niet zomaar end-to-end geregeld.

‘Daarmee begeef je je op het terrein van Identity en Access Management (I&AM) en Single Sign-On (SSO). Als het landschap groeit, is het een goed idee om I&AM en SSO uit de services te nemen en apart onder te brengen in een Identity en Access Management platform zoals AWS Cognito. Daarmee kun je zowel SSO als role based access control goed inrichten en de werking ervan aantonen. Zeker als MACH-services worden ingezet in een certified- of regulated markt landschap, bijvoorbeeld ISO 27001, PCI-DSS of in het zorgdomein, biedt deze set-up veel voordelen’, legt Geerlings uit.

De MACH-architectuur is heel testbaar en geschikt voor geautomatiseerde teststraten, die ook zo belangrijk zijn om vaak te kunnen releasen. Omdat MACH-services via APIs worden ontsloten, kun je per service aan de slag met testen. Het totale landschap is daardoor in veel mindere mate een black box dan op een klassiek platform.

‘Het is gebruikelijk om een aparte Quality Assurance (QA) omgeving op te tuigen en daarin volop in te testen en te proberen. Je wil daarin in ieder geval een goede, geautomatiseerde test-set opzetten die vertrouwen geeft. De MACH-architectuur stelt je daartoe in staat. ‘Release often’ is een strategie die perfect bij MACH past, maar wel alleen als de test-set op orde is’, zegt Geerlings.

Ook het op orde hebben van test data provisioning is belangrijk, maar lang niet vanzelfsprekend: ‘De beschikbaarheid van goede, realistische testdata en die data goed in de (test) MACH-service krijgen, zijn vaak wel een ding. Geautomatiseerd kunnen inladen van testdata zou daarom een criteria moeten zijn bij de vendor-keuze. Wellicht zou je op termijn ook kunnen investeren in automatisch anonimiseren van data uit je productieomgeving voor testdoeleinden’, zegt Geerlings.

Iedere MACH-service wordt afgerekend via een maandelijkse fee. Geerlings: ‘Dat klinkt in eerste instantie heel overzichtelijk en misschien ook wel aantrekkelijk. Bij de implementatie van een klassiek platform betaal je flinke up-front licentiekosten. Met MACH-services heb je de vrijheid om ‘fit-for-use’ te kiezen.’

En toch plaatst Geerlings daar ook kanttekeningen bij: ‘Voordat je iets kiest, is het belangrijk om goed te begrijpen hoe het pricingmodel van een service in elkaar zit. Wanneer je de ambitie hebt om bijvoorbeeld te schalen naar grote aantallen ‘low value’ gebruikers, dan kunnen services met pricingmodellen die per eindgebruiker afrekenen ineens behoorlijk in de papieren gaan lopen. In zo’n geval wil je misschien liever betalen voor daadwerkelijk gebruik, bijvoorbeeld het aantal API calls of bundels van API calls. Daarbij, als het MACH-ecosysteem groeit, ontstaat ook de noodzaak voor SSO. En dan komt vaak de enterprise versie van de MACH-services om de hoek kijken om dat te ondersteunen: SSO zit typisch niet in de goedkope instap-tiers. En die enterprise versies zijn gewoon best prijzig.’

‘Een MACH-landschap is in veel gevallen niet goedkoper dan een klassiek platform. Uiteraard is klein beginnen een voordeel. Met enkele services of weinig gebruikers, waardoor de opstartkosten voor een overstap wel een stuk aantrekkelijker zijn dan bij een monolithisch platform. Het is dan ook aan te raden om de business case voor een MACH-landschap te bouwen rond andere aspecten dan alleen het vermeende kostenvoordeel. Onderzoek het vanuit invalshoeken als business agility, de mogelijkheid om een unieke beleving te creëren of complexe value chains beter onder te brengen. Op die punten biedt MACH echt toegevoegde waarde, als dat voor jouw business relevant is’, benadrukt Geerlings.

Geerlings: ‘Een MACH-architectuur wil je eigenlijk op twee manieren monitoren en daar twee cockpits voor inrichten: business operationeel en technische operationeel. Door je totale performance gedetailleerd inzichtelijk te maken, kun je eventuele problemen snel signaleren en lokaliseren. Denk hierbij bijvoorbeeld aan een combinatie van Application Performance Monitoring (APM), Analytics en BI. En uiteraard kies je ook hiervoor tools die helemaal MACH-ready zijn.’

Zoals nu wel blijkt, behelst een MACH-architectuur voeren veel meer dan puur het in gebruik nemen van een online SaaS-platform. Geerlings concludeert: ‘Veruit het belangrijkste is om ervaren integratie- en front-end specialisten aan boord te hebben, of als partner in de arm te nemen. De technische kant van MACH is behoorlijk complex, in ieder geval als het landschap een beetje omvang krijgt en de term ecosysteem verdient. Mijn advies: begin met een klein experiment en als je gaat opschalen naar meer dan twee of drie services, maak dan heel bewust je volgende keuzes. Dat klinkt voordehand liggend, maar is niet per se eenvoudig. Hoewel MACH je per component eenvoudig keuzes laat heroverwegen, is het uiteindelijk moeilijker om het ‘cement’ van het landschap te vervangen. Test tijdig, monitor wijs, beveilig en integreer met expertise.’