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.
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…
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.
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.
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.
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.
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.
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
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.
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).
We stellen voor om de agile contractering te faseren aan de hand van de kegel van onzekerheid.
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.
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.
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.
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.
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.
Meer weten? Bel +31 20 305 3700 of email naar marketing.nl@eraneos.com