Arkitektur og teknologivalg

De fleste tekniske valg kan laves om uden større besvær, og derfor skal I ikke bruge lang tid på dem. Enkelte valg kan næsten ikke ændres, når først kunderne er på. Arkitektur handler om at kende forskellen, og det er en ledelsesopgave, fordi valgene binder virksomheden i årevis og påvirker økonomi, ansættelser og hvad kunderne kan få. Siden her samler artiklerne om de beslutninger, en stifter eller direktør bør forstå, også uden selv at kunne kode.

Det, der går igen

Tre spørgsmål kan stilles om næsten ethvert teknisk valg. Hvor svært er det at ændre om to år? Hvem hos os kan vedligeholde det, når den person, der foreslog det, er stoppet? Og hvilke krav fra produkt og kunder bygger det på? Et teknologivalg uden svar på det sidste er tit en smagssag. Skriv svaret ned, så den næste kan se, hvorfor valget blev truffet. Når kunderne begynder at spørge til de samme ting, bliver det samme materiale til grundlaget for en arkitekturbeskrivelse på tre sider.

De første valg

• Teknologivalg til MVP’en, så den ikke skal smides væk Kendt teknologi frem for spændende, valg der er lette at ændre, og de få, der ikke er.
• SaaS: hvad betyder det for den, der bygger softwaren? Kort opslag om forskellen på at levere en tjeneste og installeret software, set fra den, der bygger.
• App, webapp eller begge? Hvad brugeren skal, og hvad valget binder af vedligehold og krav fra app-butikkerne.
• Bygge, købe eller integrere: hvad skal I selv eje i produktet? Betaling, login, søgning og notifikationer, vurderet ud fra afhængighed og vedligehold.

Beslutninger, der binder i årevis

• Arkitekturbeslutninger, der er dyre at lave om Datamodel, kundeadskillelse, identitet og integrationer, og hvor tiden skal bruges.
• Multi-tenant eller én installation pr. kunde Drift, opdatering, adskillelse af kunder og kundekrav afvejet mod hinanden.
• Monolit eller microservices i en lille SaaS Teamets størrelse som den afgørende faktor, og den modulære monolit som mellemvej.
• Cloud og hosting til et SaaS-produkt Krav fra produktet og kunderne først, valget af platform bagefter.

Valgene skal kunne læses bagefter

• Skriv de tekniske beslutninger ned (ADR) Korte beslutningsnotater, der overlever, at folk skifter job, med skabelon i tekst.

Hvem træffer valgene?

I en lille virksomhed træffes de første valg tit af den første udvikler, der har gode grunde og også sine egne vaner. Det er fint, så længe nogen har overblik over, hvad der binder. Når der er en leverandør indover, skal I passe på med at lade den samme part vælge teknologien og bygge produktet, for valget kan komme til at passe bedre til leverandørens folk end til jeres fremtid. Det er behandlet i Når udviklingshuset også er jeres CTO. Har produktet allerede mange år på bagen, er spørgsmålet et andet, og så skal I læse om det gamle produkt. Den løbende prioritering af arbejdet med platformen hører under teknisk køreplan og teknisk gæld.

En god teknisk leder bruger tid på at forklare en beslutning for ledelsen i konsekvenser frem for i teknologi. Får I et svar, I ikke forstår, er det rimeligt at bede om det igen med andre ord.

Det skal I lade være med

• At vælge den nyeste teknologi, fordi den er spændende · I skal kunne ansætte folk til den om nogle år.
• At bygge til kunder, I endnu ikke har · det koster tempo nu og løser et problem, der måske aldrig kommer.
• At bygge selv, hvad der kan købes · alt, hvad I bygger, skal I også vedligeholde.

Det skal I kræve af den eksterne

• ☐ Forklaringer i konsekvenser for forretningen, så ledelsen kan tage stilling.
• ☐ En begrundet liste over de valg, I ikke let kan omgøre.
• ☐ Korte skriftlige beslutningsnotater, som teamet kan bruge.
• ☐ Anbefalinger uden binding til bestemte platforme eller leverandører.

Senest gennemgået: november 2026.

Næste skridt

• Arkitekturbeslutninger, der er dyre at lave om
• Gennemgang af produktet som første skridt

Læs også: Artikler om CTO as a Service · Når kunderne stiller krav til produktet

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT