Devops is een reactie op het probleem dat de beheerorganisatie niet is aangesloten op de ontwikkelorganisatie. Dit uit zich vaak in conflicten en inefficiëntie over en weer, ook wel de 'wall of confusion' genoemd. Deze ontstaat door een combinatie van conflicterende motivaties, processen en tooling. Een development team is er op uit om een verandering tot stand te brengen terwijl een beheerorganisatie gebaat is bij (en vaak ook afgerekend wordt op) een stabiele productie-omgeving.
De meeste Agile-implementaties hebben de muur tussen development en business al geslecht, het logische vervolg is om ook de kloof tussen development en beheer te dichten, zodat op die manier een organisatie in staat is om software snel in productie te nemen en effectief te beheren.
Het nut
Organisaties zien dat er veel geld te besparen valt als de ontwikkel- en beheerorganisatie op elkaar zijn aangesloten. Doordat organisaties met Agile-ontwikkelingsmethoden snel en wendbaar wensen van de business kunnen vertalen naar een systeemoplossing, maar vervolgens veel tijd kwijt zijn met het in productie nemen en beheren van de software, is het paard een beetje achter de wagen gespannen.
Als de beheerorganisatie niet in staat is iteratief software in productie te nemen, loopt men nog steeds vertraging op. Devops is een manier om de beheerorganisatie bij het voortbrengingsproces te betrekken door ze een integraal onderdeel van het proces te maken. Hierdoor kan de keten sneller software in productie nemen, worden kosten bespaard en dit kan een groot concurrentievoordeel zijn binnen een markt waar een korte time-to-market van belang is.
Een andere reden voor bedrijven om over te stappen naar Devops is dat de eerder aangehaalde ‘wall of confusion’ een hoop frustraties oplevert die ten koste gaan van productiviteit, samenwerking en werksfeer. Als deze nadelen kunnen worden weggenomen, en hierdoor medewerkers meer werkplezier ervaren, is de opzet in ieder geval gedeeltelijk geslaagd.
Adoptie
Er zijn een aantal grote bedrijven in Nederland die Devops hebben aangenomen als voorkeursmethode voor softwareontwikkeling, het in productie nemen en beheren van software. Voordat je begint, moet eerst het Agile-transformatie- en Scrumproces op orde zijn, omdat de complexiteit van de organisatieverandering anders teveel toeneemt. Naast it en business (wat je in een ‘standaard’ Agile-transitie doet) moet namelijk óók de beheerorganisatie transformeren. Daarnaast is het belangrijk dat het Agile-gedachtengoed volledig is geland binnen de organisatie. Het is beter klein te beginnen en langzaam uit te bouwen om de organisatie te laten wennen en leren. Hierdoor kan je de feedback die je ontvangt gebruiken om het transitieproces te verbeteren waardoor een volgende transitie nog succesvoller kan zijn. Oefening baart kunst.
Vereiste veranderingen
Iedere organisatie zou in principe met Devops kunnen werken, mits je bereid bent de organisatie (ingrijpend) te veranderen. Het doel moet niet zijn op korte termijn een time-to-market probleem op te lossen, maar wel om een it-organisatie vorm te geven die voortdurend in staat is in samenspraak met de business systeemwijzigingen door te voeren en te beheren. Dit kan het verhelpen van incidenten zijn, of het toevoegen van (nieuwe) functionaliteit.
Om DevOps correct te implementeren zijn er op drie gebieden veranderingen nodig:
Meten van cultuurverandering
Als je een cultuur wilt veranderen moet je goed kijken hoe je het resultaat gaat meten en beoordelen. Wat gemeten wordt beïnvloedt het gedrag en vice versa. Het succes van individuen en groepen dient te worden gemeten binnen de context van het succes van de gehele development-beheer cyclus. Voor veel organisaties betekent dit een verandering van kpi’s per silo en/of afdeling vaststellen, naar kpi’s per proces vaststellen. Het is belangrijk dat aan iedereen die deel uitmaakt van een proces duidelijk wordt gemaakt wat hun bijdrage aan het uiteindelijke doel is en hoe hun activiteiten zich verhouden tot andere activiteiten binnen het proces.
Geïntegreerde processen
Binnen Devops dient de gehele development-beheer cyclus als één geïntegreerd proces te worden gezien en vormgegeven. Waarbij het ook als één geheel moet worden gemanaged. Hierbij kunnen verschillende segmenten of subprocessen hun eigen methodes hanteren zolang deze maar samen kunnen worden gevoegd tot één proces op hoofdniveau. In de praktijk betekent dit dat men het eigen ‘eilandje’ moet loslaten. Dit is niet gemakkelijk en zal met weerstand gepaard gaan omdat men bepaalde macht op zal moeten geven ten gunste van het grotere geheel.
Geïntegreerde tooling
Hier lijkt de Devops-discussie zich het meest op te richten. Dit is niet verwonderlijk aangezien het een bijna natuurlijke reflex van techneuten is om meteen een discussie over tooling te starten als er een probleem moet worden opgelost. Want er moet toch een ‘tooltje’ zijn dat helpt dit proces vlot te laten verlopen? Het is belangrijk dat alle individuele tools samenwerken om als keten van tools de procesketen volledig te ondersteunen. Tools moeten voorzien in het automatiseren van handmatige taken (testen, deployment, monitoring, et cetera), beschikken over een software library die onder versiebeheer staat, zodat men in de hele keten met dezelfde gedeelde software configuratie werkt. Daarnaast moet het mogelijk zijn om softwaresystemen zo te modelleren (alle componenten, policies en dependencies zijn beschreven) zodat deze op ieder moment kunnen worden geproduceerd zonder dat dit conflicten geeft met andere omgevingen. Vaak is het beheer binnen organisaties ook van elkaar gescheiden (functioneel applicatiebeheer, technisch beheer, infrastructuur en werkplekken), wat het extra lastig maakt om flexibel met omgevingen om te gaan of om tools uit verschillende domeinen aan elkaar te koppelen. Als organisatie moet je je ervan bewust zijn dat hier veel werk moet worden verricht om alle neuzen dezelfde kant op te krijgen.
Sander de Jonge, Agile-expert bij Bartosz ICT
Agile en Devops zijn methodieken die, wanneer je er aan begint, er voor zorgen dat je organisatie op een andere manier tegen ontwikkeling (en beheer) aan gaat kijken.
De grote winst is dat, door er op een andere manier tegen aan te kijken, de “pijnpunten” van de huidige manier van werken zichtbaar worden.
Het veranderend vermogen (en bereidwilligheid uiteraard) van de organisatie is vervolgens bepalend voor het succes danwel falen van de methodiek.
Als, bijvoorbeeld, het totale beheer van jouw omgeving verdeeld is over diverse (externe) partijen, dan kun je “DevOps-en” tot je een ons weegt, maar dan zul je problemen blijven houden met het in productie brengen van wijzigingen. Pas als beheer als één geheel kan en wil werken zul je richting succes gaan.
@henri DevOps is zeker een interessant fenomeen al denk ik dat de clou van dit verhaal is dat het lastig is om de juiste mensen bij elkaar te krijgen in ICT trajecten zoals ontwikkeling of onderhoud. Want als de je de gebruiker/klant, ontwikkelaar en beheerder aan tafel hebt kan je het in principe met drie man af. Heel gechargeerd en idealiter, alleen zit zo de wereld niet elkaar, zeker niet in een grote organisatie.
Maar inmiddels heeft het DevOps een hele andere vaart genomen, in een adem wordt het genoemd met Agile, Scrum, continous delivery en integration. En daar kom mijn knorrigheid om de hoek kijken voor je het weet zijn het abstracte begrippen waar je van alles bij kunt bedenken. Dat blijkt ook wel als ik de artikelen en reacties over deze onderwerpen lees. Het zwabbert alle kanten op. En nog weet ik niet wat wat agile is, wat nu exact devops is en hoe de ware scrum in elkaar steekt. Maar we zijn wel agile hoor! Ik wacht nog steeds hier of in de reacties op iemand die nu exact kan uitleggen hoe het zit. Nog niet gelezen. Soms denk ik wel, ICT en alles wat er omheen hangt van vaagheden aan elkaar is spraakverwarring troef en misschien is dat ook wel zo prettig. Iedereen mag meedoen en meepraten, verstand van zaken of niet. Wel goed voor de werkverschaffing.
Bij DevOps denk ik dus voor mezelf maar dat het handig is om de juiste mensen bij elkaar te brengen zonder dat er van alles tussenzit en niet de organisatie, formele verhoudingen of de bureaucratie verstorend werken. Dat geldt misschien wel juist voor zulke organisaties als banken, ziekenhuizen, belastingdienst of wat voor grote logge organisaties ook. Projecten en trajecten die kwa afhankelijkheden over meerder afdelingen heenlopen. Ik meen dat die Belgische meneer juist op de DevOps is gekomen toen hij bij een overheidsorganisatie werkte.
Die cloud dienst leverancier valt naar mijn mening in een hele andere categorie, dit gaat over een software product, niet over de automatisering van een organisatie. En dat nieuwe features misschien in een iets hoger tempo opgeleverd worden en dat uitrollen naar een nieuwe versie gaautomatiseerd is, heel begrijpelijk. Dat hadden ze ook gedaan zonder dat continous delivery en integration te noemen.
@Felix Ik houd wel van mini golf, alleen is dat een sport voor toeristen en bejaarden en niet voor de ICT beslissers op de golfbaan die aan elkaar vragen: zijn jullie al agile? Maar het is een leuk artikel. Mensen boven processen (!) en meer vrijheid voor de ontwikkelteams. Dat spreekt aan en weg met de slavendrijvers en lopende band ict.
@Ewout en @PaVaKe Ja, Ewout denk dat het over afstemming gaat en ben het eens dat outsourcen helemaal de achterdeur uit is en je het dan helemaal niet meer over devops moet hebben. Als er iets is wat afstand creeert dan is het outsourcen wel.
Louis en anderen. Devops is een groeiend fenomeen. De traditionele chinese muur tussen ontwikkeling en beheer is al jaren een onneembare vesting, die bedrijven veel geld kost. Applicaties worden nog ontwikkelaars beheert of de infrastructuur is onbeheerd, wordt niet gepatched, etc.
Devops betekent dat je als team samenwerkt om het gehele systeem in een beheerde omgeving gestalte te geven en in productie te nemen. Dit kan ook in een outsourced omgeving. Er zal wel een regisseur moeten zijn, maar je zult verbaasd zijn van de kracht van een devops team dat goed samenwerkt. In plaats van elkaar te dwarsbomen helpt men elkaar en worden goede ideeen geleverd.
De manier waarop de reageerders erin zitten is wel heel behoudend en beperkt. Verdiep je eens in de materie.
@Willem
Wie heeft die Chinese muur opgeworpen, met welke doel is dat gedaan?
Natuurlijk zit de sleutel in samenwerken maar verdiep je eerst zelf maar eens in de materie, Chinese muur is ontstaan door het Excel(lente) management van zeemeeuwen die hard roepen, iedereen op hun kop schijten en dan snel weer wegvliegen. Even voor de duidelijkheid, eind jaren 90 deed ik al zoiets als DevOps door wereldwijd 6 major en 12 minor releases per jaar uit te rollen.
Toen nog voornamelijk met tapes en vliegtuigen omdat netwerk duur en traag was maar principes en processen waren hetzelfde. Met echter één verschil, als IT zei dat een release niet uitgerold kon of mocht worden dan gebeurde het ook niet.
Niet aangebrachte patches, niet goed ingerichte servers zijn in 9 van de 10 gevallen een business beslissing omdat time-to-market belangrijker geacht wordt dan de beveiliging. Aanbrengen van patches is namelijk iets dat vrijwel automatisch gedaan kan worden, net als rechttrekken van beveiliging met templates en scripts maar niet gedaan wordt omdat dan allerlei applicaties niet meer werken.
Agile is bug fixing, lean is problem solving;-)
@Willem Vraag is hoe die Chinese muur eruit ziet en wat je je daarbij moet voorstellen? Samenwerking is volgens mij iets wat iedereen die hier reageert wel noemt. Het team klinkt leuk maar dat betekent niet dat er geen taken en verantwoordelijkheden zijn en inhoudelijke leiding moet zijn.
Outsourcing werpt barrieres op en creeert afstand. Stel je besluit je ontwikkeling van een onderdeel uit te besteden, dat betekent afspraken maken en contracten opstellen. Nu bedenkt de klant na een een tijd dat hij toch zaken graag iets anders ziet, wat dan? Dan denk ik, dat betekent afspraken en contract herzien en opnieuw steggelen op hoger niveau. Als het ook nog outsourcing is waar de ontwikkeling in een land hier ver vandaan is dan is de afstand tussen ontwikkelteam en klant/gebruiker wel erg groot geworden met schijven daartussen. Als dan ook nog de beheerafdeling bijvoorbeeld intern of weer andere partij doet dan is ook die afstand tussen beheer en ontwikkeling groot. DevOps, gaat ook over korte lijnen en lijkt me zo lastig te bewerkstelligen. Er ligt in een extra probleem. Ook niet echt agile als ik naar het manifesto kijk.
Maar ik ben benieuwd naar je uitleg. Communiceren is inderdaad lastig in het uitgebreide ICT vakgebied met mensen met diverse achtergronden.
Moet ook denken aan dat bekende plaatje wat hier onlangs weer te zien was:
http://makingsoftware.foglo.com/wp-content/uploads/2011/01/PM_Build_Swing.gif
Naast dat ik de commerciële lijn en intentie wel kan en wil volgen, is die andere lijn weer onnavolgbaar. Sec IT gezien ga en wil ik de koppeling
tussen IT beheer en Devteam niet maken. De reden daarvoor is uiterst eenvoudig.
Devteams en veranderingen
Ik spreek nu even mijn praktijkervaringen uit over dit stukje. Tot nu toe heb ik nog geen enkel Devteam het volgende volmondig en helder horen verklaren: Helder, Transparant, Op tijd, Afgesproken, Conform Specs. Het resultaat: Heel veel hele hoge rekeningen. Gegarandeerd.
Devteams en veranderingen
In mijn beleving zijn er geen DevTeams nodig om IT wise veranderingen te bewerkstelligen. Je kunt ze er natuurlijk wel voor assignen en inzetten maar dan krijg je: Hele veel hele hoge rekeningen, gegarandeerd.
Waar je hier namelijk mee te maken hebt, zoals het artikel al beschrijft, twee verschillende werelden. IT – Statische en Non IT- Dynamisch.
Wall of Confusion
Leuk gevonden maar die ‘wall of confusion’ is helemaal niets meer en minder dan dat IT, nader nog, commercieel IT, het na x jaar KA, het nog niet eens voor elkaar heeft gekregen Non IT te vertellen wat nu IT is, hoe het werkt en beweegt, en het allerbelangrijkste, hoe je er als Non IT er tegen aan moet kijken en mee moet om gaan.
Daarvoor bedenk je dan volkomen overbodige en nutteloze zaken zoals DevOps, Agile, Scrum, Lean. (Are you kiddin’ me? Keep trying) Vervolgens vervat je dat allemaal in een commercieel getint artikeltje, publiceer dat en…… zie hier, een totaal overbodige discussie is geboren.
Back to basics?
Beste IT professional, waar is IT nu eigenlijk voor bedoeld en wat wil je nu feitelijk met de inzet van IT bereiken? Dat iedereen als domme aapjes nieuwe trucjes leert zoals methoden die helemaal niets met de lineairiteit van IT op hebben en dan roepen, kijk ons eens lekker bezig. Geweldig. (Max 140 chs) #Agile #Scrum #Humptidum #Bunte Illustrierte
Of was het toch nou net niet zo dat de basis van IT gewoon het verhogen van productiviteit was met zo min mogelijk FTE?
Ik kan het natuurlijk volkomen mis hebben maar wist u dat de meesten die hard #Agile #Scrum #Humptidum #Bunte Illustrierte roepen het minste uit hebben staan met en in IT? Oh ja natuurlijk, de mensen met de volkomen frisse blik die….. Oh ja.
Natuurlijk.