September 10, 2024

In relatief korte tijd is agile werken de norm geworden in IT-land. Daarbij lijkt het alsof DevOps de heilige graal is. Organisaties gaan massaal in transitie naar DevOps. Het doel dat men daarin voor ogen heeft is sneller en beter software opleveren. Het middel daarvoor zijn autonome teams die end-to-end verantwoordelijk zijn voor hun deel van de systemen. Klinkt goed? Zeker! Maar uiteraard zijn er wat kanttekeningen te plaatsen.

Woord: DevOeps grafisch weergegeven

Functioneel Beheer en DevOps

Deze transitie is moeilijk los te zien van het Functioneel Beheer van de systemen. De gedachte is vaak dat ook het beheer onder de verantwoordelijkheid van de DevOps-teams zal komen te vallen. Betekent dat het einde van Functioneel beheer zoals wij dat kennen?

In organisaties met weinig automatisering (lees: weinig teams) denk ik dat dat prima kan werken. Maar laten we eerlijk zijn, in die organisaties werkt iedereen van nature al heel nauw samen. Zodra de omvang van de automatisering toeneemt, en daarmee het aantal teams, neemt ook de complexiteit van dit vraagstuk toe.

Spotify Engineering Culture

Spotify, het schoolvoorbeeld van Agile werken (ik weet het, dat is geen DevOps), heeft op YouTube een goede uitleg van hun werkwijze geplaatst. (Spotify Engineering Culture:

Deel 1:

Watch Spotify Engineering Culture (by Henrik Kniberg) on YouTube.

Deel 2: 

In deel 2 gaat het vanaf minuut 9:38 over groeipijnen. Spotify geeft hier aan dat ze constant moeten zoeken naar de balans tussen chaos en bureaucratie. En dat voor een organisatie die vanaf het begin op deze manier werkt. Zij hebben een architectuur die 100% is ingericht op hun werkwijze. Ook doen ze er alles aan om grote projecten te vermijden. Iets wat lastiger wordt als er meer legacy architectuur is.

Watch Spotify Engineering Culture   part 2 on YouTube.

Autonome teams

Maar terug naar Functioneel Beheer. Naarmate de teams meer autonoom worden, neemt dus de verantwoordelijkheid toe. Met deze toename zullen er ook meer taken bij de teams terecht komen. Bij de transitie is het dus zaak heel goed te kijken welke taken Functioneel Beheer nu uitvoert en welke daarvan bij de teams kunnen worden belegd.

Naar mijn mening zijn er twee belangrijke aandachtsgebieden waarvan de taken lastig bij de teams kunnen worden belegd.

  • De eerste is de aansluiting op de buitenwereld. Als een klant zich meldt met een probleem (incident), is er vaak een eerste analyse nodig om te bepalen welk team dit op kan pakken. Een gemiddelde helpdesk is hier simpelweg niet voor uitgerust.
  • Ten tweede is het in een grote organisatie zaak om overzicht te houden van wat er allemaal gebeurt aan wijzigingen en opleveringen. En dan vooral de samenhang hiertussen en de gevolgen daarvan. In de praktijk is Functioneel Beheer daar vaak heel goed toe in staat gebleken.

Overzicht houden

Kortom, ik zie zeker een verplaatsing van beheertaken naar de autonome teams. Maar de rol van Functioneel Beheerder zie ik nog niet zo snel helemaal verdwijnen. Een kern van beheerders die overzicht houden blijft volgens mij noodzakelijk. Het simpelweg opheffen van Functioneel Beheer omdat er DevOps gewerkt gaat worden zal wat mij betreft leiden tot een onvermijdelijke ‘DevOeps’.

Aan de slag met DevOps en Functioneel Beheer? 

Benieuwd naar hoe je DevOps en Functioneel Beheer goed kunt toepassen in jouw organisatie? Neem dan contact met ons op. 

Harm
Harm Pul