Det finns ingen arkitektur – bara beslut som hänger ihop

Lösningsarkitektur låter stort.

Som något man ritar i Visio. Som något man presenterar i PowerPoint. Som något med rutor, pilar och moln.

Men det är inte det.

Lösningsarkitektur är en serie beslut om hur saker ska hänga ihop.

Och de besluten lever längre än koden.

⸻

Arkitektur är inte ett dokument

Jag har sett hundratals arkitekturdiagram.

Fina rutor. Snygga pilar. Lager som staplas på varandra.

Och nästan alltid frågar jag:

“Stämmer det här fortfarande?”

Svar: “Nej, men vi hade inte tid att uppdatera det.”

För arkitekturen lever inte i diagrammet.

Den lever i koden. I systemen. I relationerna mellan dem.

Och i huvudet på folk som byggt det.

⸻

Vad arkitektur egentligen är

Varje gång ni väljer hur något ska byggas - fattar ni ett arkitekturbeslut.

Exempel:

“Ska vi använda REST eller GraphQL?” “Ska vi ha en monolith eller mikrotjänster?” “Ska vi lagra det här i samma databas eller separera det?” “Ska vi bygga själva eller integrera med något?”

Det är inte tekniska frågor.

Det är affärsbeslut.

För varje val har konsekvenser:

• Hur snabbt kan ni bygga?
• Hur lätt är det att ändra?
• Vad händer när det går fel?
• Vad kostar det att driva?

Och de valen lever länge.

⸻

Beslut som lever längre än koden

Kod kan skrivas om.

Men arkitektur är svårare att ändra.

För när ni väl byggt era system på ett visst sätt - är det dyrt att riva och bygga om.

Exempel:

Ni valde att bygga en monolith för fem år sen.

Nu vill ni skala. Men monolithen klarar det inte.

Valet att inte splittra upp systemet då - kostar er nu.

Det var inte fel då. Men det begränsar er idag.

⸻

De vanligaste arkitekturmisstagen

1. Att bygga för framtiden istället för nuet

“Vi kanske behöver det här senare.”

Så ni bygger för en framtid som kanske aldrig kommer.

Och när den väl kommer - ser den annorlunda ut än ni trodde.

Bygg för vad ni vet. Inte för vad ni gissar.

2. Att kopiera någon annans arkitektur

“Netflix gör så här.”

Ja. För Netflix har Netflix problem.

Ni har era problem.

Sluta bygga som om ni vore Google om ni har 500 användare.

3. Att låta tekniken driva valet

“Jag vill testa Kubernetes.”

Bra för dig.

Men är det rätt för projektet?

Välj arkitektur baserat på behov. Inte på CV-building.

⸻

Så fattar ni bättre arkitekturbeslut

1. Förstå vad ni optimerar för

Snabbhet? Skalbarhet? Enkelhet? Kostnad?

Ni kan inte ha allt.

Så välj vad som spelar roll mest - just nu.

2. Dokumentera varför - inte bara vad

Skriv inte:

“Vi använder REST.”

Skriv:

“Vi använder REST för att teamet redan kan det, och vi behöver leverera snabbt. Vi kan byta till GraphQL senare om behovet uppstår.”

Det hjälper framtida-er att förstå varför ni valde som ni gjorde.

3. Bygg för förändring

Ni kommer göra fel. Behoven kommer ändras. Tekniken kommer utvecklas.

Så bygg så att ni kan ändra delar utan att riva allt.

4. Testa besluten tidigt

Bygg en proof of concept.

Innan ni bygger hela systemet - verifiera att ert val funkar.

Det är billigare att kassera en prototyp än att skriva om ett helt system.

⸻

På måndag

Nästa gång ni ska fatta ett arkitekturbeslut - fråga:

“Vad optimerar vi för?” “Vad blir svårt att ändra senare om vi väljer det här?” “Varför är det här rätt val - just nu?”

Och skriv ner svaren.

För om sex månader kommer ni inte komma ihåg.

⸻

Arkitektur är inte rutor och pilar.

Det är beslut.

Och bra beslut kräver att ni förstår varför ni fattar dem.