Är DevOps en fråga om överlevnad för driftsorganisationer?

Med intåget av DevOps ser vi en helt ny trend som många leverantörer av driftstjänster inte är förberedda på. Förändringar som innebär en fråga om överlevnad eller inte för drift. I en studie från ett av de stora konsulthusen som jag läste häromdagen stod det hur CIO:er i år kommer att ha stabil drift bland sina primära fokusområden för 2017. Efter några år av annat fokus har nu stabilitet seglat upp högre i prioritet. Vägen till stabil drift beskrivs i samma rapport som i stor utsträckning handla om Outsourcing. Outsourcing är för övrigt lösningen på en mängd andra frågor som att koncentrera sig på sin kärnverksamhet, snabbare TTM och framför allt sänkta kostnader.

För driftsorganisationer som erbjuder sourcade driftstjänster finns det alltså en fortsatt stabil marknad att verka på. Eller?

Organisationer med fokus på (system)utveckling ratar mer och mer traditionella driftstjänster till förmån för molntjänster. Frågan är varför och hur påverkar detta outsourcingleverantörer av driftstjänster?

Det primära svaret på “varför molnet” är inte pris, prestanda (på kran) etc. Alla de delarna är viktiga och bra men det allra viktigaste är oberoendet från leverantörens personal och leveranstider. Kortare time to market är absolut kritiskt för de flesta organisationer idag.

I molntjänster får kunden själv tillgång till att sköta en mängd viktiga aktiviteter såsom:

• Ändra en IP-adress.
• Allokera mer resurser (prestanda).
• Sätta upp nya miljöer, döda gamla miljöer etc.
• Produktionssätta nya releaser.
• Rulla tillbaka ur en release (utan att behöva inkalla en E-cab med leverantören).
• Ändra inställningar i trådningar mellan databas och mellanskikt.
• Flytta data från långsamma till snabba diskar.
• Analysera och optimera flöden mellan (virtuella) servrar.
• Sätta upp testmiljöer och genomföra produktionstester.

Varför gör vi inte så här då?

Det här är bara några av de typiska exemplen på självbetjäningsfunktioner som riktiga molntjänster erbjuder. Definitionen av molntjänst här är då att det distribueras via internet, går att skala upp och ner i kapacitet med stor enkelhet och sist men sannolikt viktigast, kommer med inbyggda självbetjäningstjänster/funktioner. Vilket då i sin tur innebär kortare TTM eftersom kunden då inte behöver vänta på att någon tekniker hos sourcingleverantören ska få tid över att utföra leveranser till kund.

Driftsorganisationer är dock i regel ointresserade av att utveckla sådana funktioner. Förklaringarna är naturligtvis olika för olika organisationer men här är några exempel:

• En signifikant andel av omsättningen kommer från tim- eller funktionsdebitering av att utföra ovan enkla aktiviteter. Man tar betalt för arbetet snarare än för sluttjänsten.
• Att tillhandahålla ovan typer av självbetjäningstjänster innebär investeringar (i verktyg, nya kompetenser etc).
• Varför ändra sig och sin affärsmodell? Vi känner till vad vi gör men det andra nya är osäkert.
• I praktiska termer är en mängd av ovan funktioner beroende av scriptbaserade leveranser, utvecklat verktygsstöd i portaler och liknande. Det är i sin tur kompetens man saknar hos driftsleverantören.
• Scriptbaserade leveranser och automatiserade tester innebär behov av att kunna checka in och ut kod, scriptversioner och versionshantering på en nivå man inte alls gör idag. Man saknar verktyg, kompetens och förståelse för varför man skall jobba på det sättet.
• Kontroll över miljön i termer av dokumentation och översikt är undermålig, ouppdaterad eller helt enkelt obefintlig
• Graden av standardisering är låg (ofta som ett resultat av att man kunnat ta betalt för teknikertid för att tillhandahålla unika och/eller komplexa lösningar).
• Våra processer, verktyg och metoder är allihop uppsatta för att stöda vår nuvarande affärsmodell. I en molnleverans kommer vi inte ens kunna ta betalt.
• Gentemot AWS, MS etc så står vi oss slätt, det är ingen idé att konkurrera så vi håller oss till vår nisch (säger det mindre driftsbolaget)
• Vårt moln är mycket bättre och billigare än AWS, MS etc för vi är jättestora globalt (säger det större driftsbolaget).

Allt ovan kan summeras i “Att lämna en affärsmodell för en annan är alltid svårt”.

Kortare ledtider och stabilare leveranser är själva essensen av DevOpsprinciperna. Allt handlar om att knyta ihop säcken mellan utveckling och drift och därmed få bort den sista stora flaskhalsen i IT-leveransen.

Om driftleverantörer inte vill bli redundanta måste de alltså också utveckla rätt förmågor. De driftsbolag som ignorerar detta riskerar att få en väsentligen kortare levnadstid än planerat. Ny teknik och nya metoder har genom historien alltid inneburit krav på människan att anpassa sig. De som inte anpassar sig, de har en dyster framtid. Är du ansvarig för en driftsleverantör gör du bäst i att snabbt sätta dig in i vad det här innebär för er organisation och vad ni måste göra för att överleva.