Ditt system fungerar utmärkt. Så länge personen som vet varför gör det.
Föreställ dig ett företag som har ett system som har fungerat i sju år. Det byggdes i etapper. Först gjorde ett software house det. Sen tog en frilansare över en del. Sen lade ett annat team till en B2B-modul. Nästa byrå kopplade in CRM. Någon annan integrerade betalningar.
Systemet fungerar.
Företaget tjänar pengar tack vare det.
Anställda använder det dagligen.
Kunderna vet inte ens hur många processer som körs i bakgrunden.
Det finns bara ett problem.
Ingen vet längre exakt hur allt fungerar.
Dokumentationen finns delvis i Confluence. Något ligger på Google Drive. Några uppgifter finns i tickets. En integration beskrivs i ett mejl från för fyra år sedan.
Och den viktigaste saken "tror jag att Łukasz kommer ihåg".
Endast Łukasz slutade för tre år sedan.
Och i tre år hände ingenting.
Tills en tisdagmorgon.
Systemet fungerar. Betyder det att allt är i ordning?
Det är ett av de mest förrädiska tillstånden ett företags system kan befinna sig i.
Det fungerar.
Inga fel.
Användarna är nöjda.
Försäljningen använder applikationen.
Beställningarna går igenom.
Data hamnar i CRM.
Rapporter genereras.
Så den naturliga reaktionen blir: Låt oss inte röra det. Varför pilla i något som fungerar?
Och visst — det finns ingen anledning att förändra ett fungerande system bara för sakens skull.
Problemet är att systemet kan vara tekniskt stabilt men samtidigt mycket organisatoriskt instabilt.
Det kan fungera idag, men ingen vet vad som händer när man behöver byta server, API-leverantör, domän, bibliotek, autentiseringsmetod eller ett fragment av en affärsprocess.
Det kan vara effektivt men beroende av en enda person.
Det kan vara säkert men ingen vet var alla åtkomstnycklar finns.
Det kan utvecklas, men endast av den person som känner till historiken bakom alla beslut.
Och här kommer begreppet bus factor in.
Hur många personer kan försvinna innan projektet börjar få problem?
Bus factor är ett mycket enkelt, om än brutalt, koncept.
Vi frågar: Hur många personer måste sluta vara tillgängliga för att projektet inte längre går att underhålla smidigt?
Om svaret är: "En", har vi ett problem.
Om svaret är: "Två, men de arbetar på ett annat företag", har vi ett ännu större problem.
Det handlar förstås inte om att folk bokstavligen försvinner.
En utvecklare kan sluta på företaget.
En frilansare kan avsluta samarbetet.
Ett software house kan sluta serva kunden.
En administratör kan byta jobb.
Personen ansvarig för en viss integration kan övergå till en annan avdelning.
Ägaren till kunskapen kan helt enkelt bli sjuk eller vara otillgänglig i flera veckor.
Om med honom försvinner möjligheten att förstå systemet, har företaget inte ett personalproblem.
Det har ett affärsproblem.
Kod berättar inte alltid varför något fungerar
Man kan säga: "Vi har ju källkoden. En ny utvecklare kan läsa den."
Teoretiskt ja.
I praktiken svarar koden främst på frågan: hur gör systemet något.
Den svarar inte alltid på frågan: varför gör det det på just det sättet.
Och det är en stor skillnad.
I koden kan det finnas ett villkor: "Om kunden har en viss kontotyp, utför operation X."
En ny utvecklare kan hitta det.
Men hur ska hen veta varför?
Det kan vara ett affärskrav.
Det kan vara en kvarleva från en gammal integration.
Det kan vara skydd mot ett fel i ett externt API.
Det kan vara en omväg för ett problem som uppstod för fem år sedan.
Det kan vara en lösning för ett udda fall hos en av de största kunderna.
Det kan finnas där av en mycket god anledning.
Eller av ingen alls.
Utan kontext är det svårt att bedöma.
Därför bör dokumentation inte begränsa sig till instruktioner:
"klicka här, sedan här".
Den mest värdefulla dokumentationen beskriver ofta beslut och beroenden, inte bara hur man använder funktioner.
Den farligaste kunskapen är den som bara finns i någons huvud
Företag har ofta dokumentation. Men dokumentation är inte alltid samma sak som kunskap.
Vi kan ha en API-beskrivning — men inte veta varför vi använder just det API:et.
Vi kan ha en deploy-instruktion — men inte en lista över alla ställen där konfiguration måste ändras.
Vi kan ha en integrationsbeskrivning — men inte veta vad som händer om en extern leverantör ändrar sina autentiseringsmetoder.
Vi kan ha en lista över servrar — men inte veta vilken som är kritisk för en viss process.
Vi kan ha åtkomst till repo — men inte åtkomst till kontot där produktionsinfrastrukturen ligger.
Det är just dessa element som kan förvandla en till synes enkel förändring till en flera dagar lång utredning.
En integration som fungerat i fem år är fortfarande ett beroende
Ett av de mest försummade områdena är externa tjänster;
- Betalningar.
- SMS.
- E-post.
- CRM.
- ERP.
- Karttjänster.
- Kurirsystem.
- Marknadsföringsplattformar.
- Bokföringssystem.
- Molntjänster.
- Extern API.
- Open source-bibliotek.
Var och en av dessa är en del av ett större ekosystem.
Om systemet använder tio externa tjänster har vi inte ett system. Vi har ett system plus tio beroenden. Och var och en av dem kan förändras.
En leverantör kan ändra API.
Den kan avsluta tjänsten.
Den kan ändra prissättningsmodell.
Den kan ta bort en äldre version.
Den kan införa nya säkerhetskrav.
Den kan bli förvärvad av ett annat företag.
Därför blir kunskap om komponenters ursprung och programvaruberoenden allt viktigare. NIST pekar bland annat på betydelsen av SBOM, Software Bill of Materials — en formell förteckning över komponenter som använts för att bygga mjukvaran. En sådan lista hjälper till att förstå vad systemet består av och snabbare bedöma effekten av sårbarheter eller förändringar i leverantörskedjan.
För affären kan detta kokas ner till en mycket enkel fråga:
Vet du vad ditt system är beroende av?
Föreställ dig nu att software house byts ut
Det är ett av de tillfällen när alla brister kommer till ytan.
Företaget har under år arbetat med en leverantör. Plötsligt upphör samarbetet. Det kan finnas många skäl; ändrad strategi. Budgetförändring. Byråförvärv. Organisationsproblem. Bristande kompetens för fortsatt utveckling. Eller helt enkelt att företaget vill jobba med en annan partner.
Det nya software house frågar:
"Var är repot?" — Det finns.
"Var är infrastrukturen?" — Den finns.
"Hur deployar vi produktion?" — "Vi vet inte, det gjorde det förra teamet."
"Hur fungerar integrationen med ERP?" — "Troligen via den där servern."
"Vilka API-nycklar har vi?" — "De borde finnas i ett mejl."
"Vilka API:er är i produktion?" — "Vi vet inte."
"Vilka processer är kritiska?" — "Fråga Łukasz."
Łukasz jobbar inte där längre...
Och därför är att överföra ett projekt inte bara att överföra kod. Man måste även överföra kunskap.
Dokumentation är inte en kostnad. Det är en försäkring
I många företag ses dokumentation som något man gör "när man har tid".
Vilket oftast innebär aldrig.
Eller i slutet av ett projekt.
Eller när någon ber om det.
Det är ett misstag.
Dokumentation är en av mekanismerna för att begränsa operationell risk. Den genererar inte direkt försäljning. Den förbättrar inte konverteringar. Den ser inte imponerande ut i en presentation.
Men i en krissituation kan den vara skillnaden mellan: "vi fixar det idag"
och: "först måste vi hitta personen som minns hur det fungerade".
I NIST:s nya riktlinjer om säkerhetsplaner, integritet och hantering av risk i mjukvaruleverantörskedjan betraktas dokumentation av systemets syfte, tillstånd, kontroller samt ansvar och beteenden hos de som hanterar det som en del av ordnad systemförvaltning.
Det visar en förändring i tänkande.
Dokumentation är inte bara ett verktyg för utvecklaren.
Det är en del av organisationens kontinuitet.
Vad bör dokumenteras?
Det handlar inte om att skapa en 800-sidig dokumentation som ingen någonsin öppnar.
Bra dokumentation bör framför allt svara på de frågor som uppstår när något ändras eller slutar fungera.
- Vem äger systemet?
- Var finns koden?
- Var finns produktionen?
- Hur ser deploy-processen ut?
- Vilka miljöer finns?
- Vilka integrationer är kritiska?
- Vilka externa tjänster använder vi?
- Vem är deras leverantör?
- Vilka avtal och konton har vi?
- Var finns nycklar och åtkomstuppgifter?
- Vem har behörighet?
- Hur ser backup ut?
- Hur återställer man systemet?
- Vilka open source-komponenter används?
- Vilka bibliotek är föråldrade?
- Vilka är de viktigaste arkitekturbesluten?
- Vilka delar är kritiska för affären?
- Vad händer om en specifik extern tjänst slutar fungera?
Det här är inte dokumentation "för utvecklare".
Det är en karta över hur affären är beroende av tekniken.
"Det fungerar, så låt oss inte röra det" kan vara en strategi. Men man måste känna till dess pris
Inte varje företag behöver riva upp ett gammalt system.
Inte varje legacy-system är dåligt.
Inte all gammal kod behöver skrivas om.
Tvärtom — ibland är ett stabilt, äldre system ett bättre val än en kostsam migrering utan tydlig anledning.
Problemet är inte systemets ålder.
Problemet är brist på kunskap om dess tillstånd.
Om vi vet hur systemet fungerar, vilka beroenden det har, var riskerna finns och vem som kan underhålla det, kan vi medvetet besluta att:
- behålla det,
- modernisera det,
- skriva om en del,
- migrera det,
- eller låta bli att röra det.
Om vi inte vet detta är beslutet "låta bli" ingen strategi.
Det är ett vadspel.
Hur ser en revision av ett ärvt system ut?
När ett software house tar över ett befintligt system bör första steget inte vara: "Låt oss skriva om det." — Först måste man förstå det.
En bra revision bör omfatta bland annat applikationens arkitektur, källkod, databas, infrastruktur, deploy-process, beroenden, integrationer, säkerhet, åtkomst till tjänster och dokumentation.
Lika viktigt är att förstå affären;
- Vilka processer är kritiska?
- Vilka funktioner används dagligen?
- Vilka moduler genererar intäkter?
- Vilka delar kan tas bort utan konsekvenser?
- Vad händer om en viss integration slutar fungera?
- Vilka delar är mest riskfyllda?
Först när den tekniska och affärsmässiga bilden kopplas ihop kan man säga vad som faktiskt behöver ändras.
Revisionen behöver inte leda till revolution
Ibland är resultatet av en revision förvånansvärt enkelt.
Systemet är i ordning, det saknas bara:
- Kompletterad dokumentation.
- Ordning på åtkomster.
- Uppdatering av några bibliotek.
- Överföring av ägande av konton.
- Beskrivning av deploy-processen.
- Lägg till övervakning.
- Fastställ backup.
- Introducera en andra person i områden som bara en utvecklare kände till.
Och plötsligt ändras bus factor från 1 till 3.
Man behöver inte skriva om hela applikationen.
Man behöver inte kasta bort sju års arbete.
Man behöver inte bygga allt från början.
Ibland är det största problemet inte teknologin.
Det är bristen på en karta.
Systemet bör överleva människorna som skapade det
Det är kanske den viktigaste regeln: ett bra system ska kunna överleva att en utvecklare slutar.
Det ska överleva byte av administratör.
Det ska överleva byte av software house.
Det ska överleva omorganisationer i företaget.
Det ska överleva flera års utveckling.
Det betyder inte att varje utvecklare måste förstå varje kodrad. Det betyder att den kunskap som är kritisk för affärens funktion inte får existera enbart i en persons huvud.
För en anställd kan sluta.
En frilansare kan avsluta samarbetet.
En byrå kan försvinna.
En leverantör kan ändra sin tjänst.
Och företaget måste ändå fungera.
Tekniken bör vara organisationens egendom, inte minnet hos en enskild person
Detta är särskilt viktigt för system som byggts under många år.
Om företaget betalar för mjukvaran bör det veta inte bara var koden finns.
Det bör veta:
- vad det äger,
- vad det är beroende av,
- vem som har åtkomst,
- vem som kan ändra det,
- hur det kan deployas,
- hur det kan återställas,
- hur det kan överlämnas till ett annat team.
NIST i sina aktuella material om leverantörsdue diligence betonar bland annat ursprung, motståndskraft, cybersäkerhetspraxis och beroenden i leverantörskedjan. Det visar en bredare riktning: organisationer bör i allt större utsträckning veta inte bara vem som levererade systemet, utan också vad systemet består av och vilka risker som är förknippade med dess underhåll.
Det är inte längre enbart en IT-fråga.
Det är en fråga om hantering av affärsrisk.
Det värsta tillfället att lära känna sitt system är när det havererar
Man kan avsätta några dagar för en revision.
Man kan ordna dokumentationen.
Man kan kontrollera beroenden.
Man kan beskriva arkitekturen.
Man kan verifiera åtkomster.
Man kan klargöra vem som verkligen ansvarar för vilka områden.
Man kan minska bus factor.
Eller så kan man vänta.
Tills systemet slutar fungera.
Då kommer frågorna vara exakt desamma.
Bara pressen blir större, användarna väntar, försäljningen kan stå still, och varje timme kommer att kosta pengar.
Därför är det värt att ställa sig en fråga innan ett problem uppstår: Om personen som bäst känner ditt system försvann imorgon, skulle vi fortfarande veta hur vi ska underhålla det?
Om svaret är "nej" betyder det inte nödvändigtvis att systemet är dåligt.
Det betyder att företaget har en dold risk som det hittills inte behövt aktivera.
På Web24 tar vi över mer än bara koden
Att ta över ett befintligt projekt är en helt annan uppgift än att starta ett nytt system från grunden.
Först måste man förstå vad som redan finns.
Vad som fungerar.
Vad som är kritiskt.
Vad som är ett beroende.
Vad som är ett problem.
Vad som bara är kvarlämningar från tidigare beslut.
Och framför allt — var finns den kunskap som utan vilken systemet inte kan utvecklas säkert.
Först då kan man planera fortsatta åtgärder.
Ibland blir det modernisering.
Ibland utveckling.
Ibland ordning på infrastrukturen.
Ibland övertagande av driften.
Och ibland helt enkelt att skapa en ordentlig karta över systemet som ingen haft tid att göra på åratal.
För ett ansvarsfullt software house ska inte bygga teknik som bara fungerar när rätt person sitter vid datorn.
Systemet ska vara större än minnet hos en enda person.
Och affären ska vara säker på att när någon lämnar, lämnar inte tekniken med dem.
