Her beskriver vi de vigtigste tekniske beslutninger bag løsningen. For hver beslutning skriver vi, hvad vi valgte, hvorfor, og hvad det betyder. Siden er til udviklere og andre tekniske læsere.
Vi arbejder sammen som et team og bruger mange iterationer, så løsningen passer til mange slags foreninger, organisationer, fællesskaber, fagforeninger og virksomheder. Det er teamet, der tager beslutningerne.
Vi skriver beslutningerne i formatet MADR. Beslutningerne her er skrevet bagefter. Fra nu af skriver vi en beslutning, hver gang vi tager en stor teknisk beslutning.
Siden nævner med vilje ikke servernavne, adresser, versioner af det, vi kører i dag, eller andre interne detaljer. Det gør vi for at beskytte løsningen.
Når vi bygger selv, får vi tre ting:
- Mere kontrol over data: hvor de gemmes og behandles, og hvem der har adgang.
- Kontrol over vores egne udgifter. Vi betaler ikke en anden udbyder pr. bruger eller pr. mængde, og vi undgår prisstigninger, som vi ikke selv bestemmer.
- Vi bliver ikke bremset af en anden udbyders begrænsninger eller tidsplan, så vi kan udvikle hurtigere.
Til gengæld skal vi selv bygge og vedligeholde løsningen.
| Nr. | Beslutning |
|---|---|
| 0001 | Én database pr. kunde og hver forening adskilt i databasen |
| 0002 | Vores servere hos Hetzner i Tyskland |
| 0003 | Webappen på moderne .NET og en fuld opgradering af backend |
| 0004 | Blazor WebAssembly og Blazor Server med Fluxor til tilstand |
| 0005 | Modulær monolit med testede grænser |
| 0006 | Vores egen beskyttelsesmur |
| 0007 | Vores eget system til logning |
| 0008 | Én kodebase til mobilappen, hvor hver forening får sit eget område |
| 0009 | AI-udbyder vælges pr. funktion med vores egne Qwen-modeller som standard |
| 0010 | White label gennem opsætning og ikke egen kode |
| 0012 | Funktioner og moduler, der slås til og fra, mens løsningen kører |
| 0013 | Hosting i tre niveauer: delt, isoleret og dedikeret |
| 0014 | Certificeringsmodulet er bygget af os selv |
| 0015 | Driftsplatformen er ét sted for kundernes livsforløb og opsætning |
| 0016 | Vores egen mailserver til e-mail fra løsningen |
| 0017 | Egne DNS-navneservere gennem NordName |
| 0018 | Vores egen generator til vejledninger til vores partnere |
Numrene følger vores egen liste, og vi bruger aldrig et nummer igen. Derfor kan der mangle et nummer.
0001 Én database pr. kunde og hver forening adskilt i databasen
Status: Vedtaget.
Kontekst
Løsningen har mange kunder. Nogle er små foreninger. Andre er store organisationer og forbund, som vil have deres data holdt adskilt fra andres. En kunde kan rumme mange foreninger, afdelinger eller små organisationer. En bruger kan være medlem af flere foreninger. Fra starten har data i databasen hørt til en bestemt forening.
Beslutning
Vi besluttede, at kunderne på MinOrganisation skal være isoleret fra hinanden. Hver kunde (tenant) får sin egen database. Derefter fik den første kunde sin egen database. Inde i databasen hører næsten alle data til én bestemt forening. API’et kontrollerer ved hver forespørgsel, at brugeren kun får data fra de foreninger, brugeren har ret til. MinForening er selv én kunde. Her deler mange foreninger én database.
API’et finder kunden ud fra adressen ved hver forespørgsel. Adressen er et underdomæne eller kundens eget domæne. Derefter bruger API’et kundens egen database og kundens eget område til filer. Baggrundsjob kører også for den rigtige kunde. En ny white label-kunde får sin egen database, når vi sætter kunden op. Foreningerne på MinForening deler servere, og en kunde på MinOrganisation kan få sin egen cloudserver som tilvalg. En white label-kunde har sin egen cloudserver hos Hetzner Cloud (se beslutning 0013).
Begrundelse
- Kunderne får mere kontrol over deres data og over deres egne afdelinger.
- En database pr. kunde giver sikkerhed og privatliv, og den gør det muligt at tilpasse løsningen til hver organisation.
- Hver forespørgsel arbejder kun i én kundes database.
- Små foreninger deler database for at holde prisen nede. Det er en afvejning mellem isolation og pris.
Konsekvenser
- Godt: En kundes data ligger i sin egen database, adskilt fra andre kunders data.
- Godt: En forening eller organisation kan flytte til et højere niveau af hosting.
- Godt: Et medlem kan få et udtræk af sine data fra en bestemt forening.
- Ulempe: En ændring af databasens opbygning skal rulles ud til hver kundes database for sig. Før ændringen tjekker vi, at det er den rigtige database.
- Ulempe: På MinForening sker adskillelsen mellem foreninger i API’et og ikke i databasen.
Se også beslutning 0013 og Arkitekturoverblik, afsnittet Flere kunder i samme løsning.
0002 Vores servere hos Hetzner i Tyskland
Status: Vedtaget.
Kontekst
Løsningen skal køre på servere et sted. Vi ville have en udbyder, som bruger grøn strøm og genbruger hardware. Udbyderen skulle også være underlagt EU’s love og have en professionel support.
Beslutning
Løsningens produktionsservere står i Hetzners datacentre i Tyskland. Vi driver selv serverne. Hetzner Online GmbH er et tysk firma. En white label-kunde får sin egen server hos Hetzner Cloud. Den server driver vi også.
Begrundelse
- Grøn strøm. Ifølge Hetzner har datacentrene i Tyskland i mange år brugt strøm fra bæredygtige kilder. Hetzner skriver, at de kun vil dække behovet for strøm med vedvarende energi.
- Genbrug af hardware. Ifølge Hetzner bruger de deres servere i gennemsnit i otte år. Med Hetzners serverauktion kan hardwaren bruges længere. Ellers bliver de enkelte dele genbrugt eller genanvendt.
- Europæisk lov. Serverne står i Tyskland og er underlagt EU’s love. Ifølge Hetzner får kun tyske myndigheder med en gyldig tysk retskendelse adgang til datacentrene.
- Professionel support. Ifølge Hetzner kan kunderne få fat i deres teknikere i datacentrene døgnet rundt.
Konsekvenser
- Godt: Hetzners hostingtjenester og datacentre er certificeret efter ISO/IEC 27001.
- Ulempe: Hetzner står for hardwaren, men vi skal selv drive og overvåge serverne fra styresystemet og op, eller betale Hetzner for at hjælpe os med det. Til driften har vi vores egen beskyttelsesmur og vores egen logning (beslutning 0006 og 0007).
- Neutralt: Nogle AI-funktioner bruger eksterne udbydere (beslutning 0009).
Hvem gør hvad
Hetzner står for datacentrene, hardwaren, netværket og beskyttelsen mod DDoS-angreb. Vi driver selv serverne fra styresystemet og op. Hetzners del bygger på det, Hetzner selv skriver.
| Lag | Hvem | Hvad |
|---|---|---|
| Apps og data | Wiiandi Group | Webappen, API’et og kalenderen, databaserne, vores beskyttelsesmur og certifikaterne. Sikkerhedskopier, som vi gemmer i 30 dage, med en ekstra kopi på vores eget udstyr i Danmark. Overvågning døgnet rundt og vores egen logning. |
| Styresystem | Wiiandi Group | Drift af serverne og opdatering hver måned. Microsoft Defender for Endpoint, som overvåger serverne. Reglerne i Hetzners firewall. |
| Hardware og netværk | Hetzner | Serverne og netværket. Ifølge Hetzner er udskiftning af defekt hardware gratis for deres dedikerede servere. Beskyttelse mod overbelastningsangreb (DDoS). Firewallen i Hetzners netværk. |
| Datacenter | Hetzner | Bygninger med sikringshegn, videoovervågning og adgangskontrol, der logger alle adgange. Nødstrøm, to separate strømveje og grøn strøm. Tidlig branddetektering. |
Se også beslutning 0013 og 0017 og Drift og sikkerhed, afsnittet Hvor data ligger.
0003 Webappen på moderne .NET og en fuld opgradering af backend
Status: Vedtaget.
Kontekst
Backend er de dele af løsningen, der kører på serveren, for eksempel API’et. Backend har længe været bygget på en ældre udgave af .NET. Før Blazor havde vi en webapp i React. Senere begyndte vi på en ny webapp i Blazor, som kræver moderne .NET.
Beslutning
Vi bygger webappen med Blazor på moderne .NET. Vi ventede med at opgradere nogle dele af backend. Vi ville først have flere funktioner i vores platforme. Vi har planlagt en fuld opgradering af backend til .NET 10, og vi forbereder allerede koden til skiftet.
Et modul er delt i en serverdel, en klientdel og fælles modeller. De fælles modeller ligger i biblioteker, som både API’et og webappen kan bruge.
Begrundelse
- Med Blazor skriver vi både webappen og API’et i C#.
- Microsoft udgiver moderne .NET i udgaver med langtidssupport. De får sikkerhedsopdateringer i tre år.
- Moderne .NET er hurtigere. Vi forventer, at backend bliver meget hurtigere efter opgraderingen.
- Moderne .NET kører på servere med både Windows og Linux.
- Den samme .NET bruges i webappen (Blazor WebAssembly), i desktopappen og i mobilappen (.NET for Android og .NET for iOS).
- Blazor kan lave den første visning af siderne på serveren, og det gør siderne hurtige.
Konsekvenser
- Godt: Webappen og API’et bruger de samme modeller til forespørgsler og svar. Så kan de ikke komme ud af trit med hinanden.
- Ulempe: Indtil opgraderingen skal vi vedligeholde og bygge på to .NET-platforme. Fælles kode skal virke på dem begge.
Mobilappen: fra Xamarin til moderne .NET
Mobilappen er også bygget i C# og .NET (se beslutning 0008). Fra starten byggede vi den med Xamarin.Android og Xamarin.iOS. Med dem taler vores C#-kode direkte med Android og iOS gennem platformenes egne funktioner. Brugerfladen, altså de sider og knapper man ser og trykker på i appen, er lavet for hver platform med platformens egne værktøjer. På iPhone bruger vi Apples filer til appens sider (XIB og storyboards), og på Android bruger vi Androids layoutfiler.
Oven på det bruger vi open source-biblioteket MvvmCross. Det deler logikken bag appens sider mellem Android og iOS. Hver side har en fælles del med logik og data (en view model) og en del for hver platform, som viser siden. Den fælles kode taler også med API’et.
En app i C# kan ikke tale med telefonens eget system uden en bro, som også kaldes en binding. Broen oversætter mellem vores C#-kode og Android eller iOS. De fleste broer, vi bruger, kommer fra Microsoft og følger med .NET. Nogle funktioner bruger færdige broer fra andre. Nogle funktioner, for eksempel push-beskeder og tilladelser, ligger i små C#-biblioteker med én udgave til Android og én til iOS. Vi havde kun lavet én bro selv. Den åbnede MobilePay fra appen, og vi stoppede med at bruge den før flytningen.
Mange apps havde svært ved at flytte fra Xamarin til moderne .NET. Apps, der havde lavet brugerfladen med Xamarin.Forms, skulle flytte den til .NET MAUI. Ifølge Microsoft skal særlige tilpasninger af brugerfladen (custom renderers) opdateres, og pakker til Xamarin.Forms virker som regel ikke med moderne .NET, før de er bygget om. Brugerfladen kan også opføre sig anderledes efter flytningen. Mange apps byggede desuden på broer og tillægsprogrammer, som skulle laves om eller skiftes ud.
For os var flytningen lettere. Xamarin.Android og Xamarin.iOS blev til .NET for Android og .NET for iOS med de samme funktioner fra platformene. Ifølge Microsoft skal de fleste af den slags projekter ikke skrives om. Vi kunne beholde appens sider til iPhone og Android og vores opbygning med MvvmCross, og vi havde ingen custom renderers at opdatere. Det, der ændrede sig, var projektfilerne og den måde, appen bliver bygget på. Vi brugte enkelte dele af Xamarin.Forms og Xamarin.Essentials til hjælpefunktioner, men ingen sider. De fleste af dem udskiftede vi med de tilsvarende dele i .NET. Vi skiftede også nogle få biblioteker ud, for eksempel til push-beskeder på iPhone og til at vise billeder. Det meste af vores egen kode blev, som den var, men vi skulle tilpasse koden nogle steder. Det er lidt som at flytte, når møblerne allerede passer i standardkasser. Flytningen tog omkring et halvt år.
I dag viser appen også nogle sider med Blazor-komponenter fra webappen. Dem viser appen gennem .NET MAUI (se beslutning 0004).
Se også beslutning 0004, 0005 og 0008.
0004 Blazor WebAssembly og Blazor Server med Fluxor til tilstand
Status: Vedtaget.
Kontekst
Webappen har mange moduler og mange sider. Siderne deler data, for eksempel den valgte forening og den bruger, der er logget ind. Siderne skal vises hurtigt, også første gang. Først var webappen en app i React, som viste moduler bygget i Blazor. Senere gik webappen helt over til Blazor.
Beslutning
Webappen kører i browseren med Blazor WebAssembly. Data, som flere sider deler, styrer vi med biblioteket Fluxor. En side sender en handling, og den fælles tilstand bliver opdateret ét sted. I dag kører Blazor også på serveren (Blazor Server). Når en side åbnes, laver serveren den første visning, så siden kommer hurtigt frem. Derefter overtager appen i browseren (Blazor WebAssembly). Mange komponenter bruger vi både i webappen, i desktopappen og i mobilappen.
Begrundelse
- Vi ville beholde den styring af tilstand og de mønstre, som vi havde i React.
- Det gør løsningen fleksibel til white label. Vi kan ændre design og brugeroplevelse uden at ødelægge styringen af tilstand og vores klientbiblioteker.
- Vi kan genbruge mange komponenter i mobilappen, fordi .NET MAUI kan vise Blazor-komponenter. Så udvikler vi én komponent, som virker i mobilappen, i desktopappen (i dag til Windows) og i browseren. Det kan for eksempel være Edge, Chrome eller Firefox.
- Når serveren laver den første visning, kommer den første side hurtigt frem.
- Søgemaskiner kan læse de sider, som serveren laver.
Konsekvenser
- Godt: Brugeren ser hurtigt indhold, og appen kører derefter i browseren.
- Godt: Mange komponenter skal kun udvikles én gang til webappen, desktopappen og mobilappen.
- Ulempe: Første besøg skal hente WebAssembly-delen. Det tager tid på en langsom forbindelse. Vi er ved at indføre en løsning, hvor appen kun henter de dele, der skal bruges med det samme, og henter resten i baggrunden. Så bliver første besøg hurtigere.
- Ulempe: Hver funktion kræver ekstra kode til handlinger og tilstand. Serveren skal også kende tilstanden, når den laver den første visning.
Se også beslutning 0003 og 0010.
0005 Modulær monolit med testede grænser
Status: Vedtaget.
Kontekst
Løsningen har mange funktioner, og foreningerne slår dem til og fra. Flere udviklere arbejder i koden på samme tid. Vi skulle vælge, hvordan koden skulle bygges op. Vi havde tre muligheder: én samlet app uden faste dele, mange små tjenester, der kører hver for sig (mikrotjenester), eller en mellemvej.
Beslutning
Vi valgte en mellemvej: en modulær monolit. En monolit er én samlet løsning, som vi bygger og sætter i drift som én enhed. Modulær betyder, at koden er delt i moduler. Et modul er en afgrænset del af løsningen med sit eget ansvar, for eksempel aktiviteter, betalinger eller chat. Små moduler kan sættes sammen til større moduler.
Hvert modul har en grænse. Modulet har en offentlig del og en privat del. Den offentlige del kalder vi kontrakten. Kontrakten beskriver, hvad andre dele af løsningen må bruge, for eksempel hvilke data modulet tager imod og sender tilbage. Den private del er modulets egen kode. Den må andre moduler ikke bruge direkte. Så kan vi ændre den private del uden at ødelægge andre moduler.
Et modul er som regel delt i flere dele: en del, der kører på serveren, en del, som brugerfladen bruger til at tale med serveren, og de fælles datamodeller, som begge sider bruger. Brugerfladen må kun bruge kontrakten. Den må aldrig bruge serverens kode eller databasen direkte.
Reglerne står som kode. Automatiske arkitekturtest og automatisk kodeanalyse tjekker en stor del af dem. Nogle regler bliver tjekket, allerede når koden bliver bygget. Testene kører automatisk, hver gang en ændring bliver foreslået til eller lagt ind i den fælles kode. De tjekker blandt andet, at brugerfladen ikke afhænger af serverens kode, at kodens tjenester ikke afhænger af hinanden i ring, og at API’et går gennem modulernes egne tjenester og ikke direkte til databasen.
Hvilke moduler en forening har, styrer vi med funktionskontakter og modulshoppen (se beslutning 0012). Alle brands bruger de samme moduler (se beslutning 0010).
Begrundelse
- En ændring i ét modul giver færre bivirkninger i resten af løsningen. Derfor kan vi ændre hurtigere.
- Flere udviklere kan arbejde i hver sit modul på samme tid.
- Vi bygger, tester og udgiver én løsning. Med én database pr. kunde er driften enklere end med mange små tjenester (se beslutning 0001).
- Det koster mindre end mikrotjenester. Fordi modulerne har klare grænser, kan vi senere flytte et modul ud i sin egen tjeneste, hvis der bliver brug for det.
- Reglerne står som kode og ikke kun i et dokument. Derfor opdager testene det hurtigt, hvis koden bryder reglerne.
Konsekvenser
- Godt: Vi bygger og driver én samlet løsning, men koden har klare grænser.
- Godt: Det samme modul kan bruges af alle brands og slås til og fra for hver forening.
- Godt: Hvert modul har sin egen beskrivelse, så en ny udvikler hurtigere kan finde rundt.
- Ulempe: Kodebasen er stor, og vi skal hele tiden holde orden i den. Det kræver disciplin at holde grænserne.
- Ulempe: Det tager tid at bygge og teste hele løsningen, også når vi kun har ændret ét modul.
- Ulempe: Det tog længere tid at komme i gang end med en almindelig monolit uden moduler.
- Ulempe: Modulerne hos en kunde deler kundens database. Grænserne ligger i koden og ikke i databasen.
Se også beslutning 0001, 0010 og 0012 og Test og kvalitet.
0006 Vores egen beskyttelsesmur
Status: Vedtaget.
Kontekst
Webappen, API’et og kalenderen skal beskyttes mod angreb fra internettet. Vi ville ikke bygge den samme beskyttelse ind i hver app. Vi kunne bruge en løsning fra en anden udbyder eller bygge vores egen.
Beslutning
Vi har udviklet vores egen beskyttelsesmur (en webapplikationsfirewall). Først designede vi beskyttelsesmuren, og derefter satte vi den helt i drift. Den står foran webappen, API’et og kalenderen. Den blokerer kendte typer af angreb og begrænser antallet af forespørgsler. Den kan bede mistænkelige klienter bevise, at de ikke er robotter, og den kan blokere efter land. Den sørger også for krypteret forbindelse med automatiske certifikater.
Begrundelse
- Vi har kontrol over vores data.
- Andre løsninger forhindrede os nogle gange i at få de data, vi skulle bruge for at forbedre sikkerheden.
- Vi har fuld kontrol over, hvor vores data bliver behandlet og gemt.
- Det er lettere at overholde reglerne for logs.
- Vi kan også tilbyde løsningen til andre kunder.
- Beskyttelsen ligger ét sted foran alle apps. Hver app skal ikke bygge den selv.
Konsekvenser
- Godt: Beskyttelsesmuren kører i Hetzners datacentre i Tyskland foran app-serverne.
- Godt: Vi har kontrol over, hvor data om trafikken bliver behandlet (se indledningen).
- Ulempe: Vi skal selv vedligeholde beskyttelsesmuren og følge med i nye typer af angreb.
Vi offentliggør ikke regler, grænseværdier eller trafikkens vej. Se Arkitekturoverblik, afsnittet Hvor beskyttelsesmuren sidder.
0007 Vores eget system til logning
Status: Vedtaget.
Kontekst
Vores medarbejdere skal kunne opdage og løse problemer i platformens tjenester. Vi kunne bruge en logtjeneste fra en anden udbyder eller bygge vores eget system.
Beslutning
Vi har vores eget interne system til driftslogs. Det samler tekniske logs fra platformens tjenester, så vores medarbejdere kan opdage og løse problemer. Først designede vi systemet og afprøvede det med prototyper. Derefter satte vi det helt i drift.
Begrundelse
- Vi har kontrol over vores logs og fuld kontrol over, hvor de bliver behandlet og gemt.
- Andre løsninger forhindrede os nogle gange i at få de data, vi skulle bruge for at forbedre sikkerheden.
- Det er lettere at overholde reglerne for logs.
- Det koster mindre, når der er store mængder logs.
- Vi kan også tilbyde systemet til andre kunder.
- Alle tekniske logs samles ét sted.
- Følsomme oplysninger bliver fjernet fra logs.
- Logs fra forskellige kunder holdes adskilt.
- Adgangen styres efter rolle, og hver adgang bliver logget.
- Logs gemmes kun i en begrænset periode.
Konsekvenser
- Godt: Medarbejderne finder tekniske logs ét sted.
- Godt: Vi holder vores udgifter nede, også når der er store mængder logs (se indledningen).
- Ulempe: Vi skal selv drive og vedligeholde systemet.
Se også beslutning 0006 og Arkitekturoverblik, afsnittet Niveau 2: Et kig ind i maskinrummet.
0008 Én kodebase til mobilappen, hvor hver forening får sit eget område
Status: Vedtaget.
Kontekst
Medlemmer, børn og unge og forældre bruger løsningen på telefonen. Appen skal findes til Android og iOS. Google og Apple stiller hvert år mange nye krav til apps.
Beslutning
Mobilappen har fra starten bygget på én fælles kodebase i C# og .NET. Kun det, der er særligt for Android eller iOS, ligger i egne projekter.
Alle foreninger i MinForening bruger den samme app. Hver forening får sit eget område i appen med sit eget logo og sine egne aktiviteter, opslag, beskeder og medlemmer. Er man medlem af flere foreninger, kan man skifte mellem dem i appen. Funktioner kan slås til for den enkelte forening (se beslutning 0012).
Samme kodebase kan også bygges som en selvstændig app med sit eget navn og ikon i App Store og Google Play, for eksempel til MinOrganisation og til white label-kunder. De første af disse apps byggede vi for nogle år siden. I dag sætter vi automatisk navn, app-id og adresser ind, når appen bygges. I dag er white label fuldt understøttet i mobilappen, og vi genbruger komponenter fra webappen og desktopappen.
MinOrganisation har sin egen app, som alle organisationer på MinOrganisation bruger. En white label-kunde får sin egen app og også sit eget API, sin egen database og sin egen server. White label købes gennem supporten hos MinOrganisation eller hos Wiiandi Group ApS.
Begrundelse
- Der kommer mange krav om opgraderinger fra Google og Apple hvert år. Med én kodebase skal vi for det meste kun opfylde kravene ét sted.
- En funktion bliver bygget én gang og virker på både Android og iOS.
- Foreningerne får hver deres eget område i den samme app. MinOrganisation har sin egen app, og white label-kunder får deres egen app fra den samme kode.
- Vi genbruger komponenter fra webappen og desktopappen.
Konsekvenser
- Godt: Alle foreninger og alle selvstændige apps får nye funktioner og rettelser fra den samme kode.
- Godt: Rettelser i den fælles kode, for eksempel for tilgængelighed, privatliv og sikkerhed, når alle apps på én gang.
- Ulempe: En selvstændig app er sin egen app i app-butikkerne. Den skal bygges og udgives for sig.
- Ulempe: Hver selvstændig app skal have sine egne oplysninger i app-butikkerne holdt opdateret: oplysninger om forhandleren, altså den virksomhed der står bag appen, efter EU’s regler (blandt andet forordningen om digitale tjenester), oplysninger om privatliv og et link til privatlivspolitikken.
- Neutralt: Vi arbejder efter kravene i EU’s tilgængelighedsdirektiv.
Se også beslutning 0003 (flytningen til moderne .NET) og 0010.
0009 AI-udbyder vælges pr. funktion med vores egne Qwen-modeller som standard
Status: Vedtaget.
Kontekst
Flere funktioner i løsningen bruger AI. Vi har arbejdet med AI i nogle år.
Vores første prototyper brugte Metas Llama-modeller. Deres dansk var ikke godt nok, og de var for langsomme. Derfor gik vi over til Microsoft Azure OpenAI. Men vi havde brug for mere kontrol over data og mere indsigt i, hvordan AI’en virker.
Vi havde fire krav til AI’en:
- Den skal skrive og forstå godt dansk.
- Den skal svare hurtigt.
- Vi skal selv have kontrol over data.
- Brugerne skal kunne se, når de bruger AI.
Gennem research fandt vi Qwen-modellerne. Qwen er sprogmodeller, som vi selv kan drive. Ifølge Qwen understøtter modellerne mange sprog, også dansk.
Beslutning
Vi byggede vores egen AI-tjeneste til Qwen-modellerne. Den har sin egen sikkerhed og logning. Vores egen AI-server står i vores kontor i Danmark.
Som standard bruger AI-funktionerne Qwen-modeller, som vi selv hoster. Microsoft Azure OpenAI i en EU-region bruges til nogle funktioner og som reserve. Claude fra Anthropic bruger vores udviklere kun internt, blandt andet til fejlrapporter. Kalenderrobotterne bruger Microsoft Azure OpenAI.
Siden om AI nævner udbyderen for hver funktion.
Begrundelse
- Vi har selv kontrol over data, når vi selv hoster modellerne.
- Vi kan se, hvordan AI’en virker, og vi bestemmer selv sikkerheden og logningen.
- Qwen-modellerne kan dansk, og vi kan selv drive dem.
- En organisation kan vælge en anden udbyder til nogle funktioner.
- En reserve holder funktionerne kørende, hvis vores egne modeller ikke er tilgængelige.
Konsekvenser
- Godt: Som standard bliver AI-opgaver løst af modeller, som vi selv hoster.
- Godt: Vi bestemmer selv, hvad vores AI-tjeneste logger og gemmer.
- Godt: For funktioner, der bruger vores egne modeller, har vi selv kontrol over, hvor data bliver behandlet (se indledningen).
- Ulempe: Vi skal selv drive, opdatere og overvåge modellerne og serveren.
- Ulempe: Udbyderen kan være forskellig fra funktion til funktion. Derfor nævner siden om AI udbyderen for hver funktion.
Sådan beskytter vi data
Vi bruger ikke jeres data til at træne AI-modeller. Det gælder også vores egne Qwen-modeller. Når funktionerne bruger Microsoft, må Microsoft efter sine vilkår ikke træne sine modeller på det, vi sender.
Vores egen AI-tjeneste tjekker, hvem der kalder den. Den logger hver forespørgsel, for eksempel tidspunkt, model og svartid. Som standard gemmer loggen ikke spørgsmål og svar.
Vi arbejder efter kravene i EU’s AI-forordning. I AI-assistenten i appen får brugeren at vide, at de chatter med et AI-system, og AI’ens svar er markeret som AI-genereret. Miniprofil-AI bruger kun et medlems data, hvis medlemmet har sagt ja.
Se også AI i løsningen og Arkitekturoverblik, afsnittet AI i løsningen.
0010 White label: samme kode til alle brands, og forskellen ligger i opsætningen
Status: Vedtaget.
Kontekst
Nogle kunder vil have løsningen under deres eget navn. Det kalder man white label. Kunden vil have sit eget navn, logo, domæne og app.
Mange leverandører laver white label ved at kopiere koden for hver kunde. Sådan en kopi kaldes en fork. Hver kopi lever derefter sit eget liv. En fejl skal rettes i hver kopi for sig, og hver kopi skal opdateres for sig. Jo flere kunder, jo flere kopier skal vedligeholdes.
Beslutning
Vi kopierer ikke koden. Alle brands kører præcis den samme kode og den samme byggede udgave af løsningen. Forskellen ligger i opsætningen, altså de indstillinger, som hver installation har.
Opsætningen dækker:
- Navn, logo og farver. Vi sætter brandets logo, ikonet i browserens fane og farverne i en editor til branding. Mobilappens farver sættes samme sted. Ændringerne virker uden en ny udgivelse.
- Adresser. Hver installation af webappen har sin egen opsætning med navn, logo og adressen på det API, den taler med.
- Database og server. Hver white label-kunde har sin egen database og sin egen cloudserver (se beslutning 0001 og 0013).
- Moduler. Moduler og funktioner slås til og fra for hver forening, organisationstype og brand (se beslutning 0012).
- Sprog. Vi vælger, hvilke sprog brugerne kan vælge imellem: for hele kunden, for et land eller for én forening. Er intet valgt, vælger løsningen sproget ud fra domænet, for eksempel dansk på et .dk-domæne.
- E-mail. Hver kunde kan have sin egen opsætning af e-mail fra løsningen, også afsenderadressen.
- Mobilapp. Når vi bygger en selvstændig app, sætter vi navn, app-id og adresser ind automatisk (se beslutning 0008).
Et nyt brand bliver sat op af et skript i faste trin. Skriptet opretter domænenavnet og databasen og bringer databasen op på den nyeste version. Det lægger den samme byggede udgave af løsningen på serveren og skriver opsætningen. Derefter tjekker det, at løsningen svarer, og opretter den første organisation. Skriptet har sine egne automatiske test.
Begrundelse
- Med en kopi for hver kunde skal hver rettelse laves mange gange. Det bliver dyrere og langsommere for hver ny kunde.
- Når alle kører den samme kode, når en rettelse eller en ny funktion alle brands på én gang.
- Kunderne skal stadig kunne få deres eget brand, deres egne data og deres egne moduler.
Konsekvenser
- Godt: Vi vedligeholder én kodebase, uanset hvor mange brands der er.
- Godt: Navn, logo og farver kan ændres uden en ny udgivelse.
- Godt: Et nyt brand bliver sat op i de samme faste trin hver gang.
- Ulempe: Det tog tid at bygge den motor, som opsætningen bygger på.
- Ulempe: En ændring i koden skal virke for alle brands på én gang. Derfor tester vi grundigt, og arkitekturtests holder grænserne mellem modulerne (beslutning 0005).
- Ulempe: Et ønske, som opsætningen ikke dækker, kræver en ændring i den fælles kode.
Se også beslutning 0001, 0005, 0008, 0012, 0013 og 0015, White label og Test og kvalitet.
0012 Funktioner og moduler, der slås til og fra, mens løsningen kører
Status: Vedtaget.
Kontekst
Løsningen har flere platforme: MinForening, MinOrganisation og white label. Kunderne har brug for forskellige funktioner. Vi vil ikke have en kodebase for hver platform.
Beslutning
Løsningen har én kodebase med funktionskontakter (feature flags) for hver platform. En kontakt kan gælde en forening, en bruger eller en organisationstype. Foreninger kan købe moduler i modulshoppen. Et modul kan også være sponsoreret eller være med som standard. API’et tjekker kontakten, før et moduls funktioner svarer. En ændring virker, mens løsningen kører. Vi skal ikke lave en ny udgivelse. Webappen og mobilappen henter også ændringerne, mens de kører.
Begrundelse
- Vi har én kodebase med funktionskontakter for hver platform.
- Vi kan slå funktioner og moduler til og fra for hver kunde.
- Vi kan slå en funktion til eller fra, mens løsningen kører.
Konsekvenser
- Godt: Vi kan slå en ny funktion til for nogle få foreninger først.
- Godt: En forening får kun de moduler, den har valgt.
- Ulempe: Koden skal tjekke kontakterne mange steder, både i API’et og i appene.
Se også beslutning 0005 og 0010.
0013 Hosting i tre niveauer: delt, isoleret og dedikeret
Status: Vedtaget.
Kontekst
Vores kunder har forskellige behov. En lille forening vil have en lav pris. En stor organisation vil have sine data mere adskilt fra andres.
Beslutning
Vi tilbyder tre niveauer af hosting. Delt er MinForening. Her deler foreningerne servere og database, og hver forening er adskilt inde i databasen. Isoleret er MinOrganisation. Her har hver organisation sin egen database (se beslutning 0001). Dedikeret er white label. Her kører kunden adskilt på sin egen cloudserver hos Hetzner, og vi driver serveren. Andre kunder kan også få deres egen server. Nogle tjenester er fælles for alle kunder: overvågning, vores beskyttelsesmur og interne værktøjer til vores medarbejdere. Først byggede vi niveauerne hver for sig. Derefter samlede vi dem i tre niveauer. I dag bliver en ny white label-server sat op automatisk.
Begrundelse
- Hvert niveau er en afvejning mellem isolation og sikkerhed på den ene side og pris på den anden.
- Kunden kan vælge det niveau, der passer til kundens behov.
Konsekvenser
- Godt: En forening eller organisation kan starte på et lavere niveau og senere flytte til white label.
- Ulempe: Flere databaser og servere giver mere drift og flere opdateringer.
Se også beslutning 0001, 0002 og 0010 og Arkitekturoverblik, afsnittet Hosting: delt, isoleret og dedikeret.
0014 Certificeringsmodulet er bygget af os selv
Status: Vedtaget.
Kontekst
Foreninger skal kunne holde styr på, at medlemmer har de rigtige kurser og prøver. Vi kunne bygge modulet selv eller bygge det på en anden udbyders tjeneste. Først lavede vi de første designs, og derefter byggede vi modulet.
Beslutning
Vi har selv bygget certificeringsmodulet. En forening opretter en certificering med en periode, frister og eventuelt et spørgeskema. Medlemmer bliver tildelt én ad gangen, efter gruppe eller automatisk, når de bliver medlem. Svarene får en procent for rigtige svar, og der er en grænse for at bestå. Medlemmer får invitationer på e-mail. Foreningen kan tillade, at et medlem, der ikke bestod, tager prøven igen. Modulet bruger løsningens egne rettigheder og grupper.
Begrundelse
- Et modul, der afhænger af en anden udbyder, kan holde op med at virke, hvis udbyderen stopper.
- Ansvaret er klart.
- Vi har kontrol over, hvad det koster at vedligeholde modulet.
- Data om medlemmer, også børn, skal være sikre.
- Modulet bruger løsningens egne rettigheder og grupper.
Konsekvenser
- Godt: Modulet virker sammen med resten af løsningen, for eksempel med grupper og organisationstyper.
- Godt: Vi har selv kontrol over data og pris, og vi skal ikke vente på, at en anden udbyder bygger det, vi har brug for.
- Ulempe: Vi skal selv bygge og vedligeholde alle dele af modulet.
Se også beslutning 0012.
0015 Driftsplatformen er ét sted for kundernes livsforløb og opsætning
Status: Vedtaget.
Kontekst
Vi skal oprette kunder, styre deres abonnement og opsætning og lukke dem igen. Det skal ske ét sted, og kun vores medarbejdere må gøre det.
Beslutning
Driftsplatformen er en intern platform, som kun vores medarbejdere bruger. Her styrer vi kundernes abonnement og opsætning ét sted. Kunder logger aldrig ind på den. Adgangen er begrænset, og den bliver logget.
Begrundelse
- Kundernes abonnement og opsætning styres ét sted.
- Driftsplatformen hjælper os med at overholde regler.
- Kun vores medarbejdere har adgang.
Konsekvenser
- Godt: Vi har selv kontrol over kundernes data (se indledningen).
- Godt: Adgangen er begrænset til vores medarbejdere, og den bliver logget.
- Ulempe: Vi skal selv drive og vedligeholde driftsplatformen.
Se også beslutning 0012 og 0013 og Platformens systemer.
0016 Vores egen mailserver til e-mail fra løsningen
Status: Vedtaget.
Kontekst
Løsningen sender mange e-mails, for eksempel invitationer og beskeder. Nogle e-mails nåede ikke frem til modtageren. Tit fik vi ikke den rigtige tekniske information om, hvorfor.
Beslutning
Vores mailserver har kørt i mange år. Den startede som en privat løsning hos et medlem af teamet, og dengang brugte ingen af vores nuværende kunder den. Siden har teammedlemmets enkeltmandsvirksomhed, derefter Softnotik ApS og i dag Wiiandi Group ApS drevet den.
E-mail fra løsningen sendes fra vores egen mailserver direkte til modtagernes mailservere. Vores medarbejdere bruger Microsoft 365 til deres e-mail, og e-mail, som brugere skriver til os, går gennem Microsoft 365.
Løsningen logger leveringen for hver modtager. Den læser beskederne om afviste e-mails fra vores mailserver og opdaterer loggen. En adresse, der bliver afvist permanent eller flere gange, bliver stoppet før næste udsendelse. Hvert domæne har sine egne nøgler til at signere e-mail (DKIM). Vi tillader ikke, at e-mail bliver sendt ukrypteret fra vores servere.
Begrundelse
- Vi vil have fuld kontrol over e-mail fra løsningen og information om problemer.
- Tit fik vi ikke den rigtige tekniske information om, hvorfor en e-mail ikke nåede frem.
Konsekvenser
- Godt: Vi kan se, hvad der skete med en e-mail til en bestemt modtager.
- Godt: Adresser, der ikke virker, bliver ikke ved med at få e-mail.
- Godt: Vi har selv kontrol over mailserveren og får selv informationen om problemer med leveringen (se indledningen).
- Godt: Mailserveren har et godt omdømme hos andre mailservere. Da vi senest tjekkede, stod den ikke på de kendte spamlister.
- Ulempe: Vi skal selv drive og vedligeholde mailserveren.
Se også Drift og sikkerhed, afsnittet Kryptering.
0017 Egne DNS-navneservere gennem NordName
Status: Vedtaget.
Kontekst
Når nogen åbner minforening.dk, skal domænenavnet først oversættes til den server, der skal svare. Det klarer DNS. En navneserver er den server, der giver svaret. Den fortæller, hvilken server et domænenavn peger på. For hvert af vores domæner er det registreret, hvilke navneservere domænet bruger.
Vi ville have kontrol over vores DNS. Vi ville også have en erfaren partner til at drive navneserverne.
Beslutning
Vi har vores egne DNS-navneservere, ns1.wiiandi.dk og ns2.wiiandi.dk. De administreres af NordName. minforening.dk, minorganisation.dk og wiiandi.dk bruger begge navneservere.
NordName er det finske firma C-Soft Oy. Firmaet har eksisteret i mange år. ICANN har akkrediteret NordName som registrator af domænenavne. Det kan ses på ICANN’s liste over akkrediterede registratorer. ICANN er den organisation, der koordinerer domænenavne i hele verden. En akkrediteret registrator skal følge ICANN’s regler for registrering af domæner. Registrene for blandt andet .eu, .se og .fi har også akkrediteret NordName.
ICANN beskriver også, hvad en registrator skal give os som indehaver af et domæne. Det gælder domæner, som ICANN står for, for eksempel .com. Se ICANN’s side om rettigheder og ansvar for indehavere af domæner. Blandt andet:
- Registreringen sker efter en aftale med en registrator, som ICANN har akkrediteret.
- Vi har ret til korrekte og tilgængelige oplysninger om registratorens vilkår og priser.
- Vi har ret til at vide, hvordan vi får support, og hvordan vi kan klage og løse uenigheder med registratoren.
- Registratoren må ikke bruge falsk reklame eller vildledende metoder over for os.
Vi har selv et ansvar. Vi skal følge registratorens vilkår, give korrekte kontaktoplysninger og holde dem opdaterede. Vi skal også svare på henvendelser fra registratoren inden for 15 dage.
Navneserverne bruger anycast. Det betyder, at de samme navneservere svarer fra servere i flere lande, også uden for EU. Serverne kører på NordNames anycast-netværk hos firmaet Rage4. DNS indeholder ingen oplysninger om medlemmer.
NordName har også et klimainitiativ, hvor de planter et træ for hvert domæne, der registreres hos dem eller flyttes til dem. Træerne plantes i Finland, Sverige, Danmark og Norge. Læs mere på NordNames side om initiativet.
Begrundelse
- Kontrol: Navneserverne har vores egne navne. Skifter vi udbyder, kan den nye udbyder overtage de samme to navne. Så skal vi kun ændre, hvor de to navne peger hen. Vi skal ikke ændre navneserverne for hvert domæne.
- EU: NordName er et europæisk firma i Finland. Ifølge NordNames privatlivspolitik følger de EU’s databeskyttelsesforordning (GDPR) og finsk lov.
- Erfaring og hjælp: NordName arbejder med domæner og DNS hver dag. Vi får hjælp til at drive navneserverne og står ikke alene med det.
- DNSSEC: NordName beskytter DNS med DNSSEC som standard. DNSSEC sætter en digital signatur på svarene fra DNS. Så kan man kontrollere, at et svar er ægte og ikke er ændret undervejs.
Konsekvenser
- Godt: Vi kan skifte udbyder uden at ændre navnene på vores navneservere.
- Godt: minforening.dk, minorganisation.dk og wiiandi.dk er signeret med DNSSEC.
- Godt: Ifølge NordName svarer den server, der er nærmest brugeren. Et angreb bliver fordelt over hele netværket. Det gør DNS mere robust.
- Ulempe: Vi afhænger af NordName for at holde navneserverne kørende.
- Ulempe: Nogle af serverne i anycast-netværket står uden for EU. De svarer kun på DNS-opslag og indeholder ingen oplysninger om medlemmer.
Se også beslutning 0002 og Drift og sikkerhed, afsnittet DNS.
0018 Vores egen generator til vejledninger til vores partnere
Status: Vedtaget.
Kontekst
Vores partnere skal kunne vise deres egne brugere, hvordan løsningen virker. Vejledninger med billeder af siderne bliver hurtigt forældede, når løsningen ændrer sig. Det tager lang tid at lave dem i hånden, og de skal findes på flere sprog.
Beslutning
Vi har bygget vores egen generator til vejledninger. For hvert modul beskriver vi trinene i de vigtigste opgaver, for eksempel at oprette en aktivitet. Generatoren går trinene igennem i en rigtig browser og tager billeder af siderne undervejs. Billederne viser, hvor man skal klikke. Derefter laver den vejledninger som PDF-filer til forskellige roller, på flere sprog, for eksempel dansk, engelsk og tysk. Vi starter selv generatoren, når vi har brug for nye vejledninger.
Vi har også et lille program, hvor vi vælger en forening eller organisation. Så kan vejledningens forside og billederne af siderne få dens logo.
Begrundelse
- Vi har bygget generatoren til vores partnere, så de kan give deres brugere gode vejledninger.
- De samme beskrivelser af trinene bruges også til automatiske test. Passer en beskrivelse ikke længere til løsningen, fejler testen, og så opdager vi det.
- Når løsningen ændrer sig, kan vi tage nye billeder af siderne og lave vejledningerne igen.
- Vejledningerne kan laves på flere sprog, og billederne af siderne er på samme sprog som teksten.
Konsekvenser
- Godt: En partner kan få vejledninger med sit eget logo.
- Godt: Vi bliver ikke bremset af en anden udbyders tidsplan (se indledningen).
- Ulempe: Vi skal selv vedligeholde beskrivelserne af trinene, når løsningen ændrer sig.
Se også beslutning 0010 og Test og kvalitet.