26 procent van de Nederlandse organisaties rapporteert een snellere time to market van nieuwe applicaties door het gebruik van softwareontwikkelmethode DevOps. Dit blijkt uit onderzoek van Vanson Bourne, uitgevoerd in 24 verschillende landen wereldwijd, waaronder Nederland, onder dertienhonderd it-professionals en -beslissingnemers in opdracht van softwareleverancier CA Technologies.
DevOps is een methode dat de samenwerking stimuleert tussen teams die applicaties maken en testen (Dev) en de teams die de toepassingen onderhouden in productieomgevingen (Ops). De studie, TechInsight Report: What Smart Business know about DevOps, toont dat DevOps het voor organisaties mogelijk maakt om het aantal klanten met 25 procent te laten toenemen. Daarnaast kan DevOps de it-kosten voor ontwikkeling en operationele werkzaamheden met 12 procent reduceren en het aantal mensen dat werkt aan de ontwikkeling en het uitrollen van nieuwe versies kan met 14 procent worden verminderd.
Financieel voordeel
De financiële voordelen voor Nederlandse organisaties zijn bijzonder interessant. Respondenten rapporteren een verbetering van 25 procent van de business door het gebruik van DevOps. Dit zien zij terug in de vorm van nieuwe klanten, toenemende omzet en lagere it-kosten.
Ongeveer 56 procent erkent nu een grotere behoefte te hebben aan DevOps-strategieën. Bovendien zegt 56 procent DevOps al in gebruik te hebben of erover na te denken dit binnen niet al te lange tijd te implementeren.
DevOps-strategie
Het onderzoek toont daarnaast aan dat de kennis over en het bewustzijn van de DevOps-strategie toeneemt, met name als een manier om beter aan de klantvraag te voldoen en om de totale klantervaring te verbeteren. Een groot deel van de Nederlandse organisaties (55 procent) overweegt dan ook te investeren in nieuwe tools en trainingen voor de ontwikkel- en uitrolmedewerkers. Nog eens 24 procent overweegt om nieuw personeel met de juiste vaardigheden aan te nemen.
De DevOps-strategie van de ondervraagde organisaties is bovendien gefocust op de business. De benodigde kennis die de ontwikkelaars en uitrollers nodig hebben om een DevOps-strategie succesvol te implementeren, is kennis van de algemene prioriteiten, strategieën en de business (41 procent). Daarnaast spelen process engineering-vaardigheden (41 procent) en communicatieve vaardigheden (35 procent) een belangrijke rol.
Meten van succes
Nederlandse organisaties meten het succes van hun DevOps-strategie door te kijken naar interne factoren, zoals verlagen van kosten, verminderen van het aantal bugs, hogere roi en verbeterde samenwerking tussen afdelingen. Daarnaast analyseren zij de externe business factoren, zoals een toenemende omzet, een snellere time-to-market, verbeterde concurrentiepositie en een betere klantervaring. Ongeveer 31 procent van de respondenten meet het succes van hun DevOps-strategie op basis van interne factoren, terwijl 33 procent zich op externe factoren baseert.
Even kort hoe ik DevOps zie, namelijk niet als een snellere time-to-market an sich. DevOps is in mijn ogen pas relevant NA nadat een product gelanceerd is, dus al in de market is.
Ik zie DevOps als een brug tussen ontwikkelaars en beheerders en een mogelijkheid om aan kortere release cycles te kunnen doen op basis van de volgende premises:
1) In de architectuur van de software EN infrastructuur wordt al rekening gehouden met snelle releases
2) Organisatorisch is alles hierop ingericht met processen
3) Men kan gedistribueerd releasen wat kan door een samenspel van de manier van ontwikkelen + noodzakelijke tools om dit te realiseren.
Punt 3 betekent dus dat je niet alle gebruikers tegelijk over laat gaan naar de nieuwste versie. En dat je dus een hele goed beheersing hebt van het testen,uitrollen, terugrollen en monitoren.
DevOps is een strategie die niet toevallig ontstaat, maar in mijn ogen bittere noodzaak voor een succesvol product die gericht is op de (internationale) massa.
DevOps is in mijn ogen de nieuwe standaard en cloud computing is een belangrijk aspect en middel hiervoor, maar niet meer dan dat. Het zwaartepunt ligt bij de mensen en de leiders met visie. Je bent niet meer alleen ontwikkelaar, maar ook een beetje beheerder en vica versa. Devops is in mijn ogen iets wat je gehele organisatie transformeert.
En ook hier geldt John Gall’s Law: “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
Chirurg en huisarts in een team… ik denk dat de chirurgen gillend weg rennen.
@Louis: en wie is in deze beknopte analogie de chirurg en wie de huisarts?
De beheerders die met chirugische precisie de stroom aan updates en bugfixes stabiel in productie moeten zien te krijgen?
Of de ontwikkelaars als eigenwijze chirurgen die met minachting over de beheerders denken?
Zonder afbreuk te willen doen aan het resultaat:
Op zichzelf eigenlijk niet zo heel bijzonder. Het is een samenwerkingsvorm die silo overstijgend is.
Wat op zichzelf altijd goed is voor betere resultaten dan binnen de individuele silo’s. Eenvoudigweg omdat mensen en middelen zijn ingesteld op het dienen van een gezamenlijk belang. En dat weer vanuit een ketenperspectief en denken/werken buiten eigen kaders.
Ik ben van mening dat je een dergelijk verbetering ook al zou kunnen realiseren door een vergelijkbare methode toe te passen op de IT-Ops zijnde netwerk, desktop en server teams. De meerwaarde van de combi Dev & IT-Ops zit hem namelijk vooral in de korte release cycle van apps.
@WillMoonen Nu weet ik niet helemaal wat silo’s zijn maar ik denk dan maar afdelingen maar dan ben ik het helemaal met je eens, devops is helemaal niet bijzonder. Het is verstandig om bijvoorbeeld ontwikkeling en beheer bij elkaar te betrekken. Ook vanuit beheer zijn er randvoorwaarden om aan voldoen en die kun je beter wel in het ontwikkelingsproces betrekken. Dan maak je ook kans om applicaties sneller uit te rollen. Maar het heel ronkende gedoe over DevOps is volkomen misplaatst en alsof het iets heel bijzonders is. Maar bestaat die nu al, die cursus voor DevOps Certified Engineer?
Zowel devops als agile hebben, zeker ten opzichte van waterval-modellen, als grote kracht dat er over grenzen van eigen afdelingen (de silo’s zoals Wil ze noemt) heen gekeken wordt.
Hiervoor zijn een 3-tal factoren van belang:
– werknemers die bereid zijn over de grenzen heen te kijken, open te staan voor suggesties van andere afdelingen en bereid zijn kennis en ervaring te delen
– tooling die afdelingen hierbij kan ondersteunen (o.a. bekend als ALM (application lifecycle management) of CLM (collaborative lifecycle management) tools.)
– als laatste ook de lastigste: managers die bereid zijn hun eigen geschapen koninkrijkjes / eilandjes op te doeken om daarmee de samenwerking te stimuleren en faciliteren.
Hoe je dat dan uiteindelijk noemt, is verder niet meer van belang. Het is een kwestie van mentaliteit en houding, niet zozeer van methoden.
@PaVaKe Eens dat het een kwestie van mentaliteit en houding is maar dan moet daar de ruimte ook voor zijn. In grote organisaties is het niet 1 IT afdeling maar heb je verschillende IT afdelingen en als het even tegenzit zijn de contacten tussen die afdelingen ook nog geformaliseerd. En klop je bij de ene afdeling zo aan, een andere afdeling zal zich achter regels en procedures verschuilen. Wie kent het niet, zit en in nood en dan: heb je een ticket nummer? Daarom denk ik dat om de DevOps samenwerking tussen beheer en ontwikkeling te forceren nog het meest een organisatorisch probleem is.
Ben het niet met je eens om naar management te wijzen wat betreft koninkrijkjes, die technische jongens kunner er ook mee terecht. Ook geen algemeenheid: Het koninkrijk bestaat niet. Verschillend van persoon tot persoon, dat is ook een kwestie van mentaliteit en houding.
@Louis … ik herken wat je zegt, maar dat roept een heel andere vraag op: wie bepaalt er nu eigenlijk hoe er gewerkt wordt? Management of de technische jongens.
En als het de technische jongens zijn, waarvoor hebben we dan nog management nodig?
Titel is misleidend, het gaat bij DevOps naar mijn mening niet alleen om de snelheid van deployment maar de kwaliteit van de service tijdens de gehele lifecycle waarbij, zoals Will al aanhaalt samenwerking tussen bloedgroepen die eerder elkaars bloed wel konden drinken, helpt om deze te verbeteren. DevOps is dus vooral een attitude wijziging waarbij ontwikkeling en beheer uitgaan van: “jouw probleem is mijn probleem”
@Louis
Methodieken worden nog weleens gebruikt om organisatorische tekortkomingen te verdoezelen en rapporteren op KPI’s zoals verlagen van kosten, verminderen van bugs, hogere roi en verbeterde samenwerking lijkt me een garantie voor mislukking. Dan gaat het niet om de kwaliteit van de service maar de cijfers waar managers, die liever geen probleemeigenaar worden, op gaan sturen.
P.S.
Configuratie management is naar mijn mening nog altijd de basis van beheer en dan bedoel ik niet het resourcebeheer van ‘metering service’ maar het registreren van de combinaties die gezamenlijk de service maken. Vastleggen van configuraties voorkomt namelijk niet alleen verkeerde wijzigingen maar maakt ook overdracht ook gemakkelijker. Applicaties snel uitrollen doen we dan ook al een jaar of 20, eerst met Kixtart en nu blijkbaar met andere tools als ik kijk naar sponsor van het onderzoek.
@PaVaKe Ik denk dat het iig niet de technische jongens zijn die bepalen hoe er gewerkt moet worden, dat zal vanuit het management bepaald worden. Maar het ging mij om samenwerking, de een zal behulpzaam zijn en de ander op zijn strepen staan. Management of technische mannen.
@Ewout Ik denk dat DevOps, wat volgens mij geen methodiek is, niet meer is dan het realiseren dat samenwerking tussen beheer en ontwikkeling zinnig is. Over je opmerking over methodieken, dat gaat naar mijn mening vaker over controle dan over inhoud.
In 1 adem met DevOps wordt ook continous delivery genoemd. Jij hebt het over snel applicaties uitrollen. Snel in de zin van minimale downtime? Want ik heb het idee dat het nu ook over vaak uitrollen gaat. Je scrumt (= todo lijstje business afwerken…) van onderdeeltje naar onderdeeltjes en hup hup snel snel snel in productie. Het liefst getest en gedeployed met 1 druk op de knop. Ik twijfel.