De hype rondom devops heeft geleid tot een hardnekkig misverstand dat dev (ontwikkeling) en ops (bedrijfsactiviteiten) in elke denkbare situatie een sterke verbinding vormen. Deze werkwijze staat dus niet gelijk aan de toverdrank uit de strip Asterix en Obelix. De devops-aanpak is geen wondermiddel dat je it-organisatie altijd en overal oersterk en onoverwinnelijk maakt.
Toch betekent deze nuance van het ‘niet altijd gelukkige huwelijk’ niet dat deze methode niet werkt. Het tegendeel is zelfs waar: in veel gevallen loont het om tijdens het ontwikkelproces ‘van zand tot klant’ een multidisciplinair team in te zetten zodat ontwerpers, bouwers, testers en beheerders niet in complete afzondering van elkaar werken.
Het gevaar zit hem in organisaties die zich laten meeslepen door de hype en zich blindstaren op de devops-aanpak. Ze zien hierin een soort heilige graal, het wondermiddel dat hun it onoverwinnelijk maakt. Toch is het verstandiger om niet lukraak een devops-team op te tuigen, maar eerst na te gaan of deze werkwijze wel voldoende rendeert. Stel jezelf een aantal cruciale vragen: wat is het geld dat ik tot mijn beschikking heb? Hoe belangrijk is het product of de applicatie die ik ga ontwikkelen? Moet het product continu uitgebreid of vernieuwd worden? Zijn er veel pieken en dalen in de werkdruk? Is er wet- of regelgeving die zorgt voor een continue stroom aan aanpassingen?
Werk voor minimaal drie
We realiseren ons maar al te goed dat deze vragen niet altijd makkelijk te beantwoorden zijn. Vaak zie je dat er veel werk te verzetten is in de eerste fase, ook wel de ontwikkelings- en groeifase van het product. Daarna staat het product en kun je afschalen. De ontwikkeling is immers een eenmalige ‘last’, terwijl het beheer een blijvende ‘last’ vormt. Schroom in dit soort situaties dan ook niet om te overwegen op een andere voet verder te gaan en het idee van devops als ‘wondermiddel’ los te laten.
Maar wanneer ben je op dat beslissende punt beland? Wanneer weet je dan of het beter is om een devops-team op te heffen of er niet aan te beginnen? Ik hanteer vaak de volgende stelregel: als de stroom aan werk niet voldoende is om drie man personeel fulltime aan het werk te houden, schrap dan de devops-constructie. Je kunt dan op een andere manier verdergaan, bijvoorbeeld door het operations team meerdere producten te laten beheren. Zij zitten misschien niet zo dicht tegen de business aan, maar vaak is dat ook niet nodig. En het scheelt aanzienlijk in de kosten.
Opschalen is dan nog steeds mogelijk als er echt wijzigingen zijn. Toegegeven, het team is dan misschien minder op elkaar ingespeeld en ook de feedbackcycles worden dan langer, maar het is nog maar vraag of je in deze gevallen überhaupt snelle feedbackanalyses nodig hebt.
Renderen in een devops-constructie
Wat ik wil adviseren aan organisaties is om niet in zijn geheel over te gaan op devops, maar goed te kijken welke teams in deze constructie het best renderen. In de praktijk blijkt namelijk dat veel organisaties in een keer volledig omgaan terwijl na een tijdje blijkt dat devops niet voor elk team de beste werkwijze is. Dit hangt af van de snelheid waarmee je sector verandert, bijvoorbeeld door regelgeving of innovatie waardoor je snel moet schakelen om de concurrentie voor te blijven. Want hoe groot de hype ook is, waan je vooral niet compleet onoverwinnelijk in een devops-constructie en blijf kritisch kijken naar je trajecten. Want voor je het weet is het devops-toverdrank uitgewerkt en raak je alsnog verstrikt in onrendabele trajecten.
Alex van Assem, managing consultant finance bij Info Support
Inderdaad, dev is sexy, ops is not. Devops ook sexy, daarom noemt men die dure teams zo,
maar een devops-team gaat echt niet haar producten beheren. Wisten we al, maar we moesten het nog even meemaken.
Hoe stelden ze zich dat toch voor : toets 1 als u uw wachtwoord wilt resetten, 2 als u een vraag heeft over de factuur. 3) als u nooit aan de app kunt wennen omdat alles altijd zo nodig moet veranderen. Bij geen keuze wordt u doorgeschakeld naar 1 van onze devops-medewerkers.
DevOps is een samentrekking van development en operations met als doel ontwikkeling en beheer samen te brengen in één team om tot een verhoogde frequentie en betrouwbare levering van software te komen. De ingrediënten van deze toverdrank lijken uitwisselbaar als daarmee de inzetbaarheid van het personeel vergroot wordt en eenvoudig repeterende taken bij het bouwen, testen en uiteindelijk het uitrollen van software geautomatiseerd worden. Het oude paradigma van teamwerk en scripting is dan ook niet echt een hype en verliest ook niet zijn waarde als je door rigide regels maar weinig veranderingen hebt want zo’n 30 jaar geleden was het principe hetzelfde alleen had deze modderschuit toen een andere vlag.
Dino, betreffende het onderhoud van de code hebben leveranciers veelal een (contractuele) verplichting als we kijken naar wat juridische punten aangaande de aansprakelijkheid. En één van de punten waar DevOps zich sterk op richt(te) – naar mijn opinie – is het QA aspect van testen. Waan van de dag over de Haarlemmerolie van een toverdrank gaat om de feedbackcycles maar de vraag is of een managing consultant finance bij Info Support weet welke loopings er gemaakt worden. Het schrappen van een devops-constructie om onrendabele projecten toch weer rendabel te maken gaat veelal om een bezuiniging op de kwaliteit.