Managed hosting door True

‘Software sneller op de markt door DevOps’

 

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4905894). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

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.

Hier is een aardig filmpje over DevOps wat vooral ingaat over het het ontstaan is in Belgie.

http://www.youtube.com/watch?v=o7-IuYS0iSE

@Henri Leuk filmpje over de historie van DevOps maar ik vroeg me wel af na het zien van het filmpje, wat is DevOps nu eigenlijk? Dat vertelde het filmpje helaas niet. Niet helemaal, ze hadden over een 'movement'.

Naar mijn mening is DevOps nog minder een softwareontwikkelmethodiek dan Agile dat is. Bij Agile had je tenminste nog ondersteunende methoden als XP, Scrum, DSDM etc.
DevOps is in mijns inziens een beweging, een visie, een mindset waarin je voor alles met elkaar samenwerkt en met elkaar gebruik maakt van elkaar kennis en competenties. Heilige huisjes en silo's vallen dan weg. En het proces wordt dan gevormd naar de behoeften van alle (!) stakeholders.
Daarbij is DevOps zeker GEEN IT-feest: als je verregaand gaan integreren (in ieder geval in de werkwijzen!) dan zal dit ook zijn effect hebben op Budgettering (finance), HRM (competentieontwikkeling), strategie (klantbenadering), management (aansturing) , etc.
Maar begin met DevOps bij het begin: met samenwerken over specialisaties en afdelingen heen :-)

@Anko Eens dat DevOps geen methode is maar ik denk dat je DevOps niet vager moet maken dan het al is en er allerhande afdelingen bij te betrekken. Development en Operations, het zegt het al. Het is naar mijn mening wel degelijk iets wat technische IT aangaat, het gaat erom dat ontwikkeling en beheer met elkaar verbonden zijn. Wat ontwikkelt wordt moet ingevoerd en beheerd worden. Beheer heeft haar voorwaarden en wijze van werken, iets om bij het ontwikkelen rekening mee te houden. Dit wordt ook in 1 adem genoemd met het automatiseren van het testen en het invoeren van de software (en geautomatiseerde roll back..!). De grote geautomatiseerde software ontwikkelstraat. Gaf het in een eerdere reactie aan, denk dat het zowel een organisatorisch als een it probleem is. Maar maakt het niet vager dan het al is, het IT vak heeft behoefte aan helderheid. Dan ga ik nogmaals eens nadenken wat Agile nu eigenlijk precies betekent.....

@Louis: Ja en nee :-) Want we kennen in de IT hele heldere functieomschrijvingen en als je je daar strikt aan houdt denkt iedereen nog maar in zijn eigen straatje / discipline / verantwoordelijkheid.
De IT heeft mijns inziens juist behoefte aan een *integrale* benadering van software ontwikkeling. Geen hokjes en vakjes, maar doelen en resultaten.
Dus: helderheid in doelen is waar we naar op zoek zijn. Het proces hoe we daar integraal naar toekomen moet ook helder zijn. Maar wie wat wanneer iets hoe doet - laat dat lekker aan het zelforganiserende team over. Kunnen ze prima als de organisatie daar de juiste randvoorwaarden voor schept. Zoals een DevOps aanpak ;-)

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×