Dit system fungerer glimrende. Så længe der er en person, som ved hvorfor.
Virksomheden har et system, der er blevet bygget over syv år. Det virker. Det servicerer kunder. Det kobler til andre systemer. Det gennemfører processer, uden hvilke virksomheden reelt ikke kunne fungere normalt.
I løbet af de syv år arbejdede fem udviklere på projektet. Derudover to freelancere og et bureau. Noget dokumentation ligger i Confluence, noget på Google Drive, noget i tickets. Et sted findes stadig et gammelt dokument vedrørende en af integrationerne. Og når nogen spørger, hvorfor et bestemt stykke af systemet virker på netop den måde, lyder svaret: "Det huskede vist Michał."
Michał forlod virksomheden for tre år siden.
Og det er dér, det rigtige problem begynder.
Ikke fordi systemet er dårligt skrevet. Ikke fordi det pludselig holdt op med at fungere. Problemet er, at virksomheden ophørte med at have fuld viden om sit eget system.
Systemet virker, men virksomheden kan mangle kontrol
Det er en af de mest undervurderede former for teknisk gæld.
Når vi taler om teknisk gæld, tænker vi normalt på gammel kode, forældede biblioteker, arkitekturfejl, mangel på tests eller løsninger, som engang var hurtige, men i dag hæmmer udvikling.
Der findes dog en anden type gæld. Vidensgæld.
Den opstår, når et system er afhængigt af information, som ikke findes i dokumentation, repositories, procedurer eller i organisationen, men kun i hovederne på bestemte personer.
Og så længe de personer er tilgængelige, kan alt se normalt ud.
Problemet opstår ved teamændringer, en udviklers opsigelse, ophør af samarbejde med et softwarehus, servernedbrud, skift af administrator eller behovet for hurtig implementering af en ny løsning.
Pludselig viser det sig, at virksomheden har kode, men ikke viden.
Har en server, men ingen sikkerhed for, hvem der har adgang.
Har en integration, men ved ikke, hvilken konto den blev oprettet under.
Har dokumentation, men ved ikke, hvilken version der er aktuel.
Har en proces, men ved ikke, hvorfor den blev designet netop sådan.
Og så opstår hurtigt spørgsmålet: hvem er egentlig ejer af dette system?
Bus factor — hvad sker der, hvis én person forsvinder?
I IT-verdenen findes begrebet bus factor. Kort sagt angiver det antallet af personer, hvis fravær kan gøre et team ude af stand til effektivt at udvikle eller vedligeholde et projekt.
Det handler selvfølgelig ikke bogstaveligt om en hændelse. Det er en måde at tænke på videnskoncentration.
Hvis kun én person ved, hvordan en kritisk integration fungerer, er bus factor for denne viden én.
Hvis kun én administrator har adgang til produktionen, er bus factor én.
Hvis kun én person ved, hvorfor systemet kører en bestemt proces hver nat, kan bus factor være én.
Hvis virksomheden samarbejder med et eksternt softwarehus, og ingen på kundesiden forstår arkitekturen, opstår et endnu større problem — viden kan befinde sig uden for organisationen.
Det betyder ikke, at enhver virksomhed skal have fem eksperter på hver del af sit system.
Det handler om noget langt enklere: virksomheden bør vide, hvor den kritiske viden findes, og om den kan genvinde den uden en konkret person.
Koden viser hvordan. Ikke altid hvorfor.
En programmør kan læse koden og forstå, hvad en given funktion gør.
Han eller hun vil dog ikke altid vide, hvorfor den blev skrevet på netop den måde.
Det er en enorm forskel.
Man kan finde det stykke, der sender data ud af systemet. Man kan analysere endpointet, parametrene, autorisationen og fejlhåndteringen.
Men koden svarer ikke nødvendigvis på spørgsmål som:
- Hvorfor sender vi data kl. 02:00 om natten?
- Hvorfor bliver denne specifikke status ignoreret?
- Hvorfor prøver systemet præcis tre gange efter en fejl?
- Hvorfor bliver en værdi omregnet før afsendelse?
- Hvorfor kan rækkefølgen af disse operationer ikke ændres?
- Hvorfor bruger denne integration en bestemt konto?
Svaret kan findes i projektets historie, en gammel ticket, en e-mail fra for seks år siden eller — hvad der er værre — udelukkende i hukommelsen hos en person, som ikke længere arbejder i virksomheden.
Derfor bør god dokumentation ikke kun være en instruktion i "hvad man skal klikke på".
Den bør også bevare kontekst og beslutninger.
Den største risiko kan være en integration, som ingen husker
Moderne systemer fungerer næsten aldrig helt isoleret.
De kobler til ERP-systemer. CRM. Betalingsgateways. SMS-leverandører. Kurersystemer. Partner-API'er. Cloud-tjenester. Analysetjenester. Regnskabssystemer. Autorisationsmekanismer.
Hver sådan forbindelse er en del af den teknologiske kæde.
Og hver del af denne kæde kan have sin egen ejer, konto, API-nøgle, certifikat, kontrakt, grænse, API-version og livscyklus.
Efter nogle år husker ingen måske længere, hvem der oprettede en given konto.
Og så kan udløb af et certifikat eller en ændring i et API være nok til, at systemet holder op med at fungere.
Endnu værre er det, hvis virksomheden ikke engang ved, at denne afhængighed eksisterer.
Derfor bliver softwareproveniens, afhængighedsstyring og transparens i softwareforsyningskæden stadigt vigtigere i et modent systemtilgang. NIST fremhæver i sine aktuelle materialer om sikkerhed i forsyningskæden blandt andet betydningen af information om komponenter, deres oprindelse, livscyklus og afhængigheder. SBOM, altså Software Bill of Materials, er et af værktøjerne, der hjælper med at skabe overblik over, hvilke komponenter softwaren består af.
Det er ikke længere udelukkende et security-tema.
Det er også et bestyrelses- og ledelsestema.
For hvis virksomheden ikke ved, hvad dens system er bygget af, bliver det sværere at vurdere risiko, driftsomkostninger og konsekvenser af ændringer.
Dokumentation er ikke en omkostning. Det er en police.
I mange virksomheder betragtes dokumentation som noget, man "gør senere".
Først funktionalitet.
Derefter implementering.
Så rettelser.
Og så næste projekt.
Og dokumentationen?
"Når vi får tid."
Problemet er, at tiden til dokumentation ofte kommer, når det allerede er for sent.
Dokumentation bør fungere som forretningsforsikring. Ikke fordi nogen skal læse den hver dag. Tværtimod — forhåbentlig bruges den sjældent i en nødssituation.
Men når et problem opstår, bør virksomheden kunne besvare grundlæggende spørgsmål:
- Hvordan virker systemet?
- Hvad består det af?
- Hvor er produktionsmiljøet?
- Hvem har adgang?
- Hvilke integrationer er kritiske?
- Hvilke eksterne konti og tjenester bruges?
- Hvad er afhængighederne?
- Hvordan udføres backups?
- Hvordan ser deploymentsprocessen ud?
- Hvad sker der under en nedbrudssituation?
- Hvilke elementer er forretningskritiske?
- Hvorfor blev nøglearkitekturvalg truffet?
- Hvem kan overtage driften af systemet?
Det behøver ikke være hundreder af sider med dokumentation.
God dokumentation skal først og fremmest være brugbar, aktuel og tilgængelig for de rette personer.
"Lad os ikke røre ved det, det virker" er ikke altid en dårlig beslutning
Der er endnu et meget almindeligt problem.
Systemet har kørt i årevis, så virksomheden antager princippet: "Vi rører det ikke. Det virker."
Og nogle gange er det helt fornuftigt.
Ikke al gammel teknologi behøver øjeblikkelig udskiftning. Ikke al gammel kode skal omskrives. Ikke hvert bibliotek betyder katastrofe. Ikke al arkitektur fra flere år tilbage er forkert.
Problemet begynder, når "lad os ikke røre ved det" også betyder:
- "Lad os ikke analysere det."
- "Lad os ikke dokumentere det."
- "Lad os ikke tjekke afhængigheder."
- "Lad os ikke spørge, hvem har adgang."
- "Lad os ikke kontrollere, om vi stadig har alle konti."
- "Lad os ikke blive enige om, hvad der sker, hvis den nuværende leverandør ikke længere er tilgængelig."
Så bliver manglende ændringer ikke en strategi.
Det er en udsættelse af risiko.
Nogle gange er den teknisk bedste beslutning faktisk ikke at ombygge noget.
Men den beslutning bør være baseret på viden om systemet, ikke på manglende viden om systemet.
Hvad bør en revision af et overtaget system omfatte?
Når en virksomhed overtager et system fra et andet softwarehus, en freelancer eller et internt team, bør det første skridt ikke være automatisk at genudvikle alt.
Først skal man forstå, hvad der egentlig er overtaget.
En revision bør svare mindst på nogle grundlæggende områder.
Arkitektur. Hvordan er systemet opbygget? Hvad er dets hovedkomponenter? Hvor ligger dataene? Hvordan kommunikerer de enkelte dele?
Kode og repositories. Har virksomheden komplet kildekode? Er det klart, hvilken gren og version der er produktionskørende? Kan bygge- og deploy-processen reproduceres?
Infrastruktur. Hvor kører produktionen? Hvordan ser testmiljøet ud? Hvem har adgang? Hvordan er monitorering og backup sat op?
Integrationer. Hvad kommunikerer systemet med? Hvilke API'er bruges? Hvem ejer de enkelte konti og nøgler?
Afhængigheder. Hvilke biblioteker, frameworks og eksterne komponenter bruges? Opdateres de? Har de kendte sikkerhedsproblemer? Hvordan er deres livscyklus?
Deploy-proces. Kan en ny person forberede, teste og rulle en ændring ud uden at ringe til en tidligere udvikler?
Viden. Hvad står i dokumentationen, og hvad eksisterer kun i folks hoveder?
Forretningsrisiko. Hvad sker der, hvis en bestemt komponent holder op med at fungere i en time, en dag eller en uge?
Moderne tilgang til sikkerhed i softwareforsyningskæden understreger stadig behovet for viden om komponenter, leverandører, afhængigheder, deres oprindelse og livscyklus. NIST fremhæver også vigtigheden af due diligence over for teknologileverandører samt vurdering af robusthed og risiko relateret til hele forsyningskæden.
Revision betyder ikke "lad os genudvikle alt"
Det er vigtigt, fordi en teknisk revision ofte fejlagtigt ses som ensbetydende med genudvikling.
Men en revision kan ende med en meget simpel konklusion: "Systemet er i orden. Vi skal bare organisere viden og fjerne nogle risici."
Det kan også vise sig, at systemet kun behøver modernisering i ét område.
Eller at det største problem ikke er koden, men manglende adgang til infrastrukturen.
Eller at applikationen er velimplementeret, men ingen har aktuel viden om deploy-processen.
Eller at alt virker, men virksomheden er afhængig af en enkelt ekstern leverandør.
Derfor bør en god analyse af et overtaget projekt svare på spørgsmålet: "Hvad skal vi virkelig ændre, og hvad behøver vi ikke røre?"
Først derefter kan investeringsbeslutninger træffes.
Hvad hvis du skifter softwarehus?
Det er et af de øjeblikke, hvor den usynlige videnst gæld kommer frem i lyset.
Virksomheden afslutter samarbejdet med leverandøren.
Den nye partner får repository'et.
Og begynder at stille spørgsmål:
- "Hvor er produktionen?"
- "Hvordan starter man projektet lokalt?"
- "Hvilken version er aktuel?"
- "Hvad gør denne service?"
- "Hvem har konto til dette API?"
- "Hvad gør denne cron?"
- "Hvorfor kører denne proces på dette tidspunkt?"
- "Hvor kommer denne parameter fra?"
- "Hvad sker der, hvis vi slår den fra?"
Hvis svaret på de fleste spørgsmål er "ved vi ikke", overtager det nye softwarehus ikke projektet. Først skal det opdage det.
Og at opdage et system koster tid. Tid, som klienten betaler senere.
Derfor bør overdragelse af et projekt mellem teams være en proces, ikke blot at smide en ZIP med kode og et password til en konto.
Systemet bør overleve mennesker
Det er nok den vigtigste regel.
Mennesker ændrer sig. Udviklere skifter job. Freelancere afslutter samarbejder. Softwarehuse skifter kunder. Administratorer går videre. Ledelser ændres.
Systemet forbliver.
Derfor bør systemet være designet, så den viden, der er nødvendig for at vedligeholde det, kan genvindes.
Det betyder ikke, at alle medarbejdere skal vide alt.
Det betyder, at organisationen bør have mekanismer til at opbevare viden:
- Repositories.
- Dokumentation.
- Integrationsregister.
- Information om infrastrukturen.
- Adgange styret af virksomheden.
- Beskrivelse af nøgleprocesser.
- Historik over væsentlige beslutninger.
- Information om afhængigheder.
- Nødprocedurer.
- Og frem for alt — mennesker, som ved, hvordan man bruger dokumentationen.
NIST fremhæver i sine retningslinjer for systemplanlægning også formel afklaring af ansvar, driftstatus og roller for de personer, der administrerer, understøtter eller har adgang til systemet.
Det afspejler en bredere ændring i måden at tænke teknologi på.
Et system er ikke kun kode. Et system er også mennesker, processer, infrastruktur, afhængigheder, data, adgang og ansvar.
Hos Web24 starter vi ofte med spørgsmålet: "Hvad har vi egentlig her?"
At overtage et eksisterende projekt bør ikke begynde med et løfte om, at alt bliver skrevet forfra.
Det bør starte med at forstå situationen:
- Hvad virker?
- Hvad virker ikke?
- Hvad er kritisk?
- Hvad er forældet?
- Hvor er de største risici?
- Hvad mangler i dokumentationen?
- Hvilke afhængigheder er usynlige?
- Kan det eksisterende system udvikles sikkert?
- Kræver det modernisering eller blot organisering?
Først derefter kan man beslutte, om projektet skal videreudvikles, ombygges, delvist omskrives eller blot dokumenteres ordentligt.
Det er især vigtigt for projekter, der gennem årene er blevet udviklet af forskellige personer og firmaer.
For en god teknologipartner bør ikke være nødvendig, fordi kun han ved, hvordan systemet virker.
Han bør være nødvendig, fordi han kan videreudvikle systemet, sikre det og overføre viden videre.
Den farligste fejl kan være personen, som allerede er gået
Problemet er ikke altid gammel kode.
Problemet er ikke altid forældet teknologi.
Problemet er ikke altid mangel på det nyeste framework.
Nogle gange er den største risiko en information, som ingen har skrevet ned.
Et password.
En arkitekturbeslutning.
En integration.
En undtagelse i processen.
Én person, som i årevis vidste, hvordan det virkede.
Og så gik vedkommende.
Derfor er det værd at stille sig selv i dag et meget enkelt spørgsmål: Hvis den person, som bedst kender jeres system, forsvandt fra virksomheden i morgen, ville I så stadig være i stand til at administrere det?
Hvis svaret er "ja" — fremragende.
Hvis svaret er "ved ikke" — så er det værd at tjekke.
Og hvis svaret er "definitivt nej" — så har I sandsynligvis netop fundet et af de vigtigste områder af teknologisk risiko i jeres virksomhed.
Systemet bør være større end én persons hukommelse.
