Ansvaret for at vide, at systemet har en fejl, før brugerne opdager den. Ansvaret for at vide, om systemet er online, før brugerne opdager, at det ikke er. Som udviklingsteam er det ansvar vores.
Det er ikke en driftsafdelings ansvar at vide, om vores applikation er i live. Det er ikke vores supportafdelings ansvar at vide, om applikationen har en fejl. Og det er slet ikke brugernes.
Det er vores ansvar.
Det kalder vi butlering.
"Butlering" for at understrege, at det er den slutbruger, som får hjælp til sit arbejde igennem softwaren, der er i centrum. Ikke os der udvikler den. Vi står til rådighed for brugerens gode oplevelse. Vi er systemets butlere. Vi er brugernes butlere.
Vi handler ikke taler om ejerskab eller governance.
Det handler ikke om at leve op til SLA'er eller kontrakter.
Det handler om at tage ansvar for brugerens oplevelse og arbejde med at forbedre den, før brugeren selv opdager, at oplevelsen er forringet.
Er vi så den klassiske butler, der stryger avisen om morgenen, så herremanden/-kvinden ikke får det tynde lag tryksværte på hænderne fra en nytrykt avis?
Ja, det kan du bande på, at vi er. Vi gør alt, hvad vi kan for at løse problemerne, før de opstår, og for at gøre oplevelsen af at anvende vores software så rar som muligt.
Forstå mig ret. Det lykkes ikke altid. Men det er ambitionen.
Butlering-konceptet: Selvorganiseret drift
En del af konceptet er blot en indstilling - eller en prioritering, om du vil. En indstilling til, at driftsstabilitet er vigtigere end nye features og deadlines. Altid. Ingen er en succes, hvis vi når deadlinen, men brugeren ikke kan anvende systemet. Vi har stadig skarpe deadlines. Vi bliver også målt på, om vi når vores deadlines. Vi har også begrænsede resurser. Vi må også prioritere ligesom alle andre. Men driftsstabiliteten er bare vigtigst.
Vores butlering-koncept står på 3 ben:
- Én kok fra jord til bord
- Vi reagerer før vores brugere
- Butlering er både et ansvar og en opgave
Lad os se på de tre dele et ad gangen.
1. Én kok fra jord til bord
Det er den samme kok, der graver gulerødderne op i køkkenhaven om formiddagen, som tilbereder dem i en cassoulet om aftenen, og som napper opvasken før sengetid og sørger for, at porcelænet er nydeligt til næste dag.
Det er samme team, der udvikler den nye funktionalitet, som er ansvarlig for vedligeholdelsen og driften efterfølgende.
Hvem har hånden på kogepladen? Det har teamet. Det er teamet, der udvikler, tester, releaser, drifter, overvåger og fejlretter. Det betyder også, at det er eksperterne, der er ansvarlige for vedligehold. Ingen anden ved bedre, hvad der kan gå galt i det system, som det team der stod for udviklingen. Ingen anden ved bedre, hvordan systemet skal opfører sig, som det team der specificerede systemet.
Det lyder måske simpelt, men vi har taget dette princip ret langt.
Det enkelte team er fx autonomt i forhold til frit at kunne deploye deres moduler. Det betyder også, at hvert team ikke blot er ansvarlige for at rette fejl på bagkant, men har mulighed for at designe deres moduler, når de bygger dem. De kan designe efter, hvordan de efterfølgende ønsker at overvåge modulet. De har også deres egen deploy pipeline, så de selv er i kontrol over, hvornår de frigiver fejlrettelserne - uden at kunne spænde ben for andre eller blive spændt ben for. Der er kun én kok i køkkenet.
2. Vi reagerer før vores brugere
Alle teams har dedikeret tid til butlering. Nogle mere end andre i erkendelse af, at nogle områder bare er mere komplekse at holde ved lige.
Teamets tid til butlering kan ikke inddrages til at løse features. Det er øremærket tid, som vi aktivt ønsker at bruge. Hvis vi ikke bruger tiden, så finder vi jo heller ikke fejlene.
For at ikke alle teams skal opfinde den dybe tallerken, har vi et centralt team, som ejer den infrastruktur, der bruges til overvågning, alerting og opfølgning. Det team er også eksperter i, hvordan infrastrukturen fungerer, og i hvad det vil sige at overvåge et it-system.
I mange af vores moduler kan vi deploye i dagtimerne, og det gør vi. Det er en del af vores evne til at kunne reagere hurtigt og rette fejl, før brugerne opdager dem. Men det er ikke alle steder, vi har den luksus. Derfor har vi lært, at i de moduler, der er vanskeligere at deploye, er vi ofte godt stillet ved at introducere andre sikkerhedsmekanismer, når vi releaser. Fx evnen til at rulle tilbage ved brug af feature toggles. Eller "langstrakte releases", hvor vi ser data trille igennem de nye moduler i produktion, imens vi bygger funktionaliteten, men inden vi releaser til slutbrugeren. Men det må være et emne til et andet blog-indlæg.
3. Butlering er både et ansvar og en opgave
Man vil kunne høre os spørge: Hvem har butlering af journal-modulet? På den måde taler vi om butlering som et ansvar. Men man kan også høre spørgsmålet: Hvordan går det med jeres butler-opgaver? På den måde taler vi ikke blot om butlering som et ansvar, men også som en type af opgaver.
Det hænger sammen med vores årshjul.
Vi vurderer løbende, om vores moduler skal efterses, om tredjepartssoftware skal løftes, om der mangler overvågning eller alarmer, om nye teknologiske muligheder skal inkorporeres på tværs af moduler, eller om der er opstået nye interne api'er eller afhængigheder, der kræver konsekvensretning på tværs af moduler.
Det er alt sammen butler-opgaver og en del af at vores langsigtede brugeroplevelse, som sikrer, at applikationen løbende bliver smurt. Det kalder vi i øvrigt løbende modernisering.
Vores target operating model
Vores operating model er struktureret omkring de tre ovenstående principper.
Uden at gå i detaljer her, betyder det, at indgangen til udviklingsteamet er kortere og mere forsimplet end tidligere, da vi havde en skarpere funktionsadskillelse imellem fx Drift og Udvikling.
Det betyder dels, at udviklingsteamsene bærer et større ansvar for driften end i et traditionelt setup. Dels, at applikationsdriften er langt mere specialiseret i deres forståelse af applikationen end i et traditionelt driftssetup. Og endelig at udviklingsverdenen og driftsverdenen mødes i et setup med fokus på infrastruktur som kode og automatiseret alerting.
Slutbrugerens oplevelse, forståelsen for driften og viden om applikationen går hånd i hånd.
Vi begår stadig fejl
Er det så et agilt driftsnirvana? Selvfølgelig ikke.
Og virkeligheden kan tage sig mere rodet ud, end hvad et 1.000 ord langt blogindlæg tillader, men vi har en ambition, som vi har eksekveret efter igennem flere år. Vi kan se, det virker, og vi kan se, vi bliver bedre år for år.