Platform engineering: stap als organisatie niet in deze valkuilen

Standaardiseren kan alleen door goed te luisteren

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 ziet dit probleem terug in zijn dagelijkse praktijk: “Ieder team heeft een bepaalde werkwijze. 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.”

De adoptie van platform engineering: wie is verantwoordelijk?

Jitse 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 procent bij het platformteam. Het is hun missie om de rest van de organisatie te overtuigen van de waarde van hun platform.”

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 veel voorkomende 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, die als CTO volledig op strategisch niveau werkt, 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.” 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.”