Spørgsmålet kommer fra en stor kunde, der overvejer at rulle produktet ud i hele koncernen, eller fra egen ledelse før et salgsfremstød. Det hurtige svar er ja, og det er sjældent belagt. Et godt svar har tre dele: hvad I har målt, hvor de kendte grænser går, og hvad I gør, når I nærmer jer dem. Den slags svar giver en erfaren kunde mere tryghed end en forsikring, for den viser, at nogen har kigget efter. Det kræver lidt arbejde at nå dertil, og det arbejde er nyttigt i sig selv.
Hvad spørgsmålet egentlig betyder
“Ti gange så meget” kan betyde vidt forskellige ting, og den første opgave er at få det præciseret. Stil modspørgsmål:
- Flere kunder med samme størrelse, eller én kunde, der er langt større end de andre?
- Flere samtidige brugere, eller mere data pr. bruger?
- Jævn belastning, eller alle på én gang klokken ni mandag morgen?
- Flere integrationer, der henter data om natten, eller flere mennesker i brugerfladen?
Skalerbarhed (produktets evne til at klare mere uden at blive tilsvarende dårligere) er forskellig for hver af dem. Et produkt kan klare mange små kunder uden besvær og stadig knække på én kunde med store dataudtræk. Få kunden til at beskrive sin egen brug. Så svarer I på det rigtige spørgsmål, og samtalen bliver mere konkret for begge parter.
Tre ting, I skal have målt
Hvad bruger produktet i dag? Svartider på de vigtigste handlinger, belastning på database og servere i de travleste timer, og datamængden pr. kunde. Har I ikke tallene, er det første skridt at få dem frem, og det er sjældent en stor opgave med moderne overvågning.
Hvor stiger det hurtigst? Vokser databasen pænt i takt med kunderne, eller vokser enkelte tabeller langt hurtigere? Tegn udviklingen over det seneste år. En kurve er ofte mere sigende end et øjebliksbillede.
Hvor brister det? Det kræver en belastningstest, hvor I i et miljø, der ligner produktion, skruer op, indtil noget går galt. Hvordan den bygges op, står i skalering før det går galt. Den vigtigste oplysning fra testen er, hvilken del der giver sig først.
Læg data ind, der ligner virkeligheden. Et testmiljø med en lille pæn database siger meget lidt om en kunde med ti års historik. Brug aldrig rigtige kundedata uden at have vurderet det, se persondata i produktet.
Kendte grænser er en styrke
Mange teams frygter at nævne svagheder. En erfaren IT-arkitekt hos kunden ved, at ethvert system har grænser, og hun vil spørge videre, indtil hun finder dem. Nævner I dem selv, står I stærkere.
Formuler det som en grænse og en plan: “I den nuværende opsætning har vi testet op til det niveau, der svarer til jeres udrulning. Ud over det er databasen første flaskehals, og det løses ved at flytte tunge læsninger til en kopi af databasen. Det arbejde ligger i køreplanen.”
Tre typer af grænser er værd at kende på forhånd:
- Grænser, I kan købe jer ud af. Større servere eller flere instanser, som kræver en beslutning og lidt tid.
- Grænser, der kræver udvikling. Fx en tung rapport eller en forespørgsel, der skal skrives om.
- Grænser i arkitekturen. Fx at alle kunder deler én database på en måde, der er svær at ændre, se valget mellem multi-tenant og egne installationer.
Den tredje type er den, ledelsen skal kende, før salget lover noget stort.
Sådan ser et brugbart svar ud
Et tænkt eksempel: En kunde med mange brugere spørger, om produktet kan bære dem. Svaret kan fylde en halv side:
- Vores nuværende brug: antal brugere, datamængde og travleste timer, opgjort sidste måned.
- Hvad vi har testet: den belastning, vi har kørt i testmiljøet, og hvilke svartider vi fik.
- Hvad vi ved om jeres brug: det, I har fortalt os om brugere, data og integrationer.
- Kendte grænser: den første flaskehals, og hvad vi gør ved den.
- Plan: hvad vi ændrer før jeres udrulning, og hvad vi overvåger undervejs.
Tilbyd gerne en trinvis udrulning, hvor kunden starter med én afdeling. Så får I rigtige målinger, før hele belastningen rammer, og kunden får et stop, hvis noget driller. Det samme svar kan lægges ind i jeres arkitekturbeskrivelse på tre sider, så det ikke skal skrives fra bunden hver gang.
Når svaret er nej
Nogle gange viser målingerne, at produktet ikke kan bære kunden i dag. Så er der tre ærlige muligheder: en plan med en realistisk dato, en mindre udrulning nu, eller et nej tak til en del af aftalen. Hvilken der er rigtig, afhænger af, hvad arbejdet fortrænger. En kunde, der kræver en ombygning af kernen, kan fylde mere i køreplanen, end omsætningen tilsiger, og det er en ledelsesbeslutning, se én stor kunde vil bestemme køreplanen.
Lov aldrig en dato, som teamet ikke selv har været med til at sætte. En forsinket skalering opdages dagen, hvor kunden går i luften, og det er den dyreste dag at opdage noget på.
Hvem skal svare
Svaret skal skrives af den, der ejer arkitekturen, og godkendes af den, der ejer kunderelationen. Lad det ikke ligge hos en enkelt udvikler som en mail sendt i farten. Gem svaret, for det samme spørgsmål kommer igen. Sælgeren skal kende hovedlinjen og vide, hvornår spørgsmålet skal sendes videre.
Det skal I lade være med
· At sige ja, før nogen har spurgt, hvad “ti gange” dækker over.
· At henvise til, at cloud skalerer af sig selv. Databasen og jeres egen kode gør det ikke uden videre.
· At teste med tomme databaser.
· At skjule en kendt grænse, kunden alligevel vil støde på.
Det skal I kræve af den eksterne
- ☐ Et overblik over målt belastning og vækst.
- ☐ En belastningstest med en klar konklusion om første flaskehals.
- ☐ Et skriftligt standardsvar på skalerbarhed, som salget kan bruge.
- ☐ En vurdering af, hvilke grænser der kræver køreplan frem for indkøb.
- ☐ En anbefaling, ledelsen kan forstå, når en kunde ligger ud over det testede.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Produktet er blevet langsomt · Kundens IT-arkitekt vil have et møde
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
