Is jouw organisatie klaar voor MACH? 7 vragen en antwoorden

Wanneer duidelijk is dat je met MACH aan de slag wil gaan, of dat op z’n minst wil onderzoeken, zou iedere organisatie zichzelf een aantal vragen moeten stellen. MACH is nu eenmaal qua organisatiebehoefte echt heel anders dan een klassiek (on-premise of IaaS) platform. In navolging van de eerste blog ‘Hoe waardevol is MACH voor jouw organisatie? vertelt iO Technology Director Friso Geerlings nu op welke zeven punten je jouw organisatie klaar moet maken om met een MACH-architectuur aan de slag te gaan.

Tech in conversation while working on Mac

#1 Heb ik een (enigszins) Agile organisatie?

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.’

#2 Hebben mijn front-end developers ook kennis van software development en techniek?

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.’

#3 Kunnen wij de integratie uitdaging aan?

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.’

Ben jij online overal?

De tijd dat een website voldeed voor een goede digitale aanwezigheid ligt achter ons. Onze experts helpen je liever aan een volwaardig digitaal ecosysteem - geoptimaliseerd en on-brand – om écht je doelen mee na te jagen.

Laptop shopping data overview

#4 Hoe zorg ik ervoor dat security en inloggen goed zijn ingericht?

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.

#5 Hoe zorg ik voor een goede MACH test-set?

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.

#6 Hoe kan ik een overzicht over alle kosten behouden?

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.

#7 Hoe beheer ik zowel het business als technische aspect van een MACH-architectuur?

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.’

Lees het volledige verhaal over MACH in deze whitepaper

De 7 antwoorden in het kort

De afkorting MACH betekent voluit: Microservices-based, API-first, Cloud-native, and Headless.

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.’

Friso Geerlings
Over de auteur
Friso Geerlings
CTO

Bij iO besteedt Friso zijn dagen aan de meest complexe tech uitdagingen voor diverse high-profile (financiële diensten) klanten. Deze combineert hij met ondersteunen van iO's tech teams en het bouwen aan verbindingen tussen developers, gebruikers en systemen. Hij kruipt regelmatig in de pen om met diepgaande, informatieve artikels deze banden verder aan te halen.

Blijf op de hoogte. Schrijf je in op onze nieuwsbrief

  • Laat je inspireren: onze strategen, technologen en creatievelingen delen hun kennis en inzichten.

  • Blijf up-to-date: ontvang relevante content over merkstrategie, bedrijfstransformatie, digitale ecosystemen of data-intelligentie.

  • Mis niks: ontdek onze nieuwe cases en blijf op de hoogte van onze laatste ontwikkelingen.