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
