Q
terug

Procesmanagement zorgt voor cohesie bij de toepassing van DevOps

Met de toenemende belangstelling voor DevOps ontstaat de vraag of daarmee procesmanagement overboord kan worden gezet. Een logische vraag gezien hetgeen DevOps nastreeft: een cultuur waarin de samenwerking tussen softwareontwikkelaars en andere IT-professionals wordt bevorderd, onder andere door zelfsturende multidisciplinaire teams en door de overgang van ontwikkeling naar productie zoveel mogelijk te automatiseren. Is er in deze nieuwe manier van samenwerking minder of juist meer behoefte aan processen?

Volgens de Nederlandse Wikipedia is een bedrijfsproces “een ordening van het werk dat uitgevoerd dient te worden in een organisatie.” Dat is niet de emotionele lading die bij veel medewerkers en hun managers aanwezig is bij het woord ‘proces’. Processen worden vaak ervaren als een synoniem voor bureaucratisch, log en verstikkend. Processen kunnen echter ook worden gebruikt om zaken te verhelderen, te versnellen en overzicht te creëren. Het moge duidelijk zijn dat waar voor de één ordening een zege is, is deze voor de ander juist belemmerend.

De Grote Vraag

De grote vraag is dan ook of DevOps meer, minder of wellicht een andere ordening van het werk vergt. Het laatste is het geval. Het speelveld verandert en daarmee de regels, maar deze verdwijnen niet. DevOps vergt op het oog minder ordening binnen de teams die gezamenlijk voor de ontwikkeling en het in beheer nemen van nieuwe applicaties zorg dragen. Men werkt lekker samen en heeft geen behoefte aan knellende afspraken. Aan de andere kant ontstaan er ook in de meeste DevOps-teams nuttige rituelen zoals dagstarts, het gebruik van scrumboards en de strikte regels waar ontwikkelsprints aan moeten voldoen, die een buitenstaander als proces zou kunnen kenschetsen. Ook het SAFe-model (http://www.scaledagileframework.com/) oogt als een geweldig procesdiagram.

Naast samenwerking binnen het DevOps-team zal er samenwerking nodig zijn tussen de teams. Wij verwachten dat voor deze samenwerking de klassieke ITIL-, ASL- en BiSL-frameworks nog steeds hun waarde zullen toevoegen. Wellicht worden ze wat minder nodig als teams minder afhankelijk van elkaar worden, maar bij afhankelijkheid zullen er spelregels nodig blijken. En ook de auditors van deze wereld, die namens klanten en aandeelhouders willen borgen dat er effectief wordt gewerkt, zullen procesafspraken en zekerheden verwachten om deze reden. Het is echter wel nodig dat er een simpel procesframework omarmd wordt waarin het hoogstnoodzakelijke zit en waarin zowel elementen gerelateerd aan de infrastructuur (ITIL), de applicaties (ASL) als de business (BiSL) verwerkt zijn. Processamenwerking over de gehele keten is namelijk gewenst.

Incident-, problem- en changemanagement

Laten we de kernprocessen van IT-servicemanagement – incident-, problem- en changemanagement – eens nader beschouwen. Deze processen zullen zonder nadere procedures binnen de DevOps-teams kunnen worden uitgevoerd. Incidenten worden op uur-, dag- of weekbasis binnen het team verwerkt en grote en veel terugkerende incidenten (de zogenaamde problems) worden op de backlog geplaatst om te worden opgelost. Bij de keuze voor livegang van een nieuwe release beslist het team of de release goed genoeg is. Tussen de teams zullen echter afspraken moeten worden gemaakt over die incidenten, problems en changes die meerdere teams raken. Ook die moeten respectievelijk op tijd worden opgelost zonder pingpongen, uitgezocht worden in multidisciplinaire teams en geverifieerd op de impact op elkaar, zodat de wijziging veilig in productie kan. Hier gaat wel een verschuiving optreden, waarbij we een aantal voorbeelden noemen:

  • minder incidenten als gevolg van inbouwen van kwaliteit bij de bron;
  • geautomatiseerd testen waardoor de impact op de omgeving van storingen wordt verminderd;
  • inzet van heuristische tools, die patronen herkennen, maakt het voor operations mogelijk om meer proactief en preventief te handelen;
  • inzet van tools die automatische de configuratie beheren.

Ook dit zal als gevolg hebben dat het belang van de operationele processen afneemt.

Conclusie

De invoering van DevOps zal dus zeker een effect hebben op zowel organisaties, die weinig of juist veel ordening hebben, als op de processen. Procesmanagement zal zorgen voor de cohesie in de organisatie bij de toepassing van DevOps. Bij de organisaties met weinig regels, die we vaak ‘immatuur’ noemen, zal DevOps eerst gebruikt worden om maar te vermijden dat er duidelijke afspraken tussen teams moeten komen. Maar om echt effectief te zijn, zullen ook zij onderling procesafspraken moeten gaan maken. Juist omdat in DevOps-teams het ook de taak is om de gezondheid van de beheerde dienst te onderhouden. De strak georganiseerde organisaties zullen bij de invoering van DevOps kunnen versnellen in de manier waarop klantwaarde wordt gecreëerd en m.n. de procesafspraken binnen de teams versoepelen. Dit kan vooral doordat de automatisering veel van die regels gaat uitvoeren. En laat dat nu de reden zijn waarom DevOps ook populair wordt: het automatiseren van het beheer-, test- en releasewerk.

Auteurs: Ronald Israels en Hans Smorenburg.

Tags
DevOps, IT Service Management