De fleste tekniske valg i et softwareprodukt kan laves om uden større besvær. Fire er undtagelsen: hvordan data er bygget op, hvordan kunderne holdes adskilt, hvordan brugere logger ind og får rettigheder, og hvordan produktet taler med andre systemer. Hvert af de fire valg spreder sig ud i hele koden, og kunderne bygger videre på dem. Brug tiden dér, også i et lille team, og tag lettere på resten. En ledelse uden teknisk baggrund kan godt følge med, når den kender de spørgsmål, der skal stilles.
Hvad der gør et valg dyrt
Softwarearkitektur er de grundlæggende valg om, hvordan produktets dele er skåret op og hænger sammen. Et valg bliver dyrt, når mange andre dele afhænger af det. To spørgsmål afslører det: Hvor mange steder i koden skal ændres, hvis vi fortryder? Og skal kunderne selv gøre noget, for at ændringen kan gennemføres?
Svarer teamet “næsten overalt” og “ja”, er beslutningen dyr. Data er den tungeste del, for kode kan skiftes ud på en nat, mens data skal flyttes og kontrolleres, samtidig med at kunderne arbejder i dem.
Datamodellen
Datamodellen beskriver, hvilke ting produktet holder styr på, og hvordan de hænger sammen. Her gemmer sig antagelser, som ingen husker at have gjort. Én bruger hører til én virksomhed. En virksomhed har én adresse, ét sprog og én valuta. En ordre ændres aldrig, efter den er lavet.
Et tænkt eksempel: Et bookingsystem er bygget, så hver kunde er ét sted. Så køber en kæde med tyve butikker produktet, og pludselig skal hele modellen, alle rapporter og hele rettighedsstyringen forstå, at en kunde kan have flere steder.
Spørg derfor: Hvilke antagelser om vores kunder står indbygget i data, og hvilke af dem holder næppe om nogle år? Skal vi kunne se, hvordan noget så ud sidste år?
Adskillelsen af kunderne
Deler kunderne installation og database, skal produktet garantere, at den ene aldrig ser den andens data. Valget mellem fælles installation og en installation til hver kunde har sin egen artikel om multi-tenant. Uanset valget gælder ét krav: Adskillelsen skal håndhæves ét sted i produktet, så den enkelte udvikler slipper for selv at tænke på den i hver eneste forespørgsel.
Stil også de praktiske spørgsmål tidligt. Kan vi eksportere alle data for én kunde? Kan vi slette dem? Kan vi genskabe én kunde fra backup, uden at de andre mærker noget?
Identitet, login og roller
Login virker som en detalje, indtil en stor kunde kræver, at medarbejderne logger ind med virksomhedens egen konto. Det kaldes single sign-on, og det hører til de krav, der går igen i enterprise-krav til SaaS. Tre ting er svære at bygge ind bagefter: at én person kan høre til flere kunder, at rettigheder styres af roller frem for af særregler i koden, og at det kan ses, hvem der gjorde hvad.
Login er også et oplagt sted at købe en færdig komponent. Hvordan valget træffes, står i bygge, købe eller integrere.
Integrationer
En integration er en aftale. Når en kunde har bygget sit system op mod jeres API, altså den indgang, andre programmer bruger for at hente og sende data, kan I ikke længere ændre den frit. Giv derfor grænsefladen versionsnummer fra starten, udstil kun det, I er villige til at støtte i årevis, og hold jeres interne databaseopbygning skjult bag den. Noter også, hvilke eksterne tjenester produktet ikke kan fungere uden, og hvad I gør, hvis en af dem ændrer vilkår eller lukker.
Hvor tiden kan spares
Meget af det, udviklere diskuterer længst, er billigt at fortryde: opdeling af koden indvendigt, valg af bibliotek til en enkelt opgave, opsætning af miljøer, de fleste skærmbilleder. Selv spørgsmålet om monolit eller microservices fylder mindre, end diskussionerne antyder, så længe produktets dele holdes pænt adskilt.
Reglen er enkel. Kan valget laves om på få dage af et par udviklere, så beslut hurtigt, og gå videre. Rører det ved data, kunder eller aftaler med andre systemer, så giv det en eftermiddag med de rigtige mennesker, og skriv beslutningen ned med begrundelse og fravalg.
Hvis valgene allerede er truffet
I de fleste produkter er de fire valg truffet undervejs, ofte uden at nogen tog stilling til dem. Det er helt normalt. Bed den, der kender koden bedst, om at gennemgå dem med jer på en time: Hvad antager vi, hvad ville en stor ny kunde vælte, og hvad ville det kræve at ændre det? Svarene hører hjemme i overblikket over teknisk gæld, så de kan prioriteres sammen med alt det andet.
Det skal I lade være med
- At behandle alle tekniske valg lige tungt · teamet bruger så tid på det billige og for lidt på det dyre.
- At lade den første kunde forme datamodellen alene · det, der passer én kunde, passer sjældent de næste ti.
- At åbne en intern grænseflade for en kunde “lige for en gangs skyld” · den bliver en aftale, I skal holde.
Det skal I kræve af den eksterne
- ☐ En kort gennemgang af de fire valg med de antagelser, der ligger bag.
- ☐ En vurdering af, hvad næste kundetype vil presse, forklaret uden fagord.
- ☐ Skriftlige beslutninger med fravalg for hvert af de dyre valg.
- ☐ En plan for de valg, der skal ændres, med rækkefølge og konsekvens for kunderne.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Skriv de tekniske beslutninger ned · Multi-tenant eller én installation pr. kunde
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
