Bart Delleman en Jitse Klomp (Conclusion) over de valkuilen van platform engineering
Hoe standaardiseer je een intern ontwikkelplatform binnen een organisatie waar elk team zijn eigen tools en werkwijzen heeft? Hoe zorg je ervoor dat je als platformteam niet vervreemdt van de ontwikkelteams die je juist zou moeten ondersteunen? Een gesprek met Bart Delleman en Jitse Klomp van Conclusion over over de valkuilen van platform engineering.
Platform engineering draait in de kern om standaardisatie. Door herbruikbare bouwblokken aan te bieden, wordt softwareontwikkeling sneller en veiliger. Maar die standaardisatie botst vaak met de bestaande werkwijzen van ontwikkelteams. Bart Delleman, Platform Engineer bij Conclusion Integration, ziet dit probleem terug in zijn dagelijkse praktijk.
“Ieder team heeft een bepaalde werkwijze”, schetst hij. “Binnen een organisatie zijn er bijvoorbeeld alleen al gemiddeld twaalf verschillende observability-stacks. Met CI/CD en deployments is dat niet anders. Het ene team gebruikt Helm Charts, het andere weer iets totaal anders. De teams hebben al een manier van werken en zullen die toch moeten aanpassen aan wat het platformteam neerzet. Dat kan een uitdaging vormen.”
Voor ontwikkelteams betekent dit een omschakeling: soms moeten ze hun vertrouwde tools en processen inruilen voor een gestandaardiseerd platform. En dat kan stuiten op weerstand. Maar werkt dat ook andersom? Moet het platformteam zich net zo goed aanpassen aan de ontwikkelteams?
Volgens Bart wel: “Dat is heel belangrijk. Je begint vaak met een MVP en het is cruciaal om constant feedback op te halen en je platform te verbeteren. Je moet een bepaalde mate van standaardisatie neerzetten, maar als je niet goed luistert naar de ontwikkelteams, zullen ze het platform simpelweg niet gebruiken. Dat zou mijn werk als Platform Engineer waardeloos maken.”
Wie is verantwoordelijk?
Jitse Klomp, CTO van Conclusion Xforce, vindt dat de verantwoordelijkheid voor het omarmen van een platform door de ontwikkelteams primair bij het platformteam ligt: “Zij moeten ervoor zorgen dat hun platform écht werkt. Dat de ontwikkelteams vertrouwen hebben in de bouwstenen die ze aangereikt krijgen. De adoptie van platform engineering ligt wat mij betreft voor 90% bij het platformteam. Het is hun missie om de rest van de organisatie te overtuigen van de waarde van hun platform.”
“Als het niet aansluit op de behoeften van je developers, gaan ze het niet gebruiken.”
Bart is het hiermee eens: “Het stakeholderveld is heel groot. Je hebt de ontwikkelteams, maar ook het managementteam dat moet investeren. Platform engineering leidt niet direct tot omzetvergroting. Het kost tijd voordat de waarde zichtbaar wordt.”
Toch benadrukt ook hij dat een platformteam kan zorgen voor een vliegwieleffect: “Als je als platformteam in je eerste twee versies een fantastisch product neerzet – bijvoorbeeld een omgeving die je met één druk op de knop kunt ‘opspinnen’ in plaats van dat je er twee weken op moet wachten – dan denken ontwikkelteams: zo, dit moeten we gebruiken! Je moet zorgen voor succeservaringen.”
Meer dan alleen techniek
Een andere veelvoorkomende valkuil is dat platform engineering puur als een technisch project wordt gezien. Maar wie zich alleen op de techniek richt, loopt vast.
Bart merkt dit ook in zijn werk: “Als engineer was ik vooral bezig met het bouwen, maar als Technical Lead doe ik inmiddels ook veel stakeholdermanagement. Zo leerde ik het belang van continu schakelen tussen de techniek en de behoeften van de organisatie.”
Jitse herkent dit maar al te goed: “Als je alleen focust op de techniek, dan ben je de klassieke ‘infrastructuurboer’, dat schiet niet op. Je moet ook bezig zijn met verandermanagement, adoptie en de bredere businessdoelen.”
‘Fake’ platform engineering
Platform engineering wordt nog weleens ingezet als lekker bekkend modewoord, zien Jitse en Bart.
“Veel initiatieven zijn in de praktijk niet meer dan het beestje een andere naam geven”, zegt Jitse. “Infrastructuurteams noemen zichzelf ineens platformteams, maar blijven precies hetzelfde doen: infrastructuur opleveren zonder na te denken over security en (her)bruikbaarheid. Een gemiste kans, want een écht platformteam neemt verantwoordelijkheid voor het volledige ontwikkelproces en biedt een geïntegreerde oplossing die ontwikkelaars daadwerkelijk helpt.”
“Omarm platform engineering zoals het bedoeld is, zet het niet in als een modeverschijnsel.”
Bart beaamt dit met een treffend voorbeeld: “Je kunt als infrastructuurteam een Kubernetes-cluster uitrollen, maar als het niet aansluit op de behoeften van je developers, gaan ze het niet gebruiken. Dan heb je iets gebouwd dat technisch misschien perfect is, maar totaal niet functioneel.”
Vind de delicate balans
Met platform engineering kunnen organisaties een hoop bereiken, maar het brengt ook grote uitdagingen met zich mee. Jitse en Bart adviseren CIO’s om vier aandachtspunten in acht te houden:
1: Ontwikkelteams moeten zich aanpassen aan het platform, maar doen dat alleen als het platform daadwerkelijk waarde toevoegt.
2: Het platformteam moet actief luisteren naar feedback, zodat het iteratief een platform bouwt dat aansluit bij de behoeften van de gebruikers.
3: De adoptie van een platform is geen vanzelfsprekendheid – het platformteam moet bewijzen dat hun oplossing de beste keuze is.
4: Platform engineering is méér dan technologie, het vereist stakeholdermanagement, verandermanagement en continue optimalisatie.
“Omarm platform engineering zoals het bedoeld is, zet het niet in als een modeverschijnsel,” besluit Jitse. “En zorg voor zoveel mogelijk succeservaringen bij de ontwikkelteams en eindgebruikers.”
