DevOps en Outsourcing

Je vindt hier antwoord op de vraag wanneer het nu wel verstandig is om DevOps toe te gaan passen en wanneer dat weggegooid geld is.

Daarna kijken we hoe je met DevOps kunt omgaan in relatie tot Outsourcing.

Wat ga je ontdekken? Wat behandelen we?

Over DevOps in combinatie met Outsourcing hebben onze lezers in de afgelopen tijd een hoop vragen gesteld. We hebben die vragen hieronder gerubriceerd en beantwoorden ze in de volgende paragrafen.

In het vervolg gaan we dieper in op de toepassing van Devops in combinatie met uitbesteedde ICT.

§ 1. Wat is DevOps?

Waarin verschilt het van de traditionele IT organisatie, van Agile en Scrum?

Voor we naar DevOps in de combi met Outsourcing kijken gaan we eerst nader in op het DevOps verschijnsel an sich.

We zien dat bij de ontwikkeling van programma’s en Apps (software) steeds vaker wordt gesproken over zaken als Agile, Scrum en DevOps.

Veel providers en interne ICT afdelingen doen hierover ook beloftes aan hun klanten zoals sneller, goedkoper en beter afgestemd op de behoefte van de klant/gebruiker.

Enkele lezersvragen die we behandelen.

• ‘Goedkoper, sneller etc. Kan dat ook? Hoe werkt dat dan? Wat heb je er echt aan?’
• ‘Moeten parttijen in een DevOps omgeving echt veel intensiever samenwerken? Hoe gaat dat dan? Hoe kan het dat ze dan ineens tot snellere resultaten komen? Wat moet je daar voor doen?’
• ‘En als het fout gaat, hoe vang je dat op en hoe zorg je dat de klant/gebruiker daar geen last van heeft?’
• ‘Wat is een composable infrastructuur?’
• ‘Ik hoor dat het aantal incidenten per verandering daalt maar toch blijft het aantal incidenten dat men per maand registreert gelijk. Hoe zit dat?’
• ‘Wat zijn de voordelen van DevOps en de nadelen? Is DevOps en Outsourcing een leveranciers en consultancy hype? Of is er deze keer echt sprake van een structurele verbetering in de dienstverlening?’

§ 2. Wanneer wel en wanneer niet DevOps?

DevOps biedt absoluut voordelen zoals we verderop gaan zien maar is niet in alle gevallen toepasbaar. We behandelen de volgende lezersvragen.

• ‘Wanneer kun je DevOps goed toepassen en wanneer moeten we je het echt afraden?
• ‘Wij hanteren een releasekalender. Vijf keer per jaar gaat er een nieuwe release life. Vaker is niet nodig. Is DevOps voor ons aan te bevelen?’
• ‘Kunnen jullie praktijkvoorbeelden geven? Ja dat gaan we doen en we laten ook zien hoe in de praktijk DevOps en traditionele methoden binnen een bedrijf naast elkaar kunnen bestaan.’
• ‘Ik las ergens dat in een business en IT omgeving waarin zorgvuldigheid en betrouwbaarheid belangrijk zijn, zoals bijvoorbeeld bij een bank of een verzekeraar of bij de overheid, DevOps beter maar niet kan worden toegepast!’
• ‘Hoe kan het dat banken zoals ING en nu ook de RABO bank deze methode toepassen? of zit hier een addertje onder het gras?’

§ 3. Moet je alle IT in één keer migreren?

De toepassing van de DevOps methodiek brengt veranderingen met zich mee.

We behandelen o.m. de volgende lezersvragen.

• ‘Kun je de traditionele benadering combineren met DevOps? Hoe werkt dat?’
• ‘Ik hoor dat je alle IT in één keer naar DevOps moet migreren. Klopt dat? Of is dat onzin? Wat zijn goede implementatie strategieën voor DevOps. En voor DevOps en Outsourcing?’
• ‘Wij hebben een aantal IT kavels uitbesteed maar niet alles. Is de combinatie van DevOps en Outsourcing dan mogelijk?’

§ 4. Wat is de impact van DevOps op de dienstverlening?

De toepassing van de DevOps methodiek brengt forse veranderingen in de IT organisatie. We behandelen de volgende lezersvragen.

• ‘Wat betekent DevOps voor IT functies? Wat verandert er in de werkzaamheden van medewerkers. Wat betekent het voor besluitvorming? Wat is de invloed op de verkaveling van IT functies?’
• ‘Kunnen de business, onze klanten, gebruikers hetzelfde blijven werken of moeten die zich ook aanpassen aan deze methodiek?’

§ 5. Wat veroorzaakt in de combinatie DevOps en Outsourcing falen

       en wat maakt het tot een succes?

De combinatie DevOps en Outsourcing is soms onmogelijk en in andere gevallen zeer goed werkbaar en effectief. We behandelen de volgende lezersvragen.

• ‘Wanneer is de combinatie Outsourcing en DevOps wel- en wanneer is het niet mogelijk?’
• ‘Welke voorwaarden moeten wij aan voldoen om de combinatie DevOps en Outsourcing mogelijk te maken?’
• ‘Hoe ga je om met een gedeeltelijk uitbestede IT? Hoe kunnen we dan toch de voordelen van DevOps naar ons toe trekken?’
• ‘Wij hebben onze IT bij verschillende gespecialiseerde providers ondergebracht. Kunnen we die providers in een DevOps benadering betrekken? Hoe pakken we dat aan?’

§ 6. Hoe DevOps voordelen pakken in een DevOps

       onvriendelijke configuratie/verkaveling?

De combinatie DevOps en Outsourcing (of SSC) kan bijna onmogelijk lijken maar dan is er altijd nog de derde weg. DevOps Light. We behandelen de volgende lezersvragen.

• ‘Koos, we horen van collega’s dat jij in sommige gevallen een derde weg aanbeveelt. DevOps Light. Wat is dat? Wanneer kun je dat toepassen?’
• ‘We horen voor- en tegenstanders van DevOps. En allemaal hebben ze praktijkvoorbeelden om hun standpunt te illustreren. De praktijk in onze organisatie bepaalt blijkbaar de kans op falen of succes. Bij welke praktijk past de light versie van DevOps en Outsourcing?’
• ‘Wat zijn de voordelen die je met de Light versie binnenhaalt en welke voordelen blijven dan liggen?’
• ‘Koos, kun je ons iets meer informatie geven over wat men verstaat onder een implementatie pijplijn? Wat moeten we ons daarbij voorstellen en wat is daar anders aan in vergelijking met wat we altijd al doen?’

§ 7. De impact van DevOps en Outsourcing op contracten

DevOps voordelen binnenhalen in een IT verkaveling waarin Outsourcing is toegepast dat vraagt outsourcing contracten die dat faciliteren. We behandelen de volgende lezersvragen.

• ‘Wij hebben met onze leverancier over de toepassing van DevOps gesproken. Hij reageerde daar positief op maar wij schrokken enorm van het kostenplaatje dat hij schetste!
• Klopt dat wel? Zo blijft er toch van de kostenvoordelen die DevOps biedt niets meer over? Is de voorstelling van onze leverancier reëel of kan het ook anders?’
• ‘Een collega verwees me naar u met de woorden dat ons contract hapert en bijstelling behoeft als we met DevOps in zee willen. Kunt u mij daar wat meer informatie over geven?’

§ 8. De impact van DevOps en Outsourcing op de SLA

Ook de SLA moet een DevOps werkwijze faciliteren wil het kunnen werken. Met name in Outsourcing en SSC situaties is dit van belang. We behandelen de volgende lezersvragen.

• ‘Wij hebben nu een rapportagestructuur waarin wij wekelijks, maandelijks, per kwartaal en jaarlijks bepaalde informatie krijgen.
• We zijn een pilot DevOps project gestart. Onze rapportages sporen totaal niet met dit project. Onze providers zeggen dat voor DevOps een andere SLA nodig is. Hoe zit dat?’
• ‘Is er echt een andere SLA nodig en wat is er dan anders aan in vergelijking met onze huidige SLA?’

Tot zover het overzicht met alle lezersvragen over de praktijk van Outsourcing en DevOps

{source} Klik op onderstaande link om jouw gids over Outsourcing en DevOps verder te lezen. {/source}

{source} Je gaat jouw vragen en de antwoorden daarin terugvinden. {/source}

DevOps en Outsourcing, de Gids

§ 1. Wat is DevOps?

Voor we naar DevOps en Outsourcing kijken gaan we eerst nader in op het DevOps verschijnsel an sich. We zien dat bij de ontwikkeling van programma’s en Apps (software) steeds vaker wordt gesproken over zaken als Agile, Scrum en DevOps.

Veel providers en interne ICT afdelingen doen hierover ook beloftes aan hun klanten zoals sneller, goedkoper en beter afgestemd op de behoefte van de klant/gebruiker. Kan dat ook? Hoe werkt dat dan? Wat heb je er echt aan?

DevOps is een term, een neologisme, samengesteld uit ‘development’ (systeem ontwikkeling) en ‘IT operations’ (het beheer van systemen).

Met die term wordt een methode aangeduid. De methode maakt het mogelijk continu applicaties in bedrijf te nemen. De lemniscaat in bovenstaande afbeelding geeft dit symbolisch weer.

Bij deze methode ligt de nadruk op samenwerking tussen alle betrokkenen en integratie van werkzaamheden.

Is die samenwerking dan niet vanzelfsprekend?

Ja en nee.

Ja, het zou vanzelfsprekend moeten zijn en dat is het ook wel, maar die samenwerking is traditioneel niet zo effectief georganiseerd. Een plaatje kan dat verduidelijken.

De afbeelding laat zien hoe in een traditioneel ontwikkelprogramma alle deelnemers na elkaar hun bijdrage aan het eindproduct leveren. Het principe is dat iedere participant aanvangt met zijn deel van het werk als de voorgaande partij klaar is met zijn deel.

Natuurlijk is er op zo’n overdracht moment sprake van samenwerking tussen de gevende en de ontvangende partij. Maar, de bal die in de afbeelding over een schutting wordt gegooid, geeft wel een goed beeld: van echte samenwerking is maar heel beperkt sprake.

Dat uit zich bijvoorbeeld als er op enig moment een fout of tekortkoming wordt geconstateerd. Bijvoorbeeld in stap 6. Dan gaat het werk terug naar bijvoorbeeld stap 3 en begint het hele spel weer van voren af aan.

Het effect daarvan is dat de doorlooptijd van idee of wens tot gerealiseerde Applicatie, van stap 1 tot stap 8 maanden en soms zelfs jaren kan duren. Die doorlooptijd past steeds slechter in onze dynamische maatschappij. Agile software ontwikkeling bracht hierin verbetering.

Agile ontwikkeling van applicaties bracht versnelling

Agile applicatie ontwikkeling houdt in dat een aantal ICT specialisten bij elkaar in een team gaan samenwerken.

Doordat IT specialisten nu interactief en gelijktijdig in plaats van na elkaar werken aan een (deel)product en doordat de ‘schutting’ tussen hun werkzaamheden wordt weggehaald, neemt de ontwikkeltijd fors af. In een afbeelding zou je het zo voor kunnen stellen.

Agile werken brengt een flinke verbetering in de doorlooptijden tot stand en ook de ontwikkelkosten gaan omlaag.

Toch kleven er ook beperkingen aan deze methodiek. DevOps haalt een deel van die beperkingen weg, maar veroorzaakt ook weer nieuwe uitdagingen. Meer over Agile vind je in onze publicatie: Agile werken en Outsourcing.

DevOps gaat net een stapje verder

Een van de beperkingen in Agile werken was namelijk dat de beheerders van het ontwikkelde systeem meestal niet in het team zaten. En als een systeembeheerder een applicatie moet implementeren terwijl hij geen kennis heeft van hoe die software werkt, dan ontstaan gemakkelijk problemen.

Voor goed werkende applicaties is het belangrijk dat beheerders en ontwikkelaars op één lijn zitten. DevOps betrekt nu ook de beheerders bij de ontwikkeling en het onderhoud van applicaties en systemen.

In onze afbeelding ziet dat er dan als volgt uit.

Alle betrokkenen werken eendrachtig en gelijktijdig samen aan hetzelfde product. Organisaties die DevOps effectief weten toe te passen, kunnen daar snel de resultaten van waarnemen.

Voordelen DevOps

Bij de support afdeling zal het aantal tickets over klachten, storingen en tekortkomingen flink afnemen. Daarnaast zal, als het goed is, de klanttevredenheid toenemen.

Klanten en gebruikers ervaren immers dat de dienstverlening is verbeterd!

Kostenvoordelen mogelijk?

Kostenvoordeel moet je niet direct verwachten. Allerlei dure specialismen die voorheen heel gericht werden ingezet, werken nu minder efficiënt. In het team waarin die specialisten participeren, brengen zij niet continu hun specialisme te gelde.

Ook ben je meer geld kwijt aan opleidingskosten. Alle team members moeten van de andere leden snappen wat hun bijdrage is en zij moeten daarin mee kunnen denken.

Composable infrastructuur

Wel zijn er kostenvoordelen mogelijk als een organisatie ervoor kiest de infrastructuur van servers, netwerken en geheugens te rationaliseren en het beheer te automatiseren.

We spreken dan over composable infrastructuur. Dat is techniek die je met commando’s vanaf je toetsenbord kunt configureren. Composable betekent dat je verschillende elementen in harmonie met elkaar samenbrengt.

Moderne datacenters beschikken over dit soort infrastructuur, vaak in combinatie met een aanbod voor het toepassen van Cloud technologie. Meer informatie over Cloud in onze publicatie: Outsourcing en Cloud services.

Maar om dat kostenvoordeel te realiseren, is een forse investering vooraf nodig en loop je eerst tegen een ingrijpende migratie van je IT landschap aan.

§ 2. Conclusie, wanneer wel en wanneer niet DevOps?

DevOps toepassen bij een release planning/agenda van één tot vijf keer per jaar heeft geen zin. Er is dan geen belang bij het invoeren van deze methode. De implementatiekosten overtreffen dan verre de voordelen die kunnen worden geoogst.

DevOps kun je effectief toepassen in innovatieve omgevingen waar veel en op korte termijn kortcyclische verandering voor de business wenselijk is. Je kunt hierbij denken aan situaties met een hoge concurrentiedruk, een groeimarkt, hoge zichtbaarheid of een grote bedrijfsdynamiek.

In relatief stabiele legacy omgevingen kun je de traditionele watervalmethode handhaven.

Duidelijk toch?

Wat is nu de uitdaging voor DevOps en Outsourcing? Wat verandert er in het DevOps verhaal in een situatie met uitbestede ICT?

Dat hang er van af. En om dat te verduidelijken bekijken we voor we naar DevOps en Outsourcing gaan eerst nog een ander aspect. Een combinatie van DevOps en traditionele methoden.

§ 3. Moet je alle IT in één keer migreren?

Het goede nieuws is dat het mogelijk is om gefaseerd over te gaan.

Er is dan geen big bang scenario nodig.

Een praktijkvoorbeeld

Retailbanken moeten risicomijdend zijn. Dat geldt zeker voor hun ICT systemen. Het deployment model van banken, het in bedrijf nemen van nieuwe of aangepaste applicaties, is geen feestje voor snelle jongens.

Meestal zijn er jaarlijks maar een stuk of zes momenten waarop nieuwe implementaties kunnen worden ingepast. Daarnaast is de overgang van ‘ontwikkeling’ naar productie, het daadwerkelijk in gebruik nemen van een ontwikkeling, een lange route.

Er zijn banken die drie preproductie omgevingen kennen waarin een applicatie een paar weken probleemloos moet werken, voordat ze daadwerkelijk ‘live’ mag gaan.

Internetbankieren en mobiele apps

De wereld van internetbankieren en mobiele apps ziet er anders uit. Deze moderne applicaties zijn ontwikkeld met behulp van eerst Agile methoden en later DevOps methoden.

Aanvankelijk zorgde de Agile aanpak nog voor veel problemen binnen de banken. Sinds men DevOps toepast, zijn die problemen aanzienlijk verminderd.

Meestal werkt men met zogenaamd Continuous Delivery (CD) methoden.

Hierbij is er sprake van een geautomatiseerd proces van App ontwikkeling naar de productie omgeving, de live omgeving, dankzij een composable infrastructuur.

Een proces dat werkt zonder menselijk ingrijpen. Dit laatste gebeurt in combinatie met andere change management processen op de gebruikersafdelingen.

Conclusie, alle IT in één keer migreren?

Uit het voorbeeld van de banken blijkt dat je kunt overwegen om een bepaalde sector de voordelen van DevOps te laten genieten. Andere sectoren waar deze voordelen niet zwaar wegen en waar de implementatiekosten te hoog zouden zijn, kun je dan nog op de traditionele manier behandelen.

Op deze conclusie is één voorwaarde van belang!

De sector die je wilt laten migreren, moet over een autonoom, een zelfstandig functionerende IT omgeving (kunnen) beschikken. Is die voorwaarde niet aanwezig, dan werkt het niet.

Maar in dat geval is er nog wel een tussenoplossing. Die oplossing behandelen we verderop.

DevOps en Outsourcing bij de banken

We zien grote verschillen tussen banken onderling, ondanks dat de meeste nu met DevOps methoden in hun commerciële applicaties werken. 

• We zien banken die de complete commerciële ICT hebben uitbesteed.
• We zien daarnaast banken die vrijwel alle commerciële ICT functies in huis hebben gehouden.
• En we zien banken die een deel van de commerciële ICT in huis hebben gehouden en een deel hebben uitbesteed.

We zien nu dat die laatste groep de meeste problemen heeft en dat is logisch.

Waarom?

Dat blijkt uit wat nu volgt.

§ 4. DevOps en Outsourcing

Wat is nu de impact van DevOps op ICT dienstverlening? Is de combinatie van DevOps en Outsourcing mogelijk?

DevOps: Impact op functies en afdelingen

DevOps doorbreekt de traditionele verkaveling en demarcatie, de afbakening en grensscheiding tussen ontwikkeling en beheer, applicaties en infrastructuur. De DevOps benadering brengt een andere werk-, taak- en verantwoordelijkheidsverdeling met zich mee.

Dat heeft consequenties voor de inzet van functies en medewerkers. Meer over DevOps organisaties lees je in deze korte samenvatting: DevOps organisaties eenvoudig uitgelegd.

DevOps: Impact op besluitvorming

Snelle, duidelijke en effectieve besluitvorming in het business management en bij de IT Regiefunctie is van cruciaal belang! De werkstroom in de teams moet gegarandeerd zijn! Een talmende opdrachtgever legt direct de snelheid in een team plat.

Bij talmende besluitvorming stijgen daardoor de kosten, ontstaat frustratie en gaan de voordelen van de DevOps werkwijze verloren.Talmende besluitvorming is een ticket voor een falende DevOps implementatie.

Lead time to decide is daarom een KPI die je aan de opdrachtgeverskant zou moeten overwegen.

DevOps: Impact op de verkaveling van IT afdelingen

Veel organisaties hebben van oudsher voor een horizontale verkaveling van afdelingen en functies gekozen.

Globaal ziet dat er ongeveer als volgt uit.

Die organisatievorm is in het verleden ontstaan vanuit de zoektocht naar schaalvoordelen en een duidelijke afbakening van verantwoordelijkheden.

Wat je ziet, is dat bij deze horizontale verkaveling soms applicatieontwikkeling en applicatiebeheer en infrastructurele diensten en technisch beheer (hosting) in twee kavels zijn gescheiden.

Meestal zijn in die situatie de verschillende kavels ook nog bij verschillende leveranciers ondergebracht. De Servicedesk, Werkplekbeheer en Security vormen meestal ook een aparte kavel.

Op de geschetste onderverdeling van werk- en deskundigheidsclusters bestaan heel veel varianten. Als je er echter door je oogharen naar kijkt, herken je de geschetste structuur.

Bij een DevOps aanpak gaat die structuur nu helemaal op haar kop en wordt vervangen door een verticale structuur.

Je leest meer over de impact van DevOps op organisaties op deze pagina.

Conclusie over de impact van DevOps op de IT dienstverlening!

De traditionele IT aanpak zorgt voor nieuwe technologische mogelijkheden die de dienstverlening naar externe klanten faciliteert. De slagkracht van die mogelijkheden is afhankelijk van de kracht van instrumenten zoals o.m. het requirements management proces, de business case en ROI metingen.

Hoewel deze instrumenten nuttig zijn, is menige IT afdeling er ondanks deze instrumenten niet in geslaagd het succes van veel projecten te waarborgen. De belofte van de DevOps benadering is dat er sneller nieuwe functies kunnen worden geleverd en dat die functies beter aansluiten bij de behoefte van de business eenheden.

Van die business wordt hierbij wel een veel intensere samenwerking met IT verwacht!

Een aantal gebruikers moet daadwerkelijk fulltime participeren in de ontwikkeling en het onderhoud van hun applicaties. Hier zien we een uitdaging om de hoek komen die bij DevOps en Outsourcing volledig in beeld is.

§ 5. DevOps en Outsourcing

Wanneer kun je DevOps combineren met Outsourcing en wanneer niet?

Alle IT nog in huis

Overstappen op een DevOps organisatiemodel is goed mogelijk. Of het nuttig is, hangt af van de intern beschikbare expertise. Heb je schaarste bij bepaalde specialisten, dan kun je die schaarse capaciteit bij de traditionele aanpak veel effectiever en efficiënter inzetten.

Een tweede aspect is de gewenste dynamiek in de IT ontwikkeling. Wordt daar veel van gevraagd, dan is het raadzaam om de overstap te gaan maken. Zo niet, ga dan niet knutselen aan een organisatie die niet kapot is!

Als je wilt overgaan tot Outsourcing, kies dan een provider die jullie volledige IT beheer voor zijn rekening neemt en die ervaring heeft met DevOps implementaties.

Een deel IT in huis, een deel extern; Devops en Outsourcing wordt een spannend traject

Een deel van de IT verkaveling zit nog in huis en een deel is extern ondergebracht. Waarschijnlijk loop je ertegenaan dat je interne mensen continu bij de provider moet detacheren of omgekeerd, de provider moet mensen continu bij jullie detacheren.

Dat zijn altijd dure oplossingen.

Je kunt natuurlijk overwegen om alles dan maar intern of extern te gaan doen, maar dat is geen korte termijn oplossing. Er is nog een derde oplossing mogelijk, een tussenoplossing. Hierover verderop meer.

Verkaveling over meerdere dienstverleners; Devops en Outsourcing wordt een super spannend traject

Een organisatie die tot nu toe een horizontale verkaveling kende, een verkaveling die ook nog bij verschillende leveranciers is ondergebracht, ziet zich nu voor een enorme uitdaging gesteld.

De gewenste DevOps structuur kan niet of alleen tegen hoge kosten worden gerealiseerd. Het is in die situatie effectiever om een andere oplossing te kiezen.

§ 6.  DevOps en Outsourcing. De derde weg,

DevOps Light

Een aantal DevOps voordelen binnenhalen

in een DevOps onvriendelijke IT omgeving

DevOps Light biedt een oplossing voor veel grote en traditionele organisaties die van en DevOps en Outsourcing de voordelen willen plukken. Organisaties die de voordelen van DevOps willen genieten, maar niet over een daarvoor benodigde IT architectuur en verkaveling beschikken.

Dat zijn organisaties met een IT infrastructuur die niet op korte termijn naar een DevOps werkwijze kan worden omgezet. Meestal is hier sprake van hecht gekoppelde oudere architecturen en complexe geïntegreerde systemen met een breed scala aan functionaliteiten.

Een wijziging in deel A van zo’n systeem heeft vaak onvoorziene gevolgen op deel X van datzelfde systeem. Grotere groepen technici, ontwikkelaars en beheerders, ieder binnen hun eigen kavel, werken deels afzonderlijk en deels serieel in samenwerking met elkaar.

Zij zijn intensief en gedurende langere tijd bezig met zelfs maar een kleine aanpassing of toevoeging aan dat systeem.

Idealiter zou je zo’n applicatie landschap en de bijpassende infrastructuur opnieuw ontwerpen. Met zo’n nieuwe architectuur kun je de voordelen van flexibele onafhankelijke teams gemakkelijk realiseren.

De realiteit is natuurlijk dat dit op de korte termijn niet praktisch is en te kostbaar is voor de meeste organisaties. De oplossing is hier dat zo’n organisatie (of een van haar IT providers) gaat werken aan een nieuw deployment systeem, DevOps Light.

DevOps en Outsourcing combineren met een derde benadering

DevOps Light is een deployment systeem met het vermogen om nieuwe source code – de bron van de meeste nieuwe functies en applicaties – vaker aan de gebruikers en/of klanten vrij te geven.

Dit deployment systeem weet de stabiliteit en kwaliteit van de totale traditionele IT architectuur vast te houden of zelfs te verbeteren.

We hebben het dan over het creëren van een goed ontworpen implementatiepijplijn.

Implementatiepijplijn

Zo’n implementatiepijplijn maakt het mogelijk dat software ontwikkeling nog in de traditionele structuur plaatsvindt. Tegelijkertijd maakt die pijplijn het mogelijk om veel makkelijker en veel sneller dan voorheen code naar productie te brengen.

Ook de frequentie van nieuwe releases kan met die pijplijn fors omhoog. Die implementatiepijplijn wordt opgebouwd uit geautomatiseerde deployment processen en geautomatiseerde testen.

De testen zorgen voor een codekwaliteit die release kwaliteit bezit. Die geautomatiseerde pijplijn zorgt er ook voor dat nieuw ingebrachte functionaliteit de bestaande functionaliteit niet doorbreekt.

Deze DevOps Light benadering verschilt van de eenheidsworst benadering die zowel in traditionele IT organisaties als in DevOps organisaties wordt toegepast.

Beide soorten organisaties opereren in een alles of niets benadering: óf DevOps, óf traditioneel.

DevOps Light biedt een tussenoplossing en brengt de combinatie van DevOps en Outsourcing binnen handbereik.

Een tussenoplossing die het voor traditionele IT organisaties mogelijk maakt snel een aantal DevOps voordelen te oogsten door:

snel en frequent kleine stukjes code naar productie te brengen.

Terwijl de traditionele IT organisatie grotendeels intact blijft en je dus niet in één keer alles ‘op zijn kop’ hoeft te zetten.

In de gepresenteerde oplossingsrichting fungeert de werkcode in de implementatiepijplijn als dwingend issue, als een alarmfase rood!

Waarom?

Als de code die door verschillende teams wordt geproduceerd niet samenwerkt of niet werkt in de preproductie omgeving, moet de organisatie deze problemen oplossen.

Die oplossing moet er ook snel zijn. Want voor je het weet, is er weer meer code geschreven die niet samenwerkt in een productie omgeving.

Het dwingende issue gebruik je om meer coördinatie in het ontwikkelwerk te brengen en de afstemming in de hele organisatie te verbeteren en te waarborgen.

De voordelen voor DevOps en Outsourcing

De voordelen van DevOps Light

Geautomatiseerd en frequent werken met kleine release pakketjes levert een forse afname van doorlooptijden op. DevOps Light levert een forse reductie van productie kosten.

Vroegtijdig en in een implementatiepijplijn aanpakken van problemen is een van de belangrijkste voordelen die traditionele IT organisaties kunnen boeken.

De effectiviteit van ontwikkelings- en implementatie-processen verbetert enorm. De impact van deze derde benadering op de traditionele organisatie is relatief gering.

De kosten voor deze benadering zijn gering ten opzichte van de kosten die je maakt als je full swing migreert naar DevOps.

§ 7. DevOps en Outsourcing & Contracten

Willen organisaties aan de slag met DevOps en Outsourcing, dan vraagt dat een andere manier van hoe Sourcing wordt gecontracteerd.

Organisaties die al langer werken met de Slagkracht benadering zijn nu spekkoper. De Slagkracht benadering van contracteren sluit prima aan bij DevOps en Outsourcing.

Business resultaten staan in de Slagkracht benadering centraal en de wijze waarop die worden bereikt, is hierbij vanuit een contractoptiek van ondergeschikt belang.

In de traditionele contractbenadering zijn contracten veelal voorzien van uitgebreide procesbeschrijvingen, procesresultaten, functionele en technische ontwerpen, verantwoordelijkheden, tools etc.

Samenwerking en resultaat in plaats van processen en methoden 

DevOps teams, die gericht zijn op samenwerken en waardegeneratie, kunnen niet uit de voeten met de oude wijze van contracteren. Die traditionele wijze van contracteren is te veel gericht op verantwoordelijkheid afbakening en op kavelverdeling.

Sommige adviesbureaus maken van het contractproces t.b.v. DevOps een heel circus. Dat circus bestaat uit meerdere fases van DevOps ontwikkeling waarbij iedere fase weer een nieuw en aangepast contract krijgt.

Dit soort contractprocessen zijn gebouwd op gestold wantrouwen en zijn zeer geschikt voor spelers die niet goed weten waar ze mee bezig zijn, die onzeker zijn.

Wil je weten hoe je een Outsourcing contract Slagkracht geeft? Volg dan de tweedaagse training Sourcing, Regie en Demand Management.

§ 8. DevOps en Outsourcing en de SLA

Ook de SLA gaat er bij toepassing van DevOps en Outsourcing in vergelijking met traditionele SLA’s anders uitzien. Deze traditionele SLA’s richten zich veelal op proces KPI’s in termen van doorlooptijden, aantal incidenten, aantallen storingen, functiepunten, budgetten etc.

Ook hierbij geldt dat als je de Slagkracht benadering al volgde er niet zoveel verandert.

Bij een DevOps SLA komen de KPI’s meer te liggen in de sfeer van succesvolle deployments, gereduceerde doorlooptijden, aantal falende changes etc.

Maandelijkse rapportages boeten in aan belang omdat er realtime wordt gemonitord.

Deze rapportages blijven een effectief instrument voor het vastleggen van ontwikkelingen en voor evaluatie van de samenwerking en de performance.

DevOps en Outsourcing. Overall conclusie