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
@Niels Leuk artikel. Maar vreemd dat de organistatorische kant onderbelicht is. Want dat is volgens mij juist de reden dat het fenomeen DevOps opgedoken is. Vanuit de inhoud weet je dat het handig is dat er een nauw contact is tussen ontwikkeling en beheer. Het bepaalt randvoorwaarden van het systeem. Maar juist die organisatorische barrieres zijn de oorzaken van een te moeizaam contact.
Onderdeel van een organisatorische verandering zou kunnen liggen op het gebied van de kpi’s van de afdelingen. Ik neem aan dat Niels dat met de sturingsmiddelen bedoelt, maar om het explicieter te maken: development wordt afgerekend op time-to-market terwijl operations op stabiliteit wordt afgerekend. Om DevOps echt op organisatieniveau aan te pakken denk ik dat beide afdelingen eerst op beide onderdelen beoordeeld moeten worden.
Overigens denk ik dat er altijd zoiets als technisch beheer nodig is, maar de vraag is een beetje tot welk niveau dit gaat: netwerk, hardware, webservers, applicatieservers, databases? Wat zit nog in een projectteam en wat is overstijgend? En wat te denken van geoutsourcede beheerafdelingen? Hmm
@Friso
Beheer wordt afgerekend op de continuiteit van een service, tenminste volgens de meeste SLA’s. Dat gaat natuurlijk het beste met een stabiele infrastructuur maar dat is uiteindelijk een technische vertaling. Het verhaal van Niels is een aardige uitleg van het PRINCIPE van DevOps maar nadruk ligt vooral ligt op deployment, snel door OTA-straat heen trekken, waardoor DepOps een betere naam is. Aangezien alleen de zin en niet de onzin benoemd wordt past titel minder bij het verhaal.
@friso Ik denk dat de taken op zich wel blijven bestaan van beheer maar je noemt het al, beide afdelingen. Tussen afdelingen worden vaak de muren opgetrokken. Om inderdaad over het outsourcen nog maar te zwijgen. Zeker voor ontwikkelwerk dwaas. Denk dat hoe informeler hoe beter, dat houd je systemen draaiend. Daar helpen al de SLA’s en andere formele afspraken niets aan, integendeel.
@Ewout Dat is waar, bij DevOps ligt inmiddels de nadruk op snel snel door de OTA heen trekken het liefst met een druk op de knop deployen. Waarbij als het even tegenzit de productowner (brrrr) aan de touwtjes trekt. Ik denk altijd, iedere release, wijziging is een risico. In sommige situatie kan het, in andere weer niet. Bij bedrijfskritische systemen niet waar een verstoring niet te verkopen is.
@Ewoud, je hebt gelijk: beheerafdeling wordt afgerekend op continuiteit. Maar het punt is dat dit wringt met de flexibiliteit en snelle time-to-market waar juist development op wordt afgerekend. Dat is een organisatorisch puntje (en misschien ook wel een psychologisch puntje).
@Louis, de muren worden doorgaans getrokken door beheerafdelingen, en met rede (namelijk dat ze worden afgerekend op continuiteit).
Zoals Ewout ook aangeeft, richt het artikel, en eigenlijk DevOps in zijn algemeenheid, zich op de wens *vanuit development* om die muur te breken. De focus komt dan inderdaad op zsm iets door de otap straat ‘heen trekken’, terwijl traditionele beheeraspecten onderbelicht blijven.
Ik kan me voorstellen waarom iemand een beetje predikt voor eigen parochie. Daar vind ik niet zoveel mis mee. Ik krijg toch een beetje ‘hikken’ als het gaat om het vergelijken met….
Wanneer ik, even in eigen beleving en ervaring, nog steeds de hiaten vanuit IT professie bezie en ervaar in FO/TO fase, wanneer ik nog steeds zie welke uren men schaamteloos durft te schrijven zonder zich te committeren aan een opleverdatum of aan ‘resultaat’, dan kun je bedenken wat je wilt maar dan heb je gewoon andere problemen die je ook met een DevOps niet te lijf zult gaan.
Het is namelijk zo dat je erg goed in je eigen discipline kunt zijn, maar gewoon geen oog/ervaring hebt in de gehele keten. Je kunt een uitmuntend tester zijn maar geen enkele klant gerichte affiniteit hebben. (Lees hier even dat Centric autisten wil gaan laten testen… proofs a point..)
Je kunt roepen Release of Change management maar geen enkel idee hebben hoe die basaal moet zijn ingericht en tenslotten heb je hele leuk babbelende verkopers, die noem ik voor het gemak maar even die professionals werkend in IT maar geen affiniteit hebbend met… and again, it proofs my point.
In de hausse van de vele nieuw bedachte richtingen en draaien omdat IT zo’n beetje op zijn gat ligt, weet ik één ding. De incidenten met steeds grotere impact nemen sinds 2011/2012 navenant toe. Niet voor niets dat ik met regelmaat eenvoudig concludeer dat je wellicht een ‘crack’ kunt zijn in je discipline maar verder geen enkele aansluiting/oog met de rest van de wereld.
Kleine tip; Leer eens kijken naar de wetmatigheden waaraan ook IT is onderworpen en hoe je daar mee om kunt gaan. Kijk naar de effecten die dat heeft op de professional en begrijp meer als professional en ook hoe en waarom je je horizon als IT professional moet open houden.
je kunt een DevOps team formeren maar als die weinig tot geen intermenselijke affiniteit hebben heb je aan het hele DevOps concept, net als al die andere nieuwbakken concepten, weinig tot niets. Hoe goed je het ook roeptoeterd.
@Friso
Even voor de duidelijkheid, continuiteit van de dienstverlening is iets anders dan continu levering van software wat een bezigheidstherapie is voor ontwikkelaars. DevOps is vooral een poging om tekortkoming van Agile methodiek op te lossen rond beheerbaar houden van alle wijzigingen in een gedistribueerde puinhoop.
“De wijze waarop it-diensten moeten worden geleverd is zeer moeilijk te handhaven in de huidige situatie.”
Dat werd ook geroepen in 2002 toen de nog bij Microsoft werkende Brian Valentine beloofde van Windows het best beheerde platform te maken met de introductie van de Dynamic System Initiative (DSI) visie. Aan de basis stond het System Definition Model dat met multidisciplinaire modellering voor autonomic computing moest zorgen en ons de volgende dingen beloofde:
1. Self-configuration, geautomatiseerde configuratie van componenten.
2. Self-healing, geautomatiseerde detectie en herkening van fouten.
3. Self-optimizing, geautomatiseerde schaling naar bezetting.
4. Self-protection, geautomatiseerde en actieve reactie op aanvallen.
Dat gebruikers flexibiliteit, snelheid en hele ERP systeem op hun tablet willen blijft knellen met stabiliteit en de continuiteit. Sommige diensten hebben namelijk zoveel draaiende schijven met één gat dat het onmogelijk is om daar constant wijzigingen aan te doen. Release management is een uitdagend proces geworden, net als trouwens configuratie management.
“De noodzaak om een incident door drie bekvechtende afdelingen heen en weer te laten ping-pong-en is verleden tijd.”
Ben benieuwd of hier nu een incident of probleem bedoeld wordt, vaak worden incidenten namelijk wel snel opgelost maar zijn het de problemen die heen en weer gaan omdat het vinden van de oorzaak zo moeilijk is door alle constante veranderingen. Nu lost het continous delivery principe dat probleem lekker makkelijk op, er zijn geen verstoring meer maar alleen maar onderhoudsmeldingen.
Next-next-finish…..
@Niels: interessant artikel, ik denk een waar veel organisaties verder mee kunnen. Wel ben ik benieuwd naar waar je exact op doelt als je het hebt over ‘de manier waarop de manager aanstuurt in relatie tot de volwassenheid van het team’ en ‘Ook blijken de sturingsmiddelen en -vaardigheden van managers een essentieel deel van de organisatie van een DevOps team’.
Zou je daar over uit willen wijden?
@Gast
Wat ik bedoel met de sturing in relatie tot de volwassenheid van het team, is dat de manager een team dat net bij elkaar gekomen is anders moet benaderen dan een die al een tijd bij elkaar is. De nadruk ligt anders in het begin moet er veel aandacht besteed worden aan het ontwikkelen van onderling begrip. Voor de realisatie van het team werd er vaak over en weer gewezen, nu moet er worden samengewerkt. Als het team wat langer bij elkaar is, kan de manager zich richten op het zelf-organiserend vermogen van het team.
Enerzijds gaat het dus om de stijl van de manager, anderszijds gaat het om de kennis en toepassing van sturingsmiddelen zoals visual management, het gepast gebruik van KPI’s en het op de juiste wijze geven van feedback die tevens het succes van een DevOps team bepalen. De complicatie is natuurlijk dat de mensen in het team vanuit diverse ‘bloedgroepen’ komen waardoor de manager extra aandacht moet besteden aan bijvoorbeeld gemeenschappelijke taal en definities.
Ik hoop dat ik hiermee je vragen heb beantwoord