Bent je nog druk met Agile implementeren? Wees je er dan van bewust dat de volgende vloedgolf aan veranderingen er al weer aan komt. De golf DevOps maakt af wat Agile begonnen is: technologische en procesmatige integratie tussen ontwikkeling en beheer. Waar Agile zich primair focust op klant en it-vernieuwing, wordt met DevOps definitief de laatste muur geslecht: die voor de beheerafdeling. In deze blog licht ik een tipje van de sluier van DevOps op.
Bij DevOps draait het dus om samenwerking tussen ontwikkeling en beheer. Daar komt de naam ook vandaan: Dev staat voor Development en Ops voor Operations. In DevOps zitten een tweetal kernprincipes: Continuous Integration en Continuous Delivery.
Onder Continuous Integration (CI) verstaan we snelle, geautomatiseerde deployments van de ene omgeving naar de andere. Dat kan de traditionele ontwikkeling test acceptatie en productie (otap)-straat zijn, maar ook het kortcyclisch verbinden van ‘zij-straten’ valt hier onder. Dit geeft de mogelijkheid om snel de kwaliteit van de nieuwe software te testen en te toetsen. Op zich wordt dit binnen Agile projecten ook vaak al gedaan om de afstand tussen ontwikkelaars en testers te verkleinen.
Continuous Delivery (CD) hanteert min of meer hetzelfde principe, alleen is er sprake van nog meer automatisering en nog minder afbakening van een release. Feitelijk is er een volledig geautomatiseerde gang naar productie, zonder menselijk ingrijpen. Alle stappen worden namelijk geautomatiseerd getest in een framework. CD stelt je in staat om zeer frequent in zeer kleine batches software op productie te releasen. Soms zelfs meerdere keren per dag. Die updates zijn zo klein dat de impact van een fout vaak nihil is. Dit wordt ‘geharnast’ door een uitgebreide set aan geautomatiseerde tests die de belangrijkste risico’s afvangen. Inmiddels hebben wij een team draaien bij een klant waarbij er in twintig minuten geïntegreerd, getest en gedeployed kan worden naar productie. En dat dus zonder grote risico’s!
Wat moet mijn organisatie met DevOps?
Het belangrijkste nieuws van DevOps is dat er geen belemmeringen meer zijn voor een snelle respons van it op business wensen. Maak je mensen, zowel vanuit de business, ontwikkeling als beheer, hierop attent. In een tijd waarin effectiviteit wordt gewaardeerd boven efficiency, worden paarse krokodillentranen niet getolereerd. Concreet betekent het dus investeren in verregaande automatisering, dus kritische toolselectie. Geen eilandjescultuur meer waarin teamperformance wordt geoptimaliseerd (een vervelend bij-effect van Agile werken!), maar een gezamenlijk doel en het operationaliseren van organisatieperformance. Er komt één keten van business-wens naar deployment, waarin alle activiteiten in het teken staan van beheersbaar live gaan. Zoals een collega van mij gonlangs zei: ‘Alles is beheer!’.
Jouw beheerafdeling werkt waarschijnlijk aan de hand van Itil, ASL en BiSL. Je ontwikkelteams werken volgens Agile-Scrum. Dat gaat dus botsen. Wie van de twee ‘vechtende honden’ gaat de methodenclash winnen? Wat mij betreft wint de derde hond: je bedrijfsvoering. Laten zij maar aangeven wat waarde heeft: een nieuw stukje software of een incident, een nieuw project of een stel bugs, technisch onderhoud of een nieuwe tool. Vergeet het onderscheid tussen incidents en changes en laat de business beginnen met het prioriteren naar business waarde. Zet nu eindelijk de business aan het roer van je it-organisatie en zorg dat je dit zo goed, snel, en beheerst mogelijk faciliteert. Ik ben ervan overtuigd dat het serieus implementeren van DevOps dit mogelijk maakt.
voor mij duidelijk, maar voor business ook ? Gaan zij betalen als ze meerwaarde niet zien ?
Hi mauwerd,
Volgens mij is DevOps heel logisch: laten we er voor zorgen dat we technische en procesmatige beperkingen in het live brengen van software zo veel mogelijk oplossen. Dat is niet heel moeilijk te begrijpen 😉
Ik denk dat de business op dit moment voldoende pijn voelt in de kat en muis spelletjes tussen Ontwikkeling en Beheer en de daarbij gepaard gaande lange overdrachtsmomenten.
Mooi en duidelijk artikel over DevOps, het laat de kracht van de verbinding tussen de Business en de IT zien. En dat is iets waar bij veel bedrijven die agile zijn gaan werken nog winst te behalen is!
@Mauwerd: Als er volgens de business geen meerwaarde is, dan moet je het niet doen. Maar mijn ervaring is dat als Business en IT samen eens goed kijken, dan is er altijd wel iets met meerwaarde te vinden. Nog genoeg te doen wat ook nut heeft!
Hoe logisch dit allemaal ook lijkt, er schuilt m.i. een uitdaging in de interpretatie van wat we “de wensen van de business” noemen. Mijn ervaring is dat business wensen vaak impulsief lijken te zijn, geuit vanuit een onvermogen/onbekendheid met een bepaalde situatie/ontwikkeling.
@NoudW Onbekendheid en onvermogen kun je aanpakken met de samenwerking van Business en IT, en goed communicatie. In het begin onwennig, maar als het daarna gaat lopen, dan betaald het zich zeker terug!
Leuk stuk Anko.
Om je antwoord aan Mauwerd wat aan te vullen: de investering voor DevOps is, als je het goed aanpakt, fundamenteel minder dan bijvoorbeeld de overschakeling van Waterval naar Agile. Een groot aantal voordelen van DevOps wordt al heel snel duidelijk en daarmee ook voelbaar binnen een organisatie.
DevOps is erg strak gericht op een verkorte time to market, snellere en naadlozere integratie van nieuwe “dingen” in de productie omgeving en vergt vanuit de Business veel minder effort om te snappen wat er gaande is.
Zoals Anko al zegt, DevOps is vooral heel erg logisch en eigenlijk zelfs voor de hand liggend.
@NoudW: “de wensen van de business” is een uitdaging in willekeurig welke aanpak ook gebruikt wordt. Groot voordeel van Agile en DevOps is dat ze zo ongeveer tailored zijn om efficient en effectief om te gaan met impulsieve wensen en wijzigingen.
@Martijn
Zoals ik development met Agile begrijp, hoeft dat ook niet extra te kosten (vergeleken Waterval). En de klant merkt het ook direct want die krijgt status overzicht na elke sprint en kan bijsturen.
Anko beschrijft tegengestelde culturen tussen ontwikkeling en beheer en DevOps om dat op te lossen. Helder toegelicht en voor mij herkenbaar ook. Maar business wil bezuinigen en waarom zou die op moeten draaien voor verbetering tussen samenwerking tussen ontwikkeling en beheer? Voor Business is ontwikkeling samen met beheer een grote ICT pot nat. Probeer maar eens duidelijk te maken dat de Business extra moet betalen op wat een interne ICT aangelegenheid is.
@Mauwerd: investeren kan IT ook vanuit haar eigen budgetten!
Als het om IT Service Management gaat is het eerste dat moet gebeuren: zorgen voor een eenduidig changeproces. Het tweede is: development integreren in beheer. Het derde is: managen op het doorvoeren van het eerste en tweede.
En nu eens ophouden met het verzinnen van allerlei kekke naampjes voor “oplossingen” voor zaken die met logica en gezond verstand kunnen worden aangepakt.
De “methodenclash” die hier wordt genoemd is feitelijk een management clash. Een “Mindset clash” ook, van IT-(manage)ers die zichzelf belangrijker vinden dan het resultaat van goed ITSM. In die zin snijdt dit artikel nog wel wat toevoegde waarde.
Maar dit even oplossen via snelle taal en oppervlakkig denkwerk gaat mij te ver. Evenals de aanname dat ITIL, BiSL of ASL wordt gebruikt en dat die botsten met Agile-Scrum. Het zijn geen methodes en ze hanteren geen logisch procesmodel. Als dat wel het geval was zou er vaker sprake zijn van goede en goed bestuurde processen en dan botst er niets. Integendeel, een goed georganiseerd proces kun je net zo agile maken als je zelf wilt en als goed is voor jouw bedrijf. Wat dat betreft moet je misschien nog eens goed kijken naar FSM en ISM.
Als het gaat om de behoefte aan ondersteunende functionaliteit en middelen om het primaire business proces te optimaliseren en daardoor de bedrijfsdoelstellingen beter en sneller te realiseren dan is de business ALTIJD leading. Het is de kunst die behoefte eenduidig vast te leggen en vast te stellen en daar vervolgens de juiste oplossing bij te leveren.
Het maakt niet uit wat je wilt veranderen, maar als er sprake is van verandering dan gaat dat altijd en overal via dezelfde principes (en het is niet eens uniek voor ICT). Je kunt er voor kiezen om dit kort cyclisch te doen of in grotere stappen, maar de cyclus is generiek. Je hoeft hem alleen maar aan te passen aan de aard van de business.
Ik zie DevOps als onderdeel van Agile en niet zozeer als een stap verder dan Agile. Goede development practices zijn essentieel in Agile. In XP kennen we al Continuus Integration, en Continuus Delivery is het logische vervolg hier op. Ik ben het eens met @Hans Kroon’s opmerking over kekke naampjes!
Binnen Agile is er sterke focus op team efficiency en performance, maar daar houdt het zeker niet op. Ik bestrijd de stelling dat een vervelend bij-effect van Agile werken is dat we in eilandjes binnen teams alles optimaliseren en de samenwerking daarbuiten te wensen over laat. Denk bijvoorbeeld aan Lean, aan business agility, agile contracts, etc… Allemaal ingredienten voor een optimale flow door de hele organisatie! Maar ook een goede Scrum implementatie houdt niet op bij de teams! Het is misschien wel de grootste misvatting over Agile dat Agile een IT speeltje is! Het gaat bij Agile vooral om de mindset, de bedrijfscultuur waar iedereen gericht is op een zo efficient en effectief mogelijke samenwerking. Welke praktijken je daar aan koppelt is van ondergeschikt belang!
Wat betreft de methodenclash tussen Development en Beheer: Als we het over Continuus Delivery hebben gaat het niet meer over Scrum teams. Scrum is kortcyclisch, maar niet Continuus! Ik zou in dat geval voor Kanban kiezen. Prima geschikt om ontwikkeling en beheer te combineren. En waarom dan nog een aparte beheerclub?