Der findes en bestemt form for selvtillid i IT, som jeg synes er farlig: forestillingen om, at vi kan tænke os frem til den perfekte arkitektur på forhånd.
Hvis bare vi analyserer nok, laver nok roadmaps, tegner nok diagrammer og involverer de rigtige mennesker, kan vi vælge den rigtige platform, den rigtige integrationsmodel, den rigtige dataløsning og den rigtige teknologi — og så kan organisationen trygt bygge videre derfra.
Det lyder rationelt. Problemet er bare, at virkeligheden sjældent respekterer vores arkitekturdiagrammer.
Forretningen ændrer sig. Leverandører ændrer sig. Priser ændrer sig. Regulering ændrer sig. Teknologier modnes, forsvinder eller bliver opkøbt. Medarbejdere skifter job, virksomheder fusionerer, nye markeder opstår, og gamle antagelser viser sig at være forkerte.
Det betyder ikke, at vi skal holde op med at planlægge. Tværtimod. Men det betyder, at god arkitektur ikke kun handler om at træffe gode beslutninger. Den handler også om at gøre det muligt at ændre dem.
Det synes jeg er en af de mest undervurderede kvaliteter ved arkitektur.
Den perfekte løsning findes kun i PowerPoint
Arkitekturarbejde bliver nogle gange behandlet, som om målet er at eliminere usikkerhed. Vi analyserer muligheder, vurderer risici og forsøger at finde frem til den løsning, der bedst opfylder de krav, vi kender i dag.
Det skal vi selvfølgelig gøre. Men der er en grænse for, hvor meget fremtid man kan designe sig ud af.
En løsning kan være fuldstændig rationel med den viden, organisationen har i dag, og stadig vise sig at være forkert tre år senere. Ikke fordi arkitekterne var inkompetente, men fordi verden ændrede sig.
Det er derfor, jeg bliver skeptisk, når beslutninger bliver beskrevet som endelige. Når nogen siger, at “nu har vi valgt platform”, “nu standardiserer vi på den her teknologi” eller “nu er retningen lagt”, får jeg næsten automatisk lyst til at spørge: Hvad ville få os til at vælge anderledes?
Hvis svaret reelt er “ingenting”, har vi måske ikke længere en arkitekturbeslutning. Så har vi fået en trosretning.
Arkitektur bør efter min mening ikke handle om at beskytte gårsdagens beslutning. Den bør handle om at skabe de bedste muligheder for morgendagens.
Den bedste arkitektur er ikke den, der forudsiger fremtiden
Jeg synes faktisk, der er noget befriende i at acceptere, at vi ikke kan forudsige fremtiden særlig præcist.
Det ændrer nemlig arkitektens rolle.
I stedet for at forsøge at designe den løsning, der vil være rigtig under alle tænkelige fremtidige scenarier, bliver opgaven i højere grad at designe en løsning, som organisationen kan ændre uden at skulle rive alt ned.
Det er forskellen på at optimere for forudsigelse og at optimere for optionalitet.
Optionalitet handler grundlæggende om at bevare muligheden for at vælge senere. Kan vi skifte leverandør? Kan vi erstatte en komponent uden at genbygge hele platformen? Kan vi ændre integrationsmønstret? Kan vi flytte data? Kan vi introducere ny teknologi uden at hele organisationen skal migreres på én gang?
Og måske vigtigst: Kan vi ændre retning uden at en teknologisk beslutning truffet i dag stadig styrer virksomheden ti år senere?
Det er den slags spørgsmål, jeg synes arkitektur bør stille.
For fremtiden belønner sjældent dem, der gættede helt rigtigt. Den belønner ofte dem, der havde råd til at justere.
Reversible og irreversible beslutninger er ikke det samme
Ikke alle teknologiske beslutninger fortjener den samme mængde analyse, men organisationer behandler dem ofte, som om de gør.
Det er efter min mening en fejl.
Hvis en beslutning er let at omgøre, bør vi måske bare træffe den, lære noget og justere senere. Hvis den derimod låser data, kompetencer, processer eller forretningslogik fast i mange år, bør vi være langt mere kritiske.
Der er en stor forskel på at vælge et mindre værktøj, som kan udskiftes på få uger, og at vælge en platform, der bliver centrum for virksomhedens data, integrationer og forretningsprocesser det næste årti.
Alligevel ser man ofte organisationer bruge uforholdsmæssigt meget tid på små beslutninger, mens de store arkitektoniske bindinger bliver behandlet som almindelige indkøbsvalg.
Det giver enten handlingslammelse eller det modsatte: dybe afhængigheder, som først bliver synlige, når det er for sent.
God arkitektur kræver derfor også dømmekraft omkring, hvilke beslutninger der faktisk fortjener at blive gjort tunge.
Lock-in er ikke problemet. Uforstået lock-in er.
Jeg skrev tidligere, at vendor lock-in ikke automatisk er djævelen, og det gælder også her.
Enhver seriøs teknologisk beslutning skaber afhængigheder. Hvis vi vælger en cloud-platform, en database, et ERP-system eller et udviklingsframework, investerer organisationen gradvist i kompetencer, integrationer og processer omkring det valg.
Det kan være helt rationelt.
Problemet opstår, når afhængigheden ikke er forstået.
Hvis vi vælger en proprietær service, fordi den giver os markant højere udviklingshastighed, bedre sikkerhed eller lavere kompleksitet, kan det være en fremragende handel. Men så bør vi også vide, hvad det betyder, hvis vi senere vil væk.
Hvor sidder data? Hvor meget forretningslogik ligger i platformen? Hvor mange integrationer afhænger af leverandørspecifik funktionalitet? Hvor sjældne er kompetencerne? Og hvor meget af organisationens drift bygger på antagelsen om, at leverandøren fortsætter nogenlunde som i dag?
Det er efter min mening dér, arkitekturen skal være voksen.
Ikke ved at råbe “lock-in” hver gang nogen foreslår en proprietær service, men ved at forstå prisen på afhængigheden og acceptere den bevidst.
Exit-strategi er almindelig risikostyring
Jeg synes, mange teknologibeslutninger ville blive bedre, hvis vi tidligere stillede spørgsmålet: Hvordan kommer vi ud igen?
Det kan lyde negativt. Hvis vi lige har valgt en strategisk leverandør, hvorfor skal vi så allerede tale om exit?
Fordi det er billigst at tænke på udgangen, før man får brug for den.
Når først relationen er blevet kritisk, data er flyttet ind, processer er tilpasset, og integrationer er bygget, er virksomhedens forhandlingsposition en anden. Det gælder både teknisk og kommercielt.
En exit-strategi betyder ikke, at vi forventer at skifte leverandør. Det betyder bare, at vi ikke ønsker først at opdage vores afhængighed den dag, vi bliver tvunget til at gøre noget ved den.
Det er ikke pessimisme. Det er almindelig risikostyring.
Og jeg synes faktisk, det er bemærkelsesværdigt, hvor ofte organisationer laver grundige business cases for at komme ind i en platform, men næsten ingen analyse af, hvad det vil koste at komme ud igen.
Data er ofte det egentlige fængsel
Når man taler om lock-in, fokuserer diskussionen ofte på selve teknologien. Men i praksis er det ofte data og forretningslogik, der gør en løsning vanskelig at forlade.
Hvis data ligger i proprietære strukturer, er dårligt dokumenteret eller tæt bundet til platformens workflows, bliver en migration hurtigt langt mere kompleks end forventet.
Det samme gælder, hvis virksomhedens regler, processer og forretningslogik gradvist flytter ind i konfigurationer, scripts og workflows, der kun eksisterer inde i leverandørens produkt.
På et tidspunkt er spørgsmålet ikke længere bare, om virksomheden kan eksportere sine data. Spørgsmålet er, om virksomheden stadig forstår sin egen forretning uden platformen.
Det synes jeg er en langt mere alvorlig afhængighed.
Derfor bør datamodeller, integrationer og ejerskab efter min mening fylde langt mere i arkitekturdiskussioner end de ofte gør. En moderne platform kan være fantastisk på overfladen og stadig være en dårlig strategisk beslutning, hvis den gør virksomhedens egne data vanskeligere at forstå og flytte.
Abstraktion er ikke gratis
En klassisk reaktion på frygten for lock-in er at bygge abstraktionslag.
Hvis vi bare skjuler leverandøren bag vores egen API, platform eller framework, kan vi jo skifte senere.
Nogle gange er det en rigtig god idé. Andre gange bygger vi bare endnu et lag kompleksitet, som organisationen derefter selv skal eje.
Det er værd at huske, at abstraktion ikke er gratis.
Hver gang vi skjuler en platform bag et generisk lag, risikerer vi også at miste noget af den værdi, der gjorde platformen attraktiv i første omgang. I værste fald ender organisationen med at bruge en avanceret cloud-platform som en meget dyr virtuel server, fordi arkitekturen skal være så portabel, at ingen tør bruge nogen af de funktioner, man faktisk betaler for.
Det er ikke nødvendigvis robusthed.
Det kan også være frygt forklædt som arkitektur.
God arkitektur handler derfor ikke om at eliminere alle bindinger, men om bevidst at vælge, hvilke bindinger organisationen vil acceptere, og hvilke den aktivt vil beskytte sig imod.
Fleksibilitet kan også blive dyrt
Optionalitet har nemlig selv en pris.
Hvis organisationen forsøger at holde alle muligheder åbne hele tiden, kan arkitekturen blive absurd kompleks. Vi understøtter flere databaser, fordi vi måske vil skifte senere. Vi bygger til flere clouds for ikke at blive afhængige af én. Vi introducerer ekstra abstraktionslag, så alt teoretisk kan udskiftes, og vi vælger generiske standarder, som ingen platform rigtig er god til, fordi de virker mere portable.
Til sidst har vi bygget en løsning, der er så fleksibel, at den er dyrere, langsommere og vanskeligere at drive end nogen af de fremtider, vi forsøgte at beskytte os imod.
Det er heller ikke god arkitektur.
Den interessante diskussion er derfor ikke, om vi ønsker fleksibilitet. Det gør alle. Spørgsmålet er, hvor meget vi er villige til at betale for den, og hvor den faktisk har strategisk værdi.
Hvis sandsynligheden for at skifte cloud-platform er meget lille, kan det være fuldstændig rationelt at acceptere mere lock-in og få højere produktivitet nu. Hvis leverandøren derimod kontrollerer en kritisk del af virksomhedens produkt, data eller forretningsproces, er regnestykket måske et andet.
Det kræver dømmekraft. Ikke dogmer.
Standardisering kan både skabe og begrænse handlefrihed
Jeg har tidligere skrevet om standardisering som en måde at reducere kompleksitet og skabe mere autonomi. Det står jeg stadig ved.
Men standardisering kan også blive en fælde, hvis den bliver for rigid.
En standard er nyttig, fordi den reducerer antallet af valg og giver organisationen et fælles fundament. Men hvis standarden bliver så dominerende, at nye behov altid skal presses ind i den samme løsning, begynder den at begrænse organisationen.
Det gælder især, når standarden oprindeligt blev valgt under helt andre forudsætninger.
“Det er vores standard” er efter min mening ikke et argument. Det er højst begyndelsen på en forklaring.
En god standard bør eksistere, fordi den stadig løser et relevant problem bedre end alternativerne. Hvis ingen længere kan forklare hvorfor, er det tid til at undersøge den.
Arkitekturprincipper må ikke erstatte tænkning
Jeg kan godt lide arkitekturprincipper, når de fungerer som beslutningsstøtte. Jeg kan langt mindre lide dem, når de bliver religiøse bud.
Et princip som “cloud first” kan være nyttigt, hvis organisationen ønsker at undgå unødvendig on-prem-kompleksitet. Men hvis det bliver fortolket som, at enhver workload altid skal i cloud uanset pris, risiko og karakter, er princippet holdt op med at hjælpe.
Det samme gælder “buy before build”, “API first”, “SaaS first”, “open source first” eller næsten enhver anden kort formulering.
Principper er gode, fordi de gør de typiske beslutninger lettere. Men de må ikke erstatte tænkning.
Et sundt arkitekturprincip bør kunne udfordres af et konkret behov, og organisationen bør kunne forklare både hvorfor princippet findes, og hvornår en undtagelse giver mening. Ellers har man bare erstattet teknisk dømmekraft med slogans.
Teknisk gæld reducerer vores mulighed for at vælge
Der er også en vigtig forbindelse til teknisk gæld.
Teknisk gæld bliver ofte beskrevet som noget, der gør systemer dyrere at vedligeholde, og det er selvfølgelig rigtigt. Men jeg synes, den mere strategiske konsekvens er, at teknisk gæld reducerer virksomhedens handlefrihed.
Hvis systemerne er så tæt koblede, at enhver ændring rammer ti andre systemer, bliver det sværere at ændre retning. Hvis deployment er manuel og risikofyldt, bliver eksperimenter dyrere. Hvis data er spredt og dårligt forstået, bliver nye initiativer langsommere. Og hvis ingen tør ændre et centralt system, fordi konsekvenserne er ukendte, har organisationen ikke bare et teknisk problem.
Den har mistet noget af sin evne til at vælge.
Det er efter min mening en langt mere interessant måde at se teknisk gæld på.
Modernisering handler så ikke kun om at gøre IT-landskabet pænere eller reducere driftsproblemer. Det handler også om at købe handlefrihed tilbage.
Gode grænser gør ændringer billigere
En af de ting, jeg derfor synes er mest værdifuld i arkitektur, er klare grænser mellem systemer, domæner, teams og dataejerskab.
Jo tydeligere organisationen forstår, hvor én ting stopper og en anden begynder, desto lettere bliver det normalt at ændre delene uafhængigt.
Det lyder måske teknisk, men konsekvensen er i høj grad organisatorisk.
Hvis alt afhænger af alt, bliver enhver ændring strategisk. Hvis komponenter derimod har klare ansvar og veldefinerede interfaces, kan langt flere beslutninger træffes lokalt.
Det skaber ikke bare en pænere arkitektur.
Det skaber en organisation, der kan bevæge sig hurtigere.
Og det er i sidste ende en af de vigtigste grunde til, at arkitektur betyder noget.
Arkitektur skal ikke bevise, at vi havde ret
Der findes også en menneskelig dimension i det her, som måske er endnu vanskeligere end teknologien.
Når mennesker har investeret tid, prestige og karriere i en bestemt løsning, bliver det sværere at indrømme, at forudsætningerne senere har ændret sig.
Arkitekturen bliver personlig.
Hvis man var den person, der argumenterede hårdt for platformen for tre år siden, kan det føles som et nederlag senere at foreslå noget andet.
Det synes jeg er farligt.
Arkitekturens opgave er ikke at bevise, at vores tidligere beslutninger var geniale. Den er at hjælpe virksomheden med at træffe den bedste beslutning med den viden, vi har nu.
Hvis forholdene ændrer sig, bør beslutningen kunne ændre sig med dem.
Ellers beskytter vi ikke arkitekturen.
Vi beskytter vores ego.
Den stærkeste arkitektur giver plads til at tage fejl
Jeg tror derfor, at en af de vigtigste kvaliteter ved god arkitektur er ydmyghed.
Vi skal træffe beslutninger. Vi skal vælge platforme, standarder og retninger, og vi kan ikke udskyde alt med henvisning til, at fremtiden er usikker. Men vi bør samtidig acceptere, at nogle af vores beslutninger vil vise sig at være forkerte.
Det interessante er derfor ikke kun, om vi træffer den bedste beslutning i dag. Det er også, hvor dyrt det bliver at opdage, at vi tog fejl.
En stærk arkitektur reducerer ikke risikoen for at tage fejl til nul. Det er urealistisk. Den reducerer konsekvensen af at tage fejl.
Organisationer, der kan ændre mening relativt billigt, kan lære hurtigt. Organisationer, hvor enhver større teknologisk beslutning bliver permanent, bliver langt mere forsigtige. Eksperimenter bliver dyrere, innovation bliver mere risikabel, og tidligere valg får stadig større magt over fremtidige muligheder.
Det er derfor, jeg ser optionalitet som en strategisk egenskab ved arkitektur og ikke bare som teknisk elegance.
Den bedste arkitektur er ikke nødvendigvis den, der forudsiger fremtiden. Det er den, der giver os råd til at tage fejl.
Og måske er det i virkeligheden noget af det mest værdifulde, arkitektur kan gøre for en virksomhed.