Inbedden van DevOps

Inbedden van DevOps

Het gebruik van DevOps voegt als hulpmiddel waarde toe aan organisaties. DevOps-inzichten helpen de kloof tussen development en operations te overbruggen, maar het vraagt een goede voorbereiding. Een visie op het gebruik van DevOps is nodig, aansluitend op de strategie en doelen van de organisatie; de IT dient de business te ondersteunen. (Mijn artikel in vakblad Informatie)

De volgende vragen komen naar boven: Heeft DevOps alleen invloed op IT of raakt het de gehele organisatie? Welke organisatieverandering moet je doorvoeren? Welke cultuur en gedrag is er nodig voor DevOps?

Door: Job ten Hagen en Jan Heunks

Gepubliceerd in: vakblad Informatie nr 1, januari/februari 2016

DevOps ondersteunt waardeketen en IT-demand-supply-relatie.
Inbedden van DevOps in de organisatie.

Figuur 1 DevOps (Artikel Informatie 02-2016)

Figuur 1 DevOps (Artikel Informatie 02-2016)

DevOps spitst zich toe op IT-servicemanagement
en op het verbeteren
van de demand-supply-relatie. In
hetgeen hiervoor nodig is, de juiste
cultuur en attitude, zit de crux. De
nadruk ligt op communicatie, samenwerking en
integratie. Hieraan ontbreekt het in menig organisatie.
Veel leveranciers van IT-services worstelen
met de vraag: Hoe moeten we DevOps in de
praktijk inzetten? DevOps dient in ieder geval te
resulteren in een hogere klanttevredenheid. Dat
DevOps zich alleen op softwareontwikkeling richt
is een misvatting. De scope is IT-servicemanagement
(de combinatie van IT-technologie, mensen
en processen) waar software wel onderdeel van is.
De vraag is: Hoe kunnen organisaties de principes
van DevOps eenduidig en herkenbaar inbedden
zodat ze de juiste resultaten bereiken en de
business toegevoegde waarde bieden? Het is zinvol
om eerst de organisatorische inrichting onder
de loep te nemen, en daarna de DevOps-practices
en -technieken te implementeren. In de praktijk is
de werkrichting (nog steeds) voornamelijk andersom.
Het inrichten van DevOps heeft sowieso organisatorische
consequenties. Allereerst dient de
DevOps-filosofie gemeengoed te zijn (people factor)
en dient de organisatie (performance factor)
er klaar voor te zijn. Dit betekent niet dat perse
de organisatiestructuur (de hiërarchie) wijzigt,
maar het heeft wel consequenties voor de manier
van samenwerken, de organisatorische scope van
nieuwe projecten/services en dus ook voor verantwoordelijkheden.
DevOps kan het beste worden
beschouwd als een ‘mindset’ en in mindere mate
als een organisatiemodel of raamwerk. DevOps
vereist een andere manier van denken en werken.
Om dit in een organisatie te introduceren is verandermanagement
nodig.

Positionering DevOps
Muren zijn verhinderend

Rondom de informatievoorziening (IV) zijn
eilandjes gebouwd en daartussen muren gemetseld;
deze beperken de performance als geheel
(figuur 1). Een grote uitdaging is het effectief
laten landen van nieuwe of gewijzigde IT-services
vanuit de ontwikkelomgeving (development) naar
de exploitatie-/productieomgeving (operations).
Enerzijds levert development projectproducten op
die niet gereed zijn om als IT-service in beheer te
nemen en anderzijds ondersteunt operations de
ontwikkelomgeving onvoldoende bij het voorbereiden
van deze IT-services. Als gevolg hiervan
ondervinden serviceproviders in de praktijk
veel knelpunten bij transitie en inbeheername.
Transitie van nieuwe of gewijzigde IT-services
blijkt in de dagelijkse praktijk versnipperd over
vele afdelingen en processen (en zelfs meerdere
organisaties), zonder veel samenhang. Een juiste
organisatorische keteninrichting biedt de basis
voor een succesvolle transitie.
Het ontwerpen en plannen van de IV-functie en
het vervolgens ontwerpen en plannen van de
benodigde IT-services vindt in de regel op een gestructureerde
(projectmatige) wijze plaats. Dit
speelt zich af in een ontwikkelomgeving (development),
waarbij op basis van de informatiebehoefte
een informatieoplossing wordt gekozen. En separaat
een exploitatieomgeving (operations) waar de
uiteindelijke informatieoplossing, als onderdeel
van een informatiesysteem, beschikbaar wordt
gesteld voor gebruik. Figuur 1 geeft deze IV-regelkring
weer. Hierbij is er onderscheid tussen:
• De ontwikkelomgeving (development), waarbinnen
de informatieoplossing wordt gekozen en
vervolgens wordt ontwikkeld en geïmplementeerd
in een exploitatieomgeving.
• De exploitatieomgeving (operations), van waaruit
het uiteindelijke informatiesysteem (de informatieoplossing)
beschikbaar wordt gesteld voor
gebruik en wordt gemanaged en onderhouden.
De vraag is hoe de DevOps-mindset en -inzichten
een rol spelen in het optimaliseren van
deze regelkring. Daarvoor is het nodig om het
DevOps-concept IT-overstijgend en als onderdeel
van de waardestroom te zien.
De meeste grote organisaties hebben de integratie
van development en operations hoog op
hun agenda staan. Er wordt steeds meer voor de
DevOps-aanpak gekozen. Maar de DevOps-werkwijzen
worden helaas te vaak vanuit een IT-perspectief
uitgerold. Het blijft dan hangen in
sub-optimalisatie. Alleen als je DevOps vanuit de
waardestroom-optiek inzet, komt de waarde ervan
tot zijn recht.

Als succesfactoren gelden
goed leiderschap en het faciliteren
van de uitvoerende teamleden

Waardestroom
Bij de term DevOps wordt vaak gedacht aan de
kloof tussen development en operations, maar
een andere belangrijke relatie wordt daarbij over
het hoofd gezien: de relatie tussen business en IT
(business IT alignment). Deze bepaalt namelijk
in grote mate de gewenste DevOps-inrichting en
parallelle ambitie. Als de business een flexibele
(agile) IT-serviceprovider verwacht, dan worden
hiermee eisen aan deze IT-serviceprovider
gesteld. De verwachting van de business bepaalt
het ambitieniveau van de inzet van DevOps. Dit
gaat van het inzetten van een DevOps-transitieteam
om de samenwerking tussen development
en operations te stroomlijnen, tot het verregaand
automatiseren van releases en de monitoring
hiervan, waardoor development en operations feitelijk
integreren. Het gebruik van Lean IT maakt
dit mede mogelijk.

Figuur 2 DevOps (Artikel Informatie 02-2016)

Figuur 2 DevOps (Artikel Informatie 02-2016)

Lean IT
De integrale Lean IT-aanpak richt zich op het
maximaliseren van waarde voor de klant door het
minimaliseren van verspilling. Lean IT gaat over het
ontwikkelen en managen van de IT-omgeving,
die bijdraagt aan het maximaliseren van de klantwaarde
door het minimaliseren van verspilling.
Lean IT gaat ook over het continu verbeteren van
de te leveren IT-services. Er gelden twee kernwaarden:
vertrouwen en samenwerking.
Development en operations zijn in dit opzicht
belangrijk om gezamenlijk waarde toe te voegen.
Lean IT biedt een uitstekend ondersteunend
kader voor een gestructureerde aanpak van de
afstemmingsproblematiek tussen de business
(demand-organisatie) en IT (supply-organistie),
waarbij afstemming tussen development en operations
als voorwaarde geldt.
Bij Lean IT gaat het in het bijzonder om het creëren
van klantwaarde. Dit is alleen haalbaar als de
gehele organisatie bereid is om de Lean-filosofie
te ‘adopteren’. Vooral voor een interne traditionele
IT-afdeling is dit een lastig proces. De hedendaagse
rol van een regieorganisatie (richting en
opdracht geven aan de informatievoorziening en
de IT-ondersteuning) is hierbij een belangrijke
factor, zeker als het gaat om ketenintegratie. Lean
IT vraagt een integrale ketenbenadering (met als
doel ketenintegratie) en in lijn daarmee een alomvattende
aanpak over alle units en bloedgroepen
van de organisatie heen (systeemdenken).
In figuur 2 is de samenhang te zien tussen een
regiefunctie (demand) en een IT-serviceverlenende
organisatie. Development en operations
zijn belangrijke onderdelen van de organisatiebrede
waardestroom, waardoor toepassing van
DevOps-inzichten de hele keten mede helpen
verbeteren.

Demand-supply
De demand-organisatie heeft te maken met
allerlei business-/klantwijzigingen, vaak zelfs op
dagelijkse basis. De supply-organisatie is vaak
overbelast en daardoor is er maar al te vaak sprake
van gedrag dat wordt omschreven als reactief
crisismanagement. Constante verandering, wisselende
prioriteiten, nieuwe releases en upgrades
en de noodzaak om bestaande en opkomende
technologieën in balans te brengen en te houden.
Dit draagt allemaal bij tot een onhoudbare
mix van complexiteit, beweeglijkheid (motility),
duurzaamheid (sustainability), beperkingen (constraints),
onzekerheden (uncertainties) en risico’s.
Om het voorgaande te doorbreken dient de
demand-organisatie direct betrokken te zijn bij de
DevOps-inzet en als deelnemer in een eventueel
DevOps-team. De demand-organisatie definieert
hierbij wat de belangrijkste waarden zijn, en de
ondersteunende DevOps-werkwijzen en daaraan
ondersteunende IT-processen worden door de
supply-organisatie ontwikkeld en gemanaged om
deze waarden te leveren.

Ketenintegratie
Voor een effectieve inzet en gebruik van
DevOps-concepten is een totaalvisie op de gehele
keten noodzakelijk. DevOps is een manier van
werken die de tegenstrijdige belangen binnen
een organisatie bij elkaar laat komen. DevOps
is dus veel meer dan processen en techniek/
tooling; voor het slagen van DevOps in organisaties
is het belangrijk de koppeling te leggen met
de organisatiedimensie (performance factor) en
de gedrag- en attitude-dimensie (people factor).
Door de uitvoering binnen afdelingen in onderlinge
samenhang te regisseren worden zowel de
effectiviteit als de efficiency vergroot.

DevOps en organisatieverandering
Organisatievormen

Figuur 3 DevOps (Artikel Informatie 02-2016)

Figuur 3 DevOps (Artikel Informatie 02-2016)

In relatie tot het DevOps-kader worden drie
organisatievormen onderkend (figuur 3). Structuurdenken
is het denken in afdelingen en organogrammen,
ook wel aangeduid met silo-gericht
denken. Zie de linkerkant van figuur 3. De verticale
aansturing via directie en managers speelt hierbij
een belangrijke rol. Afdelingen zijn uitgegroeid
tot groepen met een eigen werkwijze en een eigen
cultuur. De afstemming van de werkzaamheden
vindt plaats via het managementteam.
In de jaren 80 van de twintigste eeuw is het
procesdenken toegenomen. Zie het middenstuk
van figuur 3. Procesdenken richt zich op de communicatie
tussen medewerkers, terwijl een te
realiseren resultaat zijn weg door de organisatie
vindt. Niet de formele structuur, het organogram,
maar de manier waarop medewerkers met
elkaar samenwerken staat centraal. Niet de eigen
afdeling, maar het te realiseren resultaat geeft hierbij
richting aan de werkwijze. De wijze waarop
IT-services bij veel organisaties worden geleverd,
is nauwelijks te handhaven omdat de huidige
complexe IT-processen niet optimaal ingericht
zijn op de roep vanuit de business om snelle en
flexibele IT. Door een (overwegend) silo-gedreven
manier van organiseren zijn IT-processen onnodig
complex, is de prestatiemeting onoverzichtelijk,
zijn houding en gedrag van medewerkers intern
gericht en is tooling te sterk gericht op de individuele
technologie. Dit staat haaks op de wens
vanuit de business waar men in toenemende mate
snelle levering van nieuwe functionaliteit wil, het
snel verhelpen van incidenten, korte communicatielijnen,
en IT van hoge kwaliteit.
Er is dus een mismatch tussen de traditioneel
ingerichte IT-serviceprovider en de business. Het
is daarom tijd om de opzet van IT-serviceproviders
fundamenteel te heroverwegen. In bovenstaande
ontwikkelingen kan de DevOps-aanpak een rol
spelen, zie rechterkant figuur 3. In een (virtueel) DevOps-
team worden medewerkers van verschillende
units ingezet. Deze afdeling overstijgende
inzet komt zowel vanuit de business, development
als operations. De samenwerking heeft als doel
resultaten te halen, door oplossingen flexibel
en snel te implementeren, zonder complexe en
niet-waardetoevoegende processen.

Er is een mismatch tussen
de traditioneel ingerichte
IT-serviceprovider en de business

De rol van DevOps
DevOps is ontstaan vanuit de noodzaak om
het leveren van IT-services behendiger te laten
plaatsvinden, in plaats van de twee betrokken partijen
(de ontwikkelaars en de IT-professionals) als
silo’s (separate lijnafdelingen) te zien die elkaar
dingen doorgeven maar niet echt samenwerken.
De aanpak is erop gericht dat IT-ontwikkelprojecten
en IT-servicemanagement (verantwoordelijk
voor de exploitatie van IT-services) geïntegreerd
en (bij voorkeur) geautomatiseerd samenwerken
met de juiste vertegenwoordiging vanuit de
demand-organisatie en er sprake is van (permanente)
multidisciplinaire teams. DevOps wil silo’s
doorbreken en geautomatiseerd samenwerken in
de keten.

Figuur 4 DevOps (Artikel Informatie 02-2016)

Figuur 4 DevOps (Artikel Informatie 02-2016)

DevOps in context
DevOps dient ondersteunend te zijn aan andere
door de organisatie gebruikte best practices en
raamwerken. De DevOps-mindset kan organisatiebreed
ingezet worden, maar er dient ook een
raamwerk te zijn dat kaders stelt en handvatten
geeft dat de scope van DevOps overstijgt. Voorbeelden
hiervan zijn ITIL 2011 Editie en COBIT5.
Een organisatie die processen gebaseerd heeft
op ITIL kan dan ook prima de DevOps-inzichten
adopteren en gebruiken; het sluit naadloos op
elkaar aan. In ITIL is er de Service Transition
levenscyclusfase, juist om de daaraan voorafgaande
fase Service Design en de daaropvolgende

fase Service Operation met elkaar in verbinding
te brengen (figuur 4). Voorwaarde is wel een
strategisch kader en een cultuur van continue
verbetering.
In de praktijk blijkt dat met een Agile-aanpak
veel aan snelheid en flexibiliteit wordt gewonnen,
vergeleken met de watervalontwikkeling. Een
groot voordeel is dat de gebruikers voortdurend
zelf ‘sturen’ op de door hen gewenste functionaliteit
en dit ook snel terugzien in productierijpe
resultaten. Het snel in productie nemen van functionaliteit(
en) en tegelijkertijd ook de impact en
frequentie van incidenten beperken is een volgende
stap. Hierdoor beschikken gebruikers ook snel
over deze functionaliteiten. Op dit punt wordt
vanuit een ontwikkelomgeving een ontwikkelde
informatieoplossing geïmplementeerd in een
(operationele) productieomgeving, van waaruit de
exploitatie plaatsvindt. Waar Agile zich primair
focust op de klant en op (IT-)vernieuwing, spitst
DevOps zich toe op IT-servicemanagement en op
het verbeteren van de demand-supply-relatie
Het generieke doel van DevOps is dat met Agile-principes
nieuwe of gewijzigde IT-services van
hoge kwaliteit worden opgeleverd, die voldoen
aan de managementnormen. De IT-services
worden (zonder veel overhead) in kleine releases,
gecontroleerd in productie genomen (nieuwe en
onderhoudsreleases door elkaar) met een minimum
aan verstoringen. Een groot voordeel is dat
ook de managers onderdeel zijn van de ontwikkelteams
en zorgen voor kennisoverdracht en het
toepassen van de managementnormen.
Komt hiermee het ITIL-raamwerk te vervallen?
Absoluut niet. DevOps is als aanpak en concept te
positioneren binnen het ITIL-raamwerk. In figuur
4 is aan de pijlen tussen de vijf ITIL-levenscyclusfasen
te zien dat er terugkoppeling (feedback)
respectievelijk betrokkenheid (involvement) is
tussen de verschillende fasen. De DevOps-context
sluit naadloos aan op de beoogde doelstellingen
van de ITIL-fasen Service Design, Service Transition
en Service Operation.
Het grote verschil in DevOps ten opzichte van
andere (management)aanpakken en best practices
is dat DevOps kan worden beschouwd als een
manier van denken, een mindset. Een inbedding
of gebruik van DevOps kan prima worden uitgevoerd
bij een organisatie die al verschillende
modellen en processen in gebruik heeft. De focus
daarbij ligt op het verbeteren en het optimaliseren
op basis van kwaliteit en klantwaardering. De
meerwaarde van DevOps zit in de wijze waarop
het in de praktijk wordt toegepast.

Figuur 5 DevOps (Artikel Informatie 02-2016)

Figuur 5 DevOps (Artikel Informatie 02-2016)

Een praktische start
In de praktijk blijkt volledige inbedding van
DevOps-inzichten voor veel IT-serviceproviders
een brug te ver. Een stapsgewijze verandering kan
het beste kleinschalig beginnen met de inzet van
een transitieteam (figuur 5). In de initiële fase
van een DevOps-(volwassenheids)traject helpt
een transitieteam de kloof tussen development en
operations te verminderen. Dit kan een afdeling
zijn, naast development en operations, maar het
kan ook een virtueel team zijn met verschillende
bloedgroepen, waar ervaring in de samenwerking
wordt opgedaan.
Zoals eerder aangeduid staan er tussen ontwikkeling
en beheer ‘muren’. In de dagelijkse werkzaamheden
ervaart men een kloof en blijft de  juiste implementatie
van hetgeen is ontwikkeld
onderbelicht of achterwege. In een evolutionaire
benadering biedt het zogeheten transitieteam
veelal verlichting. Dit (virtuele) team pakt transitietrajecten,
inclusief inbeheername, professioneel
op en het zorgt voor een adequaat transitieproces
vanuit ontwikkeling richting beheer.
Het team gebruikt bijvoorbeeld de ITIL best
practices uit de levenscyclusfase Service Transition
(maar ook uit Service Design en Service
Operation). Service Transition is hierbij zo ingericht
dat het de gehele bouw(samenstelling) en
implementatie voor zijn rekening neemt. Service
Design ontwerpt en ontwikkelt deelproducten die
Service Transition zonder aanpassingen als basis
voor de samenstelling van changes/releases en
implementatie van de eindproducten gebruikt.
Service Operation ontvangt uiteindelijk kant-enklare
producten, die het dagelijkse beheer zonder
problemen opneemt. Dit alles vanuit een gemeenschappelijke
teamverantwoordelijkheid.

DevOps is geen technische
methode maar een mindset

In het team acteren (deeltijd) medewerkers uit
development- en operations-afdelingen en bij
voorkeur ook vanuit de business, waardoor nauwer
samen wordt gewerkt. Conform ITIL 2011
Editie is het transitieteam vooral gericht op de
organisatorische transitieaspecten, zoals de services,
processen en mensen. Het team speelt pas
een rol wanneer de servicecatalogus wijzigt. Alle
nieuwe IT-services en grote wijzigingen aan een
IT-service worden via Service Transition door het
transitieteam begeleid voor implementatie binnen
beheer.
De organisatievorm met een transitieteam, als
afdeling binnen development of operations, of
als virtueel team, kan een eerste stap zijn naar
een DevOps-ideaalmodel. Dit is een suboptimale
oplossing maar wel een die voor veel IT-serviceproviders
haalbaar is. Door het transitieteam kan
de complexiteit uit DevOps worden gehaald.

DevOps en de medewerkers
Gedrag en attitude
In de voorgaande paragrafen is verduidelijkt wat
consequenties zijn voor de wijze van organiseren.

Zijn we net van structuurdenken naar procesdenken
geëvolueerd, nu gaat het om teamdenken.
Eigenlijk is dit een logisch vervolg op het procesdenken.
Het gaat om de navolgende twee basisfactoren:
• De harde kant die te maken heeft met het verbeteren
van processen: de werkstructuur.
• De zachte kant die te maken heeft met het aanpassen
van de organisatiecultuur.
Deze twee factoren zijn belangrijke uitgangspunten
van Lean IT. In lijn hiermee dient een groot
deel van de verantwoordelijkheid op het operationele
niveau te liggen. Het managementteam
speelt vervolgens een actieve rol als sponsor,
maar dient wel te beseffen dat de daadwerkelijke
verbeteringen en verantwoordelijkheden binnen
het operationele lijnmanagement, en in het
bijzonder bij de medewerkers op het operationele
niveau ligt. In veel gevallen zijn dit al aanwezige
procesmanagers. Dit vraagt in veel supply-organisaties
een forse omslag in managementstijl
en cultuur. Supply-organisaties die veel waarde
hechten aan de organisatiestructuur, of waarbij de
medewerkers veel waarde hechten aan de positionering
binnen de organisatiestructuur, dienen er
rekening mee te houden dat dit veel vraagt van de
wijze van aanpak, de communicatie en de ambitie.
De veranderkracht van een supply-organisatie (als
IT-serviceprovider) is van groot belang. Het gaat
over slagvaardigheid en het hebben van de juiste
competenties.

Succesfactoren
Het succes van DevOps is voor een groot deel
afhankelijk van menselijke factoren en een omslag
in de cultuur. Dit naast een belangrijke, aanvullende
factor: communicatie. Het DevOps-concept
is een totaalvisie op de gehele keten, van het
starten van het ontwikkelproces tot en met het
in productie gaan. Het is een manier van werken
die de tegenstrijdige belangen van ontwikkelaars
en technische specialisten binnen een organisatie
bij elkaar laat komen. De werkwijze is, zoals
het acroniem al wel doet vermoeden, niet alleen
voor ontwikkelaars en operationeel medewerkers
(developers en operations). Het is bedoeld om
multidisciplinaire teams te faciliteren, zodat ze de
verantwoordelijkheid nemen voor het resultaat en
de toegevoegde waarde voor de business. DevOps
is een multidisciplinair fenomeen waarbij geldt
dat geen enkele IT-vaardigheid belangrijker is
dan de andere. Om problemen te voorkomen zijn alle
vaardigheden nodig. Wanneer teams worden
gebouwd rond medewerkers die zowel de rol van
bijvoorbeeld ontwikkelaar, tester als system administrator
aannemen, worden bijzondere teams
gebouwd.

Lean management
Lean management zorgt ervoor dat verbeteringen
in de processen binnen een organisatie in een
beheersbaar, gesynchroniseerd tempo verlopen en
gericht is op het leveren van klantwaarde. Klantwaarde
wordt bereikt door mensen, processen
en technologie; in die volgorde. Ook bij DevOps
heeft de kern van de problematiek te maken
met de afstemming en overeenstemming tussen
de bedrijfsdoelstellingen en de IT-eisen van de
organisatie.
De traditionele manier van managen geeft in ieder
geval geen enkele garantie voor de juiste aandacht
of ondersteuning. Indien er namelijk geen concrete
actie wordt genomen op het veranderen van de
wijze waarop de teams, processen en medewerkers
worden gemanaged, dan slaagt ook het ‘invoeren’
van DevOps hoogstwaarschijnlijk niet.
Het vereist de juiste ondersteuning en het juiste
leiderschap om de medewerkers te stimuleren
mee te werken aan, en mee te denken over de
continue verbetering van DevOps-teams, de aanpak
en de ondersteunende IT-processen die echt
waarde toevoegen voor de klant. De benodigde
managementaanpak om dit te bereiken betreft
Lean management. Hierbij wordt gebruikgemaakt
van diverse hulpmiddelen en technieken om het
doel, het leveren van waarde aan de klant, aan te
laten sluiten op de processen en de medewerkers.
Hulpmiddelen en technieken zijn op zichzelf nog
niet effectief; alleen met de juiste mentaliteit
(mindset) van alle betrokkenen in de organisatie
hebben de hulpmiddelen en technieken pas echt
effect. Maar om de mindset van de medewerkers
én hun managers op hetzelfde niveau te brengen,
vergt veel investering. Bij voorkeur wordt een
startpunt voor een transformatie vastgesteld. De
bepaling van het volwassenheidsniveau is hierbij
behulpzaam en geeft een afgebakend startpunt
voor verandering.

Figuur 6 DevOps (Artikel Informatie 02-2016)

Figuur 6 DevOps (Artikel Informatie 02-2016)

Automatiseren
Om een hogere volwassenheidsfase te bereiken
dient men zover te zijn dat een groot deel van de
relatie tussen development en operations wordt
geautomatiseerd. Let wel: dit is geen doel op zich
maar een hulpmiddel. DevOps is geen technische
methode maar een mindset. Om de hoog geautomatiseerde
relatie heen dient een effectieve PDCA
(plan, do, check, act) plaats te vinden waarin de
DevOps-cultuur gemeengoed is. In DevOps is een
aantal kernaspecten bijeengebracht:
1. Continuous integration (continue integratie):
Dit verwijst naar het integreren, bouwen en
testen binnen de ontwikkelomgeving. Continuous
delivery bouwt hierop voort en betreft de laatste
benodigde fasen voordat inzet naar productie
plaatsvindt.
2. Continuous delivery (continue levering): Dit
verwijst naar het in staat zijn om frequent implementaties
te doen, of te kiezen om dat niet te
doen. Dit is meestal gebaseerd op de voorkeur van
de organisatie om met een lager tempo te implementeren.
3. Continuous deployment (continue inzet): Dit
verwijst naar iedere wijziging die door de pijplijn
gaat en automatisch in productie wordt genomen
op het moment dat deze klaar is. Dit resulteert
in veel implementaties per dag. Voor continuous
deployment geldt als grondslag continuous
delivery. Continuous deployment is de volgende
stap van de continue levering en dient dan ook
het doel te zijn van de meeste bedrijven die niet
worden beperkt door wettelijke of andere vewreisten.
Het gebruik van continuous deployment dient
in ieder geval gebaseerd te zijn op de bedrijfsbehoeften.
Continuous delivery is een randvoorwaarde voor
het gebruik van DevOps. Pas wanneer er sprake is
van (automatische) continuous delivery kan erop
worden vertrouwd dat wijzigingen waarde leveren
voor de klant, binnen een korte tijdspanne nadat
de wijziging wordt vrijgegeven (figuur 6). De
voorwaarde ligt in een organisatie die hier ook
klaar voor is, met de juiste cultuur en het juiste
gedrag.

Job ten Hagen is interim-consultant
en eigenaar van Ten Hagen Consulting.
Hij is in 2015 DevOps gecertificeerd via het DevOps
Institute. Hij heeft meer dan twintig jaar ervaring als
consultant in het ontwerpen en verbeteren van (IT-)
organisaties en processen bij klanten. Hij is expert in
informatie- en servicemanagement (demand-supply) en
gecertificeerd in het toepassen van best practices. Zorgt
als adviseur en verandermanager op een initiatiefrijke
en analytische wijze voor ontwerp en transformatie van
organisaties en processen.

Literatuur
- Kim, G., Behr, K. & Spafford, G. (2014). The Phoenix Project:
A Novel About IT, DevOps, and Helping Your Business
Win.
- Heunks, J. (2014). Lean IT, Theorie en praktijk van Lean in
een IT-omgeving. Van Haren Publishing.
- Hagen, J. ten (2012). Designing and transforming IT
organizations. TSO.