Systemlandskap är inte en karta – det är en berättelse
Om att förstå hur system hänger ihop genom att förstå varför de ser ut som de gör.
Alla vill ha ett systemlandskap.
En fin översikt. Med rutor för alla system. Pilar mellan dem. Kanske lite färgkodning.
Och när det är klart säger de:
“Nu vet vi hur allt hänger ihop.”
Men det gör de inte.
För ett systemlandskap är inte en karta över verkligheten.
Det är en berättelse om varför det ser ut som det gör.
⸻
Kartan visar vad - berättelsen förklarar varför
När jag kliver in i en organisation och ber om systemlandskapet får jag ofta ett diagram.
Snyggt. Strukturerat. Uppdaterat för tre år sen.
Och jag frågar:
“Varför pratar systemet X med systemet Y via systemet Z?”
Svar: “Det vet jag inte. Men det gör det.”
Och där - precis där - förlorar kartan sitt värde.
För utan “varför” är det bara rutor.
⸻
Systemlandskap som ingen förstår
De flesta systemlandskap ser ut så här:
En stor ruta för “ERP”. En annan för “CRM”. En för “Hemsidan”. En för “Interna verktyg”.
Pilar mellan dem.
Och när man frågar:
“Vad gör pilarna?”
Svar: “De… pratar med varandra.”
Men hur? Varför? Vem bestämde det? Vad händer om en pil försvinner?
Ingen vet.
⸻
Vad som egentligen behövs
Ett systemlandskap ska inte bara visa vad som finns.
Det ska berätta:
1. Varför systemet finns
Vilket problem löser det? Vem använder det? Vad skulle hända om det försvann?
2. Varför systemen pratar med varandra
Vilken data flödar? Vem bestämde att det skulle vara så? Vad händer när det inte funkar?
3. Var besluten togs
Var det medvetet? Var det nödvändigt? Eller var det “någon som löste det snabbt en gång”?
4. Vad som inte syns
Vad är hemmabyggt? Vad är outsourcat? Vad håller på att fasas ut?
⸻
Ett exempel
Jag såg ett systemlandskap med en pil från “Hemsidan” till “ERP”.
Jag frågade:
“Vad gör den här pilen?”
Svar: “Den skickar beställningar.”
“Okej. Hur?”
“Via ett API.”
“Vem byggde det?”
“En konsult för fem år sen.”
“Finns konsulten kvar?”
“Nej.”
“Finns dokumentationen?”
“Nej.”
“Vad händer om det går sönder?”
“Vi vet inte.”
Det är inte ett systemlandskap.
Det är en karta över risk.
⸻
Så bygger ni ett systemlandskap som faktiskt hjälper
1. Rita inte bara system - rita ansvarsområden
Vem äger systemet? Vem underhåller det? Vem fattar beslut om det?
Om svaret är “vet inte” - markera det.
2. Dokumentera varje integration
För varje pil:
- Vad skickas?
- Varför?
- Hur ofta?
- Vad händer om det misslyckas?
3. Berätta historien
Varför byggdes systemet? Var det ett medvetet val eller en snabb fix? Skulle ni välja samma lösning idag?
4. Visa vad som är temporärt
Markera vad som är “tills vidare”.
För det som var tänkt som tillfälligt har en tendens att bli permanent.
5. Uppdatera när något ändras
Om ni lägger till ett system - uppdatera kartan.
Om ni river en integration - dokumentera det.
Annars blir det en lögn igen.
⸻
Varför det spelar roll
Ett systemlandskap som bara visar rutor och pilar är värdelöst.
Men ett som berättar historien om varför det ser ut som det gör?
Det hjälper er:
- Fatta beslut om vad som kan ändras
- Förstå vad som är kritiskt
- Se var risken finns
- Undvika att bygga nya beroenden utan att förstå konsekvenserna
⸻
På måndag
Om ni har ett systemlandskap - kolla på det.
Välj en pil.
Och fråga:
“Vet vi vad den här gör?” “Vet vi varför den finns?” “Vet vi vad som händer om den slutar fungera?”
Om svaret är nej på någon av frågorna - där har ni ett problem.
⸻
Ett systemlandskap utan historien bakom det är bara en bild.
Och bilder hjälper er inte när något går sönder.