En SaaS abonnementsdatamodel

SaaS (Software as a Service) er en af de tre hovedkomponenter i cloud computing. Normalt er SaaS-applikationer webbaserede og kan håndtere mange forskellige brugere på én gang. Abonnementsbaserede løsninger er meget populære SaaS-tilbud. Nogle velkendte SaaS-produkter inkluderer Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe og (selvfølgelig) Vertabelo! I dag tager vi et kig på en datamodel, der ville give os mulighed for at administrere SaaS-abonnementer.

Idéen

SaaS-produkter kan være meget forskellige. Nogle opkræver løbende for deres ydelser, f.eks. månedligt eller årligt; andre opkræver kun for mængden af tid eller ressourcer, der bruges (eller en kombination af disse to). For at holde tingene enkle i denne artikel vil jeg kun fokusere på månedlige betalte abonnementer.

Lad os antage, at vi har et par forskellige SaaS-løsninger, og vi skal spore alle vores abonnenter i én database. Dette kan være tilfældet, når vi leverer databaseløsninger (f.eks. Amazon DynamoDB), analyseværktøjer (f.eks. Amazon Athena) eller robotapplikationer (f.eks. AWS RoboMaker). Faktisk, hvis vi ser på Amazon, kan vi se, at der er mange forskellige applikationer tilgængelige. Vi ville kun vælge dem, vi virkelig har brug for.

Datamodel

Modellen består af tre fagområder:

Users & groups
Software & plans
Subscriptions, plans & payments.

Vi vil beskrive hvert af disse emneområder i den rækkefølge, de er anført.

Afsnit 1:Brugere og grupper

Users & groups emneområdet gemmer oplysninger om alle brugere af vores applikation. Vi antager, at brugere kan grupperes, f.eks. når en virksomhed ønsker at købe licenser til flere medarbejdere. Vi opretter en gruppe, selvom kun én bruger tilhører den. Dette vil give os fleksibiliteten til senere at tilføje nye medlemmer til den gruppe.

Den vigtigste tabel her er user_account bord. Vi bruger det til at gemme alle detaljer relateret til brugerkonti. Disse er:

first_name & last_name – Brugerens for- og efternavn. Bemærk venligst, at hver bruger, der er gemt her, er en privatperson.
user_name – Et brugernavn (valgt af brugeren).
password – En hashværdi af brugerens adgangskode. (Brugerne indstiller deres egne adgangskoder.)
email – Brugerens e-mailadresse, angivet under registreringsprocessen.
confirmation_code – Den kode, der blev brugt under e-mailbekræftelsesprocessen.
confirmation_time – Når registreringen/bekræftelsen var gennemført.
insert_ts – Tidsstemplet, da denne post oprindeligt blev indsat.

Brugere kan oprette grupper; grupper har foruddefinerede typer. En liste over alle mulige gruppetyper er gemt i user_group_type bord. Hver type er UNIKT defineret af dens type_name . Vi definerer også det mindste og maksimale antal tilladte gruppemedlemmer for hver gruppetype. Dette område er defineret med to værdier – members_min (den nedre grænse) og members_max (den øvre grænse).

Mens du opretter en ny konto, vil brugerne også vælge deres brugergruppe. Dette vil oprette en ny post i user_group tabel, der refererer til den valgte gruppetype og gemmer tidsstemplet (insert_ts ), da denne post blev indsat. customer_invoice_data attribut er en tekstlig beskrivelse af, hvad vi udskriver på fakturaen for den pågældende brugergruppe.

Den sidste tabel i dette emneområde er in_group bord. For hver gruppe gemmer vi en liste over alle dens medlemmer. Udover referencer til brugergruppen (user_group_id ) og brugerkonto (user_account_id ), gemmer vi også tidsstemplet, når en bruger blev føjet til gruppen (time_added ) eller fjernet fra gruppen (time_removed , som kun vil indeholde en værdi, hvis brugeren er blevet fjernet). Vi har også et flag for at angive, om brugeren er group_admin eller ikke. Gruppeadministratorer kan opdatere gruppemedlemmer og tilføje nye medlemmer.

Afsnit 2:Software og planer

Dernæst skal vi definere alt, hvad vi vil tilbyde vores (potentielle) kunder. Vi tilbyder måske kun én type software, men der er stor mulighed for, at vi har flere forskellige tilbud. Et almindeligt eksempel på denne sag er at have et SaaS-værktøj, der er adskilt fra dets analyseapplikation, f.eks. Stripe og Stripe Sigma. Vi vil dække sådanne tilfælde i vores datamodel.

Vi starter med software bord. I denne ordbog gemmer vi en liste over alle vores SaaS-tilbud. For hver enkelt gemmer vi:

software_name – ET UNIKT softwarenavn.
details – Alle detaljerne, der beskriver den software.
access_link – En placering eller et link, hvor vi kan få adgang til den software.

Vi bør kunne tilbyde vores SaaS-løsninger i en eller flere forskellige planer. Hver plan indeholder forskellige muligheder. For eksempel kunne vi have en premium-plan, der inkluderer alle de muligheder, vi tilbyder, og en grundlæggende plan, der kun inkluderer det væsentlige. Vi gemmer alle distinkte planer i plan bord. For hver plan definerer vi:

plan_name – Det navn, vi har valgt til denne plan. Sammen med referencen til softwaren (software_id ), dette danner den alternative/UNIKKE nøgle for denne tabel.
user_group_type_id – En reference, der angiver typen af den gruppe, der kan bruge denne plan. Dette kan være en enkeltbrugergruppe eller en standardgruppe. Denne reference definerer også det maksimale antal gruppemedlemmer for den plan – f.eks. hvis vores plan tillader fem forskellige konti på ét abonnement, bør vi henvise til den relevante user_group_type .
current_price – Den aktuelle pris for denne plan.
insert_ts – Tidsstemplet, da denne post blev indsat.
active – Et flag, der angiver, om denne plan er aktiv eller ej.

Vi har allerede nævnt, at planer for den samme software kommer med forskellige muligheder. En liste over alle distinkte muligheder er gemt i option ordbog. Hver valgmulighed er UNIKT defineret af dens option_name .

For at tildele muligheder til forskellige planer bruger vi option_included bord. Den gemmer referencer til den relaterede plan (plan_id ) og mulighed (option_id ). Dette par sammen med date_added attribut, danner den UNIKKE nøgle i denne tabel. date_removed attribut vil kun indeholde en værdi, hvis vi besluttede at fjerne en bestemt mulighed fra en plan. Dette kan ske, når vi bygger en ny mulighed for at erstatte den gamle, eller vi beslutter ikke at have en given mulighed længere, fordi få mennesker bruger den.

Den sidste del af dette fagområde er relateret til særlige eller kampagnetilbud. Generelt giver sådanne tilbud kunderne mere service for færre penge og varer i en vis periode. De kunne være rettet mod at skaffe nye kunder eller sælge planopgraderinger (eller en bredere vifte af tjenester) til eksisterende kunder.

Alle vores kampagnetilbud er gemt i offer bord. For hvert tilbud skal vi definere:

offer_name – Et UNIKT navn, vi har valgt til dette tilbud.
offer_start_date og offer_end_date – Det tidsrum, hvor dette tilbud er tilgængeligt.
description – En detaljeret tekstbeskrivelse af tilbuddet.
Rabatter:Vi har brug for fleksibiliteten til at have to typer rabatter – en fast beløbsbaseret rabat (f.eks. få 50 USD i rabat) og en procentvis rabat (f.eks. spar 25 %). Hvis vi tilbyder en fast rabat, indsætter vi denne værdi i discount_amount attribut; hvis vi tilbyder en procentvis rabat, indsætter vi denne procent i discount_percentage attribut.
Varighed:Vi bruger den samme logik her, som vi har brugt til rabatterne. I nogle tilfælde vil tilbud vare i et defineret antal måneder (f.eks. i 24 måneder efter kundernes tilmelding); i disse tilfælde definerer vi duration_months værdi. Andre tilbud vil være gyldige indtil en bestemt fast dato (f.eks. indtil 31. december 2019); for disse definerer vi datoen og gemmer den i duration_end_date attribut.

Vi vil bruge de resterende to tabeller i dette emneområde til at definere, hvad hvert tilbud indeholder, og hvilke forudsætninger det har. Til dette formål bruger vi to tabeller:include og prerequisite . De deler den samme struktur og indeholder det samme UNIKKE par offer_id – plan_id . Nogle tilbud har måske ingen forudsætninger, mens andre kan – f.eks. hvis vi tilbyder en rabat for at opgradere til en plan med flere brugere eller et softwareabonnement for brugere af anden software.

Tilbud kan være komplekse, så jeg vil give et par eksempler.

Hvis vi i øjeblikket bruger plan A og har et tilbud om at opgradere til plan B, er dette ligetil.
Hvis vi har to tilbud, "Plan A opgraderer til Plan B" og "Plan B opgraderer til Plan C", bør vi oprette et tilbud mere:"Plan A opgraderer direkte til Plan C". Dette giver brugerne mulighed for at opgradere deres planer i et trin i stedet for to. Et eksempel på en sådan opgradering er at ændre et abonnement, der i øjeblikket tillader fem brugere pr. gruppe til et, der tillader 20 brugere pr. gruppe uden at stoppe ved en mellemliggende plan med ti brugere pr. gruppe undervejs.
Hvis en gruppe bruger produkt A, kan vi have et særligt tilbud om at abonnere på produkter B og C til en kampagnepris. Vi kunne også have to separate tilbud om kun at abonnere på produkt B og kun på produkt C.

Generelt bør vi have ét tilbud, der vil ændre den nuværende plan til den ønskede plan uden nogen trin imellem og kun et tilbud om at abonnere på et eller flere nye produkter.

Afsnit 3:Abonnementer, planer og betalinger

Det sidste emneområde forbinder de to tidligere nævnte områder og er det sande hjerte i denne model.

Alle abonnementer gemmes i subscription bord. Vi behandler hvert enkelt abonnement som et separat abonnement, selvom disse abonnementer/planer er resultatet af det samme tilbud. Grunden til dette er, at vi vil kunne administrere abonnementer separat - f.eks. annullere dem separat, hvis vi ønskede det. Vi bliver nødt til at definere en række detaljer her:

user_group_id – ID'et for den gruppe, der abonnerer på denne plan. Dette er vigtigt, fordi brugere ikke abonneres individuelt; de tegnes indirekte, som en del af gruppen.
trial_period_start_date og trial_period_end_date – De nedre og øvre grænser for prøveperioden (hvis nogen) for dette abonnement.
subscribe_after_trial – Et flag, der angiver, om abonnementet automatisk vil blive fornyet efter prøveperioden (hvis nogen) slutter.
current_plan_id – Den nuværende plan for det abonnement. Hvis abonnementet ikke længere er aktivt, vil denne attribut indeholde værdien af den sidste aktive plan.
offer_id – En henvisning til det tilbud, som dette abonnement er relateret til. Denne attribut vil kun indeholde en værdi, hvis dette abonnement var resultatet af et bestemt tilbud.
offer_start_date og offer_end_date – Den nedre og øvre grænse for den periode, hvor dette tilbud var aktivt. Disse attributter vil kun blive defineret, hvis dette abonnement var resultatet af et bestemt tilbud.
date_subscribed – Når denne gruppe abonnerer på dette abonnement.
valid_to – Sidste dato for dette abonnement er gyldigt. I tilfælde af et månedligt abonnement kan vi forvente, at valid_to indstilles til slutningen af den aktuelle måned. Hvis en kunde afmelder sig på et hvilket som helst tidspunkt i løbet af en måned, vil de stadig kunne bruge deres software indtil udgangen af den måned.
date_unsubscribed – Datoen, hvor den pågældende gruppe afmeldte sig fra dette abonnement. Vi kan forvente, at denne dato vil blive sat manuelt af gruppeadministratoren, når gruppen beslutter sig for ikke at bruge tjenesten længere. Det kunne dog også indstilles automatisk, efter foruddefinerede kriterier – f.eks. automatisk afmelding af en gruppe fra deres tjeneste, hvis der er to eller flere ubetalte fakturaer.
insert_ts – Tidsstemplet, da denne post blev indsat.

Abonnementsplaner ændrer sig ofte over tid. For at opretholde en komplet historik over alle vores planer gemmer vi alle planændringer i plan_history bord. For hver post her skal vi bruge en:

subscription_id – ID'et for det relaterede abonnement.
plan_id – ID'et for den relaterede plan.
date_start og date_end – Det tidsrum, hvor denne plan var aktiv.
insert_ts – Tidsstemplet, da denne post blev indsat.

Den sidste tabel i vores model gemmer vores invoices . For hver faktura gemmer vi følgende oplysninger:

customer_invoice_data – En beskrivelse af den kunde, der er faktureret for denne faktura. Dette vil være dataene fra user_group.customer_invoice_data i det øjeblik, hvor fakturaen blev genereret.
subscription_id – ID'et for det relaterede abonnement.
plan_history_id – ID'et for den plan, der er aktiv i denne fakturaperiode.
invoice_period_start_date og invoice_period_end_date – Tidsintervallet (f.eks. 1. januar 2019 til 31. januar 2019), der er dækket af denne faktura.
invoice_description – En kort tekstbeskrivelse af fakturaen.
invoice_amount – Betalingsbeløbet for denne faktura.
invoice_created_ts – Når denne faktura blev genereret og indsat i tabellen.
invoice_due_ts – Når denne faktura forfalder.
invoice_paid_ts – Tidsstemplet for, hvornår denne faktura blev betalt.

Fortæl os, hvad du synes om SaaS-datamodellen

Jeg gætter på, at de fleste af jer har mødt SaaS, enten som udvikler eller som bruger. Jeg ser frem til dit syn på det og på denne datamodel. Del gerne dine erfaringer og forslag i kommentarerne nedenfor.