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.

Vraagstelling

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?

Aanpak

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.

Deel 1. Presentatie

Om de deelnemers een gefundeerde mening te geven is eerst het referentiekader rondom DevOps bijgespijkerd. De volgende onderwerpen Zijn hiertoe besproken.

1. Wat is de context van DevOps?
2. Wat is het DevOps concept?
3. Welke typen DevOps organisaties zijn te onderkennen?
4. Wat zijn DevOps drivers om de rollen te veranderen?
5. Welke verschuivingen van werk zijn zichtbaar in de markt?

1.1 Context

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.

1.2 DevOps concept

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.

DevOps proces

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).

Continuous Everything

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.

1.3 Type organisaties

Niet elke organisatie heeft gelijke behoeften aan DevOps. Er kan een onderscheid gemaakt worden in drie type:

1. Klein organisaties.
2. Middel grote organisaties.
3. Grote financiële instellingen.

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 graag 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

• Veel aandacht voor besparingen met Cloud (pipeline, PAAS, SAAS)
• Standaard oplossingen / Zero code applicaties (Mendix, Appian, …)

Ad 2. Middel servicebehoefte

• Veel aandacht voor korte TTM, focus op de business

Weinig aandacht voor Non-Functional Requirement (NFR) – waar zijn die belegd?

• Veel CMS en BI oplossingen voor SoE / SoI

Ad 3. Groot servicebehoefte

• Veel aandacht voor korte TTM, focus op de legacy systemen (SoR).
• Veel aandacht voor schaling van DevOps.
• Veel aandacht voor NFR maar dit blijkt erg lastig.
• Veel moeite om SoR ketens business values te laten leveren.
• Sterke standaardisatie door afhankelijkheid b.v. de pipeline.

1.4 DevOps drivers

De drivers die DevOps voortstuwen en organisaties disruptive laten veranderen zijn:

• Virtualisatie:
  • Infrastructure as Code.
  • Containers.
  • Verschuiving van (Ops à Dev).
• Cloud computing:
  • Schaalbaarheid.
  • Geen rekencentra / functies.
• Automatiseren:
  • Codeless programming.
  • Verlaging van applicatiebeheer en support.
• Integratie vakgebieden:
  • Shift left door integratie van requirement management, (BDD), test management (TDD) en change management (CICD).

1.5 Verschuivingen

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.

Deel 2. Nulmeting

Aan de deelnemers van de Ronde tafelsessie zijn vooraf de volgende stellingen voorgelegd:

• Stelling 1. Alles blijft hetzelfde
  • Er verandert toch niet zoveel, er is nog steeds een Servicedesk
• Stelling 2. Hanteer Lean
  • DevOps zie je alleen bij de grote IT bedrijven. Verder zie je nog steeds teams als: servicedesk, systeembeheer, netwerkbeheer, applicatiebeheer. Daar zijn de traditionele rollen nog steeds valide. Deze kun je prima verbeteren met een Lean aanpak.
• Stelling 3. Hanteer Automatisering
  • Zowel mensen, methoden als middelen worden op een efficiëntie en effectieve manier aan het werk gezet om business value op te leveren door deliverables voort te brengen door de traditionele ontwikkel-, test-, acceptatie- en productieomgeving waarbij vooral zo veel als mogelijk geautomatiseerd wordt. 
• Stelling 4. Kwaliteitsberoepen verdwijnen
  • Architecten, ITIL experts, risk managers, security manager en compliancy manager behoren tot de oude ambachten en beroepen met de komst van DevOps
• Stelling 5. DevOps mensen moeten alles kunnen
  • We hoeven geen geld te besteden aan kwaliteit managers buiten het DevOps team; met e-shaped DevOps engineers hebben we geen ITIL expert, risk managers,  security managers en compliancy managers meer nodig”.

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.

Deel 3. Workshop

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.  

3.1 Waarom DevOps of niet?

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:

• Kleinere klanten vragen standaard oplossingen.
• Klanten zoeken naar sturing, duidelijkheid en voorspelbaarheid.
• Er is geen business case voor DevOps.
• Adaptief en de markt in de gaten houden is genoeg.
• Ons bedrijf heeft geen DevOps karakter en heeft een lagenstructuur.
• Er zullen klanten zijn die dit niet gaan willen.

Waarom wel DevOps?
De argumenten die voor de DevOps introductie pleiten zijn:

• De wereld verandert.
• Grotere klanten willen graag DevOps.
• De interne organisatie knoopt steeds meer pakketten aan elkaar.

3.2 Welke Way of Working (WoW) is nodig?

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.

WoW zonder DevOps?

Tabel 1 geeft de verbeteringen weer om de toekomst tegemoet te zien zonder DevOps. Duidelijk is dat het procesmatig werken als leidend wordt beschouwd.

Tabel 1, Verder ontwikkelen zonder DevOps

WoW met 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.

Tabel 2, Ontwikkelingen om DevOps toe te passen

3.3 Waarin moet de organisatie voorzien?

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:

• Visie en strategie ontwikkelen.
• Aangeven waar we naartoe willen en aangeven hoe we daar komen?
• ITIL processen vormgeven.
• Coaching en training.
• Neem mensen mee in de verticalisering.
• Betrek iedereen erbij door sessie huidige gewenste situatie.

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:

• Strategie en duidelijke en tijdige communicatie.
• Management acceptatie van het hanteren van DevOps.
• Richting bepalen.
• Verandering in structuur en cultuur.
• Flow inrichten.
• Focus aanbrengen.
• Kennis op te mogen doen (training).
• Training.
• Coaching en automaterings tools.
• Werven klanten die willen experimenteren en opschalen

Tot slot

Dit artikel is gebaseerd op de uitspraken van 30 medewerkers van het casusbedrijf. Hierbij wil ik hen nadrukkelijk bedanken voor alle medewerking!

Related Books:

DevOps Best Practices, ISBN: 9789492618078
DevOps Architecture. ISBN: 9789492618061

Discussieer mee op LinkedIn.

-- Printbare PDF-versie --