De opkomst van de combinatie van DevOps en agile applicatieontwikkeling is onmiskenbaar. Executives doen er verstandig aan stil te staan bij de consequenties die dit heeft voor outsourcing. Strategische uitgangspunten ten aanzien van verkaveling en wijze van contractering van infrastructuurdiensten en applicatieontwikkeling zijn bijvoorbeeld anders – en dat heeft consequenties voor zowel uitbesteders als dienstverleners. Dit artikel gaat dieper in op de impact en biedt concrete handvatten. De combinatie van DevOps en agile applicatieontwikkeling is aan een flinke opmars bezig. In de huidige markt kunnen de meeste organisaties het zich niet meer permitteren om software op te leveren die klanten niet aanstaat, die vol met fouten zit of te laat wordt opgeleverd. DevOps brengt hier verandering in door de traditionele scheidslijn tussen ontwikkel- en beheerteams te doorbreken. Waarbij met behulp van agile ontwikkelmethodieken in veel kortere cycli (sprints) nieuwe functionaliteit wordt ontwikkeld en opgeleverd, op nieuwe technische platformen zoals containers en hyper-converged infrastructuur. Deze combinatie heeft de mogelijkheid om meer waarde toe te voegen aan de bedrijfsprocessen van haar klanten. In termen van hogere kwaliteit, korte time-to-market en optimalisatie van de total cost of ownership. Om hiervan te profiteren moeten IT-managers bereid zijn hun huidige organisatorische vorm uit te dagen, zelfs als het betekent dat hun ‘rijk’ kleiner wordt of drastisch verandert. DevOps is een neologisme, gevormd uit Development en IT-operations. De nadruk ligt op communicatie, samenwerking – tussen opdrachtgevers, softwareontwikkelaars en IT-beheerders – en integratie, waarbij het put uit het gedachtegoed van agile en lean IT. Het mag niet verbazen dat de opkomst van DevOps in combinatie met agile applicatieontwikkeling (verder in dit artikel voor het gemak aangehaald als ‘DevOps’) ook voor outsourcing de nodige consequenties heeft.
Impact op verkaveling
DevOps heeft grote invloed op de verkaveling die tijdens de vaststelling van de sourcingsstrategie wordt bepaald. Deze sourcingsstrategie is in kwalitatief en financieel opzicht alleen toekomstbestendig als de IT-diensten, -applicaties en -infrastructuur volgens een doordachte verkaveling worden in- en uitbesteed, met enterprise-architectuur als meetlat. Veel grootzakelijke organisaties en overheidsinstellingen hebben van oudsher voor een ‘stovepipe’-verkaveling gekozen, op zoek als ze waren naar schaalvoordelen en een eenduidige architecturele afbakening van verantwoordelijkheden. Bij deze horizontale verkaveling zijn applicatieontwikkeling, applicatiebeheer en infrastructurele diensten (hosting) vaak in drie kavels gescheiden en bij verschillende leveranciers ondergebracht en worden aansluitend de kavels servicedesk, werkplek, en security & connectivity onderkend. Het technisch applicatiebeheer werd veelal belegd bij de infrastructurele dienstverlener, om met die leverancier end-to-end applicatiebeschikbaarheid te kunnen contracteren. De gang van een nieuwe applicatierelease van de applicatie- naar de infrastructuurleverancier werd ‘betegeld’ met formele gateways. Dit was nodig, wilde de laatstgenoemde leverancier de applicatiebeschikbaarheid kunnen garanderen en zijn bonus-malusregeling niet aangetast zien worden. En zo wachtte de klant soms maanden op de nieuwe release…
Teams
DevOps en agile doorbreken deze traditionele stovepipedemarcatie tussen ontwikkeling en beheer, applicaties en infrastructuur. DevOps wordt vooral toegepast in innovatieve omgevingen waar kortcyclische verandering voor de business wenselijk is. Denk aan hoge concurrentiedruk, een groeimarkt, hoge zichtbaarheid of een grote bedrijfsdynamiek. In stabiele legacyomgevingen wordt de watervalmethode gehandhaafd. Een grote organisatie zal dus waarschijnlijk zowel traditionele waterval- als DevOps-teams kennen. Een moderne product- en dienstencatalogus moet inzet van beide, naast elkaar, vergemakkelijken. DevOps brengt een verticale verkaveling (‘value stream’) met zich mee. Dat heeft consequenties voor de inzet van DevOps-teams, waarop we hierna zullen ingaan.
Business-systemteams
DevOps pakt applicatieontwikkeling en -beheer, databases en middleware integraal aan, per functioneel georiënteerd domein (een ‘value stream’). Outsourcing in deze gebieden gebeurt middels levering door zelforganiserende, multidisciplinaire teams, door middel van scrums. De leden van deze teams dragen gezamenlijk de verantwoordelijkheid voor levering van het resultaat. In het team zit in ieder geval een productowner die als opdrachtgever verantwoordelijkheid draagt voor het functionele resultaat. De scrummaster is verantwoordelijk voor het proces, de snelheid van oplevering, het bieden en houden van overzicht en reflectie. De opbouw van de competenties van het team is grafisch weer te geven als een ‘T’, oftewel het team is ervaren, er zitten veel competente teamleden in. Leden kunnen over hun eigen vakgebied heen kijken. Architecten sturen hierbij op het afbetalen van technical debt Dit laatste ontstaat veelal door organisch gegroeide ontwerpen en bouw met veel druk (‘fix now, pay later’), waardoor werd afgeweken van architecturele standaarden, interfaces et cetera. Technical debt kan zeer verlammend werken, waardoor de gewenste snelheid in sprints niet gehaald wordt.
‘You built it, you run it’
Het technisch applicatiebeheer (databasemanagement, middleware), traditioneel vaak bij de infrastructuurleverancier belegd, komt idealiter ook onder de paraplu van het business-systemteam, onder het motto ‘you built it, you run it’. Al zien we in de praktijk ook de variant dat deze activiteit nog in handen is van het platformteam, dat dan het lifecyclemanagement van de gehele technische stack tot en met de middleware verzorgt. Tegenwoordig zetten teams daarvoor eventueel containers en hyper-converged infrastructuur in. Het business-systemteam maakt natuurlijk gebruik van sterk gestandaardiseerde infrastructurele platformdiensten (de technische stack). Deze platformdiensten worden geselecteerd op basis van hun waarde voor dit team. Traditioneel worden de meeste bedrijfsapplicaties gehost vanuit een private-clouddienst; ontwikkel- en testomgevingen maken vaker gebruik van public-clouddiensten. Een verschuiving is duidelijk zichtbaar: ook voor productieomgevingen worden vaker public-clouddiensten ingezet.
Uitgangspunten DevOps
Wanneer DevOps-teams, vaak samengesteld uit interne en externe medewerkers, hecht gaan samenwerken met opdrachtgevers om continu middels agile applicatieontwikkeling functionaliteit op te leveren, is dat een compleet andere manier van sourcen dan, zeg, het offshoren van grote watervalprojecten. DevOps-teams hangen de volgende uitgangspunten aan.
- Customer centric action: korte feedbackloops met echte klanten en eindgebruikers; alle ontwikkelactiviteiten draaien om de klant.
- Create with the end in mind: vermijden van waterval- en procesgeoriënteerde modellen, waarbij alleen vanuit de eigen rol of functie wordt gewerkt en het geheel uit het oog wordt verloren.
- End-to-end responsibility: DevOps-teams zijn verticaal georganiseerd, zodat ze verantwoordelijk zijn van concept tot het einde van de levenscyclus, ‘from concept to grave’. IT-producten en -diensten die door het team zijn gebouwd en opgeleverd, blijven onder beheer van dat team. ‘You build it, you run it’, is het motto.
- Cross-functional autonomous teams: als teams verticaal georganiseerd zijn en verantwoordelijk voor de gehele levensfase van een product of dienst, moeten ze ook autonoom zijn.
- Continuous improvement: het accent ligt op continu verbeteren van producten en diensten. Uiteraard om de kwaliteit daarvan zo hoog mogelijk te krijgen, maar ook om waste te minimaliseren – hier zien we het lean-gedachtegoed terug – en snelheid, kosten en het leveringsgemak te optimaliseren.
- Automate everything you can: automatisering waar en wanneer mogelijk is een gevolg van het streven van het team om de levering van zijn diensten steeds te vernieuwen en te verbeteren.
Platformteam
Het platformteam biedt een gestandaardiseerde omgeving aan. Die bestaat bij voorkeur uit PaaS-containers, maar IaaS is een bruikbaar alternatief. Deze omgeving is aan te vullen met opties voor orkestratie van het cloudmanagementplatform, wanneer gebruikgemaakt wordt van public-cloudvoorzieningen. Het bewaken van standaardisatie is een belangrijke taak voor dit team. Uitzonderingen leiden immers tot fouten, moeten afzonderlijk beheerd worden en kosten dus geld. Om dezelfde redenen staat ook ‘automatiseren waar mogelijk’ steeds op de agenda. Omdat het business-systemteam op basis van selfservice met infraomgevingen werkt, is nauwkeurige kostenallocatie onmisbaar. Dat bevordert het netjes opruimen van de omgeving na gebruik, zodat de teller niet blijft lopen. Om een goede samenwerking mogelijk te maken, heeft het platformteam een vertegenwoordiger in het business-systemteam, geheel in de spirit van DevOps. Dit heeft tevens als doel een nauwkeurige afstemming met het sprintritme van het business-systemteam te garanderen, zodat uiteindelijk oplevering van nieuwe functionaliteit zonder wachttijden (‘single piece flow’) binnen bereik komt. Met de adoptie van DevOps heeft de servicecatalogus wat verse ingrediënten nodig, zoals nieuw gereedschap om het leven van het DevOps-team te vergemakkelijken. Denk aan een selfserviceportal, tools voor continue integratie van systemen, geautomatiseerd testen, geautomatiseerde implementatie en geautomatiseerde levering. Hiermee worden standaarden voor de OTAP-straten afgedwongen, om de technical debt vanuit het platformteam zover mogelijk te beperken. Je kunt hierbij denken aan achterblijvend patchmanagement.
Contractering van DevOps en agile sourcing
De impact op de verkaveling en de teamfocus is duidelijk. Wat betekent dit dan voor de contractering? Willen organisaties recht doen aan DevOps en agile, dan zullen ze op een andere manier moeten contracteren. Het belangrijkste is de verschuiving van closed scope contractering naar open scope waarmee vernieuwing en beheer in dezelfde samenwerking een plek moet krijgen. DevOps-teams kunnen überhaupt niet makkelijk uit de voeten met de gebruikelijke manier van contracteren. DevOps in combinatie met agile applicatieontwikkeling kent geen vaste scope, een andere verkaveling, richt zich op waardegeneratie en beweegt mee met de inzichten van de klant. Leg dat maar eens naast de traditionele kaveldefinities en uitgebreide beschrijvingen van functioneel en technisch ontwerpen, resultaatgerichte dienstbeschrijvingen, verantwoordelijkheden en tools. Die manier van werken gaat uit van een min of meer statische situatie en een gecontroleerd proces, niet van een continu veranderende markt, waarop de klant vandaag wil inspelen. Wie wereldkampioen Formule I wil worden, kan onmogelijk van tevoren zijn race uittekenen en zal tussen de races door zijn auto moeten aanpassen. Dit is wel een fundamenteel punt. We reiken enkele handvatten aan.
Figuur 1. De kegel van onzekerheid
Business-systemteams
Wie succesvol in sourcingspartnerships wil zijn, definieert de relatie met gebruikmaking van de ‘kegel van onzekerheid’, zie figuur 1. In de basis nemen opdrachtgever en opdrachtnemer uiteindelijk altijd een eigen positie in bij contractering van dienstverlening. Deze positie wordt onder meer bepaald door de mate van onzekerheid die men voelt. Die mate van onzekerheid is te bepalen aan de hand van vier vragen.
- Wie draagt welke risico’s (bedrijfsvoering, sociaal, financieel, time-to market, technisch)?
- Welke scope kan worden gecontracteerd, waarbij de agile businesscase wordt gewaarborgd?
- Wat is een redelijke aanneemsom gegeven de hoeveelheid werk?
- Wanneer en hoe gaan we akkoord bij aanpassingen van de scope?
Als het gepercipieerde risico hoog is, maakt onzekerheid dat de klant en leverancier het niet snel eens worden over een aanneemsom. Bij een hoog risico reserveert een leverancier op voorhand een hoge risicomarge (mark-up of contingency), vooruitlopend op de onderhandeling. Vanuit klantperspectief is dit een onwenselijke uitkomst. Anderzijds geeft een contractering op basis van time & materials vaak een ‘blanco-chequebeleving’: de opdrachtgever draagt alle risico’s. Dit dilemma kan resulteren in een ongebalanceerde contractering en zorgt voor onwenselijk gedrag in de beoogde samenwerking tussen klant en leverancier (onderhandeling in plaats van samenwerking).
Fasering
We stellen voor om de agile contractering te faseren aan de hand van de kegel van onzekerheid.
- Indien de onzekerheid hoog is of het wederzijds vertrouwen laag, is het raadzaam dat partijen zich in bijvoorbeeld de eerste drie sprints aan kleine initiatieven committeren. Er worden KPI’s afgesproken en de klanttevredenheid wordt gemeten. Maar de eindafrekening vindt plaats op basis van time & materials. De samenwerking krijgt de gelegenheid om te groeien, in de eerste sprints ontstaat vaak een duidelijke productvisie, de eerste ontwikkelprioriteiten worden duidelijk (visueel weergegeven in de eerste productbacklog). Tevens verbetert in de eerste sprints de snelheid van levering van het business-systemteam. Nota bene: soms wordt deze eerste fase door de klant uitgevoerd met meerdere leveranciers om uiteindelijk de voorkeursleverancier te selecteren. Soms vindt dit plaats in een ‘snelkookpan’, de bekende hackathon.
- Na deze verkering wordt het tijd voor de verloving: een agile contractering. De onzekerheid is immers afgenomen, de samenwerking al beproefd. In deze tussenperiode – zeg tussen sprint 4 en 12 – wordt een performancebonus geïntroduceerd. Het team wordt voor 70 procent nog gefinancierd door middel van time & materials. Voor de overige 30 procent worden resultaatgerichte afspraken gemaakt met betrekking tot klanttevredenheid, technical debt en teamvelocity. Aanvullende bonusafspraken zijn ook een optie, waardoor de leverancier bijvoorbeeld uiteindelijk 110 procent kan verdienen. Doel is om ervaring op te bouwen met KPI’s en de bijsturing die hierbij hoort.
- Uiteindelijk wordt het voor het ervaren, volwassen DevOps-team tijd om in het huwelijksbootje te stappen: de DevOps-contractering. Na 12-15 sprints kan de contractering volledig (100 procent) gebaseerd worden op basis van performance-afspraken als klanttevredenheid, technical debt, beschikbaarheid, lead time for a change, aantal incidenten per release (norm = 0), productiviteit/burndown measurement. Maar ook een team happinessindex mag niet ontbreken.
De DevOps-contractering is een vorm van contractering waar klant en leverancier samen naartoe zijn gegroeid. Overigens zijn KPI’s direct gerelateerd aan de business in opkomst als directe vertaling van businessvalue. Voorbeelden uit de praktijk zijn het verkorten van de doorlooptijd van een businessproces, stijging van conversieratio’s (van lead naar klant) en verhogen van de net promotor score.
Platformteam
In het infrastructuurdomein verandert qua contractering niet veel, afgezien van uitbreiding van de servicecatalogus met allerlei tooling en metering. Dit wordt onderdeel van een integraal dashboard, dat ook volledig zichtbaar is voor de business-systemteams. Bij utilityinfrastructuur geldt een prijs per eenheid, volledig afhankelijk van het gebruik, de technologie en de zwaarte van de desbetreffende utility. Die is dus maximaal op en af te schalen op basis van een stuksprijs, zonder toepassing van prijsbandbreedtes of gegarandeerde afnamevolumes. Tevens wordt voor infrastructurele projecten een tariefkaart per profiel/per manuur gecontracteerd, op basis waarvan het mogelijk is infrastructurele projecten met vaste prijzen te calculeren. Voor tooling geldt een aparte vergoeding, soms per corporatelicentie, soms per gebruiker. Soms zijn de kosten al onderdeel van de utility die wordt afgenomen. Vanzelfsprekend zijn hier financiële drivers op hun plaats, om de gezochte standaardisatie te kunnen afdwingen. In de transitie- en transformatiefase zien we nog steeds vaak vaste prijzen per subproject, voor migraties, transformaties, overgang van personeel, harmonisatiekosten en dergelijke.
De SLA
Wat betekent dit alles voor de SLA? Die gaat er beslist anders uitzien. We gaan naar zogenoemde business-systemteam-SLA’s, met compleet andere uitgangspunten. DevOps draait om het creëren van duurzame klantwaarde op basis van een open, te veranderen scope, in tegenstelling tot de gesloten scope van traditionele SLA’s. Het accent ligt met DevOps veel meer op minimalisatie van de time-to-market van nieuwe features, de bijdrage aan end-to-end business-KPI’s, minimalisatie van de mean time to repair & to recover en de opgedane technical debt. Maandelijkse rapportages zijn eigenlijk achterhaald, het realtime monitoren is de norm. Als er dan toch wordt gerapporteerd, dan is deze rapportage veel ‘lichter’ en frequenter dan bij het uitvoerige, maandelijks ‘achteromkijken’ dat bij de traditionele SLA gebruikelijk is. Een maandelijkse rapportage bij een sprintritme van twee weken loopt immers twee iteraties achter. De SLA en bijbehorende KPI’s sluiten aan op de kegel van onzekerheid. Overigens niet met als doel om te beperken of te straffen. KPI’s dienen bij te dragen aan drie basisdoelen: optimalisatie van het resultaat (kwaliteit, time-to-market, businessvalue), optimalisatie van de financiële aspecten (kosten en toegevoegde waarde) en reductie van de risico’s.
Last but not least: de klant en leverancier zitten in hetzelfde schuitje. De sterke combinatie van DevOps en agile ontwikkeling gaat over het management van een partnership, niet over de aansturing van een leverancier. Vanuit dat perspectief mag een KPI voor de opdrachtgever niet ontbreken: lead time to decide. De flow in de teams moet gegarandeerd zijn: een talmende opdrachtgever legt direct de snelheid in een team plat.
Conclusie
DevOps en agile hebben een aanzienlijke impact op de verkaveling bij outsourcing, de manier waarop we contracteren en de wijze van samenwerking. Onderschatting hiervan betekent een mismatch tussen de inspanningen op het vlak van outsourcing en de toegevoegde waarde van DevOps en agile. Deze teams kunnen nu eenmaal niet uit de voeten met de manier waarop de sourcingswereld traditioneel contracteert. Organisaties doen er verstandig aan om te anticiperen op wat DevOps en agile sourcing nodig hebben. Om vast klaar te zijn voor de wereld van… vandaag.
Over de auteurs
Frank de Vries en Pamela Verkijk zijn beide als adviseur werkzaam bij Quint Wellington Redwood. Dit artikel is verschenen in OM, een uitgave van ICT Media.