Der findes få ord i IT, der kan få kreative og dygtige specialister til at miste begejstringen hurtigere end standardisering. Det lyder af governance boards, lange dokumenter, godkendelsesprocesser og nogen, der har besluttet, at der kun findes én rigtig måde at gøre tingene på. Innovation lyder derimod af frihed, nye idéer, eksperimenter og muligheden for at vælge den teknologi, der passer bedst til problemet.
Derfor bliver de to begreber ofte stillet op som modsætninger: Enten standardiserer vi, eller også innoverer vi. Jeg synes, det er en falsk modsætning. Faktisk vil jeg argumentere for, at god standardisering ofte er en forudsætning for innovation. Ikke fordi alle skal gøre alting ens, men fordi mennesker ikke bør bruge deres tid på at genopfinde de samme grundlæggende løsninger igen og igen.
Hvis ti teams hver især vælger deres egen måde at håndtere identitet, logging, deployment, secrets, monitorering, netværk og backup på, har vi ikke nødvendigvis skabt ti innovative teams. Vi har skabt ti forskellige måder at løse de samme kedelige problemer på.
Frihed til at vælge alt er ikke det samme som frihed til at skabe værdi
Jeg kan godt forstå tiltrækningen ved fuld teknologisk frihed. Dygtige specialister vil gerne vælge de værktøjer, de mener passer bedst, og det er som udgangspunkt sundt. Vi ansætter trods alt specialister, fordi de ved noget, og det giver ikke meget mening bagefter at reducere dem til mennesker, der blot følger instruktioner.
Men der er forskel på autonomi og total valgfrihed.
Forestil dig en organisation med 20 udviklingsteams, hvor hvert team frit vælger programmeringssprog, CI/CD-platform, logging-framework, cloud services, identity-løsning, database, secrets management og monitoring. Hvert enkelt valg kan være fuldstændig rationelt isoleret set, men problemet opstår, når man ser organisationen som helhed. Pludselig kræver driften kompetencer i fem forskellige deployment-modeller, sikkerhedsteamet skal forstå otte måder at håndtere credentials på, og observability kræver integration med seks forskellige værktøjer.
Nye medarbejdere skal lære et nyt teknisk landskab, hver gang de skifter team, og når en specialist forlader virksomheden, opdager man måske, at vedkommende også var den eneste, der virkelig forstod den teknologi, teamet valgte tre år tidligere. Lokalt har hvert team optimeret. Globalt har organisationen skabt kompleksitet.
Det er et klassisk arkitekturproblem, fordi den enkelte beslutning sagtens kan være god, mens summen af beslutningerne bliver dårlig.
Standardisering i IT handler om at vælge, hvor variation giver værdi
Når jeg taler om standardisering i IT, mener jeg derfor ikke, at enhver teknologisk beslutning skal centraliseres, eller at alle systemer nødvendigvis skal bygges på præcis samme måde. Det interessante spørgsmål er snarere, hvor valgfrihed faktisk skaber værdi.
Hvis et team udvikler en løsning, hvor valget af database er afgørende for produktets egenskaber, skal der naturligvis være plads til at vælge den rigtige teknologi. Men hvis valget mellem tre næsten identiske logging-frameworks primært skyldes personlige præferencer, er jeg ikke sikker på, at organisationen vinder noget ved variationen.
God standardisering handler derfor ikke om at standardisere alt. Den handler om at standardisere de områder, hvor forskellighed ikke giver virksomheden en reel fordel. Når vi fjerner unødvendige valg omkring de grundlæggende ting, frigør vi tid, opmærksomhed og mental kapacitet til de problemer, hvor kreativitet og innovation faktisk betyder noget.
Standardisering skal gøre de kedelige beslutninger kedelige.
Innovation sker sjældent i deployment-pipelinen
Der findes selvfølgelig virksomheder, hvor den tekniske platform i sig selv er produktet, og hvor innovation i infrastruktur, deployment eller observability kan være en konkurrenceparameter. Men i langt de fleste organisationer er kunderne relativt ligeglade med, hvilket CI/CD-system virksomheden bruger. De køber ikke produktet, fordi Kubernetes-konfigurationen er elegant, og de vælger ikke virksomheden, fordi udviklingsteamet fandt en særligt kreativ måde at distribuere secrets på.
Det betyder ikke, at de tekniske fundamenter er uvigtige. Tværtimod. De er afgørende for sikkerhed, stabilitet og evnen til at levere hurtigt, og netop derfor giver det mening at gøre dem så gennemarbejdede og genanvendelige som muligt.
Hvis teams får en veldesignet platform, hvor identity, deployment, logging, monitoring, sikkerhedsbaseline og netværksintegration allerede er løst på en fornuftig måde, kan de bruge langt mere energi på dét, der faktisk adskiller virksomheden fra konkurrenterne. Det er ikke mindre innovation. Det er innovation med færre distraktioner.
Den gode standard er en genvej, ikke en fængselsmur
Problemet opstår, når standardisering bliver et mål i sig selv. Jeg har set arkitekturprincipper og governance-modeller, hvor det tilsyneladende vigtigste succeskriterium var, at ingen kunne træffe en beslutning uden at involvere mindst tre udvalg og et Excel-ark. Det er selvfølgelig ikke det, jeg argumenterer for.
En standard har kun værdi, hvis den gør organisationen bedre i stand til at arbejde. Hvis en standard konsekvent gør teams langsommere uden samtidig at reducere risiko, kompleksitet eller omkostninger, bør man stille spørgsmål ved standarden. Det samme gælder, hvis den teknologi, organisationen har standardiseret på, ikke længere passer til de problemer, den skal løse.
Standarder skal derfor kunne udfordres, men der er stor forskel på at sige “Jeg har et konkret behov, som den eksisterende standard ikke kan løse” og “Jeg synes bare, den her teknologi er sjovere.” Den første er et arkitekturproblem, der fortjener en diskussion. Den anden er ikke nødvendigvis et forretningsargument.
Jeg synes derfor, at den gode standard skal fungere som en genvej. Den skal være den nemmeste og mest attraktive vej for langt de fleste behov, fordi organisationen allerede har løst en række problemer på forhånd. Hvis teams konstant forsøger at komme uden om standarden, er det værd at undersøge hvorfor. Måske er medarbejderne bare glade for at opfinde deres egne løsninger, men måske er standarden faktisk dårlig.
Governance bør også kunne lære.
Golden paths er mere interessante end hegn
Jeg kan godt lide tanken om det, der ofte kaldes golden paths. I stedet for at organisationen primært fortæller teams, hvad de ikke må gøre, giver man dem en veldesignet vej, der gør det nemt at gøre det rigtige.
Hvis et team vil deploye en ny service, ligger pipelinen allerede klar. Secrets management er integreret, logging og metrics følger med, og identity og adgangskontrol er tænkt ind fra starten. Governance optræder dermed ikke kun som kontrol, men som en service til organisationen.
Det interessante ved den model er, at teams ikke følger standarden, fordi nogen har skrevet et dokument, der siger, at de skal. De følger den, fordi alternativet er mere besværligt. Det er efter min mening et langt stærkere arkitekturprincip, for hvis den ønskede vej også er den nemmeste vej, behøver man langt mindre kontrol.
Autonomi kræver rammer
Det kan måske lyde paradoksalt, men jeg mener faktisk, at standardisering og autonomi kan understøtte hinanden. Hvis et team ved, hvilke rammer det arbejder indenfor, kan det træffe langt flere beslutninger selv.
Problemet opstår ofte, når rammerne er uklare. Så bliver beslutninger eskaleret, fordi ingen ved, hvor mandatet stopper. Arkitekter bliver trukket ind i detaljer, sikkerhed skal godkende småting, og ledelsen vil pludselig se tekniske designbeslutninger, fordi organisationen ikke har etableret de principper, som gør det muligt at delegere dem.
Det kan ligne governance, men i praksis bliver det micromanagement på organisationsniveau.
Veldefinerede standarder kan gøre det modsatte. De kan etablere et område, hvor teamet ved, at inden for disse rammer har det selv mandatet til at vælge og handle. Det er en ret stærk form for empowerment, for autonomi betyder ikke, at der ingen rammer findes. Det betyder, at mennesker har et tydeligt mandat inden for rammer, de forstår.
Det gælder i øvrigt både teknologi og ledelse.
Arkitekten skal ikke eje alle beslutninger
Der ligger også en faldgrube for os, der arbejder med arkitektur. Når man bliver ansvarlig for sammenhængen på tværs af organisationen, kan det være fristende at begynde at eje stadig flere beslutninger. Man opdager kompleksiteten og tænker naturligt, at løsningen må være mere central kontrol.
Men hvis arkitekturteamet skal godkende alle tekniske beslutninger, har man sandsynligvis ikke skabt god arkitektur.
Man har skabt en kø.
Arkitekturens opgave bør efter min mening i langt højere grad være at etablere principper, platforme og standarder, som gør organisationen i stand til at træffe gode beslutninger uden konstant at spørge arkitekten. Det minder påfaldende meget om god ledelse. En leder skal heller ikke træffe alle beslutninger for teamet, men skabe retning og rammer, så teamet selv kan træffe flere gode beslutninger.
På samme måde bør en arkitekt ikke være organisationens tekniske orakel, som alle løsninger skal forbi. Den bedste arkitektur er ofte den, der gør arkitekten mindre nødvendig i de daglige beslutninger.
Standarder skal kunne udfordres
Der findes dog en anden risiko ved standardisering. Når først en organisation har investeret i en bestemt måde at gøre tingene på, kan standarden begynde at få sit eget liv. Det, der oprindeligt var et fornuftigt valg, bliver gradvist til “sådan gør vi her”, og nogle år senere kan ingen længere helt forklare hvorfor.
Det er farligt, fordi teknologier ændrer sig, organisationer ændrer sig, og risikobilledet ændrer sig. Det, der var den rigtige standard for fem år siden, er ikke nødvendigvis den rigtige standard i dag.
Derfor bør standarder ikke kun etableres. De bør regelmæssigt udfordres med nogle ret enkle spørgsmål: Hvilket problem løser standarden? Eksisterer problemet stadig? Er forudsætningerne de samme? Er der kommet en bedre løsning? Og er omkostningen ved at ændre standarden større eller mindre end omkostningen ved at beholde den?
Det betyder ikke, at man skal skifte teknologi hvert andet år, fordi noget nyt ser spændende ud. Stabilitet har også værdi. Men der er stor forskel på stabilitet og stagnation.
Innovation kræver også evnen til at sige nej
Der findes en romantisk forestilling om innovation som en proces, hvor alle gode idéer får lov at blomstre. Sådan fungerer virkeligheden ikke. Enhver organisation har begrænsede penge, begrænset tid og begrænset opmærksomhed, og hvis hver ny idé samtidig introducerer endnu en teknologi, endnu en platform eller endnu et driftsmønster, vokser kompleksiteten hurtigere end organisationens evne til at håndtere den.
På et tidspunkt begynder innovationen derfor selv at gøre organisationen langsommere. Ikke fordi idéerne nødvendigvis var dårlige, men fordi man aldrig fjernede noget og aldrig satte grænser for variationen.
Teknisk kompleksitet har en pris, selv når fakturaen ikke kommer med det samme. Den betales senere gennem længere onboarding, vanskeligere fejlsøgning, højere sikkerhedsrisiko, flere kompetencekrav og langsommere ændringer.
Derfor er et velbegrundet nej også en del af teknologisk ledelse. Ikke nødvendigvis et nej til idéen, men måske et nej til, at idéen behøver endnu et nyt teknisk fundament.
Standardisering beskytter handlefriheden
Det kan virke paradoksalt, men en af de vigtigste grunde til at standardisere er efter min mening at bevare organisationens handlefrihed. Når teknologilandskabet bliver for fragmenteret, bliver ændringer dyre. Hvis hver løsning er unik, kræver transformation, sikkerhedsændringer, cloud migration eller nye regulatoriske krav individuelle projekter, og organisationen mister gradvist evnen til at bevæge sig samlet.
Det minder meget om teknisk gæld. Man mærker ikke nødvendigvis konsekvensen den dag, variationen bliver introduceret, men renterne kommer senere.
God arkitektur handler derfor ikke kun om at understøtte de løsninger, virksomheden vil bygge i dag. Den handler også om at beskytte mulighederne for at træffe andre beslutninger i morgen. Det kræver nogle gange, at vi accepterer mindre lokal valgfrihed for at bevare større organisatorisk frihed.
Vi skal standardisere fundamentet – ikke ambitionerne
Jeg tror ikke på organisationer, hvor alle teams skal være ens. Dygtige mennesker skal have plads til at eksperimentere, udfordre eksisterende løsninger og finde nye veje. Hvis standardisering bruges til at fjerne den mulighed, bliver den hurtigt en hæmsko.
Men friheden bør bruges dér, hvor den gør en forskel.
Jeg vil langt hellere have, at et team bruger sin kreativitet på at forstå kunderne, forbedre produktet, automatisere en proces eller udvikle en løsning, konkurrenterne ikke har tænkt på, end på at opfinde organisationens syvende måde at håndtere logging på.
Det er derfor, jeg ikke ser standardisering som modsætningen til innovation. Jeg ser den som en måde at skabe plads til den.
Hvis alle teams opfinder deres egen måde at løse de samme grundproblemer på, har vi ikke nødvendigvis skabt innovation. Vi har bare skabt variation.
God standardisering reducerer den variation, der ikke skaber værdi, så organisationen kan bruge sin energi på den variation, der gør.
Det er efter min mening en af arkitekturens vigtigste opgaver.