Dit system fungerer fantastisk. Så længe den, der ved hvorfor, er til stede.
Forestil dig en virksomhed, der har et system, som har kørt i syv år. Det er vokset trin for trin. Først byggede et softwarehus det. Senere overtog en freelancer en del. Senere skrev et nyt team modul B2B. En anden bureau tilsluttede CRM. Endnu en anden integrerede betalinger.
Systemet virker.
Virksomheden tjener penge på det.
Medarbejderne bruger det dagligt.
Kunderne aner ikke, hvor mange processer der kører i baggrunden.
Der er bare ét problem.
Ingen ved længere præcist, hvordan det hele fungerer.
Dokumentationen ligger delvist i Confluence. Noget er på Google Drive. Noget står i tickets. Én integration er beskrevet i en mail fra for fire år siden.
Og den vigtigste ting "tror vi, Lukas husker".
Men Lukas forlod virksomheden for tre år siden.
Og i tre år skete der intet.
Indtil en tirsdag morgen.
Systemet virker. Betyder det, at alt er i orden?
Dette er en af de mest bedragende tilstande, et virksomheds-system kan befinde sig i.
Det virker.
Der er ingen nedbrud.
Brugerne er tilfredse.
Salg bruger applikationen.
Ordrer går igennem.
Data lander i CRM.
Rapporterne genereres.
Så den naturlige reaktion er: Rør det ikke. Hvorfor rode med noget, der fungerer?
Og naturligvis - der er ingen grund til at ændre et fungerende system bare fordi man kan.
Problemet er, at systemet teknisk set kan være stabilt, men organisatorisk meget ustabilt.
Det kan fungere i dag, men ingen ved, hvad der sker, hvis man skal skifte server, API-leverandør, domæne, bibliotek, autentificeringsmetode eller et forretningsprocesstykke.
Det kan være effektivt, men afhængigt af én person.
Det kan være sikkert, men ingen ved, hvor alle adgangsnøglerne er.
Det kan være i udvikling, men kun af den person, som kender historien bag alle beslutningerne.
Og her kommer begrebet bus factor ind i billedet.
Hvor mange personer kan forsvinde, før projektet får problemer?
Bus factor er en meget simpel, om end brutal, idé.
Spørgsmålet er: Hvor mange personer skal blive utilgængelige, før projektet ikke længere kan vedligeholdes forsvarligt?
Hvis svaret er: "En", så har vi et problem.
Hvis svaret er: "To, men de arbejder begge i en anden virksomhed", har vi et endnu større problem.
Det handler ikke kun om bogstavelig "forsvinden" af mennesker.
En udvikler kan forlade virksomheden.
En freelancer kan stoppe samarbejdet.
Et softwarehus kan ophøre med at supportere.
En administrator kan skifte job.
Den ansvarlige for en bestemt integration kan flytte til en anden afdeling.
Vidensindehaveren kan blive syg eller være utilgængelig i flere uger.
Hvis forståelsen af systemet forsvinder sammen med personen, har virksomheden ikke et personalemæssigt problem.
Den har et forretningsproblem.
Koden fortæller ikke altid, hvorfor noget er lavet
Man kan sige: "Vi har kildekoden — en ny udvikler kan bare læse den."
Teoretisk set ja.
I praksis svarer koden primært på spørgsmålet: hvordan systemet gør noget.
Den svarer ikke altid på spørgsmålet: hvorfor det gør det på netop den måde.
Og det er en stor forskel.
I koden kan der være en betingelse: "Hvis kunden har en bestemt kontotype, udfør operation X."
En ny udvikler kan finde den.
Men hvordan skal vedkommende vide hvorfor?
Det kan være et forretningskrav.
Det kan være rest fra en gammel integration.
Det kan være en sikring mod en fejl i et eksternt API.
Det kan være en omvej for et problem, der opstod for fem år siden.
Det kan være en løsning for et særligt tilfælde hos en stor kunde.
Det kan være der af en god grund.
Eller af ingen årsag.
Uden kontekst er det svært at vurdere.
Derfor bør systemdokumentation ikke begrænse sig til instruktioner:
"klik her, så her".
Den mest værdifulde dokumentation beskriver ofte beslutninger og afhængigheder, ikke kun hvordan funktioner bruges.
Den farligste viden er den, der kun findes i én persons hoved
Virksomheder har ofte dokumentation. Problemet er, at dokumentation ikke altid er det samme som viden.
Vi kan have en API-beskrivelse — men ikke vide, hvorfor vi bruger netop det API.
Vi kan have en deployment-guide — men ikke en liste over alle steder, hvor konfiguration skal ændres.
Vi kan have en integrationsbeskrivelse — men ikke vide, hvad der sker, hvis en ekstern leverandør ændrer autentificeringen.
Vi kan have en liste over servere — men ikke vide, hvilken der er kritisk for en given proces.
Vi kan have adgang til repositoriet — men ikke adgang til kontoen, hvor produktionens infrastruktur ligger.
Det er præcis disse elementer, der kan forvandle en tilsyneladende simpel ændring til flere dages undersøgelser.
En integration, der har virket i fem år, er stadig en afhængighed
Et af de mest oversete områder er eksterne tjenester;
- Betalingsløsninger.
- SMS.
- E-mail.
- CRM.
- ERP.
- Korttjenester.
- Kurer-systemer.
- Marketingplatforme.
- Bogføringssystemer.
- Cloudtjenester.
- Eksterne API'er.
- Open source-biblioteker.
Hver af disse er en del af et større økosystem.
Hvis dit system bruger ti eksterne tjenester, har du ikke ét system. Du har systemet plus ti afhængigheder. Og hver af dem kan ændre sig.
En leverandør kan ændre API'et.
Den kan lukke tjenesten.
Den kan ændre prismodellen.
Den kan udfase en gammel version.
Den kan indføre nye sikkerhedskrav.
Den kan blive opkøbt af en anden virksomhed.
Derfor bliver viden om komponenters oprindelse og softwareafhængigheder stadig vigtigere. NIST fremhæver bl.a. betydningen af SBOM, Software Bill of Materials — en formel liste over komponenter brugt til at bygge softwaren. En sådan liste hjælper med at forstå, hvad systemet består af, og hurtigere vurdere konsekvenserne af sårbarheder eller ændringer i forsyningskæden.
For forretningen kan det koges ned til et enkelt spørgsmål:
Ved du, hvad dit system er afhængigt af?
Forestil dig nu et skifte af softwarehus
Det er et af de tidspunkter, hvor alle mangler bliver synlige.
Virksomheden har i årevis arbejdet med én leverandør. Pludselig stopper samarbejdet. Årsagerne kan være mange: ændret strategi. Ændret budget. Bureauet er købt. Organisatoriske problemer. Manglende kompetencer til videre udvikling. Eller virksomheden vil bare arbejde med en ny partner.
Det nye softwarehus spørger:
"Hvor er repositoriet?" - Det er der.
"Hvor er infrastrukturen?" - Den er der.
"Hvordan deployer vi til produktion?" - "Vi ved det ikke, det gjorde det tidligere team."
"Hvordan virker integrationen med ERP?" - "Tænker det er gennem den server."
"Hvor er vores API-nøgler?" - "De burde være i en mail."
"Hvilke API'er er produktive?" - "Vi ved det ikke."
"Hvilke processer er kritiske?" - "Du må spørge Lukas."
Lukas arbejder der ikke længere...
Og derfor er overdragelse af et projekt ikke bare at flytte kode. Man skal også flytte viden.
Dokumentation er ikke en omkostning. Det er en forsikring
I mange virksomheder behandles dokumentation som noget, der gøres "når der er tid".
Altså ofte aldrig.
Eller i slutningen af et projekt.
Eller når nogen beder om det.
Det er en fejl.
Dokumentation er et af mekanismerne til at begrænse operationel risiko. Den genererer ikke direkte salg. Den øger ikke konvertering. Den ser ikke imponerende ud i en præsentation.
Men i en krise kan den være forskellen mellem: "vi fik det fixet i dag"
og: "først skal vi finde den person, der husker, hvordan det virkede".
I NISTs nye retningslinjer om sikkerheds-, privatlivs- og leverandørstyringsplaner anses dokumentation af systemets formål, tilstand, controls og ansvar samt adfærd hos de personer, der styrer det, som en del af ordentlig systemstyring.
Det illustrerer en tankegangsskift.
Dokumentation er ikke kun et udviklerværktøj.
Det er et element i kontinuiteten af organisationens drift.
Hvad bør være dokumenteret?
Det handler ikke om at lave en 800-siders manual, som ingen nogensinde åbner.
God dokumentation bør først og fremmest besvare de spørgsmål, der opstår, når noget ændres eller holder op med at virke.
- Hvem ejer systemet?
- Hvor er koden?
- Hvor er produktionen?
- Hvordan ser deployment-processen ud?
- Hvilke miljøer findes?
- Hvilke integrationer er kritiske?
- Hvilke eksterne tjenester bruger vi?
- Hvem leverer dem?
- Hvilke kontrakter og konti har vi?
- Hvor er nøgler og adgangsdata?
- Hvem har rettigheder?
- Hvordan ser backup ud?
- Hvordan genskaber vi systemet?
- Hvilke open source-komponenter bruges?
- Hvilke biblioteker er forældede?
- Hvad er de vigtigste arkitekturbeslutninger?
- Hvilke elementer er kritiske for forretningen?
- Hvad sker der, hvis en bestemt ekstern tjeneste stopper?
Det er ikke dokumentation "for udviklere".
Det er et kort over forretningens afhængighed af teknologi.
"Det virker, så lad være med at røre" kan være en strategi. Men man skal kende prisen
Ikke alle virksomheder behøver at omskrive et gammelt system.
Ikke alle legacy-systemer er dårlige.
Ikke alt gammelt kode skal omskrives.
Tværtimod — nogle gange er et stabilt, ældre system bedre end en dyr migration uden klart formål.
Problemet er ikke systemets alder.
Problemet er manglende viden om dets tilstand.
Hvis vi ved, hvordan systemet virker, hvilke afhængigheder det har, hvor risiciene ligger, og hvem der kan vedligeholde det, kan vi bevidst beslutte at:
- lade det være,
- modernisere det,
- genskrive en del,
- migrere det,
- eller ikke røre noget.
Hvis vi ikke ved det, er beslutningen "lad os ikke røre" ikke en strategi.
Det er et væddemål.
Hvordan ser et audit af et arvet system ud?
Når et softwarehus overtager et eksisterende system, bør første skridt ikke være: "Lad os omskrive det." — først skal man forstå det.
Et godt audit bør blandt andet omfatte applikationsarkitektur, kildekode, database, infrastruktur, deploymentsproces, afhængigheder, integrationer, sikkerhed, adgang til tjenester og dokumentation.
Lige så vigtigt er forståelsen af forretningen;
- Hvilke processer er kritiske?
- Hvilke funktioner bruges dagligt?
- Hvilke moduler genererer indtægt?
- Hvilke elementer kan slås fra uden konsekvens?
- Hvad sker der, hvis en given integration stopper?
- Hvilke elementer er mest risikable?
Først når teknisk og forretningsmæssig vinkel er kombineret, kan man sige, hvad der virkelig behøver ændring.
Audit behøver ikke ende i revolution
Nogle gange er resultatet af et audit overraskende enkelt.
Systemet er i orden, der skal blot:
- kompletteres dokumentation,
- rydde op i adgangene,
- opdatere nogle biblioteker,
- overføre ejerskab af konti,
- beskrive deployment-processen,
- tilføje overvågning,
- fastlægge backup,
- introducere en ekstra person til områder, som kun én udvikler kendte.
Og pludselig ændres bus factor fra 1 til 3.
Man behøver ikke omskrive hele applikationen.
Man behøver ikke kassere syv års arbejde.
Man behøver ikke bygge alt forfra.
Nogle gange er det største problem ikke teknologien.
Det er manglen på et kort.
Systemet skal overleve de mennesker, der skabte det
Det er måske den vigtigste regel: et godt system skal kunne overleve, når en udvikler forlader.
Det skal kunne overleve en skiftende administrator.
Det skal kunne overleve et skifte i softwarehus.
Det skal kunne overleve en omorganisering i virksomheden.
Det skal kunne overleve flere års udvikling.
Det betyder ikke, at enhver udvikler skal forstå hver eneste linje kode. Det betyder, at den viden, som er kritisk for forretningens drift, ikke må eksistere kun i én persons hoved.
For en medarbejder kan forlade.
En freelancer kan stoppe samarbejdet.
Et bureau kan forsvinde.
En leverandør kan ændre en tjeneste.
Og virksomheden skal stadig kunne fungere.
Teknologi bør være organisationens ejendom, ikke hukommelsen hos én person
Det er især vigtigt for systemer, der er bygget over mange år.
Hvis virksomheden betaler for softwaren, bør den vide ikke kun, hvor koden er.
Den bør vide:
- hvad den ejer,
- hvad den er afhængig af,
- hvem har adgang,
- hvem kan ændre den,
- hvordan den deployes,
- hvordan den kan genskabes,
- hvordan den overdrages til et andet team.
NIST i deres seneste materiale om leverandør-due-diligence peger bl.a. på oprindelse, robusthed, cyber-sikkerhedspraksis og afhængigheder i forsyningskæden. Det viser en bredere retning: organisationer bør i stigende grad vide ikke kun hvem der leverede systemet, men også hvad systemet består af, og hvilke risici der er forbundet med at vedligeholde det.
Det er ikke længere kun et IT-emne.
Det er et spørgsmål om styring af forretningsrisiko.
Det værste tidspunkt at lære sit system at kende er under et nedbrud
Man kan bruge nogle dage på et audit.
Man kan rydde op i dokumentationen.
Man kan tjekke afhængigheder.
Man kan beskrive arkitekturen.
Man kan verificere adgangene.
Man kan fastlægge, hvem der reelt er ansvarlig for hvilke områder.
Man kan reducere bus factor.
Eller man kan vente.
Indtil systemet holder op med at fungere.
Så vil de samme spørgsmål blive stillet.
Bare med større pres, brugere venter, salget kan stoppe, og hver time vil koste penge.
Derfor er det værd at stille sig selv ét spørgsmål, før problemet opstår: Hvis den person, der kender dit system bedst, forsvandt i morgen, ville vi så stadig vide, hvordan vi vedligeholder det?
Hvis svaret er "nej", betyder det ikke nødvendigvis, at systemet er dårligt.
Det betyder, at virksomheden har en skjult risiko, som den indtil nu ikke har måttet realisere.
Hos Web24 overtager vi ikke kun koden
At overtage et eksisterende projekt er en helt anden opgave end at starte et nyt system fra bunden.
Først skal man forstå, hvad der allerede findes.
Hvad virker.
Hvad er kritisk.
Hvad er afhængigheder.
Hvad er problemer.
Hvad er blot rester fra tidligere beslutninger.
Og vigtigst af alt — hvor findes den viden, uden hvilken systemet ikke kan udvikles sikkert.
Først derefter kan man planlægge næste skridt.
Nogle gange vil det være modernisering.
Nogle gange udvikling.
Nogle gange oprydning af infrastrukturen.
Nogle gange overtagelse af drift.
Og nogle gange blot at lave et ordentligt kort over systemet, som ingen har haft tid til at lave i årevis.
For et ansvarligt softwarehus bør ikke bygge teknologi, der kun virker, når den rigtige person sidder ved tastaturet.
Systemet bør være større end hukommelsen hos én person.
Og forretningen bør være sikker på, at når nogen går, så går teknologien ikke med dem.
