Ditt system fungerar utmärkt. Tills personen som vet varför slutar jobba.
Företaget har ett system som tog sju år att bygga. Det fungerar. Det hanterar kunder. Det kopplar ihop med andra system. Det utför processer utan vilka företaget egentligen inte skulle kunna fungera normalt.
Under de sju åren arbetade fem utvecklare med projektet. Därtill två frilansare och en byrå. En del av dokumentationen finns i Confluence, en del på Google Drive, en del i tickets. Någonstans finns också ett gammalt dokument om en av integrationerna. Och när någon frågar varför en viss del av systemet fungerar på just det sättet, lyder svaret: "Michał mindes nog det."
Michał slutade för tre år sedan.
Och just då börjar det verkliga problemet.
Inte för att systemet är dåligt skrivet. Inte för att det plötsligt slutade fungera. Problemet är att företaget inte längre har full kunskap om sitt eget system.
Systemet fungerar, men företaget kanske inte kontrollerar det
Det är en av de mest underskattade formerna av teknisk skuld.
När vi talar om teknisk skuld tänker vi oftast på gammal kod, inaktuella bibliotek, arkitekturella misstag, brist på tester eller lösningar som en gång var snabba men i dag försvårar utvecklingen.
Samtidigt finns det en annan typ av skuld. Kunskapsskuld.
Den uppstår när ett system är beroende av information som inte finns i dokumentationen, repo:t, rutinerna eller organisationen, utan i huvudet på vissa specifika personer.
Och så länge dessa personer finns tillgängliga kan allt verka normalt.
Problemet uppstår vid teamförändringar, när en utvecklare slutar, när samarbetet med ett software house avslutas, vid serverfel, när administratören byts ut eller när ett nytt lösning måste införas snabbt.
Plötsligt visar det sig att företaget har kod, men inte kunskap.
Det har en server, men ingen säkerhet om vem som har åtkomst.
Det har en integration, men man vet inte vilket konto den skapades under.
Det har dokumentation, men man vet inte vilken version som är aktuell.
Det har en process, men man vet inte varför den utformades just så.
Och då dyker frågan upp väldigt snabbt: vem äger egentligen det här systemet?
Bus factor, alltså vad händer om en person försvinner?
I IT-världen finns begreppet bus factor. Förenklat betyder det antalet personer vars frånvaro kan göra att teamet inte längre kan utveckla eller förvalta projektet effektivt.
Det handlar förstås inte om en bokstavlig händelse. Det är ett sätt att tänka kring koncentration av kunskap.
Om bara en person vet hur en kritisk integration fungerar, är bus factor för den kunskapen ett.
Om bara en administratör har åtkomst till produktion, är bus factor ett.
Om bara en person vet varför systemet kör en viss process varje natt, kan bus factor vara ett.
Om företaget samarbetar med ett externt software house och ingen på kundsidan förstår lösningens arkitektur, uppstår ett ännu större problem - kunskapen kan ligga utanför organisationen.
Det betyder inte att varje företag måste ha fem experter på varje del av systemet.
Det handlar om något mycket enklare: företaget bör veta var den kritiska kunskapen finns och om det kan återfå den utan en viss person.
Koden säger hur. Inte alltid varför.
En utvecklare kan läsa koden och förstå vad en viss funktion gör.
Men hen kommer inte alltid att veta varför den skrevs just på det sättet.
Det är en enorm skillnad.
Man kan hitta den del som ansvarar för att skicka data till ett externt system. Man kan analysera endpointen, parametrarna, auktoriseringen och felhanteringen.
Men koden svarar inte nödvändigtvis på frågorna:
- Varför skickar vi data klockan 02:00 på natten?
- Varför hoppas just den här statusen över?
- Varför försöker systemet igen exakt tre gånger efter ett fel?
- Varför beräknas ett värde om innan det skickas?
- Varför får man inte ändra ordningen på dessa operationer?
- Varför använder den här integrationen ett visst konto?
Svaret kan finnas i projektets historik, i en gammal ticket, i ett mejl från sex år sedan eller - ännu värre - enbart i minnet hos personen som inte längre arbetar i företaget.
Därför bör bra dokumentation inte bara vara en instruktion om "vad man ska klicka på".
Den bör också bevara kontext och beslut.
Det största problemet kan vara en integration som ingen längre minns
Ett modernt system fungerar nästan aldrig helt på egen hand.
Det kopplar mot ett ERP-system. CRM. Betalningsgateway. SMS-leverantör. Kurirsystem. Partner-API. Molntjänst. Analysplattform. Bokföringssystem. Auktoriseringsmekanism.
Varje sådan koppling är en del av en teknologisk kedja.
Och varje del av den kedjan kan ha sin egen ägare, konto, API-nyckel, certifikat, avtal, gräns, API-version och livscykel.
Efter några år kanske ingen längre minns vem som skapade det aktuella kontot.
Och då räcker det med att certifikatet går ut eller att API:t ändras för att systemet ska sluta fungera.
Ännu värre är det om företaget inte ens vet att ett visst beroende finns.
Därför får programvarans proveniens, hantering av beroenden och transparens i programvarans leveranskedja allt större betydelse i ett moget synsätt på system. NIST pekar i sitt aktuella material om säkerhet i leveranskedjan bland annat på vikten av information om komponenter, deras ursprung, livscykel och beroenden. SBOM, alltså Software Bill of Materials, är ett av verktygen som hjälper till att strukturera kunskapen om vilka komponenter programvaran består av.
Det här är inte längre bara ett ämne för säkerhetsteamet.
Det är också ett ämne för ledningen.
För om företaget inte vet vad systemet är byggt av blir det svårare att bedöma risk, underhållskostnad och konsekvenserna av förändringar.
Dokumentation är inte en kostnad. Det är en försäkring.
I många företag behandlas dokumentation som något som "görs senare".
Först funktionalitet.
Sedan driftsättning.
Sedan förbättringar.
Sedan nästa projekt.
Och dokumentationen?
"När det finns tid."
Problemet är att tid för dokumentation oftast dyker upp först när det redan är för sent.
Dokumentation bör fungera som en affärsmässig försäkring. Inte för att någon ska läsa den varje dag. Tvärtom - förhoppningsvis behövs den så sällan som möjligt i en nödsituation.
Men när ett problem väl uppstår bör företaget kunna svara på grundläggande frågor:
- Hur fungerar systemet?
- Vad består det av?
- Var finns produktionsmiljön?
- Vem har åtkomst?
- Vilka är de kritiska integrationerna?
- Vilka konton och externa tjänster används?
- Vilka är beroendena?
- Hur görs säkerhetskopiorna?
- Hur ser driftsättningsprocessen ut?
- Vad händer vid ett avbrott?
- Vilka delar är affärskritiska?
- Varför fattades de viktigaste arkitekturbesluten?
- Vem kan ta över förvaltningen av systemet?
Det behöver inte betyda hundratals sidor dokumentation.
Bra dokumentation ska framför allt vara användbar, aktuell och tillgänglig för rätt personer.
"Rör inte det, det fungerar" är inte alltid ett dåligt beslut
Det finns ännu ett mycket vanligt problem.
Systemet har fungerat i åratal, så företaget antar principen: "Vi rör det inte. Det fungerar."
Och ibland är det helt rimligt.
Inte all gammal teknik behöver bytas ut omedelbart. Inte all äldre kod behöver skrivas om. Inte alla bibliotek betyder katastrof. Inte all arkitektur från för några år sedan är fel.
Problemet uppstår när "rör inte det" också betyder:
- "Låt oss inte analysera."
- "Låt oss inte dokumentera."
- "Låt oss inte kontrollera beroenden."
- "Låt oss inte fråga vem som har åtkomst."
- "Låt oss inte kontrollera om vi fortfarande har alla konton."
- "Låt oss inte fastställa vad som händer om den nuvarande leverantören inte längre är tillgänglig."
Då är avsaknaden av förändring inte en strategi.
Det är att skjuta upp risk.
Ibland är det bästa tekniska beslutet faktiskt att inte bygga om någonting.
Men det beslutet bör baseras på kunskap om systemet, inte på brist på kunskap om systemet.
Vad bör en granskning av ett ärvt system omfatta?
När ett företag tar över ett system från en annan mjukvarubyrå, en frilansare eller ett internt team, bör det första steget inte vara att automatiskt skriva om allt.
Först måste man förstå vad som faktiskt har tagits över.
Granskningen bör åtminstone besvara några grundläggande områden.
Arkitektur. Hur är systemet uppbyggt? Vilka är dess huvudkomponenter? Var finns data? Hur kommunicerar de olika delarna med varandra?
Kod och repositorier. Har företaget komplett källkod? Vet man vilken gren och version som är i produktion? Går bygg- och driftsättningsprocessen att återskapa?
Infrastruktur. Var kör produktionen? Hur ser testmiljön ut? Vem har åtkomst? Hur ser övervakning och backup ut?
Integrationer. Vad kommunicerar systemet med? Vilka API:er används? Vem äger de olika kontona och nycklarna?
Beroenden. Vilka bibliotek, ramverk och externa komponenter används? Uppdateras de? Har de kända säkerhetsproblem? Hur ser deras livscykel ut?
Driftsättningsprocess. Kan en ny person förbereda, testa och driftsätta en ändring utan att ringa den tidigare utvecklaren?
Kunskap. Vad finns i dokumentationen, och vad finns fortfarande bara i människors huvuden?
Affärsrisk. Vad händer om en viss komponent slutar fungera i en timme, en dag eller en vecka?
Det moderna synsättet på säkerheten i mjukvarans leveranskedja betonar allt starkare just behovet av kunskap om komponenter, leverantörer, beroenden, deras ursprung och livscykel. NIST pekar också på vikten av due diligence gentemot teknikleverantörer samt bedömning av motståndskraft och risk i hela leveranskedjan.
En granskning betyder inte "låt oss skriva om systemet från grunden"
Detta är viktigt, eftersom teknisk granskning ofta felaktigt likställs med ombyggnad.
Under tiden kan granskningen sluta med en mycket enkel slutsats: "Systemet är i ordning. Vi behöver bara strukturera kunskapen och ta bort några risker."
Det kan också visa sig att systemet bara behöver moderniseras inom ett område.
Eller att det största problemet inte är koden, utan bristen på åtkomst till infrastrukturen.
Eller att applikationen är välskriven, men ingen har aktuell kunskap om driftsättningsprocessen.
Eller att allt fungerar, men företaget är beroende av en enda extern leverantör.
Därför bör en bra analys av ett ärvt projekt besvara frågan: "Vad behöver egentligen ändras, och vad behöver man inte röra?"
Först då kan man fatta investeringsbeslut.
Och vad händer om du byter mjukvarubyrå?
Det är ett av de tillfällen då problemet med osynlig kunskapsskuld blir uppenbart.
Företaget avslutar samarbetet med leverantören.
Den nya partnern får repositoriet.
Och börjar ställa frågor:
- "Var finns produktionen?"
- "Hur kör man projektet lokalt?"
- "Vilken version är aktuell?"
- "Vad används den här tjänsten till?"
- "Vem äger kontot för detta API?"
- "Vad gör den här cron-jobbet?"
- "Varför startar den här processen vid den här tiden?"
- "Varifrån hämtar vi den här parametern?"
- "Vad händer om vi stänger av den?"
Om svaret på de flesta frågor är "vi vet inte", tar den nya mjukvarubyrån inte över projektet. Först måste den kartlägga det.
Och kartläggning av ett system kostar tid. Tid som kunden senare får betala för.
Därför bör överlämningen av ett projekt mellan team vara en process, inte att kasta över en ZIP-fil med kod och ett lösenord till ett konto.
Systemet ska överleva människorna
Det är nog den viktigaste principen.
Människor förändras. Utvecklare byter jobb. Frilansare avslutar samarbeten. Mjukvarubyråer byter kunder. Administratörer går till andra företag. Ledningar byts ut.
Systemet består.
Därför bör systemet utformas så att den kunskap som krävs för att förvalta det kan återvinnas.
Det betyder inte att varje anställd ska veta allt.
Det betyder att organisationen bör ha en mekanism för att lagra kunskap:
- Repositorier.
- Dokumentation.
- Register över integrationer.
- Information om infrastrukturen.
- Åtkomster som hanteras av företaget.
- Beskrivning av nyckelprocesser.
- Historik över viktiga beslut.
- Information om beroenden.
- Nödrutiner.
- Och framför allt - människor som kan använda den dokumentationen.
NIST betonar i aktuella riktlinjer för planering av systemsäkerhet också en formell fastställning av ansvar, systemets operativa status samt rollerna för de personer som hanterar, stödjer eller har åtkomst till systemet.
Det visar på en bredare förändring i synen på teknik.
Systemet är inte bara kod. Systemet är också människor, processer, infrastruktur, beroenden, data, åtkomst och ansvar.
På Web24 börjar vi ofta just med frågan: "Vad har vi egentligen här?"
Övertagandet av ett befintligt projekt bör inte börja med löftet att allt ska skrivas om från grunden.
Det bör börja med att förstå situationen:
- Vad fungerar?
- Vad fungerar inte?
- Vad är kritiskt?
- Vad är föråldrat?
- Var finns de största riskerna?
- Vad saknas i dokumentationen?
- Vilka beroenden är osynliga?
- Går det att säkert vidareutveckla det befintliga systemet?
- Behövs en modernisering, eller bara ordning och reda?
Först därefter kan man avgöra om projektet ska vidareutvecklas, byggas om, skrivas om delvis eller helt enkelt dokumenteras ordentligt.
Det är särskilt viktigt i projekt som under årens lopp har utvecklats av olika personer och olika företag.
För en bra teknologipartner ska inte behövas bara för att endast den vet hur systemet fungerar.
Den ska behövas därför att den kan vidareutveckla, säkra och föra vidare kunskapen om systemet.
Det farligaste felet kan vara människan som redan har slutat
Det är inte alltid gammal kod som är problemet.
Det är inte alltid föråldrad teknik som är problemet.
Det är inte alltid avsaknaden av det senaste ramverket som är problemet.
Ibland är den största risken information som ingen skrev ner.
Ett enda lösenord.
Ett enda arkitekturbeslut.
En enda integration.
Ett enda undantag i processen.
En person som i åratal visste hur allt fungerade.
Och sedan slutade hen.
Därför är det värt att ställa sig en mycket enkel fråga i dag: Om personen som bäst känner ert system försvann från företaget i morgon, skulle ni fortfarande kunna förvalta det?
Om svaret är "ja" - utmärkt.
Om det är "jag vet inte" - då är det värt att undersöka.
Och om det är "absolut inte" - då har ni förmodligen just hittat ett av de viktigaste områdena för teknisk risk i ert företag.
Systemet bör vara större än en enda persons minne.
