Den dolda risken i din tech-stack

Systemet kraschade inte på grund av dålig kod. Det kraschade för att ingen längre underhöll biblioteket det är beroende av. I den här artikeln förklarar Emanuel Palm varför även högkvalitativa system kan fallera – och hur du kan minska risken.

Vad händer när du ignorerar det du är beroende av?
Föreställ dig följande: Produktionen ligger nere. Systemen svarar inte. Varje minut kostar pengar. Medarbetare kämpar för att hitta felet. Ledningen kräver svar. Och någonstans, djupt nere i din tech‑stack, fallerar en kritisk komponent. Varje åtgärd leder till fler fel. Och leverantören? Borta. Inget supportavtal. Ingen backup-plan. Inga alternativ.

Den verkliga orsaken? Inte dålig kod. Inte dålig arkitektur. Inte ens dålig styrning. Problemet är enkelt: systemet var inte underhållet.

Även när du bygger mjukvara internt skapar du sällan allt från grunden. De flesta system är beroende av ett stort antal externa komponenter – som open source‑bibliotek, API:er och molnplattformar – som allt underhålls av andra. Dessa beroenden märks ofta inte förrän de går sönder.

Felriktade intressen är det verkliga problemet
Varje system finns för att uppfylla ett syfte – kommersiellt, tekniskt eller annat. Så länge detta syfte är i linje med dem som underhåller systemet fortsätter det att fungera. Men komponenterna du är beroende av har sina egna livscykler och underhålls av team med sina egna mål. När deras prioriteringar ändras och inte längre överensstämmer med dina kan komponenterna uppdateras på sätt som inte längre passar dina behov – eller sluta utvecklas helt.

Det är då beroenden blir strukturella risker. Varje beroende bygger på en förväntan: att det kommer fortsätta underhållas och utvecklas i en riktning som är kompatibel med din. Men när intressen divergerar saktar underhållet ner, förändringar blir störande eller stödet försvinner – och ditt system blir svagare, ofta utan att du märker det.

Ett system kan vara välbyggt och ändå bli skört med tiden. När komponenter åldras, försummas eller utvecklas åt fel håll förlorar systemet gradvis stabilitet. Organisationer fortsätter ofta att förlita sig på dessa system, utan att förstå hur bräckliga de blivit – tills ett fel gör det uppenbart.

”Ounderhållen” betyder inte låg kvalitet – det betyder bortglömd
Man kan tro att buggar, säkerhetsbrister, dåliga gränssnitt eller saknade funktioner är de största riskerna i ett mjukvaruprojekt. Och ja – dessa problem är viktiga. Men så länge någon aktivt underhåller systemet går de oftast att hantera.

Den större risken är försummelse. När ingen längre ansvarar för en komponent – för att den inte längre prioriteras, finansieras, underhålls eller passar aktuella behov – blir även högkvalitativ kod en risk.

Och det är inte ett tekniskt problem. Det är ett mänskligt problem. Ofta också ett ekonomiskt problem.

Beroenderisk är en strategisk utmaning
Du behöver inte kontrollera varje komponent – men du måste ta ansvar för hur de passar in i din arkitektur och dina långsiktiga planer.
Ur ett affärsperspektiv kan oklara eller oövervakade beroenden leda till:

– Driftstopp och operativa störningar
– Ökade supportkostnader och teknisk skuld
– Säkerhetsbrister utan tydliga patch‑möjligheter
– Förlorat kundförtroende och skadat varumärke

Vad kan du göra?
Att hantera beroenden handlar inte bara om versionskontroll – det är en form av strategisk riskhantering. Så här kan resilienta organisationer minska risken:

Utvärdera och övervaka kritiska beroenden – förstå vad du är beroende av, vem som underhåller det och hur bra det stöds
Säkerställ strategisk riktning – se till att viktiga komponenter utvecklas i en riktning som är förenlig med dina mål
Förbered fallback‑alternativ – designa för modularitet, investera i redundans och säkerställ supportavtal där det behövs
Undvik onödig komplexitet – integrera bara komponenter som ger verkligt långsiktigt värde
Underhåll det som är viktigt – särskilt beroenden som är nära kopplade till kärnlogik och affärskritiska funktioner

Avslutande tankar
Du kan inte kontrollera varje del av systemen du är beroende av – men du är ansvarig för att förstå dem.
Beroenden fallerar sällan över en natt – de glider. Långsamt och tyst. Men när de fallerar tar de ofta hela system med sig. Och när det händer kan du hamna i ”dependency hell” – och ja, det är ett verkligt fenomen.

Hur bedömer du när ett system eller en komponent blivit för riskabel att förlita sig på?