Kommer din DevOps-transformation någonsin att bli klar?

Vid det här laget har du kanske redan insett att en DevOps-transformation inte bara omfattar mjukvaruutveckling och IT-drift. Dagens DevOps handlar om affärstänkande på högsta nivå. En stor del av DevOps är att ta ansvar för resultaten av ditt arbete, förstå dem och låta dem påverka hur du fattar beslut här och nu.

DevOps hör hemma i företagsledningen

Den mest kraftfulla formen av DevOps finns i företagsledningen, eftersom de bästa DevOps-transformationerna omfattar alla och kräver helhetsperspektiv. Utan detta perspektiv begränsas din DevOps i den digitala transformationen till enskilda team, blir långsammare och dyrare samt leder inte till optimala resultat.

Företagsledningen kan mobilisera hela organisationen så att den arbetar som en sammanhängande verksamhet, utan att team förväntar sig att någon annan ska hantera eventuella problem senare. För att lyckas med det behöver varje team ha ett DevOps-tänk och ta ansvar för resultaten av sitt arbete hela vägen till driftsättning och förvaltning. DevOps föddes inom IT, där det skapade ett gemensamt mål för utvecklare och IT-drift: att automatisera återkommande processer, minska kostnader och förkorta time-to-market.

I dag är företagsledningen den enda plats där DevOps kan nå sin fulla potential. DevOps bör stödja ledningens beslutsfattande kring innovationer, nya produkter och nya marknader, och samtidigt främja en snabb verksamhet med stöd av automatiserade mätetal som visar att det fungerar.

Din DevOps-transformation bör ha ett slutdatum

Full effekt uppnås först när transformationen till en organisation som utvecklas organiskt är klar. Det innebär att du behöver sträva efter och ställa krav på detta redan från början av transformationsresan. För att transformationen någonsin ska bli klar – eftersom din organisation fungerar som en avancerad DevOps-organisation på alla nivåer, även i företagsledningens beslutsfattande – behöver den ha ett slutdatum.

För att din DevOps-transformation ska ha ett slutdatum bör du tänka efter en extra gång innan du skapar decentraliserade interna DevOps-avdelningar. Åtminstone bör du planera för vad som händer med organisationen när transformationen är klar. Annars riskerar du att skapa silos i form av DevOps Team (se ”Anti-type B” enligt DevOps Topologies), där ansvaret för att genomföra DevOps ligger hos DevOps Team i stället för hos varje team i organisationen.

Se i stället en DevOps-transformation som avgränsade projekt som genomförs inom en på förhand överenskommen tidsram, med en tydlig slutpunkt – ett slutdatum – då organisationen har tagit till sig alla fördelar med DevOps och tillämpar och delar dem i det dagliga arbetet.

De fyra faserna i en DevOps-transformation avslutas med ett slutdatum

Varför sätter inte företag ett slutdatum för sin DevOps-transformation?

Det främsta sättet som företag gör DevOps-transformationen till en utdragen process är att anställa interna DevOps-experter och integrera dem i befintliga team, eller att bygga ett nytt DevOps-team.

Den omedelbara fördelen är att det verkar kosta mindre än att anlita en konsultfirma. Men på lång sikt blir det dyrare, eftersom dessa medarbetare finns kvar på lönelistan och du behöver hitta nya projekt åt dem när DevOps-transformationen är klar. Risken är att era egna DevOps-ingenjörer efter den första delen av transformationen – trots att de skulle passa bättre i ett effektivt utvecklingsarbete – håller fast vid DevOps-ansvar som borde delas inom teamet eller organisationen.

Men är inte interna DevOps-experter det bästa sättet att behålla DevOps-kunskapen efter att transformationen är klar? Det kan verka så, eftersom DevOps-experterna fortsätter att vara en del av din avdelning. Att arbeta med konsulter innebär naturligtvis risken att de tar med sig kunskapen när de lämnar, vilket gör dig beroende av ytterligare konsulthjälp. Men interna experter har också ett pris: när DevOps-experter blir en permanent del av organisationen signalerar det till övriga medarbetare, inklusive företagsledningen, att DevOps-ansvaret inte ligger hos dem. Det minskar effektiviteten i mjukvaruutvecklingen, utvecklingsteamen och DevOps-transformationen avsevärt.

Fördelarna med en DevOps-transformation med slutdatum

Jag har redan berört fördelarna. Här är några fler skäl att ta detta på allvar.

1) En transformation med slutdatum minskar kostnaderna på lång sikt och gör dem mer transparenta: du får en uppskattad kostnad för varje avgränsat steg eller initiativ i transformationen.

2) Slutresultatet av en transformation bör vara en DevOps-maskin som omfattar hela organisationen. Om du väljer att bygga maskinen med extern hjälp, kom ihåg att dess delar är dina utvecklare och din tekniska ledning. Maskinen fungerar först när dessa utvecklare kan DevOps mycket väl. Det är så den DevOps-kunskap som är relevant för att skapa värde i din organisation stannar internt. Annars kan man hävda att DevOps-transformationen inte är klar.

Om du till exempel påbörjar DevOps-transformationen tillsammans med ett DevOps-konsultbolag får du direkt tillgång till beprövade metoder från de organisationer konsultbolaget tidigare har arbetat med, anpassade för just dig. När du anställer enskilda personer upphör erfarenheten från andra organisationer i praktiken när de börjar arbeta hos dig.

3) Snabbhet är mycket viktigt. Kortare ledtider är en fördel som branschledare världen över redan har. Det gör DevOps till mer än något som bara är bra att ha och är en av anledningarna till att det blir ett mål för företagsledningen. Genom att sätta ett slutdatum visar du att DevOps-transformationen inte är ett avlägset mål, utan ett slutmål som allt fler redan har nått – och som din organisation vill nå så snabbt som möjligt.

Din DevOps-transformation bör ha ett slutdatum. Har den det?

Du behöver inte skapa ett nytt team i organisationen som aldrig borde ha funnits från början, bara för att hjälpa organisationen att arbeta mer effektivt. DevOps är inget mer än en bra strategi, en öppen och stöttande kultur, att ta ansvar, dela beprövade metoder och automatisera allt du kan. Det är inte en separat enhet och därför bör det inte heller vara en separat avdelning.

Skeptisk? Första steget är en DevOps-bedömning och en roadmap, även om du planerar att genomföra din DevOps-transformation internt. Vill du veta mer? Kontakta oss.