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.

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:

• 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’ eller ‘two-man rule’

er en kontrolmekanisme for kritiske operationer. Når den anvendes, skal der minimum være to autoriserede personer til at gennemføre den kritiske operation. Ved at benytte princippet kan man beslutte en it-sikkerhedspolitik, der er sikker, på områder, hvor man ellers har benyttet funktionsadskillelse. ‘4-eyes principle’ kan i softwareudvikling håndhæves af source code-versionsstyringssystemer som git og bitbucket, der kan håndtere ‘Pull Requests’, der sikrer, at flere personer har været ind over og godkendt vigtige rettelser i koden.

‘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.

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.