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.
@Hans Kroon: jouw commentaar op mijn bijdrage snijdt zeker hout. Ja, de botsing in culturen en managementstijl zal groter dan de clash in methoden. En nee ik weet dat ASL en BiSL geen methoden zijn. Ik probeerde wel de verschillende culturen te schetsen en dat was iets te kort door de bocht.
Maar als ik nu op de ISM- en FSMportal kijk, dan zie ik daar toch heel vaak woorden als processen, procesmodel, standaardmethode, passende processen etcetera staan. Weinig over mensen, houding, attitude en al die andere zaken waarvan het Agile Manifesto aangeeft wat nu echt de succesfactoren van een project zijn.
Wat mij betreft is DevOps de aanleiding om DOOR te gaan met het ‘agiliseren’ van organisaties. En dat doen we vooral vanuit wederzijds begrip.
@ErikBuitenhuis Ik zie Agile als een onderdeel van DevOps :-). Agile is voor mij de opmaat die binnen IT-Ontwikkeling is gestart naar het doorbreken van functionele silo’s. Daar is het in haar context ook gelukt. Maar de brug naar IT-Beheer is vaak nog steeds een brug te ver. Alleen maar een beheerder bij de demo’s toelaten en af en toe een documentje laten schrijven doet het voor mij niet. Overigens zie ik bij Agile juist een shift naar meer effectief werken (doen we het goede voor de business) dan naar efficient werken (doen we het goed in ons proces).
Ik zie Continuous Delivery ook als onderdeel van DevOps: het faciliteren van de technische randvoorwaarden om te komen tot het snel kunnen leveren van waarde voor de business. Ben het met je eens over Kanban boven Scrum. Volgens mij komen we qua mindset aardig overeen 🙂
Leuk verhaal. Een paar jaar geleden al wat verhalen over bedrijven als amazon, ebay, intuit enz. die al langer op deze manier werken. De grote kracht hiervan is inderdaad dat je heel snel in kunt spelen op de behoeften van de markt/klant.
Maar uiteraard is dit wel markt specifiek. Je architectuur zal toe moeten staan dat je bepaalde onderdelen snel in isolatie kunt ontwikkelen en testen, zonder dat de rest van het systeem daar hinder van zal ondervinden.
Maar ook het soort wijzigingen dat je op deze manier wil introduceren is bepalend. Het maakt nogal verschil of je een button verplaatst in een webapplicatie voor het bestellen van boeken (omdat mensen volgens de experts dan meer kopen) of dat je de user interface van een medisch systeem verandert, waardoor de arts niet meer even snel bepaalde gegevens kan achterhalen tijdens een behandeling.
Het kunnen (en willen) doorbreken van de functionele silo’s, zoals Anko weergeeft in één van de reacties is uiteraard ook heel belangrijk. Wat daarbij vooral van cruciaal belang is, is dat men elkaars werelden leert begrijpen. Hierbij maakt het niet uit of je scrum, agile, waterval of kanban gebruikt. Onlangs nog een mooi voorbeeld hiervan ervaren. De architect had een bepaalde manier van het bouwen van het product voor ogen. Hierbij zou altijd alles gebouwd worden, in plaats van alleen de gewijzigde module. Wat betreffende architect over het hoofd zag (door gebrek aan inzicht in de totale keten) is dat dit voor de mensen die de installatie in het veld moeten doe betekent dat een installatie 2 uur duurt in plaats van een kwartier. Dus het systeem van de klant moet langer “down”, upgrade in het veld kost meer tijd en is dus duurder enz. enz. Functioneel (één van de eerste silo’s) werkte zijn aanpak wel, maar aan de kant van beheer (één van de laatste silo’s) zagen ze zijn idee niet te zitten. (Wat Erik ook al aangeeft in zijn reactie).
Niet alleen silo’s moeten afgebroken worden, vooral ook de heilige huisjes van managers en/of techneuten die hun silo koste wat het kost in stand willen houden.
Ik heb het idee, dat bij de DevOps team, het plaatje nog niet volledig is. Het gaat erom: “om nog snellere responses te geven van IT op business wensen.”
Dus waarom halen we er niet in het team ook een business entiteit erbij, in de vorm van “echte eindgebruikers”. Dan is de “commitment” compleet.
Dus DevOpsBus.
De Business entiteit kan bepalen welke business functionaliteit echt noodzakelijk is, de Developers kunnen zien of het technisch haalbaar is en de complexiteit, en samen wordt bepaald welke bedrijfsprocessen en gebruikersgroepen ondersteund en getest gaan worden. Dus de gebruikers, die de business functionaliteit in kaart hebben gebracht, testen hun eigen business functionaliteit, die een bepaalde business case vertegenwoordigd. Verder hebben we dan ook meteen een directe communicatie tussen (eind)gebruikers en developers.
Alleen voor DevOps teams is het nog steeds een ICT feestje, terwijl we de ICT ondersteuning zijn van de business…
Is er een demo versie te kunnen gebruiken?