Gæstebloggen

Gentænk funktionsadskillelser, når DevOps-rollen skal gives til agile teams

Det er svært at være medarbejder i et stort firma, hvor der er opstået siloer, hvor man taler forskelligt sprog, og man har forskellige mål. Selvom der er indsigt i en del af firmaet for en vigtig ændring, er det ikke sikkert, man kan forklare det til en anden del af firmaet.

Det viser sig eksempelvis, at 21 pct. af brugerne fjerner apps, efter den er prøvet en gang. Det sker, selvom Product Owner og det agile team har arbejdet hårdt på fede faciliteter til applikationen.

Martin Boel er CTO og partner i Lund&Bendsen A/S, formand for Javagruppen og har 30 års erfaring fra den danske it-verden. Han har erfaring fra store agile projekter i BEC, Nordea og Topdanmark og er uddannet civilingeniør med speciale i software fra Aalborg Universitet. Illustration: Privatfoto

Samtidig ser det ud til, at kun 23 pct. af installerede apps bliver brugt mere end 10 gange..

Det er hårde odds, og forretningen har et problem. Den største udfordring er dog, at den viden, der skal til for at løse problemet, ligger på den anden side i det funktionsadskilte firma - bag en ”wall of confusion”.

Funktionsadskillelse giver udfordringer

De 3 traditionelt funktionsadskilte organisatoriske siloer, der ofte kan findes i større organisationer, giver udfordringer for agile processer og DevOps-rollen, da fortolkningen for funktionsadskillelse er for rituel.

Nogle siger, at funktionsadskillelse er et lovkrav, og at du ikke er 'conformant', hvis du som udvikler gerne vil have et kig i forretningens produktionsdata.

Men det er ikke nødvendigvis sådan, loven er skruet sammen, det er bare sådan, 'man plejer at gøre' i firmaet. Selvom man ønsker sig fordele fra DevOps-metoder, har man ikke vilje til at se, at gamle interne arbejdsgange skal revideres for at møde nutidens og ikke mindst fremtidens virkelighed.

Finanstilsynets bekendtgørelse

I 'Bekendtgørelse om ledelse og styring af pengeinstitutter m.fl.' fra Finanstilsynet angives det:

at følgende forhold kan for eksempel være relevante at tage stilling til:
a) Organisering af it-arbejdet, herunder funktionsadskillelse mellem

  • systemudvikling/-vedligeholdelse,
  • it-drift og
  • virksomhedens forretningsførelse.

Bemærk formuleringen 'for eksempel'. Den er vigtig, da der kan være et arbejdsbetinget behov, der medfører et valg om ny opdeling af funktionsadskillelser. Eksempelvis kan det være praktisk:

  • at tillade en udvikler at få adgang til produktionsmiljø for at få identificeret en fejl.
  • at give udviklere adgang til applikation-logs, så de kan kontrollere systemet fungerer optimalt.
  • at tillade udvikleres adgang til produktionsdatabaser for at fixe et problem og skabe sig et overblik over forbrugsmønstre.

'4-eyes principle'

Når it-sikkerhedspolitikken skal formuleres, kan der med fordel skeles til '4-eyes principle', derved involveres flere personer på udvalgte, følsomme steder i systemet, når der skal arbejdes netop her.

Et 'Sealed authenticator system', som blev benyttet til misilaffyring. Illustration: Wikipedia

Eksempler på nye funktionsadskillelser, der muliggør agile teams med DevOps-roller:

  • Ret til at foretage forretningstransaktioner i produktion. Personer med forretningsansvar, f.eks. Product Owner.
  • Ret til at se applikations-logs. Personer i agile teams. Udviklere, testere, forretningsanalytikere.
  • Ret til at starte, stoppe og rette opstartsparametre som timeouts. Personer med DevOps-ansvar, f.eks. personer i agilt team med driftansvar.
  • Ansvar for godkendelsen af nye versioner af applikationer kommer i produktion. Personer med forretningsansvar, f.eks. Product Owner.

Med den nye funktionsadskillelse bliver der plads til det agile team med DevOps-rolle.

Det er muligt at få DevOps og krav om funktionsadskillelse til at virke sammen på måder, som faktisk resulterer i forbedret sikkerhed. John Burke, 'The Twain Shall Meet: DevOps and Separation of Duties'

Bemærk at en traditionel silo-opdeling også påvirker sikkerhed negativt. Eksempelvis vil versionsopgradering af komponenter inden i applikationer og uheldig brugeradfærd, der påvirker succes for systemet, være usynlig for en traditionel driftsafdeling.

Ved at flytte på de traditionelle silo-opdelte arbejdsgange og skabe agile teams, der har de nødvendige adgange, er det muligt at bevæge sig væk fra det skæve fokus, traditionel IT har skabt, og komme over i datadrevet IT, der er det ny Nirvana for systemudvikling.

Traditionel ITData-Drevet IT
DataStrukturerede data og relations databaserBåde strukturerede og ustrukturerede data
IntegrationSkrøbelig og ad-hocRobuste integrationer der har tilhørende tools og overvågning
FokusFejl og bugsReal-time rapporting via big data
MålSilo-orienteret top-down målHelhedsorienterede medarbejder-ejede mål
AnalyseværktøjHåndholdte søgninger med skiftende målMålbaserede løbende analyser med machine-learning

Source: Splunk Inc.

Agile teams vil også have tilskyndelse til at tage fat i nye værktøjer inden for klassen af Application Performance Management – APM.

Velkommen, DevOps!

En ny opdeling af funktionsadskillelser betyder, at personer med driftsansvar skal ud i de agile teams i stedet for at sidde på en etage for sig selv gemt bag et stort job-prioriterings- og frasorterings-system. Det giver bedre engagement, gladere medarbejdere og bedre resultater.

Der er mange emner, jeg gerne vil omkring i denne post. I mit arbejde med Agile Development har jeg oplevet, at en bedre funktionsadskillelse kan gøre en enorm forskel på både udviklings- og driftssiden.

DevOps spreder sig som en løbeild, og den skal være så velkommen. Kom indenfor, siger jeg.

Dette er en gæsteblog på Version2. Har du en it-faglig erfaring du vil dele med vores læsere i en gæsteblog, kontakt redaktør Henning Mølsted på hm[at]ing.dk

Relateret indhold

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mads Hjorth

Hej Martin,

Godt nok længe siden :-)

Du har fat i den helt lange ende og rammer hovedet på sømmet på et SF de helt store problemer vi oplever i offentlig it-udvikling for tiden.

Skal vi ikke lave en workshop eller to og se om vi kan få nogle fælles tanker ned på et stykke papir... og invitere nogle af de andre også :-)

Skriv endeligt!

  • 0
  • 0
Chris Bagge

Sidder i et lille team i en stor organisation hvor teamet, som jeg ser det, er meget tæt på den verden du taler om. Det kræver fleksible kollegaer. Det passer dårligt i en verden med kontrolfreaks.

Når virksomheden så pludseligt vil være agil så glemmer man at analysere. Man kaster sig over udvikling men glemmer at se på hvor det er forsinkelserne opstår. Det er ofte i beslutningslagene. Hvornår gør man noget ved forsinkelserne der?

Der er samtidigt i den agile verden en mangel på forståelse for at der er en drift. Det er muligt der er defineret et sprint med en række opgaver, men det er ret uinteressant når der pludseligt er produktionsproblemer. Den agile verdens mantra med vi retter undervejs er ikke altid en mulighed. Der er rigtigt mange steder hvor fejl i drift er et no-go. Der er ikke noget med at "lige" ruller tilbage.
Jeg fandt for et stykke tid siden følgende i en diskussion på Linked In
"Another thing that gave me hope was during Facebook's IOP - I know this from my venture IP days - Their philosophy was "move fast and break things." And recently while I was at Facebook headquartes, I saw that motto had been replaced: there were signs on the wall that said, "Move slowly and fix your sh_t."

Når der så indføres "agile processer" så er det som man går over i den anden grøft og helt glemmer noget af det der står i The agile manifesto.
"That is, while there is value in the items on the right, we value the items on the left more".
Man glemmer balancen.

  • 0
  • 0
Martin Boel

Ja, balancen er typisk hvor problemet er. Og især hvis man ikke har samme mål. Jeg tror ikke der er nogen i organisationen der betegner sig selv som kontrolfreaks, men de styrer måske efter nogle andre mål. Dit facebook eksempel er godt til at fortælle at noget der engang var målet (hurtig udvikling) er udskiftet med et andet mål (stabil drift). Hvis alle forstår hinanden, er der en bedre chance for at man ikke modarbejder hinanden. Derfor er det vigtigt at få alle aspekterne fra drift, udvikling og forretning ind i samme rum, så de kan afveje fordel og uleme i forhold til en løsning. Hvis man har mange teams skal de så hver især have lov til at gå i luften (produktion) med deres eget produkt, og se konsekvenserne af deres afvejning. Og måske hurtigt ændre på noget.

  • 0
  • 0
Hans Nielsen

" Hvis man har mange teams skal de så hver især have lov til at gå i luften (produktion) med deres eget produkt, og se konsekvenserne af deres afvejning. "

Som i Sunndhedplatformen, hvor mennesker risikere at dø ?

Men hvis man bare løber med hovedet under armen, med andre agender, uden styring så ender man med til sidst at have noget der fungere, men det koster liv.

Som Apollo 1 "Phillips Report", og når den er glemt så får vi en Challenger "episode".

Hvis din metode, med "se konsekvenserne af deres afvejning" skal virke. Så bør der være teamet der udvikler, der sider i sæderne eller bliver taget under kniven.

https://en.wikipedia.org/wiki/Apollo_1

https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disaster

  • 0
  • 2
Martin Boel

En læge skal have mod til at gå i aktion. Man skal have mod til at tænde raketten. Man skal forberede sig omhyggeligt og afveje risiko. Sundhedsplatform opgradering gik godt selvom der var en risiko, men det er også en risiko, at lade stå til. Hvis man ikke får opgraderet, står hackere i kø. Jeg foreslår blot at dem med ekspertise i afvejningen skal mødes i et rum, i stedet for at sidde hvert sit sted, med hvert sit mål.

  • 0
  • 1
Bjarne Nielsen

Derfor er det vigtigt at få alle aspekterne fra drift, udvikling og forretning ind i samme rum, så de kan afveje fordel og uleme i forhold til en løsning.

Her er "i samme rum" vigtigt, det må ikke være "i samme hovede".

Ikke bare pga. "4-eyes-principle", men mindst lige så meget fordi at der er værdi i at skulle forklare sig; alle som har udviklet mere end bare en lille smule, ved at kode-bamser er magiske.

Cross-functional betyder, at teamet kan trække på flere dybe kompetancer, ikke at man deler en kasse med 'kasketter' og deraf følgende ansvar ud til folk, som ikke har kompetencen.

PS: Og med et nik til Chris, så ser jeg også alt for tit, at man ofte er meget villig til at dele ud af ansvaret, men ikke af myndigheden.

  • 2
  • 0
Bjarne Nielsen

En læge skal have mod til at gå i aktion.

...og til at lægge skalpellen, hvis det er for farligt.

Man skal have mod til at tænde raketten.

Og modet til at lade være: https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disaster

Jeg har lige ovenfor argumenteret for værdien i cross-functional teams, men husk: "None of Us is as Dumb as All of Us".

I grupper kan ansvaret nemt bliver væk, og mod bliver erstattet med dumdristighed. "Never share a foxhole with anyone braver than yourself".

Det er ikke nok, at folk sidder i samme rum. Der skal også lyttes respektfuldt.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize