De zin en onzin van DevOps

De zin en onzin van DevOps
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 wellicht DevOps; dit begrip wordt steeds vaker gebruikt, zonder dat het duidelijk is wat men ermee bedoelt.
In dit artikel worden zin en onzin van DevOps ontrafeld en worden de voordelen geïdentificeerd.
Niels Loader
De term DevOps is ontstaan in België aan het einde van het laatste decennium, als gevolg van de zogenaamde ‘DevOps-days’. Deze dagen waren bedoeld om IT-experts van zowel de ontwikkel-(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 continue beheer en 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.
Interessant is de definitie van DevOps zoals te vinden op Wikipedia: ‘ DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.’
De kernpunten zijn dat DevOps volgens deze definitie te maken heeft met het snel produceren van software. Hiermee wordt voorbijgegaan aan de echte waarde en bedoeling van DevOps. Wat is de werkelijke waarde van DevOps die gerealiseerd kan worden als de volle breedte en diepte van een DevOps-aanpak benut wordt?
Mismatch
De wijze waarop IT-diensten bij veel organisaties worden geleverd, is nauwelijks te handhaven omdat de huidige IT-processen niet ingericht zijn op de roep vanuit de business om snelle en flexibele IT.
Door onze – overwegend – silo-gedreven manier van organiseren zijn IT-processen onnodig complex, is de prestatiemeting onoverzichtelijk, zijn houding en gedrag van mensen intern gericht en is tooling te sterk gericht op de individuele technologie. Dat staat haaks op de wens vanuit de business waar men in toenemende mate snelle levering van nieuwe functionaliteit wil, snelle oplossing van incidenten, korte communicatielijnen en IT van hoge kwaliteit.
Er is dus een mismatch tussen de traditioneel ingerichte IT-organisatie en de business. Het is daarom tijd om de opzet van IT-organisaties fundamenteel te heroverwegen. Want niets doen
en hopen dat het op termijn beter zal gaan, komt dicht in de buurt van Einstein’s definitie van waanzin: ‘Hetzelfde doen en een andere uitkomst verwachten.’
Elementen van DevOps
DevOps wordt tot nu toe door diverse experts – in grote lijnen – vanuit drie invalshoeken benaderd: tooling, processen en cultuur.
Tooling
Dit is de natuurlijke reflex binnen de wereld van IT: pas technologie toe om een probleem op te lossen. Dit is op zich een prima benadering. Vooral als 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 (Ontwikkeling Test Acceptatie en Productie) strak begeleidt, kan de releasefrequentie opgevoerd worden tot een niveau dat met handmatige werken nooit kan worden gehaald. Tooling is dus onontbeerlijk voor DevOps.
Processen
Denken in processen hoort bij de IT. Veel DevOps-denkers zien ‘development-toproduction 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.
Cultuur
Er is een significante groep DevOps-onderzoekers die hun heil zoekt in het realiseren van een gemeenschappelijke cultuur. Het gaat hierbij om het kweken van begrip tussen ontwikkelaars en ‘operatie-mensen’ en zorgen dat er meer samenwerking komt tussen de twee ‘kampen’. Voor de IT-wereld is dit geen alledaagse invalshoek.
Combinatie
Hoewel voor elk van de bovengenoemde invalshoeken relevante argumentatie aangevoerd kan worden, blijken DevOps-mensen in de praktijk toch vaak één van deze benaderingen te prefereren. Dat is jammer, want de kracht van DevOps ligt juist in de combinatie van deze invalshoeken, aangevuld met twee additionele benaderingen. Wij voegen aan de bovengenoemde drie daarom nog ‘performance’ toe (wat in sommige gevallen als onderdeel van processen wordt meegenomen) en tevens ‘organisatie’.
Daarnaast is gebleken dat cultuur een moeilijk hanteerbaar begrip is. In plaats daarvan komen ‘houding en gedrag’ veel dichter in de buurt bij de aspecten die bij Devops van belang zijn. Hier een pleidooi om de vijf dimensies op basis van gelijkwaardigheid te benaderen en ze te gebruiken om de integratie tussen ‘Dev’ en ‘Ops’ vorm te geven.
Houding en gedrag
Het is belangrijk om te onderkennen dat, zeker in het begin van de integratie, de gedragingen van ontwikkelaars en operators verschillend zijn. Om
DevOps tot een succes te maken, is het gelijktrekken van houding en gedrag van groot belang. Uiteraard is over en weer begrip kweken daarbij een cruciaal element. Door te focussen op gedrag in plaats van cultuur, zorgen we dat de mensen in het DevOps-team bewust worden van hun eigen rol in het succes van het team. Ook de manier waarop de manager aanstuurt, in relatie tot de volwassenheid en mate van integratie 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. Daar kan men vraagtekens bij zetten. Weliswaar is er niets mis met een ‘end-to-end’kijk op de levering aan klanten van IT. Maar is het belangrijk om precies te weten hoeveel uren nodig zijn om een use-case te bouwen? Temeer omdat DevOps is ontwikkeld om aan de vraag van de klant te voldoen. Een ander aspect van performance is gebruik van tijd; hoe wordt tijd besteed binnen het team? Wat is de balans tussen innovatie en instandhouding? Het gevolg moet zijn dat er verbeteracties uitgevoerd worden om de balans ten faveure van innovatie te bewegen zonder op kwaliteit in te boeten.
Organisatie
Een van de minst besproken aspecten van DevOps is de organisatorische invalshoek. Dat draait om aanpassing van de IT-organisatie om ‘Dev’ en ‘Ops’ dichter bij elkaar te brengen. In de praktijk blijkt echter dat men primair werkt aan het verbeteren van de communicatie tussen ‘Dev’ en ‘Ops’, maar geen organisatorische veranderingen doorvoert. Daarnaast blijken het aansturingmodel en de vaardigheden van managers cruciaal te zijn voor het succes van een DevOps-team. Onder meer de ‘Lean-aanpak’ biedt een breed scala aan tools, waaronder Visual Management, om gericht te sturen en problemen aan te pakken. In de praktijk blijkt dat het managen van werkvoorraden inmiddels gangbaar is binnen de Dev-organisatie. Maar het managen van de werkzaamheden via kanban-borden (een visuele weergave van de werkstroom) is vaak nog onwennig voor de ‘Ops’-mensen. Ervaring leert echter dat gewenning betrekkelijk snel gaat. Het belangrijkste aspect van de organisatorische invalshoek is aandacht voor teamvorming. Mensen bij elkaar zetten werkt tot op zekere hoogte, maar om er meer uit te halen zal gericht aan teamvorming moeten worden gewerkt.
Processen
Zoals eerder gezegd, de processen binnen een IT-organisatie zijn meestal onoverzichtelijk voor de medewerkers. Dit komt omdat de procesgang een reeks afdelingen omvat die allemaal slechts voor een deel betrokken zijn. Hun rol binnen de totale keten is daardoor niet duidelijk. Binnen een DevOps-team waar met Visual Management gewerkt wordt, is het mogelijk om processen buiten de betrokken afdelingen om te optimaliseren. Dat leidt ertoe dat complexe proceshandleidingen plaatsmaken voor simpele en duidelijke afspraken. Binnen processen blijkt dat strak monitoren en sturen van openstaande werkeenheden de kern tot succes is.
Tooling
Om de snelheid en kwaliteit binnen een DevOps-team te garanderen, is een volledig geautomatiseerde OTAP-straat een absolute voorwaarde. Betekent dit dat een DevOps-team niet kan bestaan zonder deze tooling? Nee, ook het steeds verder automatiseren van de diverse stappen door de OTAP-straat is een groeiscenario. Er kunnen al veel voordelen gehaald worden bij groei in een of meer van de andere invalshoeken.
Bovengenoemde vijf invalshoeken spelen allemaal een rol bij een aanpak volgens de DevOps-werkwijze en het realiseren van de beoogde voordelen.
Echt starten bij de klant
DevOps gaat uiteindelijk om een permanente IT-service voor een klant. De laatste jaren is duidelijk te zien dat IT-organisaties zich meer richten op de behoeften van hun klanten. Informatiemanagement 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. Werken volgens DevOps doorbreekt de traditionele organisatiestructuur van een IT-afdeling, maar om het tot een succes te maken moet wel duidelijk zijn wie de klant is, en welke diensten die geleverd wil krijgen. Dat vergt een grondige analyse en definitie van zowel de klanten als de te leveren diensten. Het identificeren van de klant of van een klantgroep maakt het veel eenvoudiger om te bepalen van welke waarde geleverd moet worden. Op basis hiervan wordt de techniek, ofwel de ‘technology stack’, bepaald waarvoor het team verantwoordelijk is. Hoe ‘dieper’ de technology stack, hoe meer kennis en vaardigheden nodig zijn binnen het team. Daarbij maakt de opkomst van cloudtechnologie, met zijn diverse varianten IaaS, PaaS, SaaS, het wel makkelijker het team en de onderliggende technologie te ontkoppelen (figuur 1) .
Figuur 1. ‘Technology stack’ van een dienst
 
We zien in de praktijk regelmatig dat DevOps integraal gekoppeld wordt aan Agile/Scrum. Het is zeker zo dat deze methoden een aantal nuttige inzichten bieden aan een DevOps-team. Met name time-boxing en het gebruik van een product-backlog kan van pas komen. Maar deze methoden zijn geen noodzakelijke randvoorwaarden voor het functioneren van een DevOpsteam. DevOps is vooral gebaat bij heldere en simpele definities. In ieder geval moeten de volgende aspecten glashelder gedefinieerd worden voor een DevOps-team:
• wie is de klant?
• welke dienst wordt geleverd?
• wat zijn de werkeenheden die door het team verwerkt worden?
• wat is de ‘Definition of Done’ voor deze werkeenheden?
 
Teamspirit
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-performingteam’ dat veel waarde toevoegt aan het bedrijfsproces. Het is belangrijk hierbij te onderstrepen dat een DevOps-team iets anders is dan de groepen die wij traditioneel ‘teams’ noemen, bijvoorbeeld het Database-team. Dat is geen team in de formele zin van het woord, met name vanwege het ontbreken van complementaire vaardigheden.
vanuit het perspectief van tijdsbesparing kan worden vastgesteld dat het versimpelen van processen en afspraken veel minder coördinatie vergt omdat het gros van de werkeenheden binnen het team wordt afgehandeld. Dat bespaart enorm veel tijd ten opzichte van de situatie waar een incident tussen drie afdelingen heen en weer pingpongt, waarbij ieder z’n eigen belang voorop stelt.
Een ander voordeel van DevOps is dat men een veel beter inzicht in de kosten heeft. Doordat alle kosten gerelateerd zijn aan het team, is het veel eenvoudiger om de cost of ownership voor het ondersteunen van een klant(groep) te bepalen. Het gaat tenslotte om de salariskosten van de mensen in het team en de kosten van de ‘technology stack’. Aangezien de personeelskosten uren van ingekochte kennis vertegenwoordigen, wordt het veel eenvoudiger de waarde van het team te kunnen bepalen. Door de uren te koppelen aan de businesswaarde van de dienstverlening kan snel berekend worden of de kosten van het team in verhouding staan tot de geleverde waarde.
 
Wat moet eerst?
Er is al aangegeven dat alle aspecten van DevOps niet gelijkmatig of volledig doorgevoerd hoeven te worden om de voordelen van DevOps te realiseren. Het DevOps Integration Model (figuur 2) geeft hierbij handvatten die aangeven welke aspecten welke aandacht moeten krijgen. Reeds vermeld is dat de definitie van diensten en klanten van groot belang is. Ook zien we dat het werken aan klantoriëntatie binnen het team daarbij hoort. Daarnaast zien we dat het meten en sturen van de prestatie op de kleinere werkeenheden (incidenten, serviceverzoeken en standaard changes) essentieel is. De grootste effecten worden behaald door aandacht te besteden aan houding en gedrag, met name het zorgen voor een veilige omgeving waarbinnen Dev- en Ops-mensen hun ervaringen kunnen delen. De rol van de teamleider bij het initiëren van acties gericht op teamvorming dragen bij aan deze veiligheid. Als laatste basisvoorwaarde om met DevOps te kunnen starten, is de beschikbaarheid van zowel ontwikkel als servicemanagementtooling.
Figuur 2.
Dit zijn de startpunten voor elke IT-organisatie die zich tot DevOps-team wil ontwikkelen.
Interessant bij DevOps-teams is het streven naar onafhankelijkheid van andere teams, oftewel het realiseren van een integrale verantwoordelijkheid voor de dienstverlening naar de klant, zonder dat een beroep gedaan hoeft te worden op andere teams waardoor vertragingen kunnen ontstaan. Dit streven heeft uiteraard zijn grenzen. Volledige onafhankelijkheid betekent feitelijk dat een DevOps-team een eigen mini-IT-organisatie is geworden. Als dit te ver doorschiet, kunnen schaalvoordelen gemist worden.
Toepassing
Is DevOps voor iedereen? Deze vraag is lastiger te beantwoorden dan het lijkt. Dit heeft te maken met de omvang van de IT-organisatie in relatie tot de diversiteit van de dienstverlening die zij levert. Het belangrijkste toetscriterium is de vraag: kunnen we de gedeelde resources optimaal benutten? Als het organiseren van DevOpsteams leidt tot de situatie dat relatief veel mensen hun tijd moeten verdelen over diverse teams, is DevOps waarschijnlijk niet de oplossing voor de problemen van de organisatie. Dit wil niet zeggen dat er niet gestreefd moet worden naar een hechtere samenwerking tussen de ‘Dev’- en ‘Ops’-bloedgroepen.
In kleinere organisaties (minder dan vijftig mensen) die veelal uit drie afdelingen bestaan (Service Desk, Infrastructuur en Applicaties), is het belang van geïntegreerde teams belangrijk voor goed functionerende IT-diensten. Het gaat dan om integratie van tooling, teamvorming, het inrichten van korte processen met goede afspraken, heldere en simpele KPI’s, en het realiseren van onderling begrip tussen de verschillende
afdelingen. De criteria voor integratie zijn voor deze organisaties zelfs van substantiële waarde. Zoals in de introductie gezegd, DevOps is een hype. De vraag is natuurlijk: wat komt hierna? En kunnen we DevOps wellicht gewoon overslaan in afwachting op ‘the next big thing’ ? Mijn inschatting is dat DevOps voor veel organisaties een definitieve breuk met het verleden kan zijn. Door de vorming van teams die eigenlijk prima zelfstandig kunnen opereren, wordt de ontmanteling van de IT-organisatie een reële optie. In dit scenario wordt een DevOps-team toegevoegd aan de businessafdeling die zij ondersteunt. Uiteraard kan er nog een relatie blijven bestaan met een intern datacenter (dat zich in toenemende mate opstelt als cloudserviceprovider), maar dit is geen verplichting. Deze diensten kunnen tenslotte eenvoudig buiten de deur afgenomen worden.
DevOps opent deuren naar een andere toekomst voor IT
Alles overziend is DevOps een zeer wenselijke ontwikkeling met de potentie om de wereld van IT drastisch te veranderen. DevOps houdt de belofte in dat het meer waarde toevoegt aan de bedrijfsprocessen van zijn klanten. Om dit potentieel te benutten moeten IT-managers bereid zijn om hun huidige organisatievormen ter discussie te stellen. Zelfs als dit betekent dat hun eigen ‘imperium’ kleiner wordt.
Bij deze kijk op DevOps hoort een nieuwe definitie: ‘DevOps (a portmanteau of development and operations) is an organizational philosophy that stresses communication, collaboration and integration between information technology (IT) software developers and IT operations professionals. DevOps uses the interdependence of software development and IT operations to create higher quality products and services. It aims to help an organization rapidly deliver the value sought by the customers of IT.’
 
 
Casus
Binnen een van de grootste banken van Nederland wordt volop ingezet op DevOps als manier om de klanten van IT sneller en beter te voorzien van de IT-diensten die zij nodig hebben. Het DevOps Integration Model leverde hierbij een duidelijke richtlijn voor de te nemen stappen. Hieruit bleek dat de omschakeling naar DevOps lastig is voor managers die hun team op een andere manier moeten aansturen. Het gaat vooral om het openlijk benoemen en bespreken van problemen. Met name het doorpakken op de oplossing van deze problemen is belangrijk.
Medewerkers ervaren de nabijheid van collega’s die vroeger in een ander team zaten als zeer positief, omdat er snel gehandeld kan worden en iedereen werkt aan hetzelfde doel.
Opvallend zijn de neveneffecten. Een DevOps-team werkt met een andere dynamiek dan een traditioneel IT-team. Dit is vooral terug te zien in de relatie tot de omgeving. Vanwege de directe relatie met de klant is de noodzaak om projecten te definiëren veel kleiner geworden. Het gros van de wensen van de klant kan via changes opgelost worden. Hierdoor is de deelname aan ‘Project Portfolio’-structuren minder noodzakelijk. Daarnaast is de budgetcyclus anders. De allocatie van mensen is gedaan en de kosten van de onderliggende contracten zijn duidelijk waardoor de kosten van het DevOps-team duidelijk zijn. De traditionele budgettering is eenvoudig.
Duidelijk is dat de algemene governance-structuren die gebruikt worden om de IT-organisatie te besturen ook moeten meebewegen bij het instellen van DevOps-teams. Dit lijkt moeilijker dan het operationaliseren van de DevOps-teams zelf.
 
Niels Loader is principal consultant bij Quintgroup. E-mail: n.loader@quintgroup.com

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag