Sharing IT Best Practices with youSharing IT Best Practices with you
Deze vraag speelt een belangrijke rol bij een serviceverlener in Nederland op het gebied van systeembeheer en technisch applicatiebeheer. Van oudsher biedt dit bedrijf detachering van specialisten op het gebied van cloud services, managed services en infrastructuur beheer voor duizenden gebruikers en tientallen sub-locaties. Het antwoord op deze vraag is voorgelegd aan een dertig medewerkers in een ronde tafel sessie. Dit artikel geeft hun antwoord op deze vraag.
Waar de organisatie nu gebruikt maakt van rollen als projectleider, systeembeheerder en helpdesk medewerker gebruiken andere organisaties al termen als Scrum master, DevOps engineer en Agile coaches. De vraag is of deze vertrouwde rollen nu echt gaan verschuiven bij de serviceverlener (verder te noemen casusbedrijf). Wat kan het casusbedrijf hiermee, waar liggen de kansen en de risico’s voor de toekomst? Of is dit een hype?
Om een antwoord te krijgen op deze vraagstelling is Bart de Best gevraagd om een ronde tafelsessie te organiseren. De ronde tafelsessie omvatte drie onderdelen. Ten eerste is een nulmeting verricht aan de hand van 5 gesloten vragen. Deze meting is ook aan het einde van de sessie gehouden om de delta te bepalen. Het tweede gedeelte betreft een presentatie waarin achtergrond informatie is gegeven. De derde en laatste sessie betreft een workshop waarin de deelnemers gevraagd is om te kiezen uit twee stellingen en de keuze te onderbouwen. Dit artikel beschrijft eerst de presentatie. Daarna volgen de resultaten van de gesloten vragen en ten slotte wordt een beeld gegeven van de beantwoording van de stellingen.
Om de deelnemers een gefundeerde mening te geven is eerst het referentiekader rondom DevOps bijgespijkerd. De volgende onderwerpen zijn hiertoe besproken.
DevOps wordt vooral succesvol toegepast bij System of Engagement (SoE) en System of Information (SoI) oplossingen.
Figuur 1, DevOps karakteristieken.
Het DevOps concept is vooral snel gegroeid door de ontwikkelingen op het gebied van virtualisatie en cloud oplossingen.
Binnen de DevOps wereld wordt gestreefd naar de eliminatie van manueel werk (waste) en mensen die E-shaped zijn (multiple expertise). De karakteristieken van oplossingen waarbij DevOps veel gebruikt wordt zijn weergegeven in figuur 1.
Er bestaat geen definitie van DevOps. Het is een culturele beweging die leidt tot een betere serviceverlening. Wel zijn er wat beeldvormingen die DevOps wat tastbaarder maken. De Three Ways van Gene Kim is er één van. Hierbij wordt de DevOps organisatie in drie stappen vormgegeven. De eerste stap is het onderkennen van een value stream of flow. Dit zorgt dat het pad van requirement van de eindgebruiker tot en met een werkend systeem in productie wordt onderkend. De tweede stap is het verbeteren van de feedback in de value stream door veel eerder in de tijd de kwaliteit te meten en te verbeteren. Zo wordt 80% van de testinspanning in de ontwikkelomgeving verricht en worden de test cases geschreven voordat de sourcecode wordt geschreven, waaronder infrastructure as code. De laatste stap is het continual learning and expirimenting waarbij de kwaliteit van de serviceverlening geborgd wordt.
Een andere visualisatie is het DevOps proces zoals afgebeeld in figuur 2.
Figuur 2, DevOps proces.
De donkere stappen reflecteren Development (Dev) en de licht blauwe stappen Operations (Ops). Development omvat alle stappen van het plannen (requirements / backlog), coderen (unit testen, sourcecode en Infrastructure as Code), build (compileren), testen (systemtest, integratietest, gebruikeracceptatietest), release (om te deployen), deploy (uitrollen), operate (in de lucht houden), monitor (in alle stappen).
Het DevOps proces laat zich eenvoudig matchen met de capabilities (kennisgebieden) van DevOps.
De Agile processen zijn de ITIL processen die ontdaan moeten worden van waste (overhead). Agile Development is het proces waarbij een service wordt ontwikkeld waarbij gebruik wordt gemaakt van een Agile aanpak zoals Agile Scrum, Kanban, Feature Engineering, eXtreme Programming et cetera. De overige capabilities beginnen allemaal met ‘Continuous’. Dit woord duidt dat er constante aandacht is voor dit onderwerp waarbij vooral aan shift left gewerkt wordt. Shift left wil zeggen dat zo vroeg mogelijk in het ontwikkeltraject rekening wordt gehouden met kwaliteit.
Continuous testing
Testen moet zo vroeg mogelijk plaatsvinden. Zo worden unit test cases geschreven en uitgevoerd voordat de eerste code wordt geschreven (Test Driven Development).
Hierdoor worden fouten voorkomen en worden de gemaakte fouten sneller ontdekt.
Continuous integration
De samenvoeging van losse onderdelen van de service vindt hoog frequent plaats in de ontwikkelomgeving waardoor fouten eerder worden gevonden.
Continuous delivery
De uitlevering vindt hoog frequent in kleine delen plaats waardoor de impact en het risico drastisch worden verminderd. Hiertoe is automatisering van de ontwikkelstraat wel een vereiste.
Continuous monitoring
De monitoring vindt plaats in alle omgevingen en is overal gelijk qua instellingen. Dit is mede mogelijk doordat alle omgevingen (Ontwikkel-, Test-, Acceptatie- en Product omgeving) gelijk zijn aan elkaar. Tevens wordt niet alleen het product gemonitord maar ook de processen en de mensen (skills).
Figuur 3, DevOps capabilities.
Niet elke organisatie heeft gelijke behoeften aan DevOps. Er kan een onderscheid gemaakt worden in drie type:
Ad 1. Klein definitie
De nadruk ligt vaak of de interface naar de klant (System of Engagement). De organisatie is klein en heeft één of heel weinig teams. De integratie van de business en DevOps is meestal hoog door de lage graad van organiseren.
Ad 2. Middel definitie
Naast SoE is hier ook sprake van System of Information (SoI). De serviceorganisatie bestaat uit vijf of meer Devops teams. Er zijn specialisaties naar de business en naar techniek. De samenwerking van partijen moet nadrukkelijk gezocht worden.
Ad 3. Groot definitie
Naast SoE en SoI neemt de behoefte aan Sytem of Records (SoR) sterk toe. Organisaties opgedeeld in business units en clusters van tientallen DevOps teams. Er ontstaan ketens van informatiesystemen dwars door organisatie eenheden heen. Er is spraken van specialisatie naar
business en naar techniek. Infrastructure management / systeembeheer worden weggeautomatiseerd in externe of interne cloud oplossingen. Vaak is er nog een restant van een centrale operations die echter nog maar een kort bestaansrecht heeft.
Vraag naar services:
Ad 1. Klein servicebehoefte
Ad 2. Middel servicebehoefte
Weinig aandacht voor Non-Functional Requirement (NFR) – waar zijn die belegd?
Ad 3. Groot servicebehoefte
De drivers die DevOps voortstuwen en organisaties disruptive laten veranderen zijn:
Figuur 4 geeft de verschuivingen van werk die nu zichtbaar worden in de markt. De linker (rode) kant van de figuur geeft de werkzaamheden weer die in volume dalen of verdwijnen. De recht (groene) kan van de figuur geeft de type van werkzaamheden weer die in de plaats komen van de slinkende / verdwijnende werkzaamheden.
Figuur 4. Verschuivingen van werk in de markt.
Deze verschuiving van werk impliceert ook een verschuiving van vraag naar expertise gebieden. Figuur 5 geeft deze verschuiving weer.
Figuur 5. Verschuiving van expertise gebieden.
Het belangrijkste is feitelijk dat er van de klant een andere attitude wordt gevraagd om dit werk uit te voeren. Het gaat niet meer om expertise maar om flexibiliteit om de expertise te leren en de oude expertises op te geven. Dit wordt een steeds belangrijkere eis dan het opgebouwde cv.
Figuur 6. Verschuiving van attitude.
Aan de deelnemers van de Ronde tafelsessie zijn vooraf de volgende stellingen voorgelegd:
De resultaten van de initiële meting en eindmeting zijn weergegeven in figuur 7.
Figuur 7. Resultaten van de nulmeting.
De linker-as zijn het aantal deelnemers. De horizontale as zijn de vijf vragen. De ‘Ja’ antwoorden zijn blauw gekleurd (eerste twee bars) en de ‘Nee’ antwoorden zijn groen gekleurd (derde en vierde bars). Bij de eerste meting hebben 30 medewerkers meegedaan. Bij de tweede meting 23-24 medewerkers.
Stelling 1. Alles blijft hetzelfde
De meerderheid vindt dat DevOps de wereld veranderd. Het percentage dat dit wel vindt slinkt van 37% vooraf naar 13% achteraf.
Stelling 2. Hanteer Lean
De meerderheid vindt dat met Lean alleen je er niet komt. Het percentage dat dit wel vindt slinkt van 43% vooraf naar 10% achteraf.
Stelling 3. Hanteer Automatisering
Vrijwel iedereen is het er over eens dat automatisering erg belangrijk wordt en dat daarbij gewoon de bestaande werkwijze gebruikt kan worden. Dit aantal daalt na de presentatie van 80% naar 57% maar blijft toch nog de meerderheid.
Stelling 4. Kwaliteitsberoepen verdwijnen
Vooraf zijn weinig mensen overtuigd dat kwaliteitsberoepen verdwijnen (30%). Maar na de presentatie slaat dit geheel om en gelooft inderdaad de meerderheid dat we overstag moeten met deze functies (73%).
Stelling 5. DevOps mensen moeten alles kunnen
Vooraf vinden de meeste mensen dat DevOps medewerkers niet alles moeten kunnen (83%), maar dit beeld daalt drastisch na de presentatie (43%).
Al met al zijn de beelden sterk veranderd in gedurende de presentatie. Dit geeft weer dat de kennis en kunde van wat DevOps inhoud in dit casusbedrijf nog sterk in beweging is. Tevens is te zien dat veel medewerkers snel te overtuigen zijn van een andere mening. Dit betekent dat er in op korte termijn snel bijgesteld kan worden.
De belangrijkste uitkomsten van de ronde tafelsessie zijn de discussies en de daarin verwoorde meningen van de medewerkers van het casus bedrijf. Hiertoe zijn twee stellingen meegegeven. De eerste stelling is: De veranderingen zijn niet wereldschokkend voor de casusorganisatie en haar opdrachtgevers. We hoeven geen Agile of DevOps te omarmen in onze business. We moeten wel zaken verbeteren.
De tweede stelling is: De veranderingen zetten onze wereld op z’n kop. We moeten heel snel Agile of DevOps omarmen in onze business. Daardoor kunnen we de problemen van onze klanten oplossen.
De deelnemers is gevraagd om een argument te geven voor stelling één of stelling twee. Tevens is gevraagd hoe hier dan invulling aan te geven alsmede te benoemen wat van de casusorganisatie wordt verwacht om dit mogelijk te maken.
Waarom geen DevOps?
Deze stellingen zijn in groepjes beantwoord en gepresenteerd aan de gehele groep. De argumenten waarom DevOps niet nodig is vooral gelegen in de volgende meningen:
Waarom wel DevOps?
De argumenten die voor de DevOps introductie pleiten zijn:
Naast de keuze om DevOps wel of niet te omarmen is de vraag gesteld hoe de organisatie zich moet voorbereiden op de toekomst. Voor zowel met als zonder DevOps (stellen 1 en 2) zijn hiertoe antwoorden voor gegeven.
Tabel 1 geeft de verbeteringen weer om de toekomst tegemoet te zien zonder DevOps. Duidelijk is dat het procesmatig werken als leidend wordt beschouwd.
| People | Proces | Technology |
| Volg de klanten | Sneller leveren (TTM) | Hanteer standaard oplossingen |
| Leer mensen het standaard pakket te hanteren | Sneller feedback geven | Lever advies en maatwerk van kant en klare producten |
| Pas je aan de klant aan | Regel eerst de basis beheerprocessen in | Blijven door ontwikkelen |
| Verbeter waar het kan Verticaliseer de organisatie Organiseer ons per klant Begin klein eindig groot |
Tabel 1, Verder ontwikkelen zonder DevOps
Hoe moeten we met DevOps gaan werken? Wat moet er verbeterd worden. In tabel 2 is weergegeven wat de DevOps introductie van de casusorganisatie vereist. Duidelijk is de nadruk gelegd op de ontwikkeling van het mensaspect.
| People | Proces | Technology |
| Voeg teams samen | Stap voor stap keuzen maken voor de toepassing | Pas je aan de klant aan |
| Delen van kennis | Begin klein | Ontzorg de klant met DevOps |
| Cursus, kennissessies, workshops, eenduidige terminologie | Pak de regie | |
| Zelfsturende teams met gemengde competenties | ||
| Maak een DevOps team in de organisatie van de klant |
Tabel 2, Ontwikkelingen om DevOps toe te passen
Als laatste vraag die in de workshop is beantwoord is de deelnemers gevraagd aan te geven wat de casusorganisatie moet bieden om de verandering mogelijk te maken.
Wat moeten we zonder DevOps mogelijk maken?
Belangrijk is dat de medewerkers meer beeld willen hebben waar de organisatie heen wil, de spreekwoordelijke stip op de horizon. Ook het aanpassen van de organisatie en het betrekken van de medewerkers wordt belangrijk geacht.
De genoemde randvoorwaarden om de WoW zonder DevOps mogelijk te maken zijn:
Wat moeten we met DevOps mogelijk maken?
De vraag aan de organisatie om DevOps mogelijk te maken is ook weer gelegen in een duidelijke richting en tevens management commitment. Maar nu spelen vooral ook de cultuur en de mensfactor een belangrijke rol.
De genoemde factoren om DevOps te enablen zijn:
Dit artikel is gebaseerd op de uitspraken van 30 medewerkers van het casusbedrijf. Hierbij wil ik hen nadrukkelijk bedanken voor alle medewerking!
DevOps Best Practices, ISBN: 9789492618078
DevOps Architecture. ISBN: 9789492618061
Discussieer mee op LinkedIn. 
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.