De zin en onzin van DevOps ontrafeld

De laatste jaren hebben we een hausse aan hypetermen langs zien komen: Agile, Scrum, big data, byod, Lean IT. Een van de meest enigmatische termen is DevOps; het wordt in ieder geval overal gebruikt, zonder dat het duidelijk is wat men ermee bedoeld. In dit artikel wil ik de zin en onzin van DevOps ontrafelen en de voordelen identificeren.

De term DevOps is ontstaan in België aan het einde van de laatste decennium, als gevolg van de zogenaamde ‘DevOps-days’. Deze dagen waren bedoeld om it-experts van zowel de ontwikkelkant (‘development’) als de beheerkant (‘operations’) van de organisatie bij elkaar te brengen. En eigenlijk is daarmee de term DevOps in zijn context geplaatst: een multidisciplinair team dat volledig verantwoordelijk is voor het beheer en continue ontwikkeling van een dienst. Voorbeelden waar DevOps in combinatie met continuous delivery wordt gebruikt, zijn bedrijven als Amazon en Google die dagelijks tientallen wijzigingen releasen.

DevOps de oplossing

De wijze waarop it-diensten moeten worden geleverd is zeer moeilijk te handhaven in de huidige situatie. Door onze – overwegend – silo-gedreven manier van organiseren zijn de processen onnodig complex geworden, de wijze van prestatiemeting onoverzichtelijk, houding en gedrag van mensen intern gericht en tooling te sterk gericht op de individuele technologie. Terwijl een keten van technologieën noodzakelijk is voor een complete ict-dienst.

Daarnaast zien we dat klanten in toenemende mate snelle levering van nieuwe functionaliteit willen. Snelle oplossing van incidenten, korte communicatielijnen en uitstekende kwaliteit eisen van hun it organisatie. Met de huidige organisatie, processen en werkwijzen, én houding en gedrag, worden de vereiste prestaties en resultaten niet of onvoldoende gerealiseerd. Het gezegde van Einstein, ‘De definitie van waanzin is hetzelfde doen en een andere uitkomst verwachten’, lijkt in toenemende mate van toepassing op de werkwijzen binnen it. Het is tijd om fundamenteel de opzet van it-organisaties te heroverwegen.

De elementen van DevOps

DevOps wordt tot nu toe door diverse experts – in grote lijnen – op een drietal manieren benaderd: tooling, cultuur en processen. Uit onze ervaring blijken er invalshoeken te ontbreken. Wij voegen hier performance (die in sommige gevallen als onderdeel van processen wordt meegenomen) en organisatie aan toe.

Houding & Gedrag: Er is een significante groep DevOps onderzoekers die hun heil vooral zoekt in het realiseren van een gemeenschappelijke cultuur onder ontwikkelaars en operatie-mensen. Het gaat hierbij om begrip kweken voor elkaar en zorgen dat er meer samenwerking komt tussen de twee ‘kampen’. Qua onderwerp is dit – zeker voor it – een redelijk onverwachte invalshoek. Ook de manier waarop de manager aanstuurt in relatie tot de volwassenheid van het team is een bepalende factor voor het succes van een DevOps team.

Performance: DevOps belooft veel in de vorm van meer en snellere releases. Er is daarom ook een sterke stroming binnen de wereld van DevOps die gericht is op het meetbaar maken van de prestaties van it. Ook hier een ‘end-to-end’ kijk op de levering aan klanten van it. Hierbij horen weinig maar wel goed gekozen kpi’s. Een ander aspect van performance is gebruik van tijd; hoe wordt tijd besteed binnen het team?

Organisatie: Een van de minst besproken oplossingen is de organisatorische invalshoek. Hierbij wordt gekeken naar hoe de organisatie van it aangepast kan worden om ‘Dev’ en ‘Ops’ dichter bij elkaar te brengen. Vaak blijft men denken en praten in termen van het verbeteren van de communciatie tussen Dev en Ops, in plaats van anders te organiseren. Ook blijken de sturingsmiddelen en -vaardigheden van managers een essentieel deel van de organisatie van een DevOps team.

Processen: Dit is een terrein die voor veel it-mensen zeer bekend is. Veel DevOps-denkers zien het integraal kijken naar ‘development-to-production’-processen als dé oplossing voor de problemen van it. Veelal worden hierbij Agile/Scrum en andere methodes aangehaald. Het integreren van ITIL processen en ontwikkelprocessen lijkt daarbij een doel te zijn. We moeten juist zorgen voor simpele en duidelijke afspraken in plaats van grote proceshandleidingen. Binnen processen blijkt dat het strak monitoren en sturen van openstaande werkeenheden de kern tot succes is.

Tooling: Als laatste is dit de natuurlijke reflex binnen de wereld van it: pas technologie toe om een probleem op te lossen. In dit geval is de natuurlijke reflex van it’ers gerechtvaardigd. Vooral als dit betekent dat er vaker en met een hogere betrouwbaarheid changes naar productie gebracht worden. Met geïntegreerde tooling die de flow van werkeenheden door een otap-straat strak begeleidt, kan de releasefrequentie opgevoerd worden tot een niveau die nooit op een handmatige wijze kan worden gehaald.

Uiteraard polariseer ik de invalshoeken om duidelijk te maken wat de belangrijkste argumenten zijn. In de uitleg die bij elke invalshoek gegeven wordt, worden de tegenstellingen in veel gevallen ontkracht: natuurlijk horen processen en performance bij elkaar. Ook is het logisch dat organisatie en houding & gedrag iets met elkaar te maken hebben. We kunnen concluderen dat de vijf invalshoeken allemaal een rol spelen in het werkend krijgen van DevOps en het realiseren van de beoogde voordelen.

Starten echt bij de klant…

DevOps gaat uiteindelijk om een continue it-service voor een klant. De laatste jaren is duidelijk te zien dat it-organisaties zich meer richten op de behoeften van hun klanten. Informatie management was een start, het invoeren van Agile-achtige methodes een tweede stap. Maar deze methoden zijn deeloplossingen voor een fundamenteel probleem binnen it: het vasthouden aan een traditionele organisatievorm waarin we soort-bij-soort organiseren.

Om DevOps tot een succes te maken is een zeer grondige analyse en definitie van klanten en diensten een absolute vereiste. Op basis hiervan wordt de techniek, de ‘technology stack’, bepaald waarvoor het team verantwoordelijk is. Dit wordt vervolgens gebruikt om de kennis en vaardigheden te definiëren die nodig zijn om de dienst te ondersteunen.

We zien ook dat DevOps integraal gekoppeld wordt aan Agile/Scrum. Het is zeker zo dat deze methodes een aantal nuttige inzichten brengen aan een DevOps-team, met name time-boxing en het gebruik van een product backlog. Maar deze methoden zijn geen noodzakelijke randvoorwaarden voor een DevOps-team. Wel is standaardisatie op één methode zinvol, los van welke methode dat is. DevOps is dus gebaat bij heldere en simpele definities. In ieder geval: klant, dienst, Definition of Done en werkeenheden.

Voordelen van DevOps teams

De échte kracht van DevOps ontstaat vanuit de psychologische effecten van het realiseren van een team dat zowel de mogelijkheden als de bevoegdheden heeft om de klant integraal van dienst te zijn.

We zien dat de regels van een team daadwerkelijk van toepassing zijn, waaronder het hebben van een gemeenschappelijk doel, te behalen door mensen met complementaire vaardigheden, die elkaar verantwoordelijk houden voor het realiseren van het doel. Hiermee ontstaat een kans om te werken naar een ‘high-performing’-team dat veel waarde toevoegt aan het bedrijfsproces. Het is belangrijk hierbij te onderstrepen dat de groepen die wij traditioneel ‘teams’ noemen, bijvoorbeeld het database-team, geen teams zijn in de formele zin van het woord, met name vanwege het ontbreken van complementaire vaardigheden.

Vanuit een perspectief van tijdsverspilling zien we dat de tijd die wordt besteed aan coördinatie drastisch vermindert door simpele processen. Het gros van de werkeenheden wordt binnen een team afgehandeld. De noodzaak om een incident door drie bekvechtende afdelingen heen en weer te laten ping-pong-en is verleden tijd: het DevOps team heeft alle kennis die nodig is om de dienst in de lucht te houden.

Een ander voordeel van DevOps is inzicht in kosten. Doordat alle kosten gerelateerd zijn aan het team, is het veel eenvoudiger om de cost of ownership voor het ondersteunen van een klantgroep te bepalen. Het gaat tenslotte om de salariskosten van de mensen in het team en de kosten van de ‘technology stack’. We weten dat de personeelskosten uren vertegenwoordigen, waarmee we veel eenvoudiger de waarde van het team kunnen bepalen door deze te koppelen aan de business waarde van de dienstverlening.

Alles bij elkaar genomen is DevOps een zeer wenselijke ontwikkeling met het potentieel om de wereld van it drastisch te veranderen. En de belofte naar klanten om meer waarde toe te voegen aan het bedrijfsproces in te lossen. Om dit potentieel te oogsten moeten it-managers bereid zijn om door hun huidige organisatievormen heen te kijken en de organisatie in te richten om waarde te leveren, met de daarbij behorende tooling, houding en gedrag, processen en prestaties.

Niels Loader, principal consultant Quint Welligton Redwood